From jjg at openjdk.org  Thu Dec  1 00:53:23 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 1 Dec 2022 00:53:23 GMT
Subject: RFR: 8296710: Update to use jtreg 7.1
In-Reply-To: <4t-uTHoUVlflpzDnfuHO7TAnix7nNO1MGF28CJBjZBo=.deb056ac-6571-4c79-a272-680b923d58c5@github.com>
References: <4t-uTHoUVlflpzDnfuHO7TAnix7nNO1MGF28CJBjZBo=.deb056ac-6571-4c79-a272-680b923d58c5@github.com>
Message-ID: <ilsNgmMPrHB9Pm4jpbWYHTvxRF5_49JBZLbKEw_LwMI=.d9c2eba3-6aab-4bb4-9be3-bea34efc38ff@github.com>

On Tue, 29 Nov 2022 14:44:12 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg `7.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
> 
> This pull request was created by copying the following and using `7.1` at appropriate places:
> - https://github.com/openjdk/jdk/pull/9393

Marked as reviewed by jjg (Reviewer).

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

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

From cushon at openjdk.org  Thu Dec  1 01:29:40 2022
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 1 Dec 2022 01:29:40 GMT
Subject: RFR: 8297875: jar should not compress the manifest directory entry
 [v3]
In-Reply-To: <EpZd9Q-41It_aunxHpbe1blQGyN3wKm-ND8_FmtP9A0=.1317ab51-f6b0-467b-93ee-fb2a9778c61e@github.com>
References: <EpZd9Q-41It_aunxHpbe1blQGyN3wKm-ND8_FmtP9A0=.1317ab51-f6b0-467b-93ee-fb2a9778c61e@github.com>
Message-ID: <VCkQhnK5Ahkt4sM-4QmI1YI6lxgNnusXaOGQBswIb7s=.1b12100f-833d-46ea-a258-343f738e5125@github.com>

> This causes jar to not compress the `META-INF/` directory entry, for consistency with the handling of other directory entries and compliance with `APPNOTE.TXT`, and for compatibility with other zip implementations.

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Improve test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11441/files
  - new: https://git.openjdk.org/jdk/pull/11441/files/eaab9b03..9abb827f

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

  Stats: 33 lines in 1 file changed: 16 ins; 8 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/11441.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11441/head:pull/11441

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

From cushon at openjdk.org  Thu Dec  1 01:29:44 2022
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 1 Dec 2022 01:29:44 GMT
Subject: RFR: 8297875: jar should not compress the manifest directory entry
 [v2]
In-Reply-To: <GjT8_41bjngKPTaHub_trg66aUrtwNoLROS-MWxc89A=.4a670172-951a-40e5-960a-ac797f63401f@github.com>
References: <EpZd9Q-41It_aunxHpbe1blQGyN3wKm-ND8_FmtP9A0=.1317ab51-f6b0-467b-93ee-fb2a9778c61e@github.com>
 <_l7qaLS0EBSdDCO9lNkmWthX-Hb9ydWpdOVun3WewrQ=.2c203834-717c-4481-bac3-7c668cd4b2fc@github.com>
 <GjT8_41bjngKPTaHub_trg66aUrtwNoLROS-MWxc89A=.4a670172-951a-40e5-960a-ac797f63401f@github.com>
Message-ID: <QtDakxXJiOqyj1ZAYk70yV3Bh7GDFzw4brIfo0-Tdi8=.7247e1c6-57b9-424f-ab3a-f2ca51ea7c0d@github.com>

On Wed, 30 Nov 2022 22:15:14 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use TestNG, and assert on the compression method
>
> test/jdk/tools/jar/ManifestDirectoryCompression.java line 52:
> 
>> 50: 
>> 51:     /** Remove dirs & files needed for test. */
>> 52:     private static void cleanup(Path dir) {
> 
> This can leverage the @afterMethod annotation if the code is reworked slightly to make it more TestNG friendly

Thanks, done

> test/jdk/tools/jar/ManifestDirectoryCompression.java line 60:
> 
>> 58:             }
>> 59:             Files.delete(dir);
>> 60:         } catch (IOException e) {
> 
> Have the method throw IOException and you do not need the catch block

Unfortunately it's recursing on `cleanup` in the lambda, so it can't throw checked exceptions without more refactoring. This is imitating the recursive deletion approach in another jar test, I'm happy to swap this out if you'd prefer a different approach

> test/jdk/tools/jar/ManifestDirectoryCompression.java line 72:
> 
>> 70:             doTest(topDir.resolve("test.jar"), entry);
>> 71:         } finally {
>> 72:             cleanup(topDir);
> 
> See comment above regarding cleanup()

Thanks, I moved the cleanup into a separate `@AfterMethod`

> test/jdk/tools/jar/ManifestDirectoryCompression.java line 83:
> 
>> 81:         try (JarFile jarFile = new JarFile(jar.toFile())) {
>> 82:             ZipEntry zipEntry = jarFile.getEntry("META-INF/");
>> 83:             assertEquals(zipEntry.getMethod(), ZipEntry.STORED);
> 
> Probably worth verifying zipEntry is not null so you do not get an NPE

Done

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

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

From darcy at openjdk.org  Thu Dec  1 05:44:44 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 1 Dec 2022 05:44:44 GMT
Subject: RFR: JDK-8297215: Update libs tests to use @enablePreview [v3]
In-Reply-To: <tc_tYnGZ-vffHa80jkOhsmVumjixoO9B-0D7xvbMo_I=.7577a2f4-b4c0-4bc8-93fe-1313077d1769@github.com>
References: <tc_tYnGZ-vffHa80jkOhsmVumjixoO9B-0D7xvbMo_I=.7577a2f4-b4c0-4bc8-93fe-1313077d1769@github.com>
Message-ID: <6TQkLW3qFJge_NHSssVQFJm6y79L1IDtO1HmMgMFE24=.8ba6b5ae-39c8-4d4b-b1f9-9913f484827a@github.com>

> Similar to an update recently done for langtools tests, update the libraries regression tests to take advantage of the @enablePreview jtreg feature.

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

 - Respond to review feedback.
 - Merge branch 'master' into JDK-8297215
 - Respond to review feedback.
 - JDK-8297215: Update libs tests to use @enablePreview

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11222/files
  - new: https://git.openjdk.org/jdk/pull/11222/files/f3fc9e26..6d11bbca

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

  Stats: 47274 lines in 976 files changed: 24551 ins; 8961 del; 13762 mod
  Patch: https://git.openjdk.org/jdk/pull/11222.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11222/head:pull/11222

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

From thomas.stuefe at gmail.com  Thu Dec  1 07:26:07 2022
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 1 Dec 2022 08:26:07 +0100
Subject: Extend Native Memory Tracking over the JDK ? (was: Proposal:
 track zlib native memory usage with NMT)
In-Reply-To: <cb8b2707-4f43-4e91-83ac-9d3b1f6df2bb@app.fastmail.com>
References: <CAA-vtUzvyqb_LZ9d1Z80oSvzyqpi89053O3B+oDZF4oZ85CuZg@mail.gmail.com>
 <c5db2105-3b78-0b77-779f-011c8649f476@oracle.com>
 <CAA-vtUxrP49w523EQ3yKFh4Zo5W+HMtqpGcsUxOEMkwZUOQ0zQ@mail.gmail.com>
 <a20d3253-47b6-41dc-b8e4-0b894137ed90@app.fastmail.com>
 <4f7deee9-366d-05a2-9268-09a25a138d8d@oracle.com>
 <cb8b2707-4f43-4e91-83ac-9d3b1f6df2bb@app.fastmail.com>
Message-ID: <CAA-vtUwPXTD71ztTbwL5ayzX1jFFjGq1VXGrJ3z=pBFGMdatVA@mail.gmail.com>

Hi Carter, Stefan,

thank you, I think it is good to have this discussion, it is important.

Side note, the discussion steered away from my original question - whether
to instrument the JDK with NMT. I still would love to discuss that, too.

About opening NMT up for user consumption, that is of course possible. But
I think the bigger question is which data we want to open for user
consumption, and at what granularity. And what contracts do we enter when
we do this.

NMT was originally a hotspot-dev-centric tool. It has a lot of
idiosyncrasies. Interpreting the results needs detailed knowledge about
hotspot memory management. Some examples:

- its reports are not consistent across JDK versions, not even across
different patch levels of the same JDK. So you cannot compare results, say,
between JDK11 and 17.
- before a certain version X (I believe JDK 11), the full thread stacks
were accounted for instead of just the in-use portion of the thread stacks.
I remember reading blogs about how thread stack consumption went down when
all that changed was NMT reporting.
- The memory sizes it shows may not have much to do with real RSS. It
systematically underreports some things, since it omits libc overhead and
retention, usage by system- and JNI libraries. But it also overreports
things since it mostly (not always) accounts in terms of "committed"
memory, which usually means mmap()ed or malloc()ed memory. But that is just
committed, not physical memory, it does not translate to RSS usage
directly. That memory may never be touched. OTOH NMT probes thread stacks
with mincore(), so for that section, "committed" really means "physical".

I am fine with opening up NMT via JFR. But does this mean we have to be
more consistent? Do we have to care about downward compatibility of NMT
reports? Are we then still free to redesign the tag system (see my original
mail) or will this tie us down with the current NMT tag system forever? As
a negative example, JFR exposes metaspace allocator details (chunk
statistics) which have been broken ever since JDK 16 when the underlying
implementation changed.

Therefore I am curious about what end users use NMT really for.

@Carter: can you give us examples of which NMT sections had been
particularly useful to you? Maybe we can define a subset to expose instead
of exposing all tags. E.g. I can see thread stack usage being very useful,
but things like ObjectMonitor footprint not so much.

Cheers, Thomas




On Wed, Nov 30, 2022 at 9:45 PM Carter Kozak <ckozak at ckozak.net> wrote:

> This looks fantastic, thank you so much! I can confirm that the proposed
> design would solve my use-case.
>
> I'd enjoy discussing the NMT event  contract somewhere more specific
> to the implementation, but I don't want to muddle this thread with
> implementation details.
>
> Carter Kozak
>
> On Wed, Nov 30, 2022, at 03:37, Stefan Johansson wrote:
>
> Hi Carter,
>
> Your mail made me pick up an old item from my wishlist: to have native
> memory tracking information available in JFR recordings. When we, in GC,
> do improvements to decrease the native memory overhead of our
> algorithms, NMT is a very good tool to track the progress. We have
> scripts that sound very similar to what you describe and more than once
> I've been thinking about adding this information into JFR. But it has
> not been a priority and the greater value has been unclear.
>
> Hearing that others might also benefit from such a change I took a
> discussion with the JFR team on how to best proceed with this. I have
> created a branch for this and will probably create a PR for it shortly,
> but I thought I would drop it here first:
> https://github.com/kstefanj/jdk/tree/8157023-jfr-events-for-nmt
>
> The change adds two new JFR events: one for the total usage and one for
> the usage of each memory type. These are sent only if Native Memory
> Tracking is turned on, and they are enabled in the default JFR profile
> with an interval of 1s. This might change during reviewing but it was a
> good starting point.
>
> With this you will be able to use JFR streaming to access the events
> from within your running process. I hope this will help your use cases
> and please let us know if you have any comments or suggestions.
>
> Thanks,
> Stefan
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221201/21e28f7d/attachment-0001.htm>

From alanb at openjdk.org  Thu Dec  1 07:58:04 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Dec 2022 07:58:04 GMT
Subject: RFR: 8297632: InputStream.transferTo() method should specify what
 the return value should be when the number of bytes transfered is
 larger than Long.MAX_VALUE [v4]
In-Reply-To: <D-eomylNHOhk9YkHXVoX6XBSKVkLxDAVJ74hImDTrT8=.e305b0be-d503-4a28-8b4b-7b64aa7fd05c@github.com>
References: <T38kO1hcz3rhpqOOPYmoPl1TlRORJBifQWtXLl10x8Y=.595338d3-df98-4202-95b5-eda88a4ed0a2@github.com>
 <D-eomylNHOhk9YkHXVoX6XBSKVkLxDAVJ74hImDTrT8=.e305b0be-d503-4a28-8b4b-7b64aa7fd05c@github.com>
Message-ID: <gV41mPEOkm0MuBk5cAMSVRf4X0mON3SZ61cIW6cG5Z0=.dcb0bb11-999d-4b6f-b6ae-8825d3068fb4@github.com>

On Wed, 30 Nov 2022 20:48:12 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> `java.io.InputStream::transferTo` could conceivably return a negative value if the count of bytes transferred overflows a `long`. Modify the method to limit the number of bytes transferred to `Long.MAX_VALUE` per invocation.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8297632: Add verbiage to ZipInputStream::transferTo

Latest version (558cbc8a) looks okay but this change will likely have a tail so I think we should wait until after the fork for JDK 20 to integrate this. To that end, I've changed the fixVersion to 21 and the same on the CSR, I hope that is okay.

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

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

From alanb at openjdk.org  Thu Dec  1 08:02:15 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Dec 2022 08:02:15 GMT
Subject: RFR: JDK-8297215: Update libs tests to use @enablePreview [v3]
In-Reply-To: <6TQkLW3qFJge_NHSssVQFJm6y79L1IDtO1HmMgMFE24=.8ba6b5ae-39c8-4d4b-b1f9-9913f484827a@github.com>
References: <tc_tYnGZ-vffHa80jkOhsmVumjixoO9B-0D7xvbMo_I=.7577a2f4-b4c0-4bc8-93fe-1313077d1769@github.com>
 <6TQkLW3qFJge_NHSssVQFJm6y79L1IDtO1HmMgMFE24=.8ba6b5ae-39c8-4d4b-b1f9-9913f484827a@github.com>
Message-ID: <mMrPf-gYYdcrkAxXUkI3jZQ7Tgi8236ij3u2F-VM4Oc=.3d8fa225-3040-41e1-9ef2-f1870c15718a@github.com>

On Thu, 1 Dec 2022 05:44:44 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Similar to an update recently done for langtools tests, update the libraries regression tests to take advantage of the @enablePreview jtreg feature.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Respond to review feedback.
>  - Merge branch 'master' into JDK-8297215
>  - Respond to review feedback.
>  - JDK-8297215: Update libs tests to use @enablePreview

Latest update looks good, will make the test changes easy when features move from preview to permanent.

test/jdk/java/net/Socket/Timeouts.java line 30:

> 28:  * @build jdk.test.lib.Utils
> 29:  * @enablePreview
> 30:  * @compile Timeouts.java

I assume the `@compile` can be dropped from this one, doesn't matter.

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

Marked as reviewed by alanb (Reviewer).

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

From stsypanov at openjdk.org  Thu Dec  1 08:07:26 2022
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 1 Dec 2022 08:07:26 GMT
Subject: RFR: 8297561: Redundant index check in String.offsetByCodePoints()
 [v2]
In-Reply-To: <WC_0iTXQzgQdQXCUM5vbAOaUlgyB9v04AsfJ-hLFgSg=.fb90719e-0d0d-45d7-85ae-51e931023bba@github.com>
References: <vnMzuzt0R2APY_UldcHatNwqgdkRMNitT2JK7S_QNks=.65faca6f-36a3-4518-879e-030a5553c9d7@github.com>
 <UgFCR1uf8c_KcoCO0SgSevWLEQCmX29WDp-Gg_DRwj8=.d58ac323-8289-4abc-972a-2502da17d020@github.com>
 <WC_0iTXQzgQdQXCUM5vbAOaUlgyB9v04AsfJ-hLFgSg=.fb90719e-0d0d-45d7-85ae-51e931023bba@github.com>
Message-ID: <sxw3vXOjppceuBbkJuXSHxBMiPHjC3VSbmPiF4zoTzc=.86d3fb76-0bc8-4065-9bed-e5b8d91aaaa4@github.com>

On Wed, 30 Nov 2022 20:41:47 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8297561
>>  - 8297561: Add benchmark
>>  - 8297561: Redundant index check in String.offsetByCodePoints()
>
> test/micro/org/openjdk/bench/java/lang/StringOffsetByCodePoints.java line 1:
> 
>> 1: package org.openjdk.bench.java.lang;
> 
> Missing copyright header

Good point, fixed

> test/micro/org/openjdk/bench/java/lang/StringOffsetByCodePoints.java line 9:
> 
>> 7: @BenchmarkMode(Mode.AverageTime)
>> 8: @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> 9: @Warmup(iterations = 10, time = 1000, timeUnit = TimeUnit.MILLISECONDS)
> 
> For non-allocating microbenchmarks we usually get by with about 5 iterations of 1 second and same for warmup to produce stable results. Keeping runtime low ensures we can keep adding coverage to more APIs without incurring undue overhead

Fixed

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

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

From stsypanov at openjdk.org  Thu Dec  1 08:10:53 2022
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 1 Dec 2022 08:10:53 GMT
Subject: RFR: 8297561: Redundant index check in String.offsetByCodePoints()
 [v3]
In-Reply-To: <vnMzuzt0R2APY_UldcHatNwqgdkRMNitT2JK7S_QNks=.65faca6f-36a3-4518-879e-030a5553c9d7@github.com>
References: <vnMzuzt0R2APY_UldcHatNwqgdkRMNitT2JK7S_QNks=.65faca6f-36a3-4518-879e-030a5553c9d7@github.com>
Message-ID: <PZLG_UXsVaGCvYNNrBtXNT1B6_hIXv88z02BImnYT5A=.13b97c33-3485-46f3-a4bd-5d649cda7c1f@github.com>

> `String.offsetByCodePoints()` delegates to `Character.offsetByCodePoints()` which in turn specifies the same exception thrown under the same conditions and the implementation does exactly the same checks. This means we can remove the check from `String.offsetByCodePoints()` and rely on the one of `Character.offsetByCodePoints()`.

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

 - Merge remote-tracking branch 'origin/JDK-8297561' into JDK-8297561
 - 8297561: Add copyright and change warmup&measurement time

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11350/files
  - new: https://git.openjdk.org/jdk/pull/11350/files/1fdc0197..2d7b178c

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

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

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

From stsypanov at openjdk.org  Thu Dec  1 08:14:07 2022
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 1 Dec 2022 08:14:07 GMT
Subject: RFR: 8297561: Redundant index check in String.offsetByCodePoints()
 [v4]
In-Reply-To: <vnMzuzt0R2APY_UldcHatNwqgdkRMNitT2JK7S_QNks=.65faca6f-36a3-4518-879e-030a5553c9d7@github.com>
References: <vnMzuzt0R2APY_UldcHatNwqgdkRMNitT2JK7S_QNks=.65faca6f-36a3-4518-879e-030a5553c9d7@github.com>
Message-ID: <CkDMSpARsRMc29D5vcGh1U5vtw7u5vZ3Yyy0TS7xicM=.78c81348-8d61-4185-861f-61243a5c6eb4@github.com>

> `String.offsetByCodePoints()` delegates to `Character.offsetByCodePoints()` which in turn specifies the same exception thrown under the same conditions and the implementation does exactly the same checks. This means we can remove the check from `String.offsetByCodePoints()` and rely on the one of `Character.offsetByCodePoints()`.

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

 - 8297561: Minor clean-up
 - 8297561: Fix copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11350/files
  - new: https://git.openjdk.org/jdk/pull/11350/files/2d7b178c..7fea8d51

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

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

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

From sspitsyn at openjdk.org  Thu Dec  1 08:56:26 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 1 Dec 2022 08:56:26 GMT
Subject: RFR: JDK-8297215: Update libs tests to use @enablePreview [v3]
In-Reply-To: <6TQkLW3qFJge_NHSssVQFJm6y79L1IDtO1HmMgMFE24=.8ba6b5ae-39c8-4d4b-b1f9-9913f484827a@github.com>
References: <tc_tYnGZ-vffHa80jkOhsmVumjixoO9B-0D7xvbMo_I=.7577a2f4-b4c0-4bc8-93fe-1313077d1769@github.com>
 <6TQkLW3qFJge_NHSssVQFJm6y79L1IDtO1HmMgMFE24=.8ba6b5ae-39c8-4d4b-b1f9-9913f484827a@github.com>
Message-ID: <tVFVumnJy51-2nom9SSRevJTkS-4rvj2DB2DUcg1VbI=.14c7c783-a13a-4351-a4b3-097378c1bfa9@github.com>

On Thu, 1 Dec 2022 05:44:44 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Similar to an update recently done for langtools tests, update the libraries regression tests to take advantage of the @enablePreview jtreg feature.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Respond to review feedback.
>  - Merge branch 'master' into JDK-8297215
>  - Respond to review feedback.
>  - JDK-8297215: Update libs tests to use @enablePreview

Looks good.
Posted several nits though.
Thanks,
Serguei

test/jdk/java/lang/Thread/virtual/GetStackTraceWhenRunnable.java line 29:

> 27:  * @requires vm.continuations
> 28:  * @enablePreview
> 29:  * @compile GetStackTraceWhenRunnable.java

Nit: Is the line 29 for compiling necessary?

test/jdk/java/lang/instrument/ParallelTransformerLoaderTest.java line 37:

> 35:  * @library /test/lib
> 36:  * @run build TestClass1 TestClass2 TestClass3
> 37:   * @compile --enable-preview -source ${jdk.version} ParallelTransformerLoaderTest.java

Nit: This change is strange. It is either not needed or missing something.

test/jdk/java/lang/runtime/SwitchBootstrapsTest.java line 41:

> 39:  * @test
> 40:  * @enablePreview
> 41:  * @compile SwitchBootstrapsTest.java

Nit: Is the line 41 for compiling necessary?

test/jdk/java/net/vthread/HttpALot.java line 32:

> 30:  * @library /test/lib
> 31:  * @enablePreview
> 32:  * @compile HttpALot.java

Nit: Is the line 32 for compiling necessary?

test/jdk/java/net/vthread/InterruptHttp.java line 29:

> 27:  * @library /test/lib
> 28:  * @enablePreview
> 29:  * @compile InterruptHttp.java

Nit: Is the line 29 for compiling necessary?

test/jdk/jdk/jfr/event/runtime/TestThreadSleepEvent.java line 44:

> 42:  * @library /test/lib
> 43:  * @enablePreview
> 44:  * @compile TestThreadSleepEvent.java

Nit: Is the line 44 for compiling necessary?

test/jdk/jdk/jfr/threading/TestManyVirtualThreads.java line 47:

> 45:  * @modules jdk.jfr/jdk.jfr.internal
> 46:  * @enablePreview
> 47:  * @compile TestManyVirtualThreads.java

Nit: Not sure the line 47 for compiling is necessary?

test/jdk/jdk/jfr/threading/TestNestedVirtualThreads.java line 45:

> 43:  * @modules jdk.jfr/jdk.jfr.internal
> 44:  * @enablePreview
> 45:  * @compile TestNestedVirtualThreads.java

Nit: Not sure the line 45 for compiling is necessary?

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

Marked as reviewed by sspitsyn (Reviewer).

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

From jlahoda at openjdk.org  Thu Dec  1 09:17:45 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 1 Dec 2022 09:17:45 GMT
Subject: RFR: 8297928: Update jdk.internal.javac.PreviewFeature.Feature to
 reflect JEP 432 and JEP 433
Message-ID: <nDQSlGOp2WON7E7zfgjxTrmgy1LoGY0HLlsm8pDe6p0=.5f6089d6-4a71-4fed-835e-f0226e2dc2cf@github.com>

The jdk.internal.javac.PreviewFeature.Feature needs to be updated to reflect JEP 432 and JEP 433 properly.

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

Commit messages:
 - 8297928: Update jdk.internal.javac.PreviewFeature.Feature to reflect JEP 432 and JEP 433

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

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

From alanb at openjdk.org  Thu Dec  1 09:17:45 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Dec 2022 09:17:45 GMT
Subject: RFR: 8297928: Update jdk.internal.javac.PreviewFeature.Feature to
 reflect JEP 432 and JEP 433
In-Reply-To: <nDQSlGOp2WON7E7zfgjxTrmgy1LoGY0HLlsm8pDe6p0=.5f6089d6-4a71-4fed-835e-f0226e2dc2cf@github.com>
References: <nDQSlGOp2WON7E7zfgjxTrmgy1LoGY0HLlsm8pDe6p0=.5f6089d6-4a71-4fed-835e-f0226e2dc2cf@github.com>
Message-ID: <WWYSh8sICxi0DvujY6w-oIKre9IU4FMD672hwuQ2XFI=.6ecee426-0430-4abf-b0e8-d78b1228423a@github.com>

On Thu, 1 Dec 2022 09:08:11 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The jdk.internal.javac.PreviewFeature.Feature needs to be updated to reflect JEP 432 and JEP 433 properly.

Marked as reviewed by alanb (Reviewer).

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

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

From alanb at openjdk.org  Thu Dec  1 09:21:33 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Dec 2022 09:21:33 GMT
Subject: RFR: 8297875: jar should not compress the manifest directory entry
 [v3]
In-Reply-To: <VCkQhnK5Ahkt4sM-4QmI1YI6lxgNnusXaOGQBswIb7s=.1b12100f-833d-46ea-a258-343f738e5125@github.com>
References: <EpZd9Q-41It_aunxHpbe1blQGyN3wKm-ND8_FmtP9A0=.1317ab51-f6b0-467b-93ee-fb2a9778c61e@github.com>
 <VCkQhnK5Ahkt4sM-4QmI1YI6lxgNnusXaOGQBswIb7s=.1b12100f-833d-46ea-a258-343f738e5125@github.com>
Message-ID: <ug09RwQOFM0bijwdwzrCrIAz_Di9AwBF9XYOHQ2ltzk=.4b2f2270-ceb5-4471-bc1a-e551a5aca282@github.com>

On Thu, 1 Dec 2022 01:29:40 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This causes jar to not compress the `META-INF/` directory entry, for consistency with the handling of other directory entries and compliance with `APPNOTE.TXT`, and for compatibility with other zip implementations.
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve test

src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 878:

> 876:                 ZipEntry e = new ZipEntry(MANIFEST_DIR);
> 877:                 setZipEntryTime(e);
> 878:                 e.setMethod(ZipEntry.STORED);

This should be okay, consistent with addFile where it will use STORED for directories.

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

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

From redestad at openjdk.org  Thu Dec  1 09:28:58 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 1 Dec 2022 09:28:58 GMT
Subject: RFR: 8297561: Redundant index check in String.offsetByCodePoints()
 [v4]
In-Reply-To: <CkDMSpARsRMc29D5vcGh1U5vtw7u5vZ3Yyy0TS7xicM=.78c81348-8d61-4185-861f-61243a5c6eb4@github.com>
References: <vnMzuzt0R2APY_UldcHatNwqgdkRMNitT2JK7S_QNks=.65faca6f-36a3-4518-879e-030a5553c9d7@github.com>
 <CkDMSpARsRMc29D5vcGh1U5vtw7u5vZ3Yyy0TS7xicM=.78c81348-8d61-4185-861f-61243a5c6eb4@github.com>
Message-ID: <J4B79WEd7hhNcuRmnybqWQHqyW6tSV_fOr6qaDmM2Mw=.b44ca9b3-8555-44cb-aa03-83006235e1fd@github.com>

On Thu, 1 Dec 2022 08:14:07 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> `String.offsetByCodePoints()` delegates to `Character.offsetByCodePoints()` which in turn specifies the same exception thrown under the same conditions and the implementation does exactly the same checks. This means we can remove the check from `String.offsetByCodePoints()` and rely on the one of `Character.offsetByCodePoints()`.
>
> Sergey Tsypanov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8297561: Minor clean-up
>  - 8297561: Fix copyright year

Marked as reviewed by redestad (Reviewer).

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

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

From alanb at openjdk.org  Thu Dec  1 09:38:46 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Dec 2022 09:38:46 GMT
Subject: RFR: 8294278: ForkJoinPool.getAndAddPoolIds should use
 Unsafe.staticFieldBase
In-Reply-To: <YDZmkKhSSh7hg5dLz2Uezfv3nx19AdTDq_kKE8TRn6A=.e5362877-f055-4669-bb72-876c7739542c@github.com>
References: <wsg2pz5Qfu3TeM8dXDdOmNsRnpGMSexlunpN5W-kbX8=.61deaa50-5404-47c2-bb7e-00c4ccb60748@github.com>
 <YDZmkKhSSh7hg5dLz2Uezfv3nx19AdTDq_kKE8TRn6A=.e5362877-f055-4669-bb72-876c7739542c@github.com>
Message-ID: <lZ5L5nZEym7CQpA1OZb-_TyiavoaTSVy0ee1Hv4vBi0=.0b11086f-6254-47cf-87ec-587c669ceb3c@github.com>

On Wed, 30 Nov 2022 02:19:15 GMT, Martin Buchholz <martin at openjdk.org> wrote:

> The introduction of POOLIDS_BASE strengthens the case for renaming POOLIDS to POOLIDS_OFFSET for clarity - I would do that.

I checked with Doug and he suggests we leave it as is.

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

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

From alanb at openjdk.org  Thu Dec  1 10:43:51 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Dec 2022 10:43:51 GMT
Subject: Integrated: 8294278: ForkJoinPool.getAndAddPoolIds should use
 Unsafe.staticFieldBase
In-Reply-To: <wsg2pz5Qfu3TeM8dXDdOmNsRnpGMSexlunpN5W-kbX8=.61deaa50-5404-47c2-bb7e-00c4ccb60748@github.com>
References: <wsg2pz5Qfu3TeM8dXDdOmNsRnpGMSexlunpN5W-kbX8=.61deaa50-5404-47c2-bb7e-00c4ccb60748@github.com>
Message-ID: <uaPT2Deb8vROUR0_K2Dce1AaxsdD3_xD-CuhibuwtV8=.eddf0d9c-e4ee-41d4-b7ff-7c009f205d66@github.com>

On Fri, 25 Nov 2022 14:53:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Two (since 19) usages of Unsafe.getAndAddInt to update a static field provide the Class object as the base instead of the base object returned by Unsafe.staticFieldBase. This doesn't change anything on the HotSpot VM.

This pull request has now been integrated.

Changeset: cd776093
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cd776093c79e9a1a4c40c0adfdbfeedf293d99c7
Stats:     17 lines in 2 files changed: 12 ins; 0 del; 5 mod

8294278: ForkJoinPool.getAndAddPoolIds should use Unsafe.staticFieldBase

Reviewed-by: burban, chegar, martin

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

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

From stefan.johansson at oracle.com  Thu Dec  1 10:52:50 2022
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Thu, 1 Dec 2022 11:52:50 +0100
Subject: [External] : Re: Extend Native Memory Tracking over the JDK ?
 (was: Proposal: track zlib native memory usage with NMT)
In-Reply-To: <CAA-vtUwPXTD71ztTbwL5ayzX1jFFjGq1VXGrJ3z=pBFGMdatVA@mail.gmail.com>
References: <CAA-vtUzvyqb_LZ9d1Z80oSvzyqpi89053O3B+oDZF4oZ85CuZg@mail.gmail.com>
 <c5db2105-3b78-0b77-779f-011c8649f476@oracle.com>
 <CAA-vtUxrP49w523EQ3yKFh4Zo5W+HMtqpGcsUxOEMkwZUOQ0zQ@mail.gmail.com>
 <a20d3253-47b6-41dc-b8e4-0b894137ed90@app.fastmail.com>
 <4f7deee9-366d-05a2-9268-09a25a138d8d@oracle.com>
 <cb8b2707-4f43-4e91-83ac-9d3b1f6df2bb@app.fastmail.com>
 <CAA-vtUwPXTD71ztTbwL5ayzX1jFFjGq1VXGrJ3z=pBFGMdatVA@mail.gmail.com>
Message-ID: <4a2dbc13-dc65-e8ba-a40c-ff6b1cef931d@oracle.com>

Hi Thomas and Carter,

I opened up a PR for this to allow more specific comments on the 
implementation:
https://github.com/openjdk/jdk/pull/11449

If this discussion leads to us not wanting to proceed with the change I 
will withdraw the PR.

Some more comments below.

On 2022-12-01 08:26, Thomas St?fe wrote:
> Hi Carter, Stefan,
> 
> thank you, I think it is good to have this discussion, it is important.
> 
> Side note, the discussion steered away from my original question - 
> whether to instrument the JDK with NMT. I still would love to discuss 
> that, too.
> 

Sorry for that :)

> About opening NMT up for user consumption, that is of course possible. 
> But I think the bigger question is which data we want to open for user 
> consumption, and at what granularity. And what contracts do we enter 
> when we do this.
> 

To me this is not so much opening it up, but just making it much simpler 
to get the already available data (JFR instead of jcmd). I get your 
point that when we make it easier it will likely get more visibility and 
that could generate expectations. To me the contract on these events 
should not be much harder than, for example, the contract we have on the 
format of GC logs. So we should not be locked down by this.

> NMT was originally a hotspot-dev-centric tool. It has a lot of 
> idiosyncrasies. Interpreting the results needs detailed knowledge about 
> hotspot memory management. Some examples:
> 
> - its reports are not consistent across JDK versions, not even across 
> different patch levels of the same JDK. So you cannot compare results, 
> say, between JDK11 and 17.
> - before a certain version X (I believe JDK 11), the full thread stacks 
> were accounted for instead of just the in-use portion of the thread 
> stacks. I remember reading blogs about how thread stack consumption went 
> down when all that changed was NMT reporting.
> - The memory sizes it shows may not have much to do with real RSS. It 
> systematically underreports some things, since it omits libc overhead 
> and retention, usage by system- and JNI libraries. But it also 
> overreports things since it mostly (not always) accounts in terms of 
> "committed" memory, which usually means mmap()ed or malloc()ed memory. 
> But that is just committed, not physical memory, it does not translate 
> to RSS usage directly. That memory may never be touched. OTOH NMT probes 
> thread stacks with mincore(), so for that section, "committed" really 
> means "physical".
> 

I agree that NMT is a low-level tool and that it's not perfect. But in 
some cases I think it's the best way to see the memory consumption of 
the JVM. Especially since you can zoom in on certain areas.

> I am fine with opening up NMT via JFR. But does this mean we have to be 
> more consistent? Do we have to care about downward compatibility of NMT 
> reports? Are we then still free to redesign the tag system (see my 
> original mail) or will this tie us down with the current NMT tag system 
> forever? As a negative example, JFR exposes metaspace allocator details 
> (chunk statistics) which have been broken ever since JDK 16 when the 
> underlying implementation changed.
> 

I think a tag based system for NMT would be awesome and it would be 
really sad if exposing the NMT information through JFR would stop us 
from doing this. Hopefully the only thing we need to do when improving 
NMT is to do CSRs. One possible way to avoid constraints even more would 
be to tag those events as "experimental" at first. This would signal 
that user should not rely on them.

> Therefore I am curious about what end users use NMT really for.
> 
> @Carter: can you give us examples of which NMT sections had been 
> particularly useful to you? Maybe we can define a subset to expose 
> instead of exposing all tags. E.g. I can see thread stack usage being 
> very useful, but things like ObjectMonitor footprint not so much.
>

I agree that not to many users would care about the ObjectMonitor 
footprint, but unless we get constrained by what we report I would like 
to report all. If there are constraints, this might be a good middle road.

Thanks,
Stefan

> Cheers, Thomas
> 
> 
> 
> 
> On Wed, Nov 30, 2022 at 9:45 PM Carter Kozak <ckozak at ckozak.net 
> <mailto:ckozak at ckozak.net>> wrote:
> 
>     __
>     This looks fantastic, thank you so much! I can confirm that the
>     proposed
>     design would solve my use-case.
> 
>     I'd enjoy discussing the NMT event? contract somewhere more specific
>     to the implementation, but I don't want to muddle this thread with
>     implementation details.
> 
>     Carter Kozak
> 
>     On Wed, Nov 30, 2022, at 03:37, Stefan Johansson wrote:
>>     Hi Carter,
>>
>>     Your mail made me pick up an old item from my wishlist: to have
>>     native
>>     memory tracking information available in JFR recordings. When we,
>>     in GC,
>>     do improvements to decrease the native memory overhead of our
>>     algorithms, NMT is a very good tool to track the progress. We have
>>     scripts that sound very similar to what you describe and more than
>>     once
>>     I've been thinking about adding this information into JFR. But it has
>>     not been a priority and the greater value has been unclear.
>>
>>     Hearing that others might also benefit from such a change I took a
>>     discussion with the JFR team on how to best proceed with this. I have
>>     created a branch for this and will probably create a PR for it
>>     shortly,
>>     but I thought I would drop it here first:
>>     https://github.com/kstefanj/jdk/tree/8157023-jfr-events-for-nmt
>>     <https://urldefense.com/v3/__https://github.com/kstefanj/jdk/tree/8157023-jfr-events-for-nmt__;!!ACWV5N9M2RV99hQ!IpI1Gbn4N8zH6ZeK20WzMC2bG8XfncJ3sH15GZk2mG3AozRbI4h6b1ZtAhWMNr4qsHE1_dLeDFZWtzF6LpA4XQ4zFFGN$>
>>
>>     The change adds two new JFR events: one for the total usage and
>>     one for
>>     the usage of each memory type. These are sent only if Native Memory
>>     Tracking is turned on, and they are enabled in the default JFR
>>     profile
>>     with an interval of 1s. This might change during reviewing but it
>>     was a
>>     good starting point.
>>
>>     With this you will be able to use JFR streaming to access the events
>>     from within your running process. I hope this will help your use
>>     cases
>>     and please let us know if you have any comments or suggestions.
>>
>>     Thanks,
>>     Stefan
> 

From jlahoda at openjdk.org  Thu Dec  1 11:49:58 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 1 Dec 2022 11:49:58 GMT
Subject: Integrated: 8297928: Update jdk.internal.javac.PreviewFeature.Feature
 to reflect JEP 432 and JEP 433
In-Reply-To: <nDQSlGOp2WON7E7zfgjxTrmgy1LoGY0HLlsm8pDe6p0=.5f6089d6-4a71-4fed-835e-f0226e2dc2cf@github.com>
References: <nDQSlGOp2WON7E7zfgjxTrmgy1LoGY0HLlsm8pDe6p0=.5f6089d6-4a71-4fed-835e-f0226e2dc2cf@github.com>
Message-ID: <w2y4lSUVh8p04ctgE4RIClUTOByD27720YJlLm4cYAw=.25ca81cb-da9f-4d52-8360-bcc21c75d585@github.com>

On Thu, 1 Dec 2022 09:08:11 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The jdk.internal.javac.PreviewFeature.Feature needs to be updated to reflect JEP 432 and JEP 433 properly.

This pull request has now been integrated.

Changeset: fc9d419b
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fc9d419b4ff46e484fa8798304dae29d3946dcfb
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8297928: Update jdk.internal.javac.PreviewFeature.Feature to reflect JEP 432 and JEP 433

Reviewed-by: alanb

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

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

From lancea at openjdk.org  Thu Dec  1 11:51:27 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 1 Dec 2022 11:51:27 GMT
Subject: RFR: 8297875: jar should not compress the manifest directory entry
 [v3]
In-Reply-To: <VCkQhnK5Ahkt4sM-4QmI1YI6lxgNnusXaOGQBswIb7s=.1b12100f-833d-46ea-a258-343f738e5125@github.com>
References: <EpZd9Q-41It_aunxHpbe1blQGyN3wKm-ND8_FmtP9A0=.1317ab51-f6b0-467b-93ee-fb2a9778c61e@github.com>
 <VCkQhnK5Ahkt4sM-4QmI1YI6lxgNnusXaOGQBswIb7s=.1b12100f-833d-46ea-a258-343f738e5125@github.com>
Message-ID: <hS22g3Dps56Hbj9yvUrSMbgykfBSsua5zTaQEM-DLyQ=.57413b78-855c-49df-9c75-b5e8539e37b4@github.com>

On Thu, 1 Dec 2022 01:29:40 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This causes jar to not compress the `META-INF/` directory entry, for consistency with the handling of other directory entries and compliance with `APPNOTE.TXT`, and for compatibility with other zip implementations.
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve test

Thank you again for the latest updates.  I think we are close.  Please see the comments to further streamline the test and once addressed we should be good to go.

test/jdk/tools/jar/ManifestDirectoryCompression.java line 81:

> 79: 
> 80:     @Test
> 81:     public void run() throws Exception {

Please rename `run() `to something like `TestDirectoryCompressionMethod()`.  We are trying to make new tests have more meaningful names.

test/jdk/tools/jar/ManifestDirectoryCompression.java line 83:

> 81:     public void run() throws Exception {
> 82:         Path entryPath = Files.writeString(tempDir.resolve("test.txt"), "Some text...");
> 83:         Path jar = tempDir.resolve("test.jar");

Please see comment above regarding the cleanup method.

One other thought you could consider given you only create a jar and file to add to the jar, is to simply add File.deleteIfExists() calls and not bother with a cleanup method given the test case is small and pretty straight forward.  Your choice though :-)

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

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

From lancea at openjdk.org  Thu Dec  1 11:51:27 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 1 Dec 2022 11:51:27 GMT
Subject: RFR: 8297875: jar should not compress the manifest directory entry
 [v2]
In-Reply-To: <QtDakxXJiOqyj1ZAYk70yV3Bh7GDFzw4brIfo0-Tdi8=.7247e1c6-57b9-424f-ab3a-f2ca51ea7c0d@github.com>
References: <EpZd9Q-41It_aunxHpbe1blQGyN3wKm-ND8_FmtP9A0=.1317ab51-f6b0-467b-93ee-fb2a9778c61e@github.com>
 <_l7qaLS0EBSdDCO9lNkmWthX-Hb9ydWpdOVun3WewrQ=.2c203834-717c-4481-bac3-7c668cd4b2fc@github.com>
 <GjT8_41bjngKPTaHub_trg66aUrtwNoLROS-MWxc89A=.4a670172-951a-40e5-960a-ac797f63401f@github.com>
 <QtDakxXJiOqyj1ZAYk70yV3Bh7GDFzw4brIfo0-Tdi8=.7247e1c6-57b9-424f-ab3a-f2ca51ea7c0d@github.com>
Message-ID: <7Nsh7xymaq8A6j6SPB_QDWH9xVZi1E2JL_UtM9bSDd8=.8c2afbb1-076f-495d-b3e9-e5077f149be2@github.com>

On Thu, 1 Dec 2022 01:21:13 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> test/jdk/tools/jar/ManifestDirectoryCompression.java line 60:
>> 
>>> 58:             }
>>> 59:             Files.delete(dir);
>>> 60:         } catch (IOException e) {
>> 
>> Have the method throw IOException and you do not need the catch block
>
> Unfortunately it's recursing on `cleanup` in the lambda, so it can't throw checked exceptions without more refactoring. This is imitating the recursive deletion approach in another jar test, I'm happy to swap this out if you'd prefer a different approach

Thanks for the reminder regarding lambada/checked exceptions. I think this can be simplified to just write the jar and test file to the current directory and then just call


Files.deleteIfExists(Path.of(JAR_FILE_NAME));
Files.deleteIfExists(Path.of(FILE_NAME));


as they are the only files used by the test .

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

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

From david32768 at btinternet.com  Thu Dec  1 13:12:53 2022
From: david32768 at btinternet.com (david32768@btinternet.com david32768@btinternet.com)
Date: Thu, 1 Dec 2022 13:12:53 +0000 (GMT)
Subject: Unsigned long to double and back
Message-ID: <7a05cfbd.49ac8.184cdd18c12.Webtop.101@btinternet.com>


On Sun Nov 6 00:17:19 UTC 2022 Johannes Kuhn <info at j-kuhn.de> wrote:

> ...
> In particular, I would love to see the following methods added*:
>
> - double Double.fromUnsignedLong(long i)
> - long Double.toUnsignedLong(double d)
> - float Float.fromUnsignedLong(long i)
> - long Float.toUnsignedLong(float f)
> ...

The methods suggested for double to unsigned long by David Lloyd and 
Remi Forax
  differ from BigInteger.doubleValue() in a few cases because of 
rounding error.
  They also fail some WebAssembly tests
(https://github.com/WebAssembly/testsuite/blob/main/conversions.wast).

The double to unsigned long method below agrees with 
BigInteger.doubleValue() on random tests and
passes the WebAssembly tests.


     // DOUBLE 1 11 52
     private static final int PHYSICAL_MANTISSA = 52;
     private static final int MANTISSA = PHYSICAL_MANTISSA + 1; // 
leading one bit not stored in normal numbers
     private static final int SHIFT_DOWN = 64 - MANTISSA;
     private static final long DIVISOR = 1L << SHIFT_DOWN;
     private static final long REMAINDER_MASK = DIVISOR - 1;
     private static final long HALF = DIVISOR >>> 1;
     private static final double MULTIPLIER = (double)DIVISOR;

     public static double doubleFromUnsignedLong(long value) {
         if (value >= 0) {
             return (double)value;
         }
         long mantissa = value >>> SHIFT_DOWN; // top bit of mantissa is 
1 as value negative
         long remainder = value & REMAINDER_MASK;
         if (remainder > HALF || remainder == HALF && (mantissa & 1) != 
0) { // round up (half to even) ?
             ++mantissa;
         }
         return MULTIPLIER * mantissa;
     }

     private final static double TWO63D = 0x1.0p63;
     private final static double TWO64D = 0x1.0p64;

     public static long doubleToUnsignedLongStrict(double x) {
         if (Double.isNaN(x)) {
             String msg = "INTEGER_CONVERSION";
             throw new ArithmeticException(msg);
         }
         if (x >= TWO64D || x <= -1.0) {
             String msg = "INTEGER_OVERFLOW";
             throw new ArithmeticException(msg);
         }
         if (x < TWO63D) {
             return (long)x;
         }
         // x is an integer in [0x1.0p63,0x1.0p64) and last 11 bits are 
zero
         double y = x/2;
         long yl = (long)y;
         return  yl << 1;
     }

     // FLOAT 1 8 23
     private static final int PHYSICAL_MANTISSA_F = 23;
     private static final int MANTISSA_F = PHYSICAL_MANTISSA_F + 1; // 
leading one bit not stored in normal numbers
     private static final int SHIFT_DOWN_F = 64 - MANTISSA_F;
     private static final long DIVISOR_F = 1L << SHIFT_DOWN_F;
     private static final long REMAINDER_MASK_F = DIVISOR_F - 1;
     private static final long HALF_F = DIVISOR_F >>> 1;
     private static final float MULTIPLIER_F = (float)DIVISOR_F;

     public static float floatFromUnsignedLong(long value) {
         if (value >= 0) {
             return (float)value;
         }
         long mantissa = value >>> SHIFT_DOWN_F; // top bit of mantissa 
is 1 as value negative
         long remainder = value & REMAINDER_MASK_F;
         if (remainder > HALF_F || remainder == HALF_F && (mantissa & 1) 
!= 0) { // round up (half to even) ?
             ++mantissa;
         }
         return MULTIPLIER_F * mantissa;
     }

     private final static double TWO31D = 0x1.0p31;
     private final static double TWO32D = 0x1.0p32;

     public static int doubleToUnsignedIntStrict(double x) {
         if (Double.isNaN(x)) {
             String msg = "INTEGER_CONVERSION";
             throw new ArithmeticException(msg);
         }
         if (x >= TWO32D || x <= -1.0) {
             String msg = "INTEGER_OVERFLOW";
             throw new ArithmeticException(msg);
         }
         if (x < TWO31D) {
             return (int)x;
         }
         return (int)(long)x;
     }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221201/9660ae2c/attachment-0001.htm>

From jlaskey at openjdk.org  Thu Dec  1 13:18:16 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 1 Dec 2022 13:18:16 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
Message-ID: <xhPzR2HTM7U0UEhvRxjpaE0ff169w3tCBX0yCpLOoY4=.be878d0b-bfc3-4d4c-a9d5-37369616e413@github.com>

On Wed, 30 Nov 2022 20:44:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Adds a test
>  - Removed JavaIOAccess.charset() which is no longer needed

LGTM

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

Marked as reviewed by jlaskey (Reviewer).

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

From alanb at openjdk.org  Thu Dec  1 14:46:48 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Dec 2022 14:46:48 GMT
Subject: RFR: 8297495: j.u.concurrent updates for JDK 20 [v2]
In-Reply-To: <HcXqonjoH0jm8K5fXlfw8YsfyNBswTwFuPD7rtEr8FI=.22189b59-24bc-44bc-add1-9587ebe60518@github.com>
References: <HcXqonjoH0jm8K5fXlfw8YsfyNBswTwFuPD7rtEr8FI=.22189b59-24bc-44bc-add1-9587ebe60518@github.com>
Message-ID: <yNV8fdFulhnQRUk6NKIuFRN-ACEExiehoHJ-EqKvce0=.f293af52-6c67-4eb0-b499-f819cf583547@github.com>

> The proposed updates for JDK 20 are:
> 
> - ForkJoinPool.externalSubmit 
> - ForkJoinWorkerThread.getQueuedTaskCount 
> 
> These methods will be used to improve the Thread.yield implementation for virtual threads. The range of alternatives explored include not exposing an API and protected methods such as "offerSubmission". The class description speaks of "external clients" and "submissions from non-ForkJoinTask clients", hence the proposed naming and javadoc text.

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

 - Expand test
 - Adjust wording to make it clear that the number of tasks is non-negative
 - Merge
 - Improve javadoc
 - Merge
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11319/files
  - new: https://git.openjdk.org/jdk/pull/11319/files/b1415b2e..a1ee40e5

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

  Stats: 14188 lines in 478 files changed: 9499 ins; 2646 del; 2043 mod
  Patch: https://git.openjdk.org/jdk/pull/11319.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11319/head:pull/11319

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

From alanb at openjdk.org  Thu Dec  1 15:11:23 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Dec 2022 15:11:23 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
Message-ID: <Scdy9u1XjWQU5gWdMdr_25uiTCXFpTSToGd46dM8frw=.acb5fc20-e233-436e-a39b-c94836bbeb7c@github.com>

On Wed, 30 Nov 2022 20:44:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Adds a test
>  - Removed JavaIOAccess.charset() which is no longer needed

src/java.base/share/classes/java/io/Console.java line 604:

> 602:                             GetPropertyAction.privilegedGetProperty("jdk.console",
> 603:                                     JdkConsoleProvider.DEFAULT_PROVIDER);
> 604:                     cons = ServiceLoader.load(JdkConsoleProvider.class).stream()

We might need a test to verify that this works when running with a security manager? That execution mode is still supported.

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

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

From alanb at openjdk.org  Thu Dec  1 15:18:39 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Dec 2022 15:18:39 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
Message-ID: <JCBfRAbsgf6bH6lqeXWodGC89bWpXwpwNlv2E1aHPUI=.85727228-d8c8-4918-818a-ae6606514b99@github.com>

On Wed, 30 Nov 2022 20:44:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Adds a test
>  - Removed JavaIOAccess.charset() which is no longer needed

src/java.base/share/classes/java/lang/System.java line 2133:

> 2131:     }
> 2132: 
> 2133:     private static InputStream initIn = null;

I think it would be helpful to rename this to `initialIn` and move this to be with `in` and `out`. It might also be helpful to have a  comment to say that it's the initial value of `in`, set in initPhase1.  It doesn't need to be initialized to null as that it's default value anyway.

src/java.base/share/classes/sun/security/util/Password.java line 63:

> 61:                 // readPassword returns "" if you just press ENTER with the built-in Console,
> 62:                 // to be compatible with old Password class, change to null
> 63:                 if (consoleEntered == null || consoleEntered.length == 0) {

@wangweij Would you have cycles to build with this change to see that keytool is okay?

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

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

From rriggs at openjdk.org  Thu Dec  1 15:20:32 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 1 Dec 2022 15:20:32 GMT
Subject: RFR: 8297561: Redundant index check in String.offsetByCodePoints()
 [v4]
In-Reply-To: <CkDMSpARsRMc29D5vcGh1U5vtw7u5vZ3Yyy0TS7xicM=.78c81348-8d61-4185-861f-61243a5c6eb4@github.com>
References: <vnMzuzt0R2APY_UldcHatNwqgdkRMNitT2JK7S_QNks=.65faca6f-36a3-4518-879e-030a5553c9d7@github.com>
 <CkDMSpARsRMc29D5vcGh1U5vtw7u5vZ3Yyy0TS7xicM=.78c81348-8d61-4185-861f-61243a5c6eb4@github.com>
Message-ID: <vfaZOi4Og56SecoJwRdOy3ntReBDg2I067nvqtfnCN8=.bce95405-824b-4cc4-9cce-808602de53b9@github.com>

On Thu, 1 Dec 2022 08:14:07 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> `String.offsetByCodePoints()` delegates to `Character.offsetByCodePoints()` which in turn specifies the same exception thrown under the same conditions and the implementation does exactly the same checks. This means we can remove the check from `String.offsetByCodePoints()` and rely on the one of `Character.offsetByCodePoints()`.
>
> Sergey Tsypanov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8297561: Minor clean-up
>  - 8297561: Fix copyright year

Marked as reviewed by rriggs (Reviewer).

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

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

From stsypanov at openjdk.org  Thu Dec  1 15:31:41 2022
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 1 Dec 2022 15:31:41 GMT
Subject: Integrated: 8297561: Redundant index check in
 String.offsetByCodePoints()
In-Reply-To: <vnMzuzt0R2APY_UldcHatNwqgdkRMNitT2JK7S_QNks=.65faca6f-36a3-4518-879e-030a5553c9d7@github.com>
References: <vnMzuzt0R2APY_UldcHatNwqgdkRMNitT2JK7S_QNks=.65faca6f-36a3-4518-879e-030a5553c9d7@github.com>
Message-ID: <GBEEIqMGqK1WjVeq_R035iu6WbNTH7KinoqVOJ2aKJQ=.1570f503-f30c-4d98-8602-32976e7a820a@github.com>

On Thu, 24 Nov 2022 10:08:31 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> `String.offsetByCodePoints()` delegates to `Character.offsetByCodePoints()` which in turn specifies the same exception thrown under the same conditions and the implementation does exactly the same checks. This means we can remove the check from `String.offsetByCodePoints()` and rely on the one of `Character.offsetByCodePoints()`.

This pull request has now been integrated.

Changeset: c6156f91
Author:    Sergey Tsypanov <stsypanov at openjdk.org>
Committer: Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c6156f9123c02b814ce0615568499f60d95b461a
Stats:     51 lines in 2 files changed: 47 ins; 3 del; 1 mod

8297561: Redundant index check in String.offsetByCodePoints()

Reviewed-by: aturbanov, rriggs, redestad

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

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

From alanb at openjdk.org  Thu Dec  1 15:35:34 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Dec 2022 15:35:34 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
Message-ID: <R4aKXarc67PDUTPbROJ23XQVirwJEVTMRkBIdSGGTtY=.ee02bf33-a445-44aa-a9f9-5e65284506ab@github.com>

On Wed, 30 Nov 2022 20:44:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Adds a test
>  - Removed JavaIOAccess.charset() which is no longer needed

A general point is that it's difficult to test Console and it looks like we don't have many existing tests in test/jdk/java/io/Console. The test that is there doesn't seem to exercise most of the methods. I wonder should improve this and have the tests run with `--limit-modules java.base` so they run with the default the is in java.base rather than the provider in jdk.intenal.le.

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

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

From weijun at openjdk.org  Thu Dec  1 15:53:27 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 Dec 2022 15:53:27 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <JCBfRAbsgf6bH6lqeXWodGC89bWpXwpwNlv2E1aHPUI=.85727228-d8c8-4918-818a-ae6606514b99@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
 <JCBfRAbsgf6bH6lqeXWodGC89bWpXwpwNlv2E1aHPUI=.85727228-d8c8-4918-818a-ae6606514b99@github.com>
Message-ID: <ZTmLDk0M9hsuICQeazcIat8UdUvM49UAisgTfoV8LCg=.799c1bfe-57a8-4b24-a72e-ed7f970bcf95@github.com>

On Thu, 1 Dec 2022 15:16:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Adds a test
>>  - Removed JavaIOAccess.charset() which is no longer needed
>
> src/java.base/share/classes/sun/security/util/Password.java line 63:
> 
>> 61:                 // readPassword returns "" if you just press ENTER with the built-in Console,
>> 62:                 // to be compatible with old Password class, change to null
>> 63:                 if (consoleEntered == null || consoleEntered.length == 0) {
> 
> @wangweij Would you have cycles to build with this change to see that keytool is okay?

Sure. Trying out now...

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

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

From weijun at openjdk.org  Thu Dec  1 16:11:12 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 Dec 2022 16:11:12 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <ZTmLDk0M9hsuICQeazcIat8UdUvM49UAisgTfoV8LCg=.799c1bfe-57a8-4b24-a72e-ed7f970bcf95@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
 <JCBfRAbsgf6bH6lqeXWodGC89bWpXwpwNlv2E1aHPUI=.85727228-d8c8-4918-818a-ae6606514b99@github.com>
 <ZTmLDk0M9hsuICQeazcIat8UdUvM49UAisgTfoV8LCg=.799c1bfe-57a8-4b24-a72e-ed7f970bcf95@github.com>
Message-ID: <nrL_Up0TmjkjNZgQtxGCZG3gkOF2eg5FiJYUK_J1kJs=.164122ef-8750-487c-abc5-e5b92bdf7c2c@github.com>

On Thu, 1 Dec 2022 15:49:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/Password.java line 63:
>> 
>>> 61:                 // readPassword returns "" if you just press ENTER with the built-in Console,
>>> 62:                 // to be compatible with old Password class, change to null
>>> 63:                 if (consoleEntered == null || consoleEntered.length == 0) {
>> 
>> @wangweij Would you have cycles to build with this change to see that keytool is okay?
>
> Sure. Trying out now...

I can still see the password on screen. Here `in` is a `jdk.jshell.execution.Util` so the updated check on line 58 above failed.

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

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

From bpb at openjdk.org  Thu Dec  1 16:29:31 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 1 Dec 2022 16:29:31 GMT
Subject: RFR: 8297632: InputStream.transferTo() method should specify what
 the return value should be when the number of bytes transfered is
 larger than Long.MAX_VALUE [v4]
In-Reply-To: <D-eomylNHOhk9YkHXVoX6XBSKVkLxDAVJ74hImDTrT8=.e305b0be-d503-4a28-8b4b-7b64aa7fd05c@github.com>
References: <T38kO1hcz3rhpqOOPYmoPl1TlRORJBifQWtXLl10x8Y=.595338d3-df98-4202-95b5-eda88a4ed0a2@github.com>
 <D-eomylNHOhk9YkHXVoX6XBSKVkLxDAVJ74hImDTrT8=.e305b0be-d503-4a28-8b4b-7b64aa7fd05c@github.com>
Message-ID: <RxRzGOqWDBP3hJta9QgVzNGpMd4OvgEre-qqDoUbH8g=.0ec02233-f871-41a6-b46c-7581da78df25@github.com>

On Wed, 30 Nov 2022 20:48:12 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> `java.io.InputStream::transferTo` could conceivably return a negative value if the count of bytes transferred overflows a `long`. Modify the method to limit the number of bytes transferred to `Long.MAX_VALUE` per invocation.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8297632: Add verbiage to ZipInputStream::transferTo

> Latest version ([558cbc8](https://github.com/openjdk/jdk/commit/558cbc8a32428a9630a2b7c57615659d92bfdc78)) looks okay but this change will likely have a tail so I think we should wait until after the fork for JDK 20 to integrate this.

It can wait a week.

> To that end, I've changed the fixVersion to 21 and the same on the CSR, I hope that is okay.

No problem.

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

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

From cstein at openjdk.org  Thu Dec  1 16:52:36 2022
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 1 Dec 2022 16:52:36 GMT
Subject: Integrated: 8296710: Update to use jtreg 7.1
In-Reply-To: <4t-uTHoUVlflpzDnfuHO7TAnix7nNO1MGF28CJBjZBo=.deb056ac-6571-4c79-a272-680b923d58c5@github.com>
References: <4t-uTHoUVlflpzDnfuHO7TAnix7nNO1MGF28CJBjZBo=.deb056ac-6571-4c79-a272-680b923d58c5@github.com>
Message-ID: <lZAtUZEOklC8hkoGANSV8U9RQosigGI36_pJft8Cpgk=.b18b40d7-32a1-4a25-95cf-159f554b4698@github.com>

On Tue, 29 Nov 2022 14:44:12 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg `7.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
> 
> This pull request was created by copying the following and using `7.1` at appropriate places:
> - https://github.com/openjdk/jdk/pull/9393

This pull request has now been integrated.

Changeset: c70d1e1b
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c70d1e1bd32c71e0d2df635bc565201a09084a83
Stats:     9 lines in 8 files changed: 0 ins; 0 del; 9 mod

8296710: Update to use jtreg 7.1

Reviewed-by: erikj, alanb, jjg

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

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

From cushon at openjdk.org  Thu Dec  1 17:00:02 2022
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 1 Dec 2022 17:00:02 GMT
Subject: RFR: 8297875: jar should not compress the manifest directory entry
 [v4]
In-Reply-To: <EpZd9Q-41It_aunxHpbe1blQGyN3wKm-ND8_FmtP9A0=.1317ab51-f6b0-467b-93ee-fb2a9778c61e@github.com>
References: <EpZd9Q-41It_aunxHpbe1blQGyN3wKm-ND8_FmtP9A0=.1317ab51-f6b0-467b-93ee-fb2a9778c61e@github.com>
Message-ID: <sL7nHuMbpB_VELaadNz3leUnTEFu-KStN33EamCt6YE=.37ad0bee-c233-432c-9c9e-3db47eba721a@github.com>

> This causes jar to not compress the `META-INF/` directory entry, for consistency with the handling of other directory entries and compliance with `APPNOTE.TXT`, and for compatibility with other zip implementations.

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Test improvements

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11441/files
  - new: https://git.openjdk.org/jdk/pull/11441/files/9abb827f..96de05ea

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

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

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

From cushon at openjdk.org  Thu Dec  1 17:00:03 2022
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 1 Dec 2022 17:00:03 GMT
Subject: RFR: 8297875: jar should not compress the manifest directory entry
 [v2]
In-Reply-To: <7Nsh7xymaq8A6j6SPB_QDWH9xVZi1E2JL_UtM9bSDd8=.8c2afbb1-076f-495d-b3e9-e5077f149be2@github.com>
References: <EpZd9Q-41It_aunxHpbe1blQGyN3wKm-ND8_FmtP9A0=.1317ab51-f6b0-467b-93ee-fb2a9778c61e@github.com>
 <_l7qaLS0EBSdDCO9lNkmWthX-Hb9ydWpdOVun3WewrQ=.2c203834-717c-4481-bac3-7c668cd4b2fc@github.com>
 <GjT8_41bjngKPTaHub_trg66aUrtwNoLROS-MWxc89A=.4a670172-951a-40e5-960a-ac797f63401f@github.com>
 <QtDakxXJiOqyj1ZAYk70yV3Bh7GDFzw4brIfo0-Tdi8=.7247e1c6-57b9-424f-ab3a-f2ca51ea7c0d@github.com>
 <7Nsh7xymaq8A6j6SPB_QDWH9xVZi1E2JL_UtM9bSDd8=.8c2afbb1-076f-495d-b3e9-e5077f149be2@github.com>
Message-ID: <gAoMp2UQYJbwYyxepmn3EdfGh3L9tyVlYPSCreyY9Ec=.7281479b-3670-41fd-9316-47067a9fc7c0@github.com>

On Thu, 1 Dec 2022 11:44:07 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Unfortunately it's recursing on `cleanup` in the lambda, so it can't throw checked exceptions without more refactoring. This is imitating the recursive deletion approach in another jar test, I'm happy to swap this out if you'd prefer a different approach
>
> Thanks for the reminder regarding lambada/checked exceptions. I think this can be simplified to just write the jar and test file to the current directory and then just call
> 
> 
> Files.deleteIfExists(Path.of(JAR_FILE_NAME));
> Files.deleteIfExists(Path.of(FILE_NAME));
> 
> 
> as they are the only files used by the test .

Done, thanks

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

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

From cushon at openjdk.org  Thu Dec  1 17:00:07 2022
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 1 Dec 2022 17:00:07 GMT
Subject: RFR: 8297875: jar should not compress the manifest directory entry
 [v3]
In-Reply-To: <hS22g3Dps56Hbj9yvUrSMbgykfBSsua5zTaQEM-DLyQ=.57413b78-855c-49df-9c75-b5e8539e37b4@github.com>
References: <EpZd9Q-41It_aunxHpbe1blQGyN3wKm-ND8_FmtP9A0=.1317ab51-f6b0-467b-93ee-fb2a9778c61e@github.com>
 <VCkQhnK5Ahkt4sM-4QmI1YI6lxgNnusXaOGQBswIb7s=.1b12100f-833d-46ea-a258-343f738e5125@github.com>
 <hS22g3Dps56Hbj9yvUrSMbgykfBSsua5zTaQEM-DLyQ=.57413b78-855c-49df-9c75-b5e8539e37b4@github.com>
Message-ID: <fV-Ht1484VHuCDp0Y5CCJnz5MEKinXWxrDf5cJc-U5w=.6891443d-2cac-49d4-b26d-dbe2edb22591@github.com>

On Thu, 1 Dec 2022 11:44:11 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve test
>
> test/jdk/tools/jar/ManifestDirectoryCompression.java line 81:
> 
>> 79: 
>> 80:     @Test
>> 81:     public void run() throws Exception {
> 
> Please rename `run() `to something like `TestDirectoryCompressionMethod()`.  We are trying to make new tests have more meaningful names.

Done

> test/jdk/tools/jar/ManifestDirectoryCompression.java line 83:
> 
>> 81:     public void run() throws Exception {
>> 82:         Path entryPath = Files.writeString(tempDir.resolve("test.txt"), "Some text...");
>> 83:         Path jar = tempDir.resolve("test.jar");
> 
> Please see comment above regarding the cleanup method.
> 
> One other thought you could consider given you only create a jar and file to add to the jar, is to simply add File.deleteIfExists() calls and not bother with a cleanup method given the test case is small and pretty straight forward.  Your choice though :-)

Thanks - I left the cleanup in an `@After` method for now, but I'm happy to change it.

One small reason to keep the `@After` method is that I think it ensures the cleanup happens even if the test fails and exits early, without having to wrap the test body in a `try`/`finally`.

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

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

From mcimadamore at openjdk.org  Thu Dec  1 17:22:51 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 1 Dec 2022 17:22:51 GMT
Subject: RFR: 8291359: Specification of method j.l.foreign.VaList::skip
 still deserves clarification [v2]
In-Reply-To: <VgD0_n7cpBcnT5OdL0jrSPEDwoeZF5Q3d-ZTt0dFfiA=.98dc5712-67ee-4141-8b38-bd42479bf75b@github.com>
References: <vHHYP2B3-wJHXVPjmc0bP6Raouhn3ni-M_d1A_ULlp8=.17cfc6d8-f18e-46fb-a1fe-ffdf4b816d84@github.com>
 <VgD0_n7cpBcnT5OdL0jrSPEDwoeZF5Q3d-ZTt0dFfiA=.98dc5712-67ee-4141-8b38-bd42479bf75b@github.com>
Message-ID: <ITJSxOx9YjWHr7-BpV5PxgfEMdLsI14menCBgM18_bs=.c4669ed0-19b7-44e4-bd79-11b7ed658f7e@github.com>

On Wed, 30 Nov 2022 18:54:49 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> A small clarification of the VaList spec to say that attempts to access elements through an incorrect memory layout result in undefined behavior.
>
> Jorn Vernee has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Clarify spec

src/java.base/share/classes/java/lang/foreign/VaList.java line 55:

> 53:  * and any other type that fits into a {@code long}.
> 54:  * <h2 id="safety">Safety considerations</h2>
> 55:  * The behavior of any attempts to access a value in the va list, whether through one of the {@code nextVarg} overloads

Suggestion:

 * The behavior of any attempts to access a value in the variable argument list, whether through one of the {@code nextVarg} overloads

src/java.base/share/classes/java/lang/foreign/VaList.java line 56:

> 54:  * <h2 id="safety">Safety considerations</h2>
> 55:  * The behavior of any attempts to access a value in the va list, whether through one of the {@code nextVarg} overloads
> 56:  * or {@link #skip(MemoryLayout...)}, using a memory layout other than the layout of the accessed value, or any subsequent

Not super sure what you mean here by using a layout "other than the layout of the accessed value". I think you mean the layout of the underlying value that needs to be accessed? Also, is the behavior undefined even when the VaList is created safely, from Java code?

src/java.base/share/classes/java/lang/foreign/VaList.java line 57:

> 55:  * The behavior of any attempts to access a value in the va list, whether through one of the {@code nextVarg} overloads
> 56:  * or {@link #skip(MemoryLayout...)}, using a memory layout other than the layout of the accessed value, or any subsequent
> 57:  * accesses to the same va list, is undefined.

Suggestion:

 * accesses to the same variable argument list, is undefined.

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

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

From jvernee at openjdk.org  Thu Dec  1 17:25:00 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 1 Dec 2022 17:25:00 GMT
Subject: RFR: 8291359: Specification of method j.l.foreign.VaList::skip
 still deserves clarification [v2]
In-Reply-To: <ITJSxOx9YjWHr7-BpV5PxgfEMdLsI14menCBgM18_bs=.c4669ed0-19b7-44e4-bd79-11b7ed658f7e@github.com>
References: <vHHYP2B3-wJHXVPjmc0bP6Raouhn3ni-M_d1A_ULlp8=.17cfc6d8-f18e-46fb-a1fe-ffdf4b816d84@github.com>
 <VgD0_n7cpBcnT5OdL0jrSPEDwoeZF5Q3d-ZTt0dFfiA=.98dc5712-67ee-4141-8b38-bd42479bf75b@github.com>
 <ITJSxOx9YjWHr7-BpV5PxgfEMdLsI14menCBgM18_bs=.c4669ed0-19b7-44e4-bd79-11b7ed658f7e@github.com>
Message-ID: <zL9SkQ5SiknPWVyN7kfCHP1d8_OQkqZVFrQxNjcQ9DI=.a86de67b-2930-4fd6-bfc3-e4fa5196b1cf@github.com>

On Thu, 1 Dec 2022 17:20:18 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jorn Vernee has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   Clarify spec
>
> src/java.base/share/classes/java/lang/foreign/VaList.java line 56:
> 
>> 54:  * <h2 id="safety">Safety considerations</h2>
>> 55:  * The behavior of any attempts to access a value in the va list, whether through one of the {@code nextVarg} overloads
>> 56:  * or {@link #skip(MemoryLayout...)}, using a memory layout other than the layout of the accessed value, or any subsequent
> 
> Not super sure what you mean here by using a layout "other than the layout of the accessed value". I think you mean the layout of the underlying value that needs to be accessed? Also, is the behavior undefined even when the VaList is created safely, from Java code?

Yes, I mean the layout of the underlying value that is being accessed. i.e. can't access a boolean as an int.

The behavior is undefined either way. Even when a VaList is created from Java, we create the same underlying native data structure (because we want to pass it to native code). This doesn't keep track of the layouts the list was built with, so there can still be mismatches.

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

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

From jvernee at openjdk.org  Thu Dec  1 17:28:12 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 1 Dec 2022 17:28:12 GMT
Subject: RFR: 8291359: Specification of method j.l.foreign.VaList::skip
 still deserves clarification [v3]
In-Reply-To: <vHHYP2B3-wJHXVPjmc0bP6Raouhn3ni-M_d1A_ULlp8=.17cfc6d8-f18e-46fb-a1fe-ffdf4b816d84@github.com>
References: <vHHYP2B3-wJHXVPjmc0bP6Raouhn3ni-M_d1A_ULlp8=.17cfc6d8-f18e-46fb-a1fe-ffdf4b816d84@github.com>
Message-ID: <ZIYfXGyTEIMtVXN68Ma2kTbfmuKrbMIcknAppnVLB4E=.4623b16b-0f30-4c79-b7a0-ca972c542bd2@github.com>

> A small clarification of the VaList spec to say that attempts to access elements through an incorrect memory layout result in undefined behavior.

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

  Apply suggestions from code review
  
  Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11440/files
  - new: https://git.openjdk.org/jdk/pull/11440/files/79590943..6b2f059d

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

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

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

From aph at openjdk.org  Thu Dec  1 17:30:34 2022
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 1 Dec 2022 17:30:34 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v33]
In-Reply-To: <_Gn9ItyEwKzyhunfxC5b6wz7BZzPg2qD_e-wvhEqR-Q=.5be37213-7be9-40c7-8503-392bacc1cfa9@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <lrGP8yOwAQ9WoHM5MesCdosl1FVpO6J_kLNVBY7W--M=.a1398409-df9e-4ff8-a061-f85bb6c6cbcc@github.com>
 <_Gn9ItyEwKzyhunfxC5b6wz7BZzPg2qD_e-wvhEqR-Q=.5be37213-7be9-40c7-8503-392bacc1cfa9@github.com>
Message-ID: <jTT0F31Yt1OlIx9I2TGd4sLo84_oZsfLrOo7Pb4_ajE=.fcf744fd-ede3-4c2d-927f-7456568ea8aa@github.com>

On Wed, 30 Nov 2022 21:34:59 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Unused variable
>
> src/hotspot/cpu/aarch64/aarch64.ad line 3635:
> 
>> 3633:       }
>> 3634:     } else if (_method->intrinsic_id() == vmIntrinsicID::_ensureMaterializedForStackWalk) {
>> 3635:       __ nop();
> 
> Please add a comment explaining why the nop is needed or desirable here.

It's there because C2 in this area is littered with bits of code that use magic offsets, and I don't know how to find them all. It seemed safest to keep everything the same size. Hence, a 4-byte NOP in AArch64 and a 5-byte NOP in x86.

> src/hotspot/cpu/x86/x86_64.ad line 2174:
> 
>> 2172:                      RELOC_DISP32);
>> 2173:     } else if (_method->intrinsic_id() == vmIntrinsicID::_ensureMaterializedForStackWalk) {
>> 2174:       __ addr_nop_5();
> 
> Needs a comment.  I guess this is because of how call sizes are computed.

Yes, that's my guess. I didn't want to change any offsets.

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

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

From mcimadamore at openjdk.org  Thu Dec  1 17:55:10 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 1 Dec 2022 17:55:10 GMT
Subject: RFR: 8291359: Specification of method j.l.foreign.VaList::skip
 still deserves clarification [v2]
In-Reply-To: <zL9SkQ5SiknPWVyN7kfCHP1d8_OQkqZVFrQxNjcQ9DI=.a86de67b-2930-4fd6-bfc3-e4fa5196b1cf@github.com>
References: <vHHYP2B3-wJHXVPjmc0bP6Raouhn3ni-M_d1A_ULlp8=.17cfc6d8-f18e-46fb-a1fe-ffdf4b816d84@github.com>
 <VgD0_n7cpBcnT5OdL0jrSPEDwoeZF5Q3d-ZTt0dFfiA=.98dc5712-67ee-4141-8b38-bd42479bf75b@github.com>
 <ITJSxOx9YjWHr7-BpV5PxgfEMdLsI14menCBgM18_bs=.c4669ed0-19b7-44e4-bd79-11b7ed658f7e@github.com>
 <zL9SkQ5SiknPWVyN7kfCHP1d8_OQkqZVFrQxNjcQ9DI=.a86de67b-2930-4fd6-bfc3-e4fa5196b1cf@github.com>
Message-ID: <Gdywkdba9s0tfVksRJU-8LQscoZ6bbfcfkr7P3T3Jd4=.678c15a9-b4d3-4c26-80e2-e4abac12b064@github.com>

On Thu, 1 Dec 2022 17:22:49 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/VaList.java line 56:
>> 
>>> 54:  * <h2 id="safety">Safety considerations</h2>
>>> 55:  * The behavior of any attempts to access a value in the va list, whether through one of the {@code nextVarg} overloads
>>> 56:  * or {@link #skip(MemoryLayout...)}, using a memory layout other than the layout of the accessed value, or any subsequent
>> 
>> Not super sure what you mean here by using a layout "other than the layout of the accessed value". I think you mean the layout of the underlying value that needs to be accessed? Also, is the behavior undefined even when the VaList is created safely, from Java code?
>
> Yes, I mean the layout of the underlying value that is being accessed. i.e. can't access a boolean as an int.
> 
> The behavior is undefined either way. Even when a VaList is created from Java, we create the same underlying native data structure (because we want to pass it to native code). This doesn't keep track of the layouts the list was built with, so there can still be mismatches.

Right.

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

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

From weijun at openjdk.org  Thu Dec  1 17:56:17 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 Dec 2022 17:56:17 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <nrL_Up0TmjkjNZgQtxGCZG3gkOF2eg5FiJYUK_J1kJs=.164122ef-8750-487c-abc5-e5b92bdf7c2c@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
 <JCBfRAbsgf6bH6lqeXWodGC89bWpXwpwNlv2E1aHPUI=.85727228-d8c8-4918-818a-ae6606514b99@github.com>
 <ZTmLDk0M9hsuICQeazcIat8UdUvM49UAisgTfoV8LCg=.799c1bfe-57a8-4b24-a72e-ed7f970bcf95@github.com>
 <nrL_Up0TmjkjNZgQtxGCZG3gkOF2eg5FiJYUK_J1kJs=.164122ef-8750-487c-abc5-e5b92bdf7c2c@github.com>
Message-ID: <no3fTAbXqXI9w9odDcE5nFpKzJWuUHHi9eOY04AXBAI=.fafda472-c4b3-4251-b496-f149e463bea4@github.com>

On Thu, 1 Dec 2022 16:08:39 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Sure. Trying out now...
>
> I can still see the password on screen. Here `in` is a `jdk.jshell.execution.Util` so the updated check on line 58 above failed.
> 
> $ jshell -C--add-exports -Cjava.base/sun.security.tools.keytool=ALL-UNNAMED -R--add-exports -Rjava.base/sun.security.tools.keytool=ALL-UNNAMED
> |  Welcome to JShell -- Version 20-internal
> |  For an introduction type: /help intro
> 
> jshell> sun.security.tools.keytool.Main.main("-genkeypair -keyalg EC -alias a -dname CN=A -keystore ks".split(" "))
> Enter keystore password:  changeit
> Re-enter new password: changeit
> Generating 384 bit EC (secp384r1) key pair and self-signed certificate (SHA384withECDSA) with a validity of 90 days
> 	for: CN=A

What's the expected behavior?

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

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

From darcy at openjdk.org  Thu Dec  1 18:00:11 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 1 Dec 2022 18:00:11 GMT
Subject: RFR: JDK-8297215: Update libs tests to use @enablePreview [v4]
In-Reply-To: <tc_tYnGZ-vffHa80jkOhsmVumjixoO9B-0D7xvbMo_I=.7577a2f4-b4c0-4bc8-93fe-1313077d1769@github.com>
References: <tc_tYnGZ-vffHa80jkOhsmVumjixoO9B-0D7xvbMo_I=.7577a2f4-b4c0-4bc8-93fe-1313077d1769@github.com>
Message-ID: <DGylEDvO6X5n9mKCzZpisqQo_5B6_AjFwvIWiyxBkqc=.26e1e4ad-7130-47ca-bb85-521d99e89c22@github.com>

> Similar to an update recently done for langtools tests, update the libraries regression tests to take advantage of the @enablePreview jtreg feature.

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

  Respond to review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11222/files
  - new: https://git.openjdk.org/jdk/pull/11222/files/6d11bbca..c0bef63e

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

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

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

From aph at openjdk.org  Thu Dec  1 18:01:15 2022
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 1 Dec 2022 18:01:15 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v33]
In-Reply-To: <00vRbThlo7WIZeqbqMNYNYQKiBH2aFP0O5d-swCOvtY=.f02f4b5a-fb86-4861-affd-000438b83b47@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <lrGP8yOwAQ9WoHM5MesCdosl1FVpO6J_kLNVBY7W--M=.a1398409-df9e-4ff8-a061-f85bb6c6cbcc@github.com>
 <00vRbThlo7WIZeqbqMNYNYQKiBH2aFP0O5d-swCOvtY=.f02f4b5a-fb86-4861-affd-000438b83b47@github.com>
Message-ID: <sEGbGnkCoDnklEgEleaM7GGtmE2YlZqZTuVKgA36GBs=.234fa9e9-165b-4a61-a4ba-451cc35789b6@github.com>

On Wed, 30 Nov 2022 21:39:40 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Unused variable
>
> src/hotspot/share/classfile/javaClasses.cpp line 1731:
> 
>> 1729: }
>> 1730: 
>> 1731: void java_lang_Thread::clear_scopedValueBindings(oop java_thread) {
> 
> It looks like there is only one caller of this method that takes an oop.  Would it make sense to have the caller check for the null oop, and assert that the oop is not null here?

Done.

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

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

From aph at openjdk.org  Thu Dec  1 18:01:12 2022
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 1 Dec 2022 18:01:12 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v34]
In-Reply-To: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
Message-ID: <JBQqMQkdcd25MR8uGUrLKNRLlIRxCGKY357p2dTeFnM=.687e0ad9-bf64-4651-a6c6-ce06dbcca815@github.com>

> JEP 429 implementation.

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

  Feedback from reviewers

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10952/files
  - new: https://git.openjdk.org/jdk/pull/10952/files/37441eeb..4f2716a3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=33
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=32-33

  Stats: 9 lines in 2 files changed: 5 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10952.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952

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

From lancea at openjdk.org  Thu Dec  1 18:06:17 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 1 Dec 2022 18:06:17 GMT
Subject: RFR: 8297875: jar should not compress the manifest directory entry
 [v4]
In-Reply-To: <sL7nHuMbpB_VELaadNz3leUnTEFu-KStN33EamCt6YE=.37ad0bee-c233-432c-9c9e-3db47eba721a@github.com>
References: <EpZd9Q-41It_aunxHpbe1blQGyN3wKm-ND8_FmtP9A0=.1317ab51-f6b0-467b-93ee-fb2a9778c61e@github.com>
 <sL7nHuMbpB_VELaadNz3leUnTEFu-KStN33EamCt6YE=.37ad0bee-c233-432c-9c9e-3db47eba721a@github.com>
Message-ID: <uuk1vCPqFKzQ8VrD37HYPERfis8s1LAaOR6ZK4liic4=.dd8b1bbe-7ad3-4298-a164-b297aaf37b5f@github.com>

On Thu, 1 Dec 2022 17:00:02 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This causes jar to not compress the `META-INF/` directory entry, for consistency with the handling of other directory entries and compliance with `APPNOTE.TXT`, and for compatibility with other zip implementations.
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test improvements

Thank you for the updates.  I think this is good to go :-)

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

Marked as reviewed by lancea (Reviewer).

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

From thomas.stuefe at gmail.com  Thu Dec  1 18:14:52 2022
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 1 Dec 2022 19:14:52 +0100
Subject: Extend Native Memory Tracking over the JDK ? (was: Proposal:
 track zlib native memory usage with NMT)
In-Reply-To: <CAA-vtUxrP49w523EQ3yKFh4Zo5W+HMtqpGcsUxOEMkwZUOQ0zQ@mail.gmail.com>
References: <CAA-vtUzvyqb_LZ9d1Z80oSvzyqpi89053O3B+oDZF4oZ85CuZg@mail.gmail.com>
 <c5db2105-3b78-0b77-779f-011c8649f476@oracle.com>
 <CAA-vtUxrP49w523EQ3yKFh4Zo5W+HMtqpGcsUxOEMkwZUOQ0zQ@mail.gmail.com>
Message-ID: <CAA-vtUxB8Z1CD9EYMaMT8OJjw6unwCYd7ONBvQRCVQqO4VTUZQ@mail.gmail.com>

Are there any opinions about whether or not to extend NMT across the JDK?

This blocks https://bugs.openjdk.org/browse/JDK-8296360, and I had a PR
prepared as https://github.com/openjdk/jdk/pull/10988. Originally I was
hoping to get this into JDK 20, but I don't think that is realistic
anymore. I am fine with postponing my work in favor of a baseline
discussion, but so far there is very little discussion about this topic.

How should I proceed?

Thanks, Thomas



On Wed, Nov 9, 2022 at 8:12 AM Thomas St?fe <thomas.stuefe at gmail.com> wrote:

> Hi Alan,
>
> (replaced hotspot-runtime-dev with hotspot-dev, since its more of a
> general topic)
>
> thank you for your time!
>
> I am very happy to talk this through. I think native memory observability
> in the JDK (and customer code!) is sorely lacking. Witness the countless
> "where did my native memory go" blog articles. At SAP we have been
> struggling with this topic for a long time and have come up with a mixture
> of solutions. The aforementioned tracker was one, which extended our
> version of NMT across the JDK. Our SapMachine MallocTracer, which allows us
> to trace uninstrumented customer code, another. We even experimented with
> exchanging the allocator (using jemalloc) to gain insights. But that is a
> whole different topic with deep logistical implications, I don't want to
> touch it here. Exchanging the allocator does not help to observe virtual
> memory or the brk segment, of course.
>
> And to make the picture complete, another insight we currently lack is the
> implicit allocator overhead, which can be very significant and is hidden by
> the libc. We also have observability for that in the SapMachine, and I miss
> it in OpenJDK.
>
> As you noticed, my original intent was just to instrument Zlib and
> possibly improve tracking for DBBs. Although, thinking beyond that, another
> attractive instrumentation target would be mapped NIO buffers at least.
>
> So I think native memory observability is important. Arguably we could
> even extend observability to cover other OS resources, e.g. file handles.
> If we shift code around, to java/Panama: data that move the java heap does
> not need to be tracked, but other memory will always come from one of the
> basic system APIs, regardless of who allocates it and where in the stack
> allocation happens. Be it native JDK code, Panama, or even customer JNI
> code.
>
> If we agree on the importance of native memory observability, then I
> believe NMT is the right tool for it. It is a good tool. The machinery is
> already there. It covers both C-heap and virtual memory APIs, as well as
> thread stacks, and could easily be extended to cover sbrk if needed. And I
> assume that whatever shape OpenJDK takes on in the future, there always
> will be a libjvm.so at its core, so we will always have it. But even if
> not, NMT could be separated from libjvm.so quite easily, since it has no
> deep ties with the JVM.
>
> About coupling JVM with outside code: We don't have to directly link
> against libjvm.so. We can keep things loose if the intent is to be runnable
> without a JVM, or be JVM-version-agnostic. That could take the form of a
> function-pointer interface like JVMTI. Or outside code could dynamically
> dlsym the JVM allocation hooks. In any case gracefully falling back to
> system allocation routines when necessary.
>
> And I agree, polluting the NMT tag space with outside meaning is ugly. I
> only did it because I planned to go no further than instrumenting Zlib and
> possibly DBBs. But if we take this further, my preferred solution would be
> a reserved tag range or -ranges for outside use, whose inner meaning would
> be opaque to the JVM. Kind of like SIGRTMIN+SIGRTMAX. Then, outside code
> could register tags and their meta information with the JVM, or we find a
> different way to convey the tag meaning to NMT (config files, or
> callbacks). That could even be opened up for customer use.
>
> This also touches on another question, that of NMT tag space. NMT tags are
> very useful since they allow cheap tracking without capturing call stacks.
> However, tags are underused and show growing pains since they are too
> one-dimensional and restrictive. We had competing interests in the past
> about tag granularity. It is all over the place. We have coarse-grained
> tags like "mtThread", and very fine-grained ones like "mtObjectMonitor".
> There are several ways we could improve, e.g., by making them combinable
> like UL does, or allowing for a hierarchy of them - either a hard-wired
> limited one like "domain"+"tag", or an unlimited tree-like one. Technically
> interesting since whatever the new encoding is, they still must fit into a
> malloc header. I opened https://bugs.openjdk.org/browse/JDK-8281819 to
> track ideas like these.
>
> Instrumenting Panama allocations, including the ability to tag
> allocations, would be a very good idea. For instance, if we ever remove the
> native Zlib layer and convert it to java using Panama, we can do the same
> with Panama I do now natively - use the Zlib zalloc interface to hook in
> JVM memory allocation functions. The result could be completely identical,
> and the end user looking at the NMT output need never know that anything
> changed.
>
> And that goes for all instrumentation - if today we add it to JNI code,
> and that code gets removed tomorrow, we can add it to Panama code too.
> Unless data structures move to the heap, in which case there is no need to
> track them.
>
> You mentioned that NMT was more of an in-house support tool. Our
> experience is different. Even though it was positioned as a tool for JVM
> developers, and we never cared for the backward compatibility or
> consistency, it gets used a *lot* by our customers. We have to explain its
> output frequently. Also, many blog articles exist documenting its use. So,
> maybe it would be okay to elevate it to a user-facing tool since it seems
> to occupy that role anyway. We may also open up consumption of NMT results
> via java APIs, or expose its results via MXBeans.
>
> If this is to be a JEP, okay, but I'm afraid it would stall things a bit.
> I am interested in getting a simpler and quicker solution for older support
> releases at least, possibly based on my PR. I know that would be
> unconventional though.
>
> Thank you,
>
> Thomas
>
>
> On Sun, Nov 6, 2022 at 9:31 AM Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
>
>> On 04/11/2022 16:54, Thomas St?fe wrote:
>> > Hi all,
>> >
>> > I am currently working on https://bugs.openjdk.org/browse/JDK-8296360;
>> > I was preparing the final PR [1], but then Alan did ask me to discuss
>> > this on core-libs first.
>> >
>> > Backstory:
>> >
>> > NMT tracks hotspot native allocations but does not cover the JDK
>> > libraries (small exception: Unsafe.AllocateMemory). However, the
>> > native memory footprint of JDK libraries can be significant. We have
>> > no in-VM tracker for these and need tools like valgrind or our
>> > SapMachine MallocTracer [2] to observe them.
>>
>> Thanks for starting a discussion on this as this is a topic that
>> requires agreement from several areas. If this is the start of something
>> bigger, where you want to have all allocation sites in the libraries
>> using NMT, then I think it needs a write-up, maybe a JEP.
>>
>> For starters, I think it needs some agreement on using NMT for memory
>> allocated outside of libjvm. You mentioned Unsafe as an exception but
>> that is implemented in the VM so you get tracking for free, albeit I
>> think all allocations are in the "mtOther" category.
>>
>> A general concern is that it creates more coupling between the VM code
>> and the libraries code. As you probably know, we've removed most of the
>> dependences on JVM_* functions from non-core areas over many years. So I
>> think that needs consideration as I assume we don't want
>> memory/allocation.hpp declaring a dozen catagories for allocations done
>> in say java.desktop module for example. Maybe your proposal will be
>> strictly limited to java.base but even then, do we really want the VM
>> even knowing about categories that are specific to zip compression or
>> decompression?
>>
>> There are probably longer term trends that should be part of the
>> discussion too. One general trend is that "run time" is becoming more
>> and more a hybrid of code in libvm and the Java libraries. Lambdas,
>> module system, virtual threads implementations are a few examples in the
>> last few release. This comes with many "Java on Java" challenges,
>> including serviceability where users of the platform will expect tools
>> to just work and won't care where the code is. NMT is probably more for
>> support teams and not something that most developers will ever use but I
>> think is part of the challenge of having serviceability solutions "just
>> work".
>>
>> In addition to having more of the Java runtime written in Java, there
>> will likely be less JNI code in the future. It's very possible that the
>> JNI code (including the JNI methods in libzip) will be replaced with
>> code that uses Panama memory and linker APIs once they are become
>> permanent. The effect of that would to have a lot of the memory
>> allocations be tracked in the mtOther category again. Maybe integration
>> with memory tracking should be looked at in conjunction with these APIs
>> and this migration. I could imagine the proposed "Arena" API
>> (MemorySession in Java 19) having some integration with NMT and it might
>> be interesting to look into that.
>>
>> So yes, this topic does need broader discussion and it might be a bit
>> premature to start with a PR for libzip without talking about the bigger
>> picture first.
>>
>> -Alan
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221201/11472e41/attachment.htm>

From aph at openjdk.org  Thu Dec  1 18:24:38 2022
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 1 Dec 2022 18:24:38 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v35]
In-Reply-To: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
Message-ID: <C6tDzFY5kyeKElIvJGNXlyb8xUkM8vwSduPIUBmqIv0=.33c28904-f95f-4d7e-83d8-4cac31303500@github.com>

> JEP 429 implementation.

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

  Feedback from reviewers

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10952/files
  - new: https://git.openjdk.org/jdk/pull/10952/files/4f2716a3..97a82b7e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=34
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=33-34

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

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

From aph at openjdk.org  Thu Dec  1 18:24:39 2022
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 1 Dec 2022 18:24:39 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v33]
In-Reply-To: <M18a3ZLOyyHRpwfez7cHkBr6ZNLUQq7VGfBm_VZhOYU=.b2fbaa34-d51a-4d69-a06f-3df096c2b65f@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <lrGP8yOwAQ9WoHM5MesCdosl1FVpO6J_kLNVBY7W--M=.a1398409-df9e-4ff8-a061-f85bb6c6cbcc@github.com>
 <M18a3ZLOyyHRpwfez7cHkBr6ZNLUQq7VGfBm_VZhOYU=.b2fbaa34-d51a-4d69-a06f-3df096c2b65f@github.com>
Message-ID: <kd8HANQad1t9iix1FYpGGxTxjj3r7B_H4LoY4xf9oXM=.df135f86-2690-491f-a62a-faa56eccdc33@github.com>

On Wed, 30 Nov 2022 21:47:47 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Unused variable
>
> src/hotspot/share/prims/jvm.cpp line 1385:
> 
>> 1383:   vframeStream vfst(thread);
>> 1384:   for(; !vfst.at_end(); vfst.next()) {
>> 1385:     int loc = 0;
> 
> Use -1 instead (see below)?

Good idea, thanks.

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

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

From darcy at openjdk.org  Thu Dec  1 18:53:38 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 1 Dec 2022 18:53:38 GMT
Subject: RFR: JDK-8296149: Start of release updates for JDK 21 [v2]
In-Reply-To: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
Message-ID: <ffGFfKVVqXYcANRB1UdVKkYHUs2obgp3P1aF8mv2bUU=.1a8c9d0c-5110-4516-8d25-ffa4956532f2@github.com>

> Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21.

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

 - Update symbol information for JDK 20 build 26.
 - Merge branch 'master' into JDK-8296149
 - Merge branch 'master' into JDK-8296149
 - Fix failed HotSpot regression tests.
 - Merge branch 'master' into JDK-8296149
 - Update symbol information to JDK 20 build 24.
 - Merge branch 'master' into JDK-8296149
 - Merge branch 'master' into JDK-8296149
 - Update symbols for JDK 20 b23.
 - Merge branch 'master' into JDK-8296149
 - ... and 4 more: https://git.openjdk.org/jdk/compare/c9a32e22...89731cb2

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10924/files
  - new: https://git.openjdk.org/jdk/pull/10924/files/5810345e..89731cb2

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

  Stats: 14898 lines in 525 files changed: 8720 ins; 3390 del; 2788 mod
  Patch: https://git.openjdk.org/jdk/pull/10924.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10924/head:pull/10924

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

From iris at openjdk.org  Thu Dec  1 19:18:28 2022
From: iris at openjdk.org (Iris Clark)
Date: Thu, 1 Dec 2022 19:18:28 GMT
Subject: RFR: JDK-8296149: Start of release updates for JDK 21 [v2]
In-Reply-To: <ffGFfKVVqXYcANRB1UdVKkYHUs2obgp3P1aF8mv2bUU=.1a8c9d0c-5110-4516-8d25-ffa4956532f2@github.com>
References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
 <ffGFfKVVqXYcANRB1UdVKkYHUs2obgp3P1aF8mv2bUU=.1a8c9d0c-5110-4516-8d25-ffa4956532f2@github.com>
Message-ID: <Z6o91npEbHUWgq5J7rXo9O4ftM206E2Iipsqe5_Cv6Q=.e37cf7c0-ec5f-4647-b2dc-8f8f75fef395@github.com>

On Thu, 1 Dec 2022 18:53:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Update symbol information for JDK 20 build 26.
>  - Merge branch 'master' into JDK-8296149
>  - Merge branch 'master' into JDK-8296149
>  - Fix failed HotSpot regression tests.
>  - Merge branch 'master' into JDK-8296149
>  - Update symbol information to JDK 20 build 24.
>  - Merge branch 'master' into JDK-8296149
>  - Merge branch 'master' into JDK-8296149
>  - Update symbols for JDK 20 b23.
>  - Merge branch 'master' into JDK-8296149
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/03d7ad1d...89731cb2

Marked as reviewed by iris (Reviewer).

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

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

From egahlin at openjdk.org  Thu Dec  1 19:21:23 2022
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 1 Dec 2022 19:21:23 GMT
Subject: RFR: JDK-8297215: Update libs tests to use @enablePreview [v4]
In-Reply-To: <DGylEDvO6X5n9mKCzZpisqQo_5B6_AjFwvIWiyxBkqc=.26e1e4ad-7130-47ca-bb85-521d99e89c22@github.com>
References: <tc_tYnGZ-vffHa80jkOhsmVumjixoO9B-0D7xvbMo_I=.7577a2f4-b4c0-4bc8-93fe-1313077d1769@github.com>
 <DGylEDvO6X5n9mKCzZpisqQo_5B6_AjFwvIWiyxBkqc=.26e1e4ad-7130-47ca-bb85-521d99e89c22@github.com>
Message-ID: <tEEjAkyD6F_NsLSl42H6kGQonQaYyypvb12xfRbXKCo=.6b76aad7-8f0e-41fd-a8e4-5907e706a905@github.com>

On Thu, 1 Dec 2022 18:00:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Similar to an update recently done for langtools tests, update the libraries regression tests to take advantage of the @enablePreview jtreg feature.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

test/jdk/jdk/jfr/threading/TestDeepVirtualStackTrace.java line 46:

> 44:  * @modules jdk.jfr/jdk.jfr.internal
> 45:  * @enablePreview
> 46:  * @compile TestDeepVirtualStackTrace.java

Is compilation needed here?

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

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

From naoto at openjdk.org  Thu Dec  1 19:34:35 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 1 Dec 2022 19:34:35 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <no3fTAbXqXI9w9odDcE5nFpKzJWuUHHi9eOY04AXBAI=.fafda472-c4b3-4251-b496-f149e463bea4@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
 <JCBfRAbsgf6bH6lqeXWodGC89bWpXwpwNlv2E1aHPUI=.85727228-d8c8-4918-818a-ae6606514b99@github.com>
 <ZTmLDk0M9hsuICQeazcIat8UdUvM49UAisgTfoV8LCg=.799c1bfe-57a8-4b24-a72e-ed7f970bcf95@github.com>
 <nrL_Up0TmjkjNZgQtxGCZG3gkOF2eg5FiJYUK_J1kJs=.164122ef-8750-487c-abc5-e5b92bdf7c2c@github.com>
 <no3fTAbXqXI9w9odDcE5nFpKzJWuUHHi9eOY04AXBAI=.fafda472-c4b3-4251-b496-f149e463bea4@github.com>
Message-ID: <ktUnahpoaSsO7Ycw0Bav_j-Tb0iOA-4S3BpmK7h8LWo=.ad9b526a-f0d8-4963-a1c3-1f098d0fcbc6@github.com>

On Thu, 1 Dec 2022 17:53:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I can still see the password on screen. Here `in` is a `jdk.jshell.execution.Util` so the updated check on line 58 above failed.
>> 
>> $ jshell -C--add-exports -Cjava.base/sun.security.tools.keytool=ALL-UNNAMED -R--add-exports -Rjava.base/sun.security.tools.keytool=ALL-UNNAMED
>> |  Welcome to JShell -- Version 20-internal
>> |  For an introduction type: /help intro
>> 
>> jshell> sun.security.tools.keytool.Main.main("-genkeypair -keyalg EC -alias a -dname CN=A -keystore ks".split(" "))
>> Enter keystore password:  changeit
>> Re-enter new password: changeit
>> Generating 384 bit EC (secp384r1) key pair and self-signed certificate (SHA384withECDSA) with a validity of 90 days
>> 	for: CN=A
>
> What's the expected behavior?

I confirmed that the standalone `keytool` did not echo the input, which should be OK for this IMO.

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

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

From jjg at openjdk.org  Thu Dec  1 19:36:16 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 1 Dec 2022 19:36:16 GMT
Subject: RFR: 8296546: Add @spec tags to API [v4]
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <0SjUCtMo9Z9Oiq-ITr1-CA8_RoibtPkzfAZPdaR4tSU=.950b338f-e68c-4825-8831-872fbbd04956@github.com>

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

Jonathan Gibbons has updated the pull request with a new target base 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:

 - Change ietf.org URLs to use rfc-editor.org
 - Merge remote-tracking branch 'upstream/master' into 8296546.add-spec-tags
 - Remove updates from unexported files
 - Prefix RFC titles with `RFC NNNN:`
 - JDK-8296547: Add @spec tags to API

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11073/files
  - new: https://git.openjdk.org/jdk/pull/11073/files/3905ac83..07882ffc

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

  Stats: 83309 lines in 1834 files changed: 38491 ins; 27762 del; 17056 mod
  Patch: https://git.openjdk.org/jdk/pull/11073.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11073/head:pull/11073

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

From jjg at openjdk.org  Thu Dec  1 19:40:16 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 1 Dec 2022 19:40:16 GMT
Subject: RFR: 8296546: Add @spec tags to API [v4]
In-Reply-To: <4PBH5ikKAEFzv_15GkmEi9BxdB60gRMrDJIBEIaEy0Q=.f335bafb-3fbf-4902-8121-cdf99ed92589@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <4PBH5ikKAEFzv_15GkmEi9BxdB60gRMrDJIBEIaEy0Q=.f335bafb-3fbf-4902-8121-cdf99ed92589@github.com>
Message-ID: <q9avJLkpJ4wgyuswrLm_YSdqUD_5GNnWYPEux_Xy7OI=.cb1704f2-7452-435e-984e-1aeb917ac907@github.com>

On Thu, 10 Nov 2022 23:51:19 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base 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:
>> 
>>  - Change ietf.org URLs to use rfc-editor.org
>>  - Merge remote-tracking branch 'upstream/master' into 8296546.add-spec-tags
>>  - Remove updates from unexported files
>>  - Prefix RFC titles with `RFC NNNN:`
>>  - JDK-8296547: Add @spec tags to API
>
> src/java.base/share/classes/java/lang/Character.java line 172:
> 
>> 170:  * occur. For example, in a future release, synchronization may fail.
>> 171:  *
>> 172:  * @spec https://www.unicode.org/reports/tr27 Unicode 3.1.0
> 
> This should probably be removed, as the original link (explaining `U+n` notation) is broken.

@naotoj The edits are driven by a script, using info about existing links in the same doc comment. If you don't think this reference is appropriate, it would be better to either remove the existing link (and I'll regenerate this patch) or else this patch goes through and you fix up both the existing link and the `@spec` tag afterwards.

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

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

From jjg at openjdk.org  Thu Dec  1 19:57:33 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 1 Dec 2022 19:57:33 GMT
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <Y0Qj1qIytaKulH9059ekA6usyUpypf7mVymxst4jwDs=.bb77135a-cdf2-4d3e-9801-c417bdf53e37@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
 <Y0Qj1qIytaKulH9059ekA6usyUpypf7mVymxst4jwDs=.bb77135a-cdf2-4d3e-9801-c417bdf53e37@github.com>
Message-ID: <XVUIV3LMzWV4Y-0veldczkRr4bD_X-2JxbRLJRDikeI=.36f81c4a-f467-4352-90ba-cc3fc656791f@github.com>

On Wed, 23 Nov 2022 23:04:36 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove updates from unexported files
>
> src/java.xml/share/classes/javax/xml/XMLConstants.java line 35:
> 
>> 33:  * @spec https://www.w3.org/TR/REC-xml-names Namespaces in XML 1.0 (Third Edition)
>> 34:  * @spec https://www.w3.org/TR/xml-names11 Namespaces in XML 1.1 (Second Edition)
>> 35:  * @spec https://www.w3.org/TR/xmlschema-1 XML Schema Part 1: Structures Second Edition
> 
> Hi Jon,
> 
> I would agree with what Alan said earlier that the @see ref can be dropped. This particular class (XMLConstants.java [1]) is a good example for that argument: in the resulting javadoc, 5 specs were listed in the "External Specifications" section, 6 in "See Also:", and then they were listed again for each field. That's a lot of duplicates. Adding to the confusion was that the @spec and @see were not always the same, e.g. @spec XML 1.0.
> points to the fifth edition while @see second.
> 
> A minor comment is that the '@spec's were rendered in one line while the @see refs a list. I would see the later is easier to read.
> 
> [1] http://cr.openjdk.java.net/~jjg/8296546/api.00/java.xml/javax/xml/XMLConstants.html

The presentation of lists of `@spec` tags was fixed separately (JDK-8297802), and is incorporated into the latest docs that demo this work.   The same algorithm is now used for both `@see` and `@spec` tags ... if the links are short and do not contain commas, they will be displayed as an inline list; otherwise, they will be displayed in a bulleted list.

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

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

From jonathan.gibbons at oracle.com  Thu Dec  1 19:59:29 2022
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 1 Dec 2022 11:59:29 -0800
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <6eb484c9-2652-0e4d-ac6d-f13f3810795b@comcast.net>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
 <JtvVGemz10-N9otE53_d4qnDX55iqR82daQ2EAFXdTM=.983f7514-3c5b-40af-a60d-0210cfec43a4@github.com>
 <6eb484c9-2652-0e4d-ac6d-f13f3810795b@comcast.net>
Message-ID: <4f9a44bb-5337-750c-960e-3d04cca90def@oracle.com>

Mike,

Thank you for the additional info.

In general, the intent of this patch is to leverage the existing links 
in the doc comments, but given that there is now an intent to update 
those links as well, I have incorporated the change into the latest update.

-- Jon

On 11/28/22 7:14 PM, Michael StJohns wrote:
> Hi -
>
> I need to repeat again.? Please avoid using www.ietf.org as the URL 
> base for referencing RFCs.? The appropriate location is 
> www.rfc-editor.org and is going to be more stable in the long run than 
> any reference to an RFC that runs through the IETF's website.? These 
> two websites have different purposes, and the structure of the IETF 
> website has changed at least once recently and may change again 
> relatively (~5 years) soon.
>
> The most general and correct form for referencing RFCs is 
> "https://www.rfc-editor.org/info/rfc<number>"? That will get you to 
> the front page with pointers to all of the current semi-canonical 
> versions of the spec (e.g. text, pdf-a, html, and xml).
>
> Mike
>
>
>
> On 11/28/2022 6:27 PM, Phil Race wrote:
>> On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons <jjg at openjdk.org> 
>> wrote:
>>
>>>> Please review a "somewhat automated" change to insert `@spec` tags 
>>>> into doc comments, as appropriate, to leverage the recent new 
>>>> javadoc feature to generate a new page listing the references to 
>>>> all external specifications listed in the `@spec` tags.
>>>>
>>>> "Somewhat automated" means that I wrote and used a temporary 
>>>> utility to scan doc comments looking for HTML links to selected 
>>>> sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may 
>>>> be in the main description of a doc comment, or in `@see` tags. For 
>>>> each link, the URL is examined, and "normalized", and inserted into 
>>>> the doc comment with a new `@spec` tag, giving the link and tile 
>>>> for the spec.
>>>>
>>>> "Normalized" means...
>>>> * Use `https:` where possible (includes pretty much all cases)
>>>> * Use a single consistent host name for all URLs coming from the 
>>>> same spec site (i.e. don't use different aliases for the same site)
>>>> * Point to the root page of a multi-page spec
>>>> * Use a consistent form of the spec, preferring HTML over plain 
>>>> text where both are available (this mostly applies to IETF specs)
>>>>
>>>> In addition, a "standard" title is determined for all specs,? 
>>>> determined either from the content of the (main) spec page or from 
>>>> site index pages.
>>>>
>>>> The net effect is (or should be) that **all** the changes are to 
>>>> just **add** new `@spec` tags, based on the links found in each doc 
>>>> comment. There should be no other changes to the doc comments, or 
>>>> to the implementation of any classes and interfaces.
>>>>
>>>> That being said, the utility I wrote does have additional 
>>>> abilities, to update the links that it finds (e.g. changing to use 
>>>> `https:` etc,) but those features are _not_ being used here, but 
>>>> could be used in followup PRs if component teams so desired. I did 
>>>> notice while working on this overall feature that many of our links 
>>>> do point to "outdated" pages, some with eye-catching notices 
>>>> declaring that the spec has been superseded. Determining how, when 
>>>> and where to update such links is beyond the scope of this PR.
>>>>
>>>> Going forward, it is to be hoped that component teams will maintain 
>>>> the underlying links, and the URLs in `@spec` tags, such that if 
>>>> references to external specifications are updated, this will 
>>>> include updating the `@spec` tags.
>>>>
>>>> To see the effect of all these new `@spec` tags, see 
>>>> http://cr.openjdk.java.net/~jjg/8296546/api.00/
>>>>
>>>> In particular, see the new [External 
>>>> Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) 
>>>> page, which you can also find via the new link near the top of the 
>>>> [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) 
>>>> pages.
>>> Jonathan Gibbons has updated the pull request incrementally with one 
>>> additional commit since the last revision:
>>>
>>> ?? Remove updates from unexported files
>> src/java.desktop/share/classes/java/awt/package-info.java line 58:
>>
>>> 56:? *???? <li><a href="doc-files/Modality.html">The AWT Modality</a>
>>> 57:? *???? <li><a href="{@docRoot}/../specs/AWT_Native_Interface.html">
>>> 58:? *????????????????? The Java AWT Native Interface (JAWT)</a>
>> Why only 1 of these 3 ?
>>
>> src/java.desktop/share/classes/java/awt/package-info.java line 62:
>>
>>> 60:? *
>>> 61:? * @spec AWT_Native_Interface.html The Java AWT Native Interface 
>>> Specification and Guide
>>> 62:? * @since 1.0
>> I wonder if links to html we include in the javadoc should be really 
>> treated in the same manner as referecnes to externally defined 
>> specifactions ?
>> But I also wonder why only the native_interface spec was added and 
>> not the other two ?
>>
>> src/java.desktop/share/classes/javax/imageio/plugins/tiff/BaselineTIFFTagSet.java 
>> line 226:
>>
>>> 224:????? * @spec https://www.ietf.org/rfc/rfc1951.html RFC 1951: 
>>> DEFLATE Compressed Data Format Specification version 1.3
>>> 225:????? * @see #TAG_COMPRESSION
>>> 226:????? * @see <a 
>>> href="https://tools.ietf.org/html/rfc1951">DEFLATE specification</a>
>> Does having @spec and @see mean we have two clickable links to the 
>> same place adjacent to each other ?
>>
>> -------------
>>
>> PR: https://git.openjdk.org/jdk/pull/11073
>
>

From darcy at openjdk.org  Thu Dec  1 20:32:53 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 1 Dec 2022 20:32:53 GMT
Subject: RFR: JDK-8297215: Update libs tests to use @enablePreview [v4]
In-Reply-To: <tEEjAkyD6F_NsLSl42H6kGQonQaYyypvb12xfRbXKCo=.6b76aad7-8f0e-41fd-a8e4-5907e706a905@github.com>
References: <tc_tYnGZ-vffHa80jkOhsmVumjixoO9B-0D7xvbMo_I=.7577a2f4-b4c0-4bc8-93fe-1313077d1769@github.com>
 <DGylEDvO6X5n9mKCzZpisqQo_5B6_AjFwvIWiyxBkqc=.26e1e4ad-7130-47ca-bb85-521d99e89c22@github.com>
 <tEEjAkyD6F_NsLSl42H6kGQonQaYyypvb12xfRbXKCo=.6b76aad7-8f0e-41fd-a8e4-5907e706a905@github.com>
Message-ID: <f8GBacBPh2s819saTZKvrufinFON7xN1zC9OH-rsiZg=.5e8c7742-8fa2-4164-ac37-6e6f9a589a3c@github.com>

On Thu, 1 Dec 2022 19:19:01 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to review feedback.
>
> test/jdk/jdk/jfr/threading/TestDeepVirtualStackTrace.java line 46:
> 
>> 44:  * @modules jdk.jfr/jdk.jfr.internal
>> 45:  * @enablePreview
>> 46:  * @compile TestDeepVirtualStackTrace.java
> 
> Is compilation needed here?

For the two tests that compiled a single file, I remove the @compile directive. Any additional refactoring left for future work.

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

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

From darcy at openjdk.org  Thu Dec  1 20:32:49 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 1 Dec 2022 20:32:49 GMT
Subject: RFR: JDK-8297215: Update libs tests to use @enablePreview [v5]
In-Reply-To: <tc_tYnGZ-vffHa80jkOhsmVumjixoO9B-0D7xvbMo_I=.7577a2f4-b4c0-4bc8-93fe-1313077d1769@github.com>
References: <tc_tYnGZ-vffHa80jkOhsmVumjixoO9B-0D7xvbMo_I=.7577a2f4-b4c0-4bc8-93fe-1313077d1769@github.com>
Message-ID: <UxH_zMeP2zKV67K227WheyU8GP4eWiYKq3991_3Q86Y=.adb1ab99-60b2-4bf9-904b-de41980fb234@github.com>

> Similar to an update recently done for langtools tests, update the libraries regression tests to take advantage of the @enablePreview jtreg feature.

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

 - Remove unnecessary @compile directives.
 - Merge branch 'master' into JDK-8297215
 - Respond to review feedback.
 - Respond to review feedback.
 - Merge branch 'master' into JDK-8297215
 - Respond to review feedback.
 - JDK-8297215: Update libs tests to use @enablePreview

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11222/files
  - new: https://git.openjdk.org/jdk/pull/11222/files/c0bef63e..d03ba044

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

  Stats: 6073 lines in 149 files changed: 3996 ins; 1399 del; 678 mod
  Patch: https://git.openjdk.org/jdk/pull/11222.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11222/head:pull/11222

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

From darcy at openjdk.org  Thu Dec  1 20:41:35 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 1 Dec 2022 20:41:35 GMT
Subject: Integrated: JDK-8297215: Update libs tests to use @enablePreview
In-Reply-To: <tc_tYnGZ-vffHa80jkOhsmVumjixoO9B-0D7xvbMo_I=.7577a2f4-b4c0-4bc8-93fe-1313077d1769@github.com>
References: <tc_tYnGZ-vffHa80jkOhsmVumjixoO9B-0D7xvbMo_I=.7577a2f4-b4c0-4bc8-93fe-1313077d1769@github.com>
Message-ID: <E3RZJnrbnK2T55GDFJ9CZRHQ8_9cEvHaG-tvWARXOUY=.da2a1630-861a-40e2-9d5a-daa2d4cff3a5@github.com>

On Thu, 17 Nov 2022 21:48:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Similar to an update recently done for langtools tests, update the libraries regression tests to take advantage of the @enablePreview jtreg feature.

This pull request has now been integrated.

Changeset: 770ff5a8
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/770ff5a812d7b895ed2badfef9bb4e0b211d55bb
Stats:     101 lines in 35 files changed: 12 ins; 2 del; 87 mod

8297215: Update libs tests to use @enablePreview

Reviewed-by: alanb, sspitsyn

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

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

From jonathan.gibbons at oracle.com  Thu Dec  1 21:19:40 2022
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 1 Dec 2022 13:19:40 -0800
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <JtvVGemz10-N9otE53_d4qnDX55iqR82daQ2EAFXdTM=.983f7514-3c5b-40af-a60d-0210cfec43a4@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
 <JtvVGemz10-N9otE53_d4qnDX55iqR82daQ2EAFXdTM=.983f7514-3c5b-40af-a60d-0210cfec43a4@github.com>
Message-ID: <0ca26da7-b15a-26e4-d809-0db563d42ffe@oracle.com>


On 11/28/22 3:27 PM, Phil Race wrote:
> On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:
>
>>> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
>>>
>>> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
>>>
>>> "Normalized" means...
>>> * Use `https:` where possible (includes pretty much all cases)
>>> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
>>> * Point to the root page of a multi-page spec
>>> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
>>>
>>> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
>>>
>>> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
>>>
>>> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
>>>
>>> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
>>>
>>> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
>>>
>>> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.
>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    Remove updates from unexported files
> src/java.desktop/share/classes/java/awt/package-info.java line 58:
>
>> 56:  *     <li><a href="doc-files/Modality.html">The AWT Modality</a>
>> 57:  *     <li><a href="{@docRoot}/../specs/AWT_Native_Interface.html">
>> 58:  *                  The Java AWT Native Interface (JAWT)</a>
> Why only 1 of these 3 ?

Only one is a link outside of the overall api/ documentation hierarchy 
(i.e. the one whose URL starts with {@docRoot}/../specs/), which is the 
focus of the `@spec` tag.? The other two links (only one shown in your 
email) both point to documentation within the same package.


>
> src/java.desktop/share/classes/java/awt/package-info.java line 62:
>
>> 60:  *
>> 61:  * @spec AWT_Native_Interface.html The Java AWT Native Interface Specification and Guide
>> 62:  * @since 1.0
> I wonder if links to html we include in the javadoc should be really treated in the same manner as referecnes to externally defined specifactions ?
> But I also wonder why only the native_interface spec was added and not the other two ?

The patch is generated by running a tool that detects existing links to 
either the sibling `specs` directory or to well-known hosts that provide 
specifications used by JDK.? It would be a feature-enhancement of the 
`@spec` tag to also accept "stand-alone" HTML files within the `api/` 
hierarchy of pages.


>
> src/java.desktop/share/classes/javax/imageio/plugins/tiff/BaselineTIFFTagSet.java line 226:
>
>> 224:      * @spec https://www.ietf.org/rfc/rfc1951.html RFC 1951: DEFLATE Compressed Data Format Specification version 1.3
>> 225:      * @see #TAG_COMPRESSION
>> 226:      * @see <a href="https://tools.ietf.org/html/rfc1951">DEFLATE specification</a>
> Does having @spec and @see mean we have two clickable links to the same place adjacent to each other ?

At this time yes, although the tooling does currently allow `@see` tags 
to be removed if the URL _and title_ match that used for the `@spec` 
tag.??? Not all `@see` tags to a spec should be removed, since some may 
point to places within a spec, perhaps using a `#fragment` identifier, 
or to a sub-page within a multi-page spec.? It is my expectation that we 
may way to do a manual pass over the doc comments to examine places 
where there may be duplication, such that the `@see` tag can be updated 
and/ore removed.? That manual pass might also include updating to more 
normative URLs ... see the separate email discussion in the PR comments 
about changing `ietf.org` to `rfc-editor.org`.??? Any such manual work 
would need to be done in conjunction with the relevant component teams.


>
> -------------
>
> PR: https://git.openjdk.org/jdk/pull/11073

From naoto at openjdk.org  Thu Dec  1 21:23:09 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 1 Dec 2022 21:23:09 GMT
Subject: RFR: 8296546: Add @spec tags to API [v4]
In-Reply-To: <q9avJLkpJ4wgyuswrLm_YSdqUD_5GNnWYPEux_Xy7OI=.cb1704f2-7452-435e-984e-1aeb917ac907@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <4PBH5ikKAEFzv_15GkmEi9BxdB60gRMrDJIBEIaEy0Q=.f335bafb-3fbf-4902-8121-cdf99ed92589@github.com>
 <q9avJLkpJ4wgyuswrLm_YSdqUD_5GNnWYPEux_Xy7OI=.cb1704f2-7452-435e-984e-1aeb917ac907@github.com>
Message-ID: <NzMOOFfncZ1U5XWrfhkWjwcvhKxiand9c5VfptjGehM=.9d78d127-3374-4c48-8a7d-614b64fcdb0a@github.com>

On Thu, 1 Dec 2022 19:37:28 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Character.java line 172:
>> 
>>> 170:  * occur. For example, in a future release, synchronization may fail.
>>> 171:  *
>>> 172:  * @spec https://www.unicode.org/reports/tr27 Unicode 3.1.0
>> 
>> This should probably be removed, as the original link (explaining `U+n` notation) is broken.
>
> @naotoj The edits are driven by a script, using info about existing links in the same doc comment. If you don't think this reference is appropriate, it would be better to either remove the existing link (and I'll regenerate this patch) or else this patch goes through and you fix up both the existing link and the `@spec` tag afterwards.

Either way is fine with me. I will fix it up if you choose the latter.

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

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

From duke at openjdk.org  Thu Dec  1 21:31:07 2022
From: duke at openjdk.org (Chris Hennick)
Date: Thu, 1 Dec 2022 21:31:07 GMT
Subject: RFR: 8284493: Fix rounding error in computeNextExponential [v16]
In-Reply-To: <GKQOg02og11alcCgOGPGZ2wn41zf6g5RylUm74Glr_k=.e5ad1226-a6ee-412f-8508-08946ef11eae@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
 <GKQOg02og11alcCgOGPGZ2wn41zf6g5RylUm74Glr_k=.e5ad1226-a6ee-412f-8508-08946ef11eae@github.com>
Message-ID: <Wr09ra4YHijG5cWr8Y10Ewkk2fb3_J97-MHXrgojRvA=.aa1c6a6c-5e4e-43be-a903-0170fcb5fb93@github.com>

On Tue, 4 Oct 2022 17:36:56 GMT, Chris Hennick <duke at openjdk.org> wrote:

>> This PR improves both the performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections:
>> 
>> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`.
>> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.)
>> * Uses the newly-extracted `computeWinsorizedNextExponential` function to greatly reduce the probability that `nextGaussian` suffers from *two* tail cases of `nextExponential`.
>
> Chris Hennick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add parameter to enable/disable fixed PRNG seed

JMH benchmark results (`make test TEST="micro:java.util.random"`) with `fixedSeed = true` on EC2 are below. Average time improves only for nextExponential() and only on non-Intel CPUs, but p100 improved more consistently (7 of the 12 tests improved by at least 1000ns, only 2 deteriorated by that amount.)
# c6i.metal
L64X128MixRandom.nextExponential() average ns/op: 26.984 ? 0.015 before, 34.914 ? 0.021 after
L64X128MixRandom.nextExponential() p100 ns/op: 8224 before, 5624 after
L64X1024MixRandom.nextExponential() average ns/op: 30.026 ? 0.020 before, 36.730 ? 0.024 after
L64X1024MixRandom.nextExponential() p100 ns/op: 8736 before, 7464 after
L64X128MixRandom.nextGaussian() average ns/op: 29.995 ? 0.017 before, 30.016 ? 0.019 after
L64X128MixRandom.nextGaussian() p100 ns/op: 5392 before, 3024 after
L64X1024MixRandom.nextGaussian() average ns/op: 31.394 ? 0.020 before, 31.660 ? 0.021 after
L64X1024MixRandom.nextGaussian() p100 ns/op: 5984 before, 6072 after
# c7g.16xlarge
L64X128MixRandom.nextExponential() average ns/op: 41.006 ? 0.056 before, 40.288 ? 0.055 after
L64X128MixRandom.nextExponential() p100 ns/op: 6384 before, 6416 after
L64X1024MixRandom.nextExponential() average ns/op: 45.218 ? 0.071 before, 40.549 ? 0.062 after
L64X1024MixRandom.nextExponential() p100 ns/op: 560 before, 3760 after
L64X128MixRandom.nextGaussian() average ns/op: 39.643 ? 0.052 before, 40.473 ? 0.070 after
L64X128MixRandom.nextGaussian() p100 ns/op: 7728 before, 1264 after
L64X1024MixRandom.nextGaussian() average ns/op: 40.393 ? 0.061 before, 40.274 ? 0.061 after
L64X1024MixRandom.nextGaussian() p100 ns/op: 9184 before, 1280 after
# m6a.metal
L64X128MixRandom.nextExponential() average ns/op: 31.241 ? 0.039 before, 29.004 ? 0.018 after
L64X128MixRandom.nextExponential() p100 ns/op: 4224 before, 7224 after
L64X1024MixRandom.nextExponential() average ns/op: 31.903 ? 0.017 before, 31.146 | ? | 0.021 | ns/op |
L64X1024MixRandom.nextExponential() p100 ns/op: 9744 before, 8688 after
L64X128MixRandom.nextGaussian() average ns/op: 29.164 ? 0.017 before, 29.073 ? 0.021 after
L64X128MixRandom.nextGaussian() p100 ns/op: 5920 before, 1504 after
L64X1024MixRandom.nextGaussian() average ns/op: 29.503 ? 0.022 before, 29.639 ? 0.018 after
L64X1024MixRandom.nextGaussian() p100 ns/op: 4256 before, 4288 after

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

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

From duke at openjdk.org  Thu Dec  1 21:35:22 2022
From: duke at openjdk.org (Chris Hennick)
Date: Thu, 1 Dec 2022 21:35:22 GMT
Subject: RFR: 8284493: Fix rounding error in computeNextExponential [v16]
In-Reply-To: <GKQOg02og11alcCgOGPGZ2wn41zf6g5RylUm74Glr_k=.e5ad1226-a6ee-412f-8508-08946ef11eae@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
 <GKQOg02og11alcCgOGPGZ2wn41zf6g5RylUm74Glr_k=.e5ad1226-a6ee-412f-8508-08946ef11eae@github.com>
Message-ID: <8f6zH_Gx-PKYE9RVC3Ac4YfuFonsC0AlHhvHzdsMdKQ=.9c26ea79-66e7-40d0-9e9d-0a4f07801232@github.com>

On Tue, 4 Oct 2022 17:36:56 GMT, Chris Hennick <duke at openjdk.org> wrote:

>> This PR improves both the performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections:
>> 
>> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`.
>> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.)
>> * Uses the newly-extracted `computeWinsorizedNextExponential` function to greatly reduce the probability that `nextGaussian` suffers from *two* tail cases of `nextExponential`.
>
> Chris Hennick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add parameter to enable/disable fixed PRNG seed

@simonis @navyxliu @turbanoff @rgiulietti This is ready for review with the benchmark results.

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

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

From mcimadamore at openjdk.org  Thu Dec  1 22:00:09 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 1 Dec 2022 22:00:09 GMT
Subject: RFR: 8291359: Specification of method j.l.foreign.VaList::skip
 still deserves clarification [v2]
In-Reply-To: <Gdywkdba9s0tfVksRJU-8LQscoZ6bbfcfkr7P3T3Jd4=.678c15a9-b4d3-4c26-80e2-e4abac12b064@github.com>
References: <vHHYP2B3-wJHXVPjmc0bP6Raouhn3ni-M_d1A_ULlp8=.17cfc6d8-f18e-46fb-a1fe-ffdf4b816d84@github.com>
 <VgD0_n7cpBcnT5OdL0jrSPEDwoeZF5Q3d-ZTt0dFfiA=.98dc5712-67ee-4141-8b38-bd42479bf75b@github.com>
 <ITJSxOx9YjWHr7-BpV5PxgfEMdLsI14menCBgM18_bs=.c4669ed0-19b7-44e4-bd79-11b7ed658f7e@github.com>
 <zL9SkQ5SiknPWVyN7kfCHP1d8_OQkqZVFrQxNjcQ9DI=.a86de67b-2930-4fd6-bfc3-e4fa5196b1cf@github.com>
 <Gdywkdba9s0tfVksRJU-8LQscoZ6bbfcfkr7P3T3Jd4=.678c15a9-b4d3-4c26-80e2-e4abac12b064@github.com>
Message-ID: <22NI2qOGin9akfiuHlZtOnEVFf48IjFWTHVjFjA9WrU=.77ff6ce2-9da4-46dc-a291-6943274cabc0@github.com>

On Thu, 1 Dec 2022 17:53:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Yes, I mean the layout of the underlying value that is being accessed. i.e. can't access a boolean as an int.
>> 
>> The behavior is undefined either way. Even when a VaList is created from Java, we create the same underlying native data structure (because we want to pass it to native code). This doesn't keep track of the layouts the list was built with, so there can still be mismatches.
>
> Right.

This sentence still needs to be clarified IMHO. E.g. it is not clear when reading what "using a memory layout other than the layout of the accessed value" - since we are passing a layout to the access operation... it feels like we're trying to compress too much. We should say something like:


The values in a variable argument list are stored in one or more regions of memory in a platform specific fashion. 
Any attempt to access (or skip) any such value with a mismatched memory layout (example) will result in undefined behavior.

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

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

From cushon at openjdk.org  Thu Dec  1 22:12:11 2022
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 1 Dec 2022 22:12:11 GMT
Subject: Integrated: 8297875: jar should not compress the manifest directory
 entry
In-Reply-To: <EpZd9Q-41It_aunxHpbe1blQGyN3wKm-ND8_FmtP9A0=.1317ab51-f6b0-467b-93ee-fb2a9778c61e@github.com>
References: <EpZd9Q-41It_aunxHpbe1blQGyN3wKm-ND8_FmtP9A0=.1317ab51-f6b0-467b-93ee-fb2a9778c61e@github.com>
Message-ID: <gnVE4y6Or5xfH2rmzDFVB5O-ghrtEu-hVahIf1sokYE=.96e27db2-76bb-4cf8-97f6-da67bb8f4b18@github.com>

On Wed, 30 Nov 2022 18:48:30 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This causes jar to not compress the `META-INF/` directory entry, for consistency with the handling of other directory entries and compliance with `APPNOTE.TXT`, and for compatibility with other zip implementations.

This pull request has now been integrated.

Changeset: e846b043
Author:    Liam Miller-Cushon <cushon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e846b0438ca12f457ee763fed3a435d3a863c383
Stats:     75 lines in 2 files changed: 75 ins; 0 del; 0 mod

8297875: jar should not compress the manifest directory entry

Reviewed-by: lancea

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

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

From weijun at openjdk.org  Thu Dec  1 23:41:12 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 Dec 2022 23:41:12 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <ktUnahpoaSsO7Ycw0Bav_j-Tb0iOA-4S3BpmK7h8LWo=.ad9b526a-f0d8-4963-a1c3-1f098d0fcbc6@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
 <JCBfRAbsgf6bH6lqeXWodGC89bWpXwpwNlv2E1aHPUI=.85727228-d8c8-4918-818a-ae6606514b99@github.com>
 <ZTmLDk0M9hsuICQeazcIat8UdUvM49UAisgTfoV8LCg=.799c1bfe-57a8-4b24-a72e-ed7f970bcf95@github.com>
 <nrL_Up0TmjkjNZgQtxGCZG3gkOF2eg5FiJYUK_J1kJs=.164122ef-8750-487c-abc5-e5b92bdf7c2c@github.com>
 <no3fTAbXqXI9w9odDcE5nFpKzJWuUHHi9eOY04AXBAI=.fafda472-c4b3-4251-b496-f149e463bea4@github.com>
 <ktUnahpoaSsO7Ycw0Bav_j-Tb0iOA-4S3BpmK7h8LWo=.ad9b526a-f0d8-4963-a1c3-1f098d0fcbc6@github.com>
Message-ID: <tP7Z8ToLzTciRkvSBXR5WlF65EGcVQ89tSvtSO3XCaw=.da2e4cdd-a652-4813-9fc5-62e1c50c1105@github.com>

On Thu, 1 Dec 2022 19:30:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> What's the expected behavior?
>
> I confirmed that the standalone `keytool` did not echo the input, which should be OK for this IMO.

If the console cannot be used anyway inside jshell, then this is good enough.

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

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

From ysatowse at openjdk.org  Fri Dec  2 01:18:16 2022
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Fri, 2 Dec 2022 01:18:16 GMT
Subject: RFR: 8297804: (tz) Update Timezone Data to 2022g
In-Reply-To: <4b1tG73Xp3BMUy2X6Ab7W2So7u4jcSu9SrAWvrHLw1g=.d6218261-7f4e-48c5-9989-eb0887e0207e@github.com>
References: <4b1tG73Xp3BMUy2X6Ab7W2So7u4jcSu9SrAWvrHLw1g=.d6218261-7f4e-48c5-9989-eb0887e0207e@github.com>
Message-ID: <2Izs6eygJONprQg5VmOp5atywmJqZgVJnccKqcjK918=.0184672c-fc38-4b4d-b3a8-71414eddeba7@github.com>

On Wed, 30 Nov 2022 18:07:07 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Update to the latest tzdata, 2022g.
> 
> Primary changes:
> * `America/Ojinaga` (CST) is split, creating `America/Ciudad_Juarez` (MST/MDT)
> * `America/Pangnirtung` becomes a link to `America/Iqaluit`
> * `America/Ojinaga` gains DST (CDT)
> 
> See bug for the full details.
> 
> There will likely also be CLDR changes ([CLDR-16181](https://unicode-org.atlassian.net/browse/CLDR-16181)) that are not yet included in this change. We can either wait for these and include them in this patch, or do a separate change like [JDK-8296715](https://bugs.openjdk.org/browse/JDK-8296715)
> 
> Tests in `java/util/TimeZone`, `java/time/test` and `sun/text/resources` all pass.

The following files need to be updated with the timezone data version.  
src/java.base/share/data/tzdata/VERSION
test/jdk/java/util/TimeZone/TimeZoneData/VERSION

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

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

From jiefu at openjdk.org  Fri Dec  2 02:10:43 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Fri, 2 Dec 2022 02:10:43 GMT
Subject: RFR: 8297992: Tests fail after JDK-8297215 due to lack of
 @enablePreview
Message-ID: <9_eGFc1M2M_ojKDALNbVWREYhTpg1F5iNbE1SGTPyUw=.90b206f5-b375-4ff6-9cf8-e39b35511cfa@github.com>

Hi all,

The following 3 tests fail with debug VMs due to lack of @enablePreview after JDK-8297215.


* jtreg:test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALot.java
* jtreg:test/jdk/java/lang/Thread/virtual/HoldsLock.java
* jtreg:test/jdk/jdk/internal/vm/Continuation/Basic.java


Let's fix them.

Thanks.
Best regards,
Jie

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

Commit messages:
 - 8297992: Tests fail after JDK-8297215 due to lack of @enablePreview

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

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

From darcy at openjdk.org  Fri Dec  2 02:21:54 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 2 Dec 2022 02:21:54 GMT
Subject: RFR: 8297992: Tests fail after JDK-8297215 due to lack of
 @enablePreview
In-Reply-To: <9_eGFc1M2M_ojKDALNbVWREYhTpg1F5iNbE1SGTPyUw=.90b206f5-b375-4ff6-9cf8-e39b35511cfa@github.com>
References: <9_eGFc1M2M_ojKDALNbVWREYhTpg1F5iNbE1SGTPyUw=.90b206f5-b375-4ff6-9cf8-e39b35511cfa@github.com>
Message-ID: <ZnKQ3K2Teg4fjMwe1hHJiAPcOcfoxhIllJthH-eZUl0=.3d159893-3256-4ab7-882c-61d91412a12d@github.com>

On Fri, 2 Dec 2022 02:01:57 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> The following 3 tests fail with debug VMs due to lack of @enablePreview after JDK-8297215.
> 
> 
> * jtreg:test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALot.java
> * jtreg:test/jdk/java/lang/Thread/virtual/HoldsLock.java
> * jtreg:test/jdk/jdk/internal/vm/Continuation/Basic.java
> 
> 
> Let's fix them.
> 
> Thanks.
> Best regards,
> Jie

How are you running the tests? They pass on Oracle-internal tier 1 to 3 testing.

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

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

From jiefu at openjdk.org  Fri Dec  2 02:31:03 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Fri, 2 Dec 2022 02:31:03 GMT
Subject: RFR: 8297992: Tests fail after JDK-8297215 due to lack of
 @enablePreview
In-Reply-To: <ZnKQ3K2Teg4fjMwe1hHJiAPcOcfoxhIllJthH-eZUl0=.3d159893-3256-4ab7-882c-61d91412a12d@github.com>
References: <9_eGFc1M2M_ojKDALNbVWREYhTpg1F5iNbE1SGTPyUw=.90b206f5-b375-4ff6-9cf8-e39b35511cfa@github.com>
 <ZnKQ3K2Teg4fjMwe1hHJiAPcOcfoxhIllJthH-eZUl0=.3d159893-3256-4ab7-882c-61d91412a12d@github.com>
Message-ID: <QUOtJCts1P66F2q0vbqRHJMOg7y-NJfQIc0MK5huj48=.99d3d8e2-c8ce-416e-b304-21cf888cab3e@github.com>

On Fri, 2 Dec 2022 02:19:49 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> How are you running the tests? They pass on Oracle-internal tier 1 to 3 testing.

Just run with

Ben="java/lang/Thread/virtual/stress/GetStackTraceALot.java java/lang/Thread/virtual/HoldsLock.java jdk/internal/vm/Continuation/Basic.java"
ARG=""
make test TEST="${Ben}" JTREG="VM_OPTIONS=${ARG};" CONF=server-fast

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

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

From darcy at openjdk.org  Fri Dec  2 05:19:41 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 2 Dec 2022 05:19:41 GMT
Subject: RFR: 8297992: Tests fail after JDK-8297215 due to lack of
 @enablePreview
In-Reply-To: <9_eGFc1M2M_ojKDALNbVWREYhTpg1F5iNbE1SGTPyUw=.90b206f5-b375-4ff6-9cf8-e39b35511cfa@github.com>
References: <9_eGFc1M2M_ojKDALNbVWREYhTpg1F5iNbE1SGTPyUw=.90b206f5-b375-4ff6-9cf8-e39b35511cfa@github.com>
Message-ID: <rTB7II1tdWBQbzLM4ZxNAag2nzzk44PRR21B_q-Ob5s=.39e1207e-71a5-47c3-945c-e8023dc1eb1f@github.com>

On Fri, 2 Dec 2022 02:01:57 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> The following 3 tests fail with debug VMs due to lack of @enablePreview after JDK-8297215.
> 
> 
> * jtreg:test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALot.java
> * jtreg:test/jdk/java/lang/Thread/virtual/HoldsLock.java
> * jtreg:test/jdk/jdk/internal/vm/Continuation/Basic.java
> 
> 
> Let's fix them.
> 
> Thanks.
> Best regards,
> Jie

(Failures seen in subsequent testing in Oracle.)

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

Marked as reviewed by darcy (Reviewer).

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

From jiefu at openjdk.org  Fri Dec  2 06:04:06 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Fri, 2 Dec 2022 06:04:06 GMT
Subject: RFR: 8297992: Tests fail after JDK-8297215 due to lack of
 @enablePreview
In-Reply-To: <rTB7II1tdWBQbzLM4ZxNAag2nzzk44PRR21B_q-Ob5s=.39e1207e-71a5-47c3-945c-e8023dc1eb1f@github.com>
References: <9_eGFc1M2M_ojKDALNbVWREYhTpg1F5iNbE1SGTPyUw=.90b206f5-b375-4ff6-9cf8-e39b35511cfa@github.com>
 <rTB7II1tdWBQbzLM4ZxNAag2nzzk44PRR21B_q-Ob5s=.39e1207e-71a5-47c3-945c-e8023dc1eb1f@github.com>
Message-ID: <pm2ALVpU8n7Iljo1tzHjbL-rvnSBFNJJq-sPeEQpI3A=.6d01a8f8-6a94-431d-b71c-37270b2c1128@github.com>

On Fri, 2 Dec 2022 05:16:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> (Failures seen in subsequent testing in Oracle.)

Thanks @jddarcy for your review.

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

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

From jiefu at openjdk.org  Fri Dec  2 06:07:53 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Fri, 2 Dec 2022 06:07:53 GMT
Subject: Integrated: 8297992: Tests fail after JDK-8297215 due to lack of
 @enablePreview
In-Reply-To: <9_eGFc1M2M_ojKDALNbVWREYhTpg1F5iNbE1SGTPyUw=.90b206f5-b375-4ff6-9cf8-e39b35511cfa@github.com>
References: <9_eGFc1M2M_ojKDALNbVWREYhTpg1F5iNbE1SGTPyUw=.90b206f5-b375-4ff6-9cf8-e39b35511cfa@github.com>
Message-ID: <rZl8nwM0fdmX17LuCQ3h0G8X9EN1rNzNvZD-bLTU-yY=.f3c68605-4ecb-4786-b508-74ed5149b537@github.com>

On Fri, 2 Dec 2022 02:01:57 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> The following 3 tests fail with debug VMs due to lack of @enablePreview after JDK-8297215.
> 
> 
> * jtreg:test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALot.java
> * jtreg:test/jdk/java/lang/Thread/virtual/HoldsLock.java
> * jtreg:test/jdk/jdk/internal/vm/Continuation/Basic.java
> 
> 
> Let's fix them.
> 
> Thanks.
> Best regards,
> Jie

This pull request has now been integrated.

Changeset: 11ba7591
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/11ba7591dfd3f7ca58e2e1ac6d1b3e81391f5bfb
Stats:     3 lines in 3 files changed: 3 ins; 0 del; 0 mod

8297992: Tests fail after JDK-8297215 due to lack of @enablePreview

Reviewed-by: darcy

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

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

From alanb at openjdk.org  Fri Dec  2 07:08:18 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 2 Dec 2022 07:08:18 GMT
Subject: RFR: 8297992: Tests fail after JDK-8297215 due to lack of
 @enablePreview
In-Reply-To: <9_eGFc1M2M_ojKDALNbVWREYhTpg1F5iNbE1SGTPyUw=.90b206f5-b375-4ff6-9cf8-e39b35511cfa@github.com>
References: <9_eGFc1M2M_ojKDALNbVWREYhTpg1F5iNbE1SGTPyUw=.90b206f5-b375-4ff6-9cf8-e39b35511cfa@github.com>
Message-ID: <OkK_WpIhTOkzBQCpePlBKpCD4-_5k_M-KB__r8YBDYw=.f5f9ee02-dc34-4c32-a345-ed339ea3a12f@github.com>

On Fri, 2 Dec 2022 02:01:57 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> The following 3 tests fail with debug VMs due to lack of @enablePreview after JDK-8297215.
> 
> 
> * jtreg:test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALot.java
> * jtreg:test/jdk/java/lang/Thread/virtual/HoldsLock.java
> * jtreg:test/jdk/jdk/internal/vm/Continuation/Basic.java
> 
> 
> Let's fix them.
> 
> Thanks.
> Best regards,
> Jie

It looks like Joe's change dropped the enable preview from the tests that require a debug build.

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

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

From shade at openjdk.org  Fri Dec  2 07:32:21 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 2 Dec 2022 07:32:21 GMT
Subject: Integrated: 8297784: Optimize @Stable field for
 Method.isCallerSensitive
In-Reply-To: <cyLnoiWQYsL5MbGWXc0GYWJqoXd75l8w0vcnm2TH5KA=.647e2e2e-f28f-4a07-8b87-de6ba268a115@github.com>
References: <cyLnoiWQYsL5MbGWXc0GYWJqoXd75l8w0vcnm2TH5KA=.647e2e2e-f28f-4a07-8b87-de6ba268a115@github.com>
Message-ID: <XZ86Bh86ryyTd_lk6Kre1f1Coa5TQAMhOIQL46_R0Xc=.e9ed3edd-6eca-43d1-b1ee-d44c466cc9f5@github.com>

On Tue, 29 Nov 2022 19:39:02 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8271820](https://bugs.openjdk.org/browse/JDK-8271820) introduced the `@Stable private Boolean callerSensitive;` cache in `Method`. That field is essentially a tri-state `Boolean` that relies on its `null` value to serve as "not initialized" value for `@Stable`.
> 
> This works well when the holder `Method` instance is constant: JIT compilers fold `@Stable` well. But if such folding fails, we always dereference the full-blown reference to "boxed" `Boolean` from the field on every access. We can instead do a more lean tri-state primitive field to improve that non-optimized case without sacrificing optimized case.
> 
> I chose `byte` and `-1`, `0`, `1` to let the fastpath encode well on most (all?) architectures.
> 
> On adhoc benchmark like:
> 
> 
> @State(Scope.Thread)
> public class WrapperConstness {
>     static final Method CONST;
>     static Method NON_CONST;
> 
>     static {
>         try {
>             CONST = WrapperConstness.class.getDeclaredMethod("target");
>             NON_CONST = CONST;
>         } catch (NoSuchMethodException e) {
>             throw new RuntimeException(e);
>         }
>     }
> 
>     public void target() {}
> 
>     @Benchmark
>     public void nonConstant() throws Exception {
>         NON_CONST.invoke(this);
>     }
> 
>     @Benchmark
>     public void constant() throws Exception {
>         CONST.invoke(this);
>     }
> }
> 
> 
> We have a minor improvement for non-const case, confirmed due to better `isCallerSensitive` access:
> 
> 
> Benchmark                     Mode  Cnt  Score   Error  Units
> 
> # Baseline
> WrapperConstness.constant     avgt   25  0.410 ? 0.010  ns/op
> WrapperConstness.nonConstant  avgt   25  7.283 ? 0.025  ns/op
> 
> # Patched
> WrapperConstness.constant     avgt    5  0.407 ? 0.008  ns/op
> WrapperConstness.nonConstant  avgt    5  7.054 ? 0.027  ns/op  ; -3%
> 
> 
> Additional testing:
>  - [x] Ad-hoc benchmarks
>  - [x] Linux x86_64 fastdebug `java/lang/reflect`
>  - [x] Linux x86_64 fastdebug `tier1`, `tier2`

This pull request has now been integrated.

Changeset: 9bbcb546
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9bbcb546c86b40ae23d46e12a1a03aae7a7a6182
Stats:     9 lines in 1 file changed: 4 ins; 0 del; 5 mod

8297784: Optimize @Stable field for Method.isCallerSensitive

Reviewed-by: redestad, jvernee, alanb

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

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

From alanb at openjdk.org  Fri Dec  2 08:21:05 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 2 Dec 2022 08:21:05 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <tP7Z8ToLzTciRkvSBXR5WlF65EGcVQ89tSvtSO3XCaw=.da2e4cdd-a652-4813-9fc5-62e1c50c1105@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
 <JCBfRAbsgf6bH6lqeXWodGC89bWpXwpwNlv2E1aHPUI=.85727228-d8c8-4918-818a-ae6606514b99@github.com>
 <ZTmLDk0M9hsuICQeazcIat8UdUvM49UAisgTfoV8LCg=.799c1bfe-57a8-4b24-a72e-ed7f970bcf95@github.com>
 <nrL_Up0TmjkjNZgQtxGCZG3gkOF2eg5FiJYUK_J1kJs=.164122ef-8750-487c-abc5-e5b92bdf7c2c@github.com>
 <no3fTAbXqXI9w9odDcE5nFpKzJWuUHHi9eOY04AXBAI=.fafda472-c4b3-4251-b496-f149e463bea4@github.com>
 <ktUnahpoaSsO7Ycw0Bav_j-Tb0iOA-4S3BpmK7h8LWo=.ad9b526a-f0d8-4963-a1c3-1f098d0fcbc6@github.com>
 <tP7Z8ToLzTciRkvSBXR5WlF65EGcVQ89tSvtSO3XCaw=.da2e4cdd-a652-4813-9fc5-62e1c50c1105@github.com>
Message-ID: <ShycxtxiMZ0JMdI3EaSMKTHPO8NzJclj5VuOe2Xbqxk=.a8d846a6-0bc7-4a2e-83bb-224ed8a0e72e@github.com>

On Thu, 1 Dec 2022 23:38:40 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I confirmed that the standalone `keytool` did not echo the input, which should be OK for this IMO.
>
> If the console cannot be used anyway inside jshell, then this is good enough.

Naoto has confirmed that the password prompt from keytool does not echo, good!

The intention is that Console be usable in jshell so I think the issue is that readPassword is echo'ing when used in jshell. Maybe someone experimenting with the Console API might run into this but we can separate out that issue.

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

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

From djelinski at openjdk.org  Fri Dec  2 08:57:23 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 2 Dec 2022 08:57:23 GMT
Subject: RFR: 8297976: Remove sun.net.ProgressMonitor and related classes
Message-ID: <yw8Q8tA8_4jUmc1gWd-xAN-m5kjFPeou3dn0qML9TQ4=.18a511ff-946f-4a8a-8fe3-3eaf00a8a396@github.com>

Please review this patch that removes progress monitoring classes used by UrlConnection.
Since Java 9 these classes are not used in the JDK, and are not exported from java.base. If anyone was still using them, reimplementing them in user code should be pretty straightforward.

This PR also fixes the issue where MeteredStream finalizer could resurrect an unusable connection, causing unexpected exceptions in other parts of the code.

No new regression test; since we are removing the finalizer, I don't believe we will see the issue again. I can add a test for that if you think it still makes sense.

I had to adjust `ProxyModuleMapping.java` test which used `sun.net.ProgressListener` as an example of a module-private interface; I replaced it with another public interface from the same package.

Existing tier 1-3 tests continue to pass.

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

Commit messages:
 - Update copyright
 - Update broken test
 - Remove broken MeteredStream finalizer
 - Remove progress monitoring classes

Changes: https://git.openjdk.org/jdk/pull/11474/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11474&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297976
  Stats: 895 lines in 13 files changed: 1 ins; 875 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/11474.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11474/head:pull/11474

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

From dfuchs at openjdk.org  Fri Dec  2 10:28:14 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 2 Dec 2022 10:28:14 GMT
Subject: RFR: 8297976: Remove sun.net.ProgressMonitor and related classes
In-Reply-To: <yw8Q8tA8_4jUmc1gWd-xAN-m5kjFPeou3dn0qML9TQ4=.18a511ff-946f-4a8a-8fe3-3eaf00a8a396@github.com>
References: <yw8Q8tA8_4jUmc1gWd-xAN-m5kjFPeou3dn0qML9TQ4=.18a511ff-946f-4a8a-8fe3-3eaf00a8a396@github.com>
Message-ID: <Fq5kymit2n_Rxqima2hljRJTToA-HxjMbC23AEcbnA8=.b2acaf87-220e-4f2a-95c7-600e22ff4919@github.com>

On Fri, 2 Dec 2022 08:31:25 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this patch that removes progress monitoring classes used by UrlConnection.
> Since Java 9 these classes are not used in the JDK, and are not exported from java.base. If anyone was still using them, reimplementing them in user code should be pretty straightforward.
> 
> This PR also fixes the issue where MeteredStream finalizer could resurrect an unusable connection, causing unexpected exceptions in other parts of the code.
> 
> No new regression test; since we are removing the finalizer, I don't believe we will see the issue again. I can add a test for that if you think it still makes sense.
> 
> I had to adjust `ProxyModuleMapping.java` test which used `sun.net.ProgressListener` as an example of a module-private interface; I replaced it with another public interface from the same package.
> 
> Existing tier 1-3 tests continue to pass.

[JDK-8240275](https://bugs.openjdk.org/browse/JDK-8240275) seems to have a reproducer attached. Did you investigate whether turning that into a non-regression test would be worthwhile?

Otherwise this looks like a good cleanup and simplification!

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

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

From asotona at openjdk.org  Fri Dec  2 10:46:39 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 2 Dec 2022 10:46:39 GMT
Subject: RFR: [DRAFT] 8294982: Implementation of Classfile API [v3]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <H2LI0ufUldbDp2P55d8F1zqbuSwK74VTlh7KSdDIjJM=.8c19e693-9873-406f-a8ad-d8d18a3e1066@github.com>

> **This pull request is not intended for immediate integration to JDK mainline.**
> 
> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/jdk/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

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

  removal of AccessController::doPriviledged from ClassHierarchyResolver

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/3827e529..31fa159f

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

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

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

From dfuchs at openjdk.org  Fri Dec  2 12:15:23 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 2 Dec 2022 12:15:23 GMT
Subject: RFR: 8296546: Add @spec tags to API [v4]
In-Reply-To: <0SjUCtMo9Z9Oiq-ITr1-CA8_RoibtPkzfAZPdaR4tSU=.950b338f-e68c-4825-8831-872fbbd04956@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <0SjUCtMo9Z9Oiq-ITr1-CA8_RoibtPkzfAZPdaR4tSU=.950b338f-e68c-4825-8831-872fbbd04956@github.com>
Message-ID: <4EIiX-uBShLoH1cl1MdngnvCc1HfVFXT_GJgFl5LoTE=.b07eefdf-8c2d-439e-a3c1-8ecfe323e2fd@github.com>

On Thu, 1 Dec 2022 19:36:16 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
>> 
>> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
>> 
>> "Normalized" means...
>> * Use `https:` where possible (includes pretty much all cases)
>> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
>> * Point to the root page of a multi-page spec
>> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
>> 
>> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
>> 
>> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
>> 
>> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
>> 
>> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
>> 
>> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
>> 
>> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.
>
> Jonathan Gibbons has updated the pull request with a new target base 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:
> 
>  - Change ietf.org URLs to use rfc-editor.org
>  - Merge remote-tracking branch 'upstream/master' into 8296546.add-spec-tags
>  - Remove updates from unexported files
>  - Prefix RFC titles with `RFC NNNN:`
>  - JDK-8296547: Add @spec tags to API

I have reviewed again the java.net, java.net.http, jdk.httpserver, java.naming, and javax.management changes - and I spotted a few places where the `@spec` duplicates an `@see` (noted below). I believe the duplicated `@see` should be removed now.

src/java.base/share/classes/java/net/StandardSocketOptions.java line 62:

> 60:      * @spec https://www.rfc-editor.org/info/rfc919 RFC 919: Broadcasting Internet Datagrams
> 61:      * @see <a href="http://www.ietf.org/rfc/rfc919.txt">RFC&nbsp;929:
> 62:      * Broadcasting Internet Datagrams</a>

This `@see` line should now be removed since it's referencing the exact same document.

src/java.base/share/classes/java/net/StandardSocketOptions.java line 83:

> 81:      * @spec https://www.rfc-editor.org/info/rfc1122 RFC 1122: Requirements for Internet Hosts - Communication Layers
> 82:      * @see <a href="http://www.ietf.org/rfc/rfc1122.txt">RFC&nbsp;1122
> 83:      * Requirements for Internet Hosts -- Communication Layers</a>

Same remark here: please remove the `@see`

src/java.base/share/classes/java/net/StandardSocketOptions.java line 154:

> 152:      * @spec https://www.rfc-editor.org/info/rfc1323 RFC 1323: TCP Extensions for High Performance
> 153:      * @see <a href="http://www.ietf.org/rfc/rfc1323.txt">RFC&nbsp;1323: TCP
> 154:      * Extensions for High Performance</a>

Remove the `@see`

src/java.base/share/classes/java/net/StandardSocketOptions.java line 186:

> 184:      *
> 185:      * @spec https://www.rfc-editor.org/info/rfc793 RFC 793: Transmission Control Protocol
> 186:      * @see <a href="http://www.ietf.org/rfc/rfc793.txt">RFC&nbsp;793: Transmission

Remove the @see

src/java.base/share/classes/java/net/StandardSocketOptions.java line 377:

> 375:      * @spec https://www.rfc-editor.org/info/rfc1122 RFC 1122: Requirements for Internet Hosts - Communication Layers
> 376:      * @see <a href="http://www.ietf.org/rfc/rfc1122.txt">RFC&nbsp;1122:
> 377:      * Requirements for Internet Hosts -- Communication Layers</a>

Remove the @see

src/java.management/share/classes/javax/management/remote/JMXServiceURL.java line 122:

> 120:  * @see <a
> 121:  * href="http://www.ietf.org/rfc/rfc2609.txt">RFC 2609,
> 122:  * "Service Templates and <code>Service:</code> Schemes"</a>

The two `@see` should now be removed

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

Changes requested by dfuchs (Reviewer).

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

From stsypanov at openjdk.org  Fri Dec  2 12:53:12 2022
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 2 Dec 2022 12:53:12 GMT
Subject: RFR: 8298033: Character.codePointAt(char[], int,
 int) doesn't do JavaDoc-specified check
Message-ID: <dHjviGmASssYfntfClzDC28Ppjrn3pECnO3HzbZHopY=.d9923de3-6de7-41f5-a84e-03a7c5267e2f@github.com>

I found out that this code

public class Main {
    public static void main(String[] args) {
        String s = "Hello world!";
        char[] chars = s.toCharArray();
        int point = Character.codePointAt(chars, -1, 1);
    }
}

throws `ArrayIndexOutOfBoundsException` instead of JavaDoc-specified `IndexOutOfBoundsException`: 

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds for length 12
	at java.base/java.lang.Character.codePointAtImpl(Character.java:9254)
	at java.base/java.lang.Character.codePointAt(Character.java:9249)
	at org.example.Main.main(Main.java:7)

and the method doesn't check whether `index` parameter is negative:

public static int codePointAt(char[] a, int index, int limit) {
    if (index >= limit || limit < 0 || limit > a.length) {
        throw new IndexOutOfBoundsException();
    }
    return codePointAtImpl(a, index, limit);
}

I suggest to check the `index` parameter explicitly instead of relying on AIOOBE thrown from accessing the array with negative index.

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

Commit messages:
 - 8298033: Character.codePointAt(char[], int, int) doesn't do JavaDoc-specified check

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

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

From erikj at openjdk.org  Fri Dec  2 14:31:00 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 2 Dec 2022 14:31:00 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v30]
In-Reply-To: <ol0E1_Wje0XRQgoaDlbboZ9l_Zr9vV3dQ_VoryUJphg=.70bd7bd1-c56f-420e-a0e4-7fca91776d9c@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <kstu-zmyhVPARnuKs2ocWm-2DCzB81ScVIGr5BmRBMI=.1a12f859-6a34-4760-8e15-48c9ee98b14b@github.com>
 <ol0E1_Wje0XRQgoaDlbboZ9l_Zr9vV3dQ_VoryUJphg=.70bd7bd1-c56f-420e-a0e4-7fca91776d9c@github.com>
Message-ID: <Bz9N4O4qUKCuVAt7ZoAZl1FkR48qI6iKm_S0FiJDANs=.511266f5-95b3-4e0b-82f6-fb5730ecdae2@github.com>

On Wed, 23 Nov 2022 15:38:29 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> > /issue add JDK-8296302
> 
> The BOT comment at the top says /issue cannot refer to a CSR. You'll need to /issue remove it before integration.

Roger is correct, please do not add CSR issues with `/issue add`. The bot should auto discover CSRs if linked correctly in JBS. You need to `/issue remove` the CSR.

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

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

From rriggs at openjdk.org  Fri Dec  2 14:51:15 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 2 Dec 2022 14:51:15 GMT
Subject: RFR: 8298033: Character.codePointAt(char[], int,
 int) doesn't do JavaDoc-specified check
In-Reply-To: <dHjviGmASssYfntfClzDC28Ppjrn3pECnO3HzbZHopY=.d9923de3-6de7-41f5-a84e-03a7c5267e2f@github.com>
References: <dHjviGmASssYfntfClzDC28Ppjrn3pECnO3HzbZHopY=.d9923de3-6de7-41f5-a84e-03a7c5267e2f@github.com>
Message-ID: <ADRuiZzHogHXpJdThMDtYFHfJcKuDNaDszGH7PHmB0M=.cf785690-6fc3-461a-8ae7-a5477c7851a3@github.com>

On Fri, 2 Dec 2022 12:44:18 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> I found out that this code
> 
> public class Main {
>     public static void main(String[] args) {
>         String s = "Hello world!";
>         char[] chars = s.toCharArray();
>         int point = Character.codePointAt(chars, -1, 1);
>     }
> }
> 
> throws `ArrayIndexOutOfBoundsException` instead of JavaDoc-specified `IndexOutOfBoundsException`: 
> 
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds for length 12
> 	at java.base/java.lang.Character.codePointAtImpl(Character.java:9254)
> 	at java.base/java.lang.Character.codePointAt(Character.java:9249)
> 	at org.example.Main.main(Main.java:7)
> 
> and the method doesn't check whether `index` parameter is negative:
> 
> public static int codePointAt(char[] a, int index, int limit) {
>     if (index >= limit || limit < 0 || limit > a.length) {
>         throw new IndexOutOfBoundsException();
>     }
>     return codePointAtImpl(a, index, limit);
> }
> 
> I suggest to check the `index` parameter explicitly instead of relying on AIOOBE thrown from accessing the array with negative index.

Please add a test to `test/jdk/java/lang/Character/Supplementary.java`

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

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

From stsypanov at openjdk.org  Fri Dec  2 15:02:24 2022
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 2 Dec 2022 15:02:24 GMT
Subject: RFR: 8298033: Character.codePointAt(char[], int,
 int) doesn't do JavaDoc-specified check
In-Reply-To: <ADRuiZzHogHXpJdThMDtYFHfJcKuDNaDszGH7PHmB0M=.cf785690-6fc3-461a-8ae7-a5477c7851a3@github.com>
References: <dHjviGmASssYfntfClzDC28Ppjrn3pECnO3HzbZHopY=.d9923de3-6de7-41f5-a84e-03a7c5267e2f@github.com>
 <ADRuiZzHogHXpJdThMDtYFHfJcKuDNaDszGH7PHmB0M=.cf785690-6fc3-461a-8ae7-a5477c7851a3@github.com>
Message-ID: <VI81wc_Xp37z-N0ZgI0egnhdVYm8NniujTrMGjlNLqs=.86e0e0e1-342a-470d-87ac-ff17f647ac8d@github.com>

On Fri, 2 Dec 2022 14:47:24 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I found out that this code
>> 
>> public class Main {
>>     public static void main(String[] args) {
>>         String s = "Hello world!";
>>         char[] chars = s.toCharArray();
>>         int point = Character.codePointAt(chars, -1, 1);
>>     }
>> }
>> 
>> throws `ArrayIndexOutOfBoundsException` instead of JavaDoc-specified `IndexOutOfBoundsException`: 
>> 
>> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds for length 12
>> 	at java.base/java.lang.Character.codePointAtImpl(Character.java:9254)
>> 	at java.base/java.lang.Character.codePointAt(Character.java:9249)
>> 	at org.example.Main.main(Main.java:7)
>> 
>> and the method doesn't check whether `index` parameter is negative:
>> 
>> public static int codePointAt(char[] a, int index, int limit) {
>>     if (index >= limit || limit < 0 || limit > a.length) {
>>         throw new IndexOutOfBoundsException();
>>     }
>>     return codePointAtImpl(a, index, limit);
>> }
>> 
>> I suggest to check the `index` parameter explicitly instead of relying on AIOOBE thrown from accessing the array with negative index.
>
> Please add a test to `test/jdk/java/lang/Character/Supplementary.java`

@RogerRiggs there's already a test for this case, see line 693:

callCodePoint(At, a, -1, 1, IndexOutOfBoundsException.class);

The reason why it was passing prior to these changes is that `ArrayIndexOutOfBoundsException` extends `IndexOutOfBoundsException` and the latter is caught in the test.

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

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

From rriggs at openjdk.org  Fri Dec  2 15:09:56 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 2 Dec 2022 15:09:56 GMT
Subject: RFR: 8298033: Character.codePointAt(char[], int,
 int) doesn't do JavaDoc-specified check
In-Reply-To: <VI81wc_Xp37z-N0ZgI0egnhdVYm8NniujTrMGjlNLqs=.86e0e0e1-342a-470d-87ac-ff17f647ac8d@github.com>
References: <dHjviGmASssYfntfClzDC28Ppjrn3pECnO3HzbZHopY=.d9923de3-6de7-41f5-a84e-03a7c5267e2f@github.com>
 <ADRuiZzHogHXpJdThMDtYFHfJcKuDNaDszGH7PHmB0M=.cf785690-6fc3-461a-8ae7-a5477c7851a3@github.com>
 <VI81wc_Xp37z-N0ZgI0egnhdVYm8NniujTrMGjlNLqs=.86e0e0e1-342a-470d-87ac-ff17f647ac8d@github.com>
Message-ID: <aEBOPd4o3R7Nm9reQn5mWA5sHqrgmX46CCJrmP696Ng=.19192697-14c6-4a80-a397-45e35057ac7e@github.com>

On Fri, 2 Dec 2022 15:00:15 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> The reason why it was passing prior to these changes is that `ArrayIndexOutOfBoundsException` extends `IndexOutOfBoundsException` and the latter is caught in the test.

Perhaps then, tighten up the test.  It seems odd to have a case that doesn't meet the spec but doesn't fail the test

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

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

From stsypanov at openjdk.org  Fri Dec  2 15:14:40 2022
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 2 Dec 2022 15:14:40 GMT
Subject: RFR: 8298033: Character.codePointAt(char[], int,
 int) doesn't do JavaDoc-specified check
In-Reply-To: <dHjviGmASssYfntfClzDC28Ppjrn3pECnO3HzbZHopY=.d9923de3-6de7-41f5-a84e-03a7c5267e2f@github.com>
References: <dHjviGmASssYfntfClzDC28Ppjrn3pECnO3HzbZHopY=.d9923de3-6de7-41f5-a84e-03a7c5267e2f@github.com>
Message-ID: <OCXj1nLrx73uEoVqzqN_qM3bXGQI57R59iaAPb8LW_E=.55524ccf-b8aa-4e17-af9a-aa04cd8158fa@github.com>

On Fri, 2 Dec 2022 12:44:18 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> I found out that this code
> 
> public class Main {
>     public static void main(String[] args) {
>         String s = "Hello world!";
>         char[] chars = s.toCharArray();
>         int point = Character.codePointAt(chars, -1, 1);
>     }
> }
> 
> throws `ArrayIndexOutOfBoundsException` instead of JavaDoc-specified `IndexOutOfBoundsException`: 
> 
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds for length 12
> 	at java.base/java.lang.Character.codePointAtImpl(Character.java:9254)
> 	at java.base/java.lang.Character.codePointAt(Character.java:9249)
> 	at org.example.Main.main(Main.java:7)
> 
> and the method doesn't check whether `index` parameter is negative:
> 
> public static int codePointAt(char[] a, int index, int limit) {
>     if (index >= limit || limit < 0 || limit > a.length) {
>         throw new IndexOutOfBoundsException();
>     }
>     return codePointAtImpl(a, index, limit);
> }
> 
> I suggest to check the `index` parameter explicitly instead of relying on AIOOBE thrown from accessing the array with negative index.

I think the only way to do this is to change

private static void callCodePoint(boolean isAt, char[] a, int index, int limit,
                                  Class expectedException) {
    try {
        int c = isAt ? Character.codePointAt(a, index, limit)
                     : Character.codePointBefore(a, index, limit);
    } catch (Exception e) {
        if (expectedException.isInstance(e)) { // <---
            return;
        }
        throw new RuntimeException("Unspecified exception", e);
    }
    throw new RuntimeException("codePoint" + (isAt ? "At" : "Before")
                               + " didn't throw " + expectedException.getName());
}

to 

private static void callCodePoint(boolean isAt, char[] a, int index, int limit,
                                  Class expectedException) {
    try {
        int c = isAt ? Character.codePointAt(a, index, limit)
                     : Character.codePointBefore(a, index, limit);
    } catch (Exception e) {
        if (expectedException.getClass() == e.getClass()) { // <---
            return;
        }
        throw new RuntimeException("Unspecified exception", e);
    }
    throw new RuntimeException("codePoint" + (isAt ? "At" : "Before")
                               + " didn't throw " + expectedException.getName());
}

i.e. check exception type strictly. What do you think?

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

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

From weijun at openjdk.org  Fri Dec  2 15:23:51 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 2 Dec 2022 15:23:51 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <ShycxtxiMZ0JMdI3EaSMKTHPO8NzJclj5VuOe2Xbqxk=.a8d846a6-0bc7-4a2e-83bb-224ed8a0e72e@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
 <JCBfRAbsgf6bH6lqeXWodGC89bWpXwpwNlv2E1aHPUI=.85727228-d8c8-4918-818a-ae6606514b99@github.com>
 <ZTmLDk0M9hsuICQeazcIat8UdUvM49UAisgTfoV8LCg=.799c1bfe-57a8-4b24-a72e-ed7f970bcf95@github.com>
 <nrL_Up0TmjkjNZgQtxGCZG3gkOF2eg5FiJYUK_J1kJs=.164122ef-8750-487c-abc5-e5b92bdf7c2c@github.com>
 <no3fTAbXqXI9w9odDcE5nFpKzJWuUHHi9eOY04AXBAI=.fafda472-c4b3-4251-b496-f149e463bea4@github.com>
 <ktUnahpoaSsO7Ycw0Bav_j-Tb0iOA-4S3BpmK7h8LWo=.ad9b526a-f0d8-4963-a1c3-1f098d0fcbc6@github.com>
 <tP7Z8ToLzTciRkvSBXR5WlF65EGcVQ89tSvtSO3XCaw=.da2e4cdd-a652-4813-9fc5-62e1c50c1105@github.com>
 <ShycxtxiMZ0JMdI3EaSMKTHPO8NzJclj5VuOe2Xbqxk=.a8d846a6-0bc7-4a2e-83bb-224ed8a0e72e@github.com>
Message-ID: <qq5C9afaTVN6a3JJci9IOrVN7eNsZY1o2OCdcN_abS4=.f1088244-a9fa-4227-93f5-7bfec38b4019@github.com>

On Fri, 2 Dec 2022 08:18:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> If the console cannot be used anyway inside jshell, then this is good enough.
>
> Naoto has confirmed that the password prompt from keytool does not echo, good!
> 
> The intention is that Console be usable in jshell so I think the issue is that readPassword is echo'ing when used in jshell. Maybe someone experimenting with the Console API might run into this but we can separate out that issue.

Still not sure what the expected behavior is, but for keytool, because of the updated check, `sun.security.util.Password` now uses `System.in.read` instead of `Console.readPassword`, therefore the password is echoing. I tried removing the check and force `Console.readPassword` to be called. There is no echo but the return key also does not work. I have to Ctrl-C to break out.

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

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

From duke at openjdk.org  Fri Dec  2 15:36:19 2022
From: duke at openjdk.org (Brett Okken)
Date: Fri, 2 Dec 2022 15:36:19 GMT
Subject: RFR: 8298033: Character.codePointAt(char[], int,
 int) doesn't do JavaDoc-specified check
In-Reply-To: <dHjviGmASssYfntfClzDC28Ppjrn3pECnO3HzbZHopY=.d9923de3-6de7-41f5-a84e-03a7c5267e2f@github.com>
References: <dHjviGmASssYfntfClzDC28Ppjrn3pECnO3HzbZHopY=.d9923de3-6de7-41f5-a84e-03a7c5267e2f@github.com>
Message-ID: <h11W_hwOIeKTFCMzR8xyJRVxs2guPW92_bpWsw-aKt8=.22575b73-0682-4e90-81a7-5bd0989cf26c@github.com>

On Fri, 2 Dec 2022 12:44:18 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> I found out that this code
> 
> public class Main {
>     public static void main(String[] args) {
>         String s = "Hello world!";
>         char[] chars = s.toCharArray();
>         int point = Character.codePointAt(chars, -1, 1);
>     }
> }
> 
> throws `ArrayIndexOutOfBoundsException` instead of JavaDoc-specified `IndexOutOfBoundsException`: 
> 
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds for length 12
> 	at java.base/java.lang.Character.codePointAtImpl(Character.java:9254)
> 	at java.base/java.lang.Character.codePointAt(Character.java:9249)
> 	at org.example.Main.main(Main.java:7)
> 
> and the method doesn't check whether `index` parameter is negative:
> 
> public static int codePointAt(char[] a, int index, int limit) {
>     if (index >= limit || limit < 0 || limit > a.length) {
>         throw new IndexOutOfBoundsException();
>     }
>     return codePointAtImpl(a, index, limit);
> }
> 
> I suggest to check the `index` parameter explicitly instead of relying on AIOOBE thrown from accessing the array with negative index.

As `ArrayIndexOutOfBoundsException` is an `IndexOutOfBoundsException`, it is not clear to me how this is not matching the javadoc/spec.
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/ArrayIndexOutOfBoundsException.html

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

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

From rriggs at openjdk.org  Fri Dec  2 15:48:06 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 2 Dec 2022 15:48:06 GMT
Subject: RFR: 8298033: Character.codePointAt(char[], int,
 int) doesn't do JavaDoc-specified check
In-Reply-To: <dHjviGmASssYfntfClzDC28Ppjrn3pECnO3HzbZHopY=.d9923de3-6de7-41f5-a84e-03a7c5267e2f@github.com>
References: <dHjviGmASssYfntfClzDC28Ppjrn3pECnO3HzbZHopY=.d9923de3-6de7-41f5-a84e-03a7c5267e2f@github.com>
Message-ID: <kfMj_67BVci6Kjw2nD1C7GziCaSypudvNbFNI_tC2-A=.08107109-c30a-45d5-972f-0fa410c17034@github.com>

On Fri, 2 Dec 2022 12:44:18 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> I found out that this code
> 
> public class Main {
>     public static void main(String[] args) {
>         String s = "Hello world!";
>         char[] chars = s.toCharArray();
>         int point = Character.codePointAt(chars, -1, 1);
>     }
> }
> 
> throws `ArrayIndexOutOfBoundsException` instead of JavaDoc-specified `IndexOutOfBoundsException`: 
> 
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds for length 12
> 	at java.base/java.lang.Character.codePointAtImpl(Character.java:9254)
> 	at java.base/java.lang.Character.codePointAt(Character.java:9249)
> 	at org.example.Main.main(Main.java:7)
> 
> and the method doesn't check whether `index` parameter is negative:
> 
> public static int codePointAt(char[] a, int index, int limit) {
>     if (index >= limit || limit < 0 || limit > a.length) {
>         throw new IndexOutOfBoundsException();
>     }
>     return codePointAtImpl(a, index, limit);
> }
> 
> I suggest to check the `index` parameter explicitly instead of relying on AIOOBE thrown from accessing the array with negative index.

It does meet the spec (subclasses of exception types are ok), but doesn't meet expectations of the implementation, especially since the implementation has an explicit test and throw.

As for the test, checking for exact exception type is fine.  
JTreg tests frequently test the implementation, not just the spec.

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

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

From stsypanov at openjdk.org  Fri Dec  2 16:13:31 2022
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 2 Dec 2022 16:13:31 GMT
Subject: RFR: 8298033: Character.codePointAt(char[], int,
 int) doesn't do JavaDoc-specified check [v2]
In-Reply-To: <dHjviGmASssYfntfClzDC28Ppjrn3pECnO3HzbZHopY=.d9923de3-6de7-41f5-a84e-03a7c5267e2f@github.com>
References: <dHjviGmASssYfntfClzDC28Ppjrn3pECnO3HzbZHopY=.d9923de3-6de7-41f5-a84e-03a7c5267e2f@github.com>
Message-ID: <3HTg080tgOcxVZo1q5-zm4M83Ah3dpMfoS4Hwa7nX9U=.263c65ad-84ea-4e8e-b160-6beafe852b09@github.com>

> I found out that this code
> 
> public class Main {
>     public static void main(String[] args) {
>         String s = "Hello world!";
>         char[] chars = s.toCharArray();
>         int point = Character.codePointAt(chars, -1, 1);
>     }
> }
> 
> throws `ArrayIndexOutOfBoundsException` instead of JavaDoc-specified `IndexOutOfBoundsException`: 
> 
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds for length 12
> 	at java.base/java.lang.Character.codePointAtImpl(Character.java:9254)
> 	at java.base/java.lang.Character.codePointAt(Character.java:9249)
> 	at org.example.Main.main(Main.java:7)
> 
> and the method doesn't check whether `index` parameter is negative:
> 
> public static int codePointAt(char[] a, int index, int limit) {
>     if (index >= limit || limit < 0 || limit > a.length) {
>         throw new IndexOutOfBoundsException();
>     }
>     return codePointAtImpl(a, index, limit);
> }
> 
> I suggest to check the `index` parameter explicitly instead of relying on AIOOBE thrown from accessing the array with negative index.

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

  8298033: Tighten test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11480/files
  - new: https://git.openjdk.org/jdk/pull/11480/files/a15bc974..5099c08a

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

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

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

From stsypanov at openjdk.org  Fri Dec  2 16:15:25 2022
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 2 Dec 2022 16:15:25 GMT
Subject: RFR: 8298033: Character.codePointAt(char[], int,
 int) doesn't do JavaDoc-specified check
In-Reply-To: <h11W_hwOIeKTFCMzR8xyJRVxs2guPW92_bpWsw-aKt8=.22575b73-0682-4e90-81a7-5bd0989cf26c@github.com>
References: <dHjviGmASssYfntfClzDC28Ppjrn3pECnO3HzbZHopY=.d9923de3-6de7-41f5-a84e-03a7c5267e2f@github.com>
 <h11W_hwOIeKTFCMzR8xyJRVxs2guPW92_bpWsw-aKt8=.22575b73-0682-4e90-81a7-5bd0989cf26c@github.com>
Message-ID: <qYvcto8hOdlHkIEzRHcJvUVUrW_4Nseue878RaKob2E=.0f117104-3d0f-481b-9ba8-6ce2eedbd4a1@github.com>

On Fri, 2 Dec 2022 15:32:20 GMT, Brett Okken <duke at openjdk.org> wrote:

> As ArrayIndexOutOfBoundsException is an IndexOutOfBoundsException, it is not clear to me how this is not matching the javadoc/spec.

The check within `codePointAt()` doesn't match the spec. `ArrayIndexOutOfBoundsException` is thrown from the array element access, however even in some classes explicitly declaring it in their JavaDoc e.g. `Arrays` it's never thrown from array access but from Java code,

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

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

From jlaskey at openjdk.org  Fri Dec  2 16:51:48 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 2 Dec 2022 16:51:48 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v32]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <U2ZZfoc2VKb3KdXhEy9dKR4yU6lUeawIDV9auD3nGkI=.fc56de1c-6752-4a41-ab64-6b33f784ad29@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

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

 - Merge branch 'master' into 8285932
 - FormatProcessor changes
 - Update @since
 - Requested changes #12
 - Seal Digits
 - Requested changes #11
 - Typo
 - Requested changes #10
 - Requested changes #9
 - Requested changes #8
 - ... and 37 more: https://git.openjdk.org/jdk/compare/6065696e...581e0f7a

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

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=31
  Stats: 9519 lines in 81 files changed: 9356 ins; 28 del; 135 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

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

From ihse at openjdk.org  Fri Dec  2 16:52:16 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 16:52:16 GMT
Subject: RFR: 8298045: Fix hidden but significant trailing whitespace in
 properties files for core-libs code
Message-ID: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>

According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.

We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").

After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)

Doing so has a dual benefit:

1) It makes it clear to everyone reading the code that there is a trailing space and it is intended

2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.

Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the core-libs team.

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

Commit messages:
 - 8298045: Fix hidden but significant trailing whitespace in properties files for core-libs code

Changes: https://git.openjdk.org/jdk/pull/11489/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11489&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298045
  Stats: 308 lines in 78 files changed: 0 ins; 0 del; 308 mod
  Patch: https://git.openjdk.org/jdk/pull/11489.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11489/head:pull/11489

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

From ihse at openjdk.org  Fri Dec  2 16:52:16 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 16:52:16 GMT
Subject: RFR: 8298045: Fix hidden but significant trailing whitespace in
 properties files for core-libs code
In-Reply-To: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>
References: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>
Message-ID: <fFxu85P9b4eRFBowNuiSYQdyCA9OJvRPVPm5C_mqB70=.2b7eac64-ec95-49df-b3fd-cebcb18e674b@github.com>

On Fri, 2 Dec 2022 16:40:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the core-libs team.

**A note to reviewers:**

This PR has been automatically generated by converting all trailing spaces in key-value lines (ignoring empty lines and comments) in the property files into unicode sequences.

In a way, this is a no-op, converting one representation of the already existing space into another. But I think that most of these instances are likely to be bugs, and should thus be fixed.

I think the easiest way to fix those instances is to use the Github "suggestion" review mechanism: 
If you see a value where the trailing space should be removed, press the blue `+` in the gutter as usual, and then in the comment box press the `+/-` icon (or press `ctrl-G`/`cmd-G`). Now you get a copy of the offending line, and can edit it to remove the trailing unicode sequence. I can then easily accept the suggestion into the PR.

But you can also come with review feedback like "remove trailing spaces for all files in directory XXX" and I'll fix that for you.

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

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

From jvernee at openjdk.org  Fri Dec  2 16:52:44 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 2 Dec 2022 16:52:44 GMT
Subject: RFR: 8291359: Specification of method j.l.foreign.VaList::skip
 still deserves clarification [v2]
In-Reply-To: <22NI2qOGin9akfiuHlZtOnEVFf48IjFWTHVjFjA9WrU=.77ff6ce2-9da4-46dc-a291-6943274cabc0@github.com>
References: <vHHYP2B3-wJHXVPjmc0bP6Raouhn3ni-M_d1A_ULlp8=.17cfc6d8-f18e-46fb-a1fe-ffdf4b816d84@github.com>
 <VgD0_n7cpBcnT5OdL0jrSPEDwoeZF5Q3d-ZTt0dFfiA=.98dc5712-67ee-4141-8b38-bd42479bf75b@github.com>
 <ITJSxOx9YjWHr7-BpV5PxgfEMdLsI14menCBgM18_bs=.c4669ed0-19b7-44e4-bd79-11b7ed658f7e@github.com>
 <zL9SkQ5SiknPWVyN7kfCHP1d8_OQkqZVFrQxNjcQ9DI=.a86de67b-2930-4fd6-bfc3-e4fa5196b1cf@github.com>
 <Gdywkdba9s0tfVksRJU-8LQscoZ6bbfcfkr7P3T3Jd4=.678c15a9-b4d3-4c26-80e2-e4abac12b064@github.com>
 <22NI2qOGin9akfiuHlZtOnEVFf48IjFWTHVjFjA9WrU=.77ff6ce2-9da4-46dc-a291-6943274cabc0@github.com>
Message-ID: <SrUag3r9LcfpMcKB8xDJCtz6CUSebY_-o80Jp95-abU=.79153bcd-914c-4cca-8dc1-2ed91569fb67@github.com>

On Thu, 1 Dec 2022 21:56:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Right.
>
> This sentence still needs to be clarified IMHO. E.g. it is not clear when reading what "using a memory layout other than the layout of the accessed value" - since we are passing a layout to the access operation... it feels like we're trying to compress too much. We should say something like:
> 
> 
> The values in a variable argument list are stored in one or more regions of memory in a platform specific fashion. 
> Any attempt to access (or skip) any such value with a mismatched memory layout (example) will result in undefined behavior.

I think we don't need to say anything about how the values are stored. I wanted to avoid using the term "undefined behavior" at first as well, since it sounds like something that is defined elsewhere (which it isn't), but maybe that's okay. Though, I agree that what I have now doesn't quite feel right.

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

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

From jvernee at openjdk.org  Fri Dec  2 17:03:43 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 2 Dec 2022 17:03:43 GMT
Subject: RFR: 8291359: Specification of method j.l.foreign.VaList::skip
 still deserves clarification [v4]
In-Reply-To: <vHHYP2B3-wJHXVPjmc0bP6Raouhn3ni-M_d1A_ULlp8=.17cfc6d8-f18e-46fb-a1fe-ffdf4b816d84@github.com>
References: <vHHYP2B3-wJHXVPjmc0bP6Raouhn3ni-M_d1A_ULlp8=.17cfc6d8-f18e-46fb-a1fe-ffdf4b816d84@github.com>
Message-ID: <GBjwfX6y9Z46LxLlt6ywbXh65f6PB_GkUn4ax1AowQI=.7ca9e86d-9d9c-4cd3-9088-73b9138283bb@github.com>

> A small clarification of the VaList spec to say that attempts to access elements through an incorrect memory layout result in undefined behavior.

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

  rewrite doc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11440/files
  - new: https://git.openjdk.org/jdk/pull/11440/files/6b2f059d..a0648062

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

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

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

From jvernee at openjdk.org  Fri Dec  2 17:03:45 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 2 Dec 2022 17:03:45 GMT
Subject: RFR: 8291359: Specification of method j.l.foreign.VaList::skip
 still deserves clarification [v4]
In-Reply-To: <GBjwfX6y9Z46LxLlt6ywbXh65f6PB_GkUn4ax1AowQI=.7ca9e86d-9d9c-4cd3-9088-73b9138283bb@github.com>
References: <vHHYP2B3-wJHXVPjmc0bP6Raouhn3ni-M_d1A_ULlp8=.17cfc6d8-f18e-46fb-a1fe-ffdf4b816d84@github.com>
 <GBjwfX6y9Z46LxLlt6ywbXh65f6PB_GkUn4ax1AowQI=.7ca9e86d-9d9c-4cd3-9088-73b9138283bb@github.com>
Message-ID: <e_dNa2u0_eW6SUfcvnYWHC4VAv0vdJaxoWJFnuJ-uo8=.65b30cde-67e8-422e-bfd9-08fb58b80517@github.com>

On Fri, 2 Dec 2022 16:59:25 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> A small clarification of the VaList spec to say that attempts to access elements through an incorrect memory layout result in undefined behavior.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rewrite doc

src/java.base/share/classes/java/lang/foreign/VaList.java line 55:

> 53:  * and any other type that fits into a {@code long}.
> 54:  * <h2 id="safety">Safety considerations</h2>
> 55:  * Accessing a value through a variable argument list using the wrong memory layout will result in undefined behavior.

Note that I went with "through" here, instead of "in", since we describe a va list as a "stateful cursor used to iterate over a set of arguments" in the section before this.

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

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

From jvernee at openjdk.org  Fri Dec  2 17:03:46 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 2 Dec 2022 17:03:46 GMT
Subject: RFR: 8291359: Specification of method j.l.foreign.VaList::skip
 still deserves clarification [v2]
In-Reply-To: <SrUag3r9LcfpMcKB8xDJCtz6CUSebY_-o80Jp95-abU=.79153bcd-914c-4cca-8dc1-2ed91569fb67@github.com>
References: <vHHYP2B3-wJHXVPjmc0bP6Raouhn3ni-M_d1A_ULlp8=.17cfc6d8-f18e-46fb-a1fe-ffdf4b816d84@github.com>
 <VgD0_n7cpBcnT5OdL0jrSPEDwoeZF5Q3d-ZTt0dFfiA=.98dc5712-67ee-4141-8b38-bd42479bf75b@github.com>
 <ITJSxOx9YjWHr7-BpV5PxgfEMdLsI14menCBgM18_bs=.c4669ed0-19b7-44e4-bd79-11b7ed658f7e@github.com>
 <zL9SkQ5SiknPWVyN7kfCHP1d8_OQkqZVFrQxNjcQ9DI=.a86de67b-2930-4fd6-bfc3-e4fa5196b1cf@github.com>
 <Gdywkdba9s0tfVksRJU-8LQscoZ6bbfcfkr7P3T3Jd4=.678c15a9-b4d3-4c26-80e2-e4abac12b064@github.com>
 <22NI2qOGin9akfiuHlZtOnEVFf48IjFWTHVjFjA9WrU=.77ff6ce2-9da4-46dc-a291-6943274cabc0@github.com>
 <SrUag3r9LcfpMcKB8xDJCtz6CUSebY_-o80Jp95-abU=.79153bcd-914c-4cca-8dc1-2ed91569fb67@github.com>
Message-ID: <nJcdOIeY8w3Rs-2x8cF2pATX51IQovObTqQf2YAI3oc=.e2e765b5-183c-4108-8157-0372c48fce44@github.com>

On Fri, 2 Dec 2022 16:45:56 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This sentence still needs to be clarified IMHO. E.g. it is not clear when reading what "using a memory layout other than the layout of the accessed value" - since we are passing a layout to the access operation... it feels like we're trying to compress too much. We should say something like:
>> 
>> 
>> The values in a variable argument list are stored in one or more regions of memory in a platform specific fashion. 
>> Any attempt to access (or skip) any such value with a mismatched memory layout (example) will result in undefined behavior.
>
> I think we don't need to say anything about how the values are stored. I wanted to avoid using the term "undefined behavior" at first as well, since it sounds like something that is defined elsewhere (which it isn't), but maybe that's okay. Though, I agree that what I have now doesn't quite feel right.

I've tried to re-write this to be more clear (including an example)

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

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

From ihse at openjdk.org  Fri Dec  2 17:12:37 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 17:12:37 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <Cwps2k2ip4t3Jr5Joqk8hKXxuweY8V71hiAzZW5hto4=.8da555f4-12ef-4e10-b656-093a834e0d5f@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

This turned out to be much more complicated than anticipated. I am going to close this PR (and bug), and instead I have split up this work in five different bugs:

[JDK-8298047](https://bugs.openjdk.org/browse/JDK-8298047) is about removing all non-significant whitespace from all properties files, basically corresponding to how this PR looked after the second commit.

[JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046) is about fixing the significant whitespace, by turning it to unicode sequences or removing it, if it turns out there should not have been a space there. This work is split into four parts to be able to have one bug per component team.

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

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

From ihse at openjdk.org  Fri Dec  2 17:12:39 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 17:12:39 GMT
Subject: Withdrawn: 8295729: Add jcheck whitespace checking for properties
 files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <FucejIc47XdfLlKe8MOVxYBnv1k7GvnH1TgHiinx9ak=.b06a548a-3575-4456-8df4-f8804114105b@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

This pull request has been closed without being integrated.

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

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

From ihse at openjdk.org  Fri Dec  2 17:14:23 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 17:14:23 GMT
Subject: RFR: 8298047: Remove all non-significant trailing whitespace from
 properties files
Message-ID: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>

[JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an attempt to remove all trailing whitespace from properties files, and enable a jcheck verification that they did not come back, similar to other source code. It turned out that this was not so simple, however, since trailing whitespace in values is actually significant in properties files.

To address this, I have opened four bugs on different component teams to either remove the trailing significant whitespace (if it is there erroneously), or convert it to the unicode sequence `\u0020`: [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046).

That leaves all the other trailing spaces, in blank lines and in the end of comments. These serve no purpose and should just be removed, and is what this issue concerns.

When this and the four "significant whitespace" bugs are all finally integrated, we can finally turn on the verification in jcheck for properties files as well.

The changes in this PR is based on [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), in #10792. I have restored all the "delete trailing whitespace" changes, except for those with significance. These changes were in turned created by  running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

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

Commit messages:
 - 8298047: Remove all non-significant trailing whitespace from properties files

Changes: https://git.openjdk.org/jdk/pull/11491/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11491&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298047
  Stats: 693 lines in 264 files changed: 0 ins; 0 del; 693 mod
  Patch: https://git.openjdk.org/jdk/pull/11491.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11491/head:pull/11491

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

From angorya at openjdk.org  Fri Dec  2 17:15:19 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 Dec 2022 17:15:19 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <Cwps2k2ip4t3Jr5Joqk8hKXxuweY8V71hiAzZW5hto4=.8da555f4-12ef-4e10-b656-093a834e0d5f@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <Cwps2k2ip4t3Jr5Joqk8hKXxuweY8V71hiAzZW5hto4=.8da555f4-12ef-4e10-b656-093a834e0d5f@github.com>
Message-ID: <2Ed-oJoEq8e9g8Og4JD8_Pddjj3A_O5KGSrJpaDFrmk=.bcd0280d-33bb-4570-81e0-6700ff65e921@github.com>

On Fri, 2 Dec 2022 17:10:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> and instead I have split up this work in five different bugs

would you consider also adding a unit test to check whether the localized resources also contain leading/trailing whitespace, and possibly special characters (like {, }, , etc.) that are present in the main resource?

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

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

From jvernee at openjdk.org  Fri Dec  2 17:42:51 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 2 Dec 2022 17:42:51 GMT
Subject: RFR: 8296477: Foreign linker implementation update following JEP
 434 [v10]
In-Reply-To: <CGd4JSefJvfEVkZEfORzthEIeV53kLk_UkZHAhJGrQ0=.7741b5f2-2227-4017-8164-d54fb9d30d10@github.com>
References: <CGd4JSefJvfEVkZEfORzthEIeV53kLk_UkZHAhJGrQ0=.7741b5f2-2227-4017-8164-d54fb9d30d10@github.com>
Message-ID: <Te2ZS9wAT5n_r8s3Uu6w7UBiueX4MTtkDYaaznp6w4E=.e44ca44c-3a2d-49bd-b1ca-39b5ce756bc7@github.com>

> Pull in linker implementation changes, that include non-trivial changes to VM code, from the panama-foreign repo into the main JDK.
> 
> This is split off from the main JEP integration to make reviewing easier.
> 
> This includes the following patches:
> 
> 1. https://github.com/openjdk/panama-foreign/pull/698
> 2. https://github.com/openjdk/panama-foreign/pull/699
> 3. (part of) https://github.com/openjdk/panama-foreign/pull/731
> 4. https://github.com/openjdk/panama-foreign/pull/740
> 5. https://github.com/openjdk/panama-foreign/pull/746
> 6. https://github.com/openjdk/panama-foreign/pull/742
> 7. https://github.com/openjdk/panama-foreign/pull/743
> 
> Probably the biggest change to the code comes from replacing `VMReg` - which can not represent offsets into the stack that are not a multiple of the VM's stack slot size (32-bits) - with the new `VMStorage` class, which can describe byte offsets into the stack, as well as having a register mask to indicate only certain register segments.
> 
> The only part of 3. that is in this PR is the part that turns the `VMStorage` class in Java into a record.
> 
> Please refer to the PR of each individual patch for a more detailed description.

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 25 additional commits since the last revision:

 - Merge branch 'PR_20' into VM_Changes
 - Merge branch 'PR_20' into VM_Changes
 - use Arena in example
 - Merge branch 'PR_20' into VM_Changes
 - drop .inline from vmstorage header names
 - 8296973: saving errno on a value-returning function crashes the JVM
   
   Reviewed-by: mcimadamore
 - fix stubs
 - constexpr some functions
 - Review pt1
 - Tweak copyright headers
 - ... and 15 more: https://git.openjdk.org/jdk/compare/ea28395b...6e94e452

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11019/files
  - new: https://git.openjdk.org/jdk/pull/11019/files/75917216..6e94e452

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

  Stats: 67862 lines in 1342 files changed: 30668 ins; 21968 del; 15226 mod
  Patch: https://git.openjdk.org/jdk/pull/11019.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11019/head:pull/11019

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

From jvernee at openjdk.org  Fri Dec  2 18:01:27 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 2 Dec 2022 18:01:27 GMT
Subject: RFR: 8291359: Specification of method j.l.foreign.VaList::skip
 still deserves clarification [v5]
In-Reply-To: <vHHYP2B3-wJHXVPjmc0bP6Raouhn3ni-M_d1A_ULlp8=.17cfc6d8-f18e-46fb-a1fe-ffdf4b816d84@github.com>
References: <vHHYP2B3-wJHXVPjmc0bP6Raouhn3ni-M_d1A_ULlp8=.17cfc6d8-f18e-46fb-a1fe-ffdf4b816d84@github.com>
Message-ID: <o3-yBbRaz1zdI_zc_u-0i5eMExomTvsQNSD8trn2lrA=.b8ff5ee1-6a12-4f27-bd16-b2ed6dd1a323@github.com>

> A small clarification of the VaList spec to say that attempts to access elements through an incorrect memory layout result in undefined behavior.

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

  Typos

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11440/files
  - new: https://git.openjdk.org/jdk/pull/11440/files/a0648062..ba3e977e

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

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

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

From weijun at openjdk.org  Fri Dec  2 18:51:07 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 2 Dec 2022 18:51:07 GMT
Subject: RFR: 8298045: Fix hidden but significant trailing whitespace in
 properties files for core-libs code
In-Reply-To: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>
References: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>
Message-ID: <xp58-oyXNmSSI1GSAZfCbYGVMUMRACd1cfBV8gUqwug=.757bf432-e9c8-4a80-abe9-d9f94cd45a12@github.com>

On Fri, 2 Dec 2022 16:40:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the core-libs team.

test/jdk/javax/net/ssl/Stapling/TEST.properties line 5:

> 3:     java.base/sun.security.util \
> 4:     java.base/sun.security.validator \
> 5:     java.base/sun.security.x509\u0020

Useless space. Should remove.

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

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

From stsypanov at openjdk.org  Fri Dec  2 18:53:21 2022
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 2 Dec 2022 18:53:21 GMT
Subject: RFR: 8298033: Character.codePointAt(char[], int,
 int) doesn't do JavaDoc-specified check [v3]
In-Reply-To: <dHjviGmASssYfntfClzDC28Ppjrn3pECnO3HzbZHopY=.d9923de3-6de7-41f5-a84e-03a7c5267e2f@github.com>
References: <dHjviGmASssYfntfClzDC28Ppjrn3pECnO3HzbZHopY=.d9923de3-6de7-41f5-a84e-03a7c5267e2f@github.com>
Message-ID: <4UxZnSr4yjQQIAFOP_Lm1n-lqQ0m1zQAp-knX42Cy-k=.124fabe0-7cf8-4f19-bdcc-234d2f2e4796@github.com>

> I found out that this code
> 
> public class Main {
>     public static void main(String[] args) {
>         String s = "Hello world!";
>         char[] chars = s.toCharArray();
>         int point = Character.codePointAt(chars, -1, 1);
>     }
> }
> 
> throws `ArrayIndexOutOfBoundsException` instead of JavaDoc-specified `IndexOutOfBoundsException`: 
> 
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds for length 12
> 	at java.base/java.lang.Character.codePointAtImpl(Character.java:9254)
> 	at java.base/java.lang.Character.codePointAt(Character.java:9249)
> 	at org.example.Main.main(Main.java:7)
> 
> and the method doesn't check whether `index` parameter is negative:
> 
> public static int codePointAt(char[] a, int index, int limit) {
>     if (index >= limit || limit < 0 || limit > a.length) {
>         throw new IndexOutOfBoundsException();
>     }
>     return codePointAtImpl(a, index, limit);
> }
> 
> I suggest to check the `index` parameter explicitly instead of relying on AIOOBE thrown from accessing the array with negative index.

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

  8298033: Fix test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11480/files
  - new: https://git.openjdk.org/jdk/pull/11480/files/5099c08a..39ab3401

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

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

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

From mcimadamore at openjdk.org  Fri Dec  2 20:25:17 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 2 Dec 2022 20:25:17 GMT
Subject: RFR: 8291359: Specification of method j.l.foreign.VaList::skip
 still deserves clarification [v4]
In-Reply-To: <e_dNa2u0_eW6SUfcvnYWHC4VAv0vdJaxoWJFnuJ-uo8=.65b30cde-67e8-422e-bfd9-08fb58b80517@github.com>
References: <vHHYP2B3-wJHXVPjmc0bP6Raouhn3ni-M_d1A_ULlp8=.17cfc6d8-f18e-46fb-a1fe-ffdf4b816d84@github.com>
 <GBjwfX6y9Z46LxLlt6ywbXh65f6PB_GkUn4ax1AowQI=.7ca9e86d-9d9c-4cd3-9088-73b9138283bb@github.com>
 <e_dNa2u0_eW6SUfcvnYWHC4VAv0vdJaxoWJFnuJ-uo8=.65b30cde-67e8-422e-bfd9-08fb58b80517@github.com>
Message-ID: <hTX9dhrzOLuaynqIrCBQsRLWkhaYCGq-3Ha2kgII7lU=.7b8d9421-dac5-47c6-8ccf-dadf025e9c77@github.com>

On Fri, 2 Dec 2022 16:59:25 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rewrite doc
>
> src/java.base/share/classes/java/lang/foreign/VaList.java line 55:
> 
>> 53:  * and any other type that fits into a {@code long}.
>> 54:  * <h2 id="safety">Safety considerations</h2>
>> 55:  * Accessing a value through a variable argument list using the wrong memory layout will result in undefined behavior.
> 
> Note that I went with "through" here, instead of "in", since we describe a va list as a "stateful cursor used to iterate over a set of arguments" in the section before this.

I think we can condense this:


 For instance, if a variable argument list currently points at a C {@code int} value, then accessing it using
 * {@link #nextVarg(ValueLayout.OfLong)} is illegal. Similarly, accessing the variable argument list with  {@link #skip(MemoryLayout...)}, and providing a layout other than {@link ValueLayout.OfInt} is illegal. Any such illegal accesses might not be detected by the implementation, and can corrupt the variable argument list, so that the behavior of subsequent accesses is also undefined.
 ```

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

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

From xliu at openjdk.org  Fri Dec  2 20:25:50 2022
From: xliu at openjdk.org (Xin Liu)
Date: Fri, 2 Dec 2022 20:25:50 GMT
Subject: RFR: 8284493: Improve computeNextExponential tail performance and
 accuracy [v16]
In-Reply-To: <8f6zH_Gx-PKYE9RVC3Ac4YfuFonsC0AlHhvHzdsMdKQ=.9c26ea79-66e7-40d0-9e9d-0a4f07801232@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
 <GKQOg02og11alcCgOGPGZ2wn41zf6g5RylUm74Glr_k=.e5ad1226-a6ee-412f-8508-08946ef11eae@github.com>
 <8f6zH_Gx-PKYE9RVC3Ac4YfuFonsC0AlHhvHzdsMdKQ=.9c26ea79-66e7-40d0-9e9d-0a4f07801232@github.com>
Message-ID: <sHIuPW9xtcGAAHwoqA-VByvkM_5S36frOu2dOyfLcRg=.ba19a97b-5ee5-4343-a214-be3d92fbd71e@github.com>

On Thu, 1 Dec 2022 21:31:28 GMT, Chris Hennick <duke at openjdk.org> wrote:

>> Chris Hennick has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add parameter to enable/disable fixed PRNG seed
>
> @simonis @navyxliu @turbanoff @rgiulietti This is ready for review with the benchmark results.

hi, @Pr0methean 

I notice that  there is a big regression in L64X1024MixRandom.nextExponential p100 on [c7g.16xlarge](https://aws.amazon.com/ec2/instance-types/c7g/)

L64X1024MixRandom.nextExponential() p100 ns/op: 560 before, 3760 after


but the average ns/op improves. Can you explain the discrepancy? 

btw: I updated the JBS issue to ensure the subject is aligned with your PR. 

Thanks,
--lx

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

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

From jvernee at openjdk.org  Fri Dec  2 20:34:30 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 2 Dec 2022 20:34:30 GMT
Subject: RFR: 8291359: Specification of method j.l.foreign.VaList::skip
 still deserves clarification [v6]
In-Reply-To: <vHHYP2B3-wJHXVPjmc0bP6Raouhn3ni-M_d1A_ULlp8=.17cfc6d8-f18e-46fb-a1fe-ffdf4b816d84@github.com>
References: <vHHYP2B3-wJHXVPjmc0bP6Raouhn3ni-M_d1A_ULlp8=.17cfc6d8-f18e-46fb-a1fe-ffdf4b816d84@github.com>
Message-ID: <LBwFrJ_UPiJ5-2wijP51U7ofgeRPzu4LqTBbBawResw=.e0943020-c759-45d0-bd00-907d48f0d4c3@github.com>

> A small clarification of the VaList spec to say that attempts to access elements through an incorrect memory layout result in undefined behavior.

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

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11440/files
  - new: https://git.openjdk.org/jdk/pull/11440/files/ba3e977e..95cac667

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

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

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

From jvernee at openjdk.org  Fri Dec  2 20:34:32 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 2 Dec 2022 20:34:32 GMT
Subject: RFR: 8291359: Specification of method j.l.foreign.VaList::skip
 still deserves clarification [v4]
In-Reply-To: <hTX9dhrzOLuaynqIrCBQsRLWkhaYCGq-3Ha2kgII7lU=.7b8d9421-dac5-47c6-8ccf-dadf025e9c77@github.com>
References: <vHHYP2B3-wJHXVPjmc0bP6Raouhn3ni-M_d1A_ULlp8=.17cfc6d8-f18e-46fb-a1fe-ffdf4b816d84@github.com>
 <GBjwfX6y9Z46LxLlt6ywbXh65f6PB_GkUn4ax1AowQI=.7ca9e86d-9d9c-4cd3-9088-73b9138283bb@github.com>
 <e_dNa2u0_eW6SUfcvnYWHC4VAv0vdJaxoWJFnuJ-uo8=.65b30cde-67e8-422e-bfd9-08fb58b80517@github.com>
 <hTX9dhrzOLuaynqIrCBQsRLWkhaYCGq-3Ha2kgII7lU=.7b8d9421-dac5-47c6-8ccf-dadf025e9c77@github.com>
Message-ID: <MKPAm5FDwScIVpoPnsFvcUnuxbvhJb-zMJqCz6Tw6XQ=.4a65ce38-eb2d-415e-adf6-ef75c4c83762@github.com>

On Fri, 2 Dec 2022 20:21:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/VaList.java line 55:
>> 
>>> 53:  * and any other type that fits into a {@code long}.
>>> 54:  * <h2 id="safety">Safety considerations</h2>
>>> 55:  * Accessing a value through a variable argument list using the wrong memory layout will result in undefined behavior.
>> 
>> Note that I went with "through" here, instead of "in", since we describe a va list as a "stateful cursor used to iterate over a set of arguments" in the section before this.
>
> I think we can condense this:
> 
> 
>  For instance, if a variable argument list currently points at a C {@code int} value, then accessing it using
>  * {@link #nextVarg(ValueLayout.OfLong)} is illegal. Similarly, accessing the variable argument list with  {@link #skip(MemoryLayout...)}, and providing a layout other than {@link ValueLayout.OfInt} is illegal. Any such illegal accesses might not be detected by the implementation, and can corrupt the variable argument list, so that the behavior of subsequent accesses is also undefined.
>  ```

Done

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

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

From duke at openjdk.org  Fri Dec  2 20:42:14 2022
From: duke at openjdk.org (Chris Hennick)
Date: Fri, 2 Dec 2022 20:42:14 GMT
Subject: RFR: 8284493: Improve computeNextExponential tail performance and
 accuracy [v16]
In-Reply-To: <GKQOg02og11alcCgOGPGZ2wn41zf6g5RylUm74Glr_k=.e5ad1226-a6ee-412f-8508-08946ef11eae@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
 <GKQOg02og11alcCgOGPGZ2wn41zf6g5RylUm74Glr_k=.e5ad1226-a6ee-412f-8508-08946ef11eae@github.com>
Message-ID: <wbFmoH5Ezcp66xSmyKmfG2kyYL2RIJTxGcLY06MalUc=.257566db-d246-4211-8422-2638768d5943@github.com>

On Tue, 4 Oct 2022 17:36:56 GMT, Chris Hennick <duke at openjdk.org> wrote:

>> This PR improves both the worst-case performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections:
>> 
>> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`.
>> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.)
>> * Uses the newly-extracted `computeWinsorizedNextExponential` function to prevent `nextGaussian` from going into the `nextExponential` tail twice.
>
> Chris Hennick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add parameter to enable/disable fixed PRNG seed

It's probably just a statistical fluke involving a very large return value, but to know for sure I'd need a way to gather statistics about the return values and how they correlate with running-time outliers.

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

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

From rriggs at openjdk.org  Fri Dec  2 21:34:02 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 2 Dec 2022 21:34:02 GMT
Subject: RFR: 8298033: Character.codePointAt(char[], int,
 int) doesn't do JavaDoc-specified check [v3]
In-Reply-To: <4UxZnSr4yjQQIAFOP_Lm1n-lqQ0m1zQAp-knX42Cy-k=.124fabe0-7cf8-4f19-bdcc-234d2f2e4796@github.com>
References: <dHjviGmASssYfntfClzDC28Ppjrn3pECnO3HzbZHopY=.d9923de3-6de7-41f5-a84e-03a7c5267e2f@github.com>
 <4UxZnSr4yjQQIAFOP_Lm1n-lqQ0m1zQAp-knX42Cy-k=.124fabe0-7cf8-4f19-bdcc-234d2f2e4796@github.com>
Message-ID: <YRjjKiUbkB6uXnAYMUEZxMzAztfl_KlnGxiXu1Np-Is=.5e4dadba-5886-4e46-8b81-5fa129b343f6@github.com>

On Fri, 2 Dec 2022 18:53:21 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> I found out that this code
>> 
>> public class Main {
>>     public static void main(String[] args) {
>>         String s = "Hello world!";
>>         char[] chars = s.toCharArray();
>>         int point = Character.codePointAt(chars, -1, 1);
>>     }
>> }
>> 
>> throws `ArrayIndexOutOfBoundsException` instead of JavaDoc-specified `IndexOutOfBoundsException`: 
>> 
>> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds for length 12
>> 	at java.base/java.lang.Character.codePointAtImpl(Character.java:9254)
>> 	at java.base/java.lang.Character.codePointAt(Character.java:9249)
>> 	at org.example.Main.main(Main.java:7)
>> 
>> and the method doesn't check whether `index` parameter is negative:
>> 
>> public static int codePointAt(char[] a, int index, int limit) {
>>     if (index >= limit || limit < 0 || limit > a.length) {
>>         throw new IndexOutOfBoundsException();
>>     }
>>     return codePointAtImpl(a, index, limit);
>> }
>> 
>> I suggest to check the `index` parameter explicitly instead of relying on AIOOBE thrown from accessing the array with negative index.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8298033: Fix test

test/jdk/java/lang/Character/Supplementary.java line 808:

> 806:                 return;
> 807:             }
> 808:             if (expectedException.isInstance(e)) { // Character.codePointBefore() throws

The test should fail without the fix, but this fall-through allows the test to pass.

The qualification added for `isAt` is hiding a second/corresponding bug in `codePointBefore` where the index is not checked and an ArrayIndexOutOfBounds occurs at codePointBeforeImpl: 9488.

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

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

From naoto at openjdk.org  Fri Dec  2 21:55:24 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 2 Dec 2022 21:55:24 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v3]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <HM5Wmd_ENr7tE83zt4n2wIIdfaD4OIapOcA5VfsYE1E=.55aff254-32c6-4771-9b5e-daedb07af297@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

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

  Added more tests, loading with doPrivileged()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/3d2b01f6..4c38b01b

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

  Stats: 137 lines in 5 files changed: 121 ins; 2 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/11421.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11421/head:pull/11421

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

From mcimadamore at openjdk.org  Fri Dec  2 22:02:06 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 2 Dec 2022 22:02:06 GMT
Subject: RFR: 8291359: Specification of method j.l.foreign.VaList::skip
 still deserves clarification [v6]
In-Reply-To: <LBwFrJ_UPiJ5-2wijP51U7ofgeRPzu4LqTBbBawResw=.e0943020-c759-45d0-bd00-907d48f0d4c3@github.com>
References: <vHHYP2B3-wJHXVPjmc0bP6Raouhn3ni-M_d1A_ULlp8=.17cfc6d8-f18e-46fb-a1fe-ffdf4b816d84@github.com>
 <LBwFrJ_UPiJ5-2wijP51U7ofgeRPzu4LqTBbBawResw=.e0943020-c759-45d0-bd00-907d48f0d4c3@github.com>
Message-ID: <PMOJzHXSM1S0ii1ysOCZVMjYWw14aNwRTJ1j6Fo9PG8=.69a0e7da-959c-416c-ad8e-74320e478975@github.com>

On Fri, 2 Dec 2022 20:34:30 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> A small clarification of the VaList spec to say that attempts to access elements through an incorrect memory layout result in undefined behavior.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Marked as reviewed by mcimadamore (Reviewer).

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

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

From naoto at openjdk.org  Fri Dec  2 22:03:02 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 2 Dec 2022 22:03:02 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <qq5C9afaTVN6a3JJci9IOrVN7eNsZY1o2OCdcN_abS4=.f1088244-a9fa-4227-93f5-7bfec38b4019@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
 <JCBfRAbsgf6bH6lqeXWodGC89bWpXwpwNlv2E1aHPUI=.85727228-d8c8-4918-818a-ae6606514b99@github.com>
 <ZTmLDk0M9hsuICQeazcIat8UdUvM49UAisgTfoV8LCg=.799c1bfe-57a8-4b24-a72e-ed7f970bcf95@github.com>
 <nrL_Up0TmjkjNZgQtxGCZG3gkOF2eg5FiJYUK_J1kJs=.164122ef-8750-487c-abc5-e5b92bdf7c2c@github.com>
 <no3fTAbXqXI9w9odDcE5nFpKzJWuUHHi9eOY04AXBAI=.fafda472-c4b3-4251-b496-f149e463bea4@github.com>
 <ktUnahpoaSsO7Ycw0Bav_j-Tb0iOA-4S3BpmK7h8LWo=.ad9b526a-f0d8-4963-a1c3-1f098d0fcbc6@github.com>
 <tP7Z8ToLzTciRkvSBXR5WlF65EGcVQ89tSvtSO3XCaw=.da2e4cdd-a652-4813-9fc5-62e1c50c1105@github.com>
 <ShycxtxiMZ0JMdI3EaSMKTHPO8NzJclj5VuOe2Xbqxk=.a8d846a6-0bc7-4a2e-83bb-224ed8a0e72e@github.com>
 <qq5C9afaTVN6a3JJci9IOrVN7eNsZY1o2OCdcN_abS4=.f1088244-a9fa-4227-93f5-7bfec38b4019@github.com>
Message-ID: <sLn0o9FkgSCSAKP-FGJCFYrPXh8soGDTi8I-1jktmzU=.02e644b1-48a6-41c2-b488-8b9ad7deeb17@github.com>

On Fri, 2 Dec 2022 15:21:40 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Naoto has confirmed that the password prompt from keytool does not echo, good!
>> 
>> The intention is that Console be usable in jshell so I think the issue is that readPassword is echo'ing when used in jshell. Maybe someone experimenting with the Console API might run into this but we can separate out that issue.
>
> Still not sure what the expected behavior is, but for keytool, because of the updated check, `sun.security.util.Password` now uses `System.in.read` instead of `Console.readPassword`, therefore the password is echoing. I tried removing the check and force `Console.readPassword` to be called. There is no echo but the return key also does not work. I have to Ctrl-C to break out.

I thought that in `jshell`, `System.console()` returns null, so it is always not using `Console.readPassword`. Anyway, I think the scenario is not practical (changing password using jshell), and in the future, jshell can provide its own Console implementation (that's a part of this enhancement's motivation) that would nicely handle this situation.

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

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

From jvernee at openjdk.org  Fri Dec  2 22:19:02 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 2 Dec 2022 22:19:02 GMT
Subject: Integrated: 8291359: Specification of method j.l.foreign.VaList::skip
 still deserves clarification
In-Reply-To: <vHHYP2B3-wJHXVPjmc0bP6Raouhn3ni-M_d1A_ULlp8=.17cfc6d8-f18e-46fb-a1fe-ffdf4b816d84@github.com>
References: <vHHYP2B3-wJHXVPjmc0bP6Raouhn3ni-M_d1A_ULlp8=.17cfc6d8-f18e-46fb-a1fe-ffdf4b816d84@github.com>
Message-ID: <9gHJ1hNG3z_n5g_B3hVAxLl_K86WZ_OKLzY1DcVWis0=.1505d275-0339-4842-9681-6cc751111fc6@github.com>

On Wed, 30 Nov 2022 18:35:47 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> A small clarification of the VaList spec to say that attempts to access elements through an incorrect memory layout result in undefined behavior.

This pull request has now been integrated.

Changeset: 562bc171
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/562bc171b971091421ee0a93665880682ae96c09
Stats:     7 lines in 1 file changed: 7 ins; 0 del; 0 mod

8291359: Specification of method j.l.foreign.VaList::skip still deserves clarification

Reviewed-by: mcimadamore

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

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

From ihse at openjdk.org  Fri Dec  2 23:06:08 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 23:06:08 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <2Ed-oJoEq8e9g8Og4JD8_Pddjj3A_O5KGSrJpaDFrmk=.bcd0280d-33bb-4570-81e0-6700ff65e921@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <Cwps2k2ip4t3Jr5Joqk8hKXxuweY8V71hiAzZW5hto4=.8da555f4-12ef-4e10-b656-093a834e0d5f@github.com>
 <2Ed-oJoEq8e9g8Og4JD8_Pddjj3A_O5KGSrJpaDFrmk=.bcd0280d-33bb-4570-81e0-6700ff65e921@github.com>
Message-ID: <BJDInfZQ8pfjgoiYRHsRTcw2dxBWSu4ZcsNC0wktKPM=.9fef5722-e842-4119-a380-46b5dd3bbc02@github.com>

On Fri, 2 Dec 2022 17:12:55 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This turned out to be much more complicated than anticipated. I am going to close this PR (and bug), and instead I have split up this work in five different bugs:
>> 
>> [JDK-8298047](https://bugs.openjdk.org/browse/JDK-8298047) is about removing all non-significant whitespace from all properties files, basically corresponding to how this PR looked after the second commit.
>> 
>> [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046) is about fixing the significant whitespace, by turning it to unicode sequences or removing it, if it turns out there should not have been a space there. This work is split into four parts to be able to have one bug per component team.
>
>> and instead I have split up this work in five different bugs
> 
> would you consider also adding a unit test to check whether the localized resources also contain leading/trailing whitespace, and possibly special characters (like {, }, , etc.) that are present in the main resource?

@andy-goryachev-oracle No. Any such test is up to the component owners to write, if they deem it fitting.

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

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

From naoto at openjdk.org  Sat Dec  3 00:25:08 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Sat, 3 Dec 2022 00:25:08 GMT
Subject: RFR: 8297804: (tz) Update Timezone Data to 2022g
In-Reply-To: <4b1tG73Xp3BMUy2X6Ab7W2So7u4jcSu9SrAWvrHLw1g=.d6218261-7f4e-48c5-9989-eb0887e0207e@github.com>
References: <4b1tG73Xp3BMUy2X6Ab7W2So7u4jcSu9SrAWvrHLw1g=.d6218261-7f4e-48c5-9989-eb0887e0207e@github.com>
Message-ID: <0N9zRcGnG_U_tr8I9Qr2L9DM0Ex2qfztxbdVDDedgcU=.b9cd95e2-afce-4d3b-943c-2582e597c0a8@github.com>

On Wed, 30 Nov 2022 18:07:07 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Update to the latest tzdata, 2022g.
> 
> Primary changes:
> * `America/Ojinaga` (CST) is split, creating `America/Ciudad_Juarez` (MST/MDT)
> * `America/Pangnirtung` becomes a link to `America/Iqaluit`
> * `America/Ojinaga` gains DST (CDT)
> 
> See bug for the full details.
> 
> There will likely also be CLDR changes ([CLDR-16181](https://unicode-org.atlassian.net/browse/CLDR-16181)) that are not yet included in this change. We can either wait for these and include them in this patch, or do a separate change like [JDK-8296715](https://bugs.openjdk.org/browse/JDK-8296715)
> 
> Tests in `java/util/TimeZone`, `java/time/test` and `sun/text/resources` all pass.

Hi Andrew,
Thanks for taking on this. I think you can cherry-pick the relevant [CLDR changes](https://github.com/unicode-org/cldr/commit/0bd22412b35b6e7037a39c3ad6a4dc49c699439b) (under `common` directory) into this PR so that backporting would be easier.

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

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

From tvaleev at openjdk.org  Sat Dec  3 08:26:01 2022
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sat, 3 Dec 2022 08:26:01 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface [v3]
In-Reply-To: <JEYob79-sNyvaqpuxuzIJQHNBuqRolzWf6V3WYJGt90=.424a1878-b393-4d1c-8613-d485303c5a67@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
 <JEYob79-sNyvaqpuxuzIJQHNBuqRolzWf6V3WYJGt90=.424a1878-b393-4d1c-8613-d485303c5a67@github.com>
Message-ID: <YWO2wTB2miEbk3Hdp7kx_ZlHysy43gInAP1YyGkerWM=.5c260521-0048-4c86-98bb-ea2ef9d5904c@github.com>

On Wed, 12 Oct 2022 13:26:29 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Java 17 added RandomGenerator interface. However, existing method Collections.shuffle accepts old java.util.Random class. While since Java 19, it's possible to use Random.from(RandomGenerator) wrapper, it would be more convenient to provide direct overload shuffle(List<?> list, RandomGenerator rnd).
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes according to review
>   
>   1. Reduce duplication in tests
>   2. Use JumpableGenerator#copy() instead of create(1) in tests, as according to the spec, seed can be ignored
>   3. Simplify documentation for shuffle(List, Random) to avoid duplication.

A gentle ping: please review the change and the CSR. Thanks.

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

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

From matej.turcel at oracle.com  Sat Dec  3 18:15:50 2022
From: matej.turcel at oracle.com (Matej Turcel)
Date: Sat, 3 Dec 2022 19:15:50 +0100
Subject: jdeps - option to to analyze package-private API
Message-ID: <2dd880da-6ddc-302e-2e03-504b4171f484@oracle.com>

Hello,

I would like to propose a new option for jdeps, similar to --api-only,
which would analyze not only private and protected API (like --api-only
does), but also package-private API. In more detail, this option would
report all dependencies which occur in all types (not only public ones),
namely in the type's:
- non-private members (= public, protected, or package-private),
- signatures of non-private constructors and methods,
- one of the above inside an arbitrarily deeply nested inner type,
 ? such that all its enclosing types are non-private.

A little bit about the motivation for this additional functionality.
We use Gradle to build our product, and have several hundred modules
with a few thousands mutual dependencies between them. With each change
in the source code, developers must manually update the Gradle module
dependencies and ensure they have the correct type, e.g. `api` or
`implementation` (there are more types but they are not relevant here).
With tens of thousands of classes, this gets out of hand quickly, and
as a result, the dependencies declared in our build.gradle files often
do not match the actual dependencies of the underlying source code.
Naturally, we would like to automatically analyze the code and obtain
correct dependency types, and since we use several JDK languages, we want
to analyze bytecode using jdeps, instead of analyzing source code as that
would require having a separate front-end for each language we use.

So far, jdeps with the --api-only flag seems like the perfect tool, except
there is a little problem -- we have packages (dozens of them) which
exist in multiple modules. For example, package `com.foo` exists in
three separate modules (meaning each of these modules has a class in that
package). That means package-private "stuff" (members + constructor/method
signatures) is a part of module's API. So to infer correct types of gradle
module dependencies using jdeps, we need jdeps to consider package-private
stuff a part of the API.

On an unrelated note, I believe bounds of type parameters should be
a part of type's API:

 ??? public class C<T extends Boolean> {
 ??????? T x;
 ??? }

But according to jdeps they are not:

 ??? > jdeps --verbose C.class
 ??? C.class -> java.base
 ?????? C?????? -> java.lang.Boolean??????? java.base
 ?????? C?????? -> java.lang.Object???????? java.base

 ??? > jdeps --verbose --api-only C.class
 ??? C.class -> java.base
 ?????? C?????? -> java.lang.Object???????? java.base

Is this behavior intended?


From stsypanov at openjdk.org  Sat Dec  3 18:45:00 2022
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Sat, 3 Dec 2022 18:45:00 GMT
Subject: RFR: 8298033: Character.codePointAt(char[], int,
 int) doesn't do JavaDoc-specified check [v3]
In-Reply-To: <YRjjKiUbkB6uXnAYMUEZxMzAztfl_KlnGxiXu1Np-Is=.5e4dadba-5886-4e46-8b81-5fa129b343f6@github.com>
References: <dHjviGmASssYfntfClzDC28Ppjrn3pECnO3HzbZHopY=.d9923de3-6de7-41f5-a84e-03a7c5267e2f@github.com>
 <4UxZnSr4yjQQIAFOP_Lm1n-lqQ0m1zQAp-knX42Cy-k=.124fabe0-7cf8-4f19-bdcc-234d2f2e4796@github.com>
 <YRjjKiUbkB6uXnAYMUEZxMzAztfl_KlnGxiXu1Np-Is=.5e4dadba-5886-4e46-8b81-5fa129b343f6@github.com>
Message-ID: <obzX6gFjzBXHa4fwPcSW80GWANmJoVx-XXQ12wn9jQA=.6595ab56-a390-4197-974c-9399f7fdd4c2@github.com>

On Fri, 2 Dec 2022 21:31:42 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8298033: Fix test
>
> test/jdk/java/lang/Character/Supplementary.java line 808:
> 
>> 806:                 return;
>> 807:             }
>> 808:             if (expectedException.isInstance(e)) { // Character.codePointBefore() throws
> 
> The test should fail without the fix, but this fall-through allows the test to pass.
> 
> The qualification added for `isAt` is hiding a second/corresponding bug in `codePointBefore` where the index is not checked and an ArrayIndexOutOfBounds occurs at codePointBeforeImpl: 9488.

Yeah, this AIOOBE is exactly the reason why I added this. So should we modify `codePointBefore` in the same way as `codePointAt`?

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

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

From naoto at openjdk.org  Sat Dec  3 19:18:48 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Sat, 3 Dec 2022 19:18:48 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v4]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <01thVeD5joKRB8oex093EUINsuSrfs2HHXEL_MMEtJU=.83c39abd-0f31-4609-b7ed-731f3ed8f342@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

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

  Changed the expected behavior when the SecurityManager is enabled

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/4c38b01b..7c0740aa

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

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

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

From darcy at openjdk.org  Sat Dec  3 23:10:48 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 3 Dec 2022 23:10:48 GMT
Subject: RFR: JDK-8296149: Start of release updates for JDK 21 [v3]
In-Reply-To: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
Message-ID: <XGiwl-FfzsJn6_teztoT9PEtdCdByIBR7tlGjcpXpCY=.4a4bd6e9-a4d9-4985-85da-8d2ace7483a3@github.com>

> Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21.

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

 - Merge branch 'master' into JDK-8296149
 - Merge branch 'master' into JDK-8296149
 - Update symbol information for JDK 20 build 26.
 - Merge branch 'master' into JDK-8296149
 - Merge branch 'master' into JDK-8296149
 - Fix failed HotSpot regression tests.
 - Merge branch 'master' into JDK-8296149
 - Update symbol information to JDK 20 build 24.
 - Merge branch 'master' into JDK-8296149
 - Merge branch 'master' into JDK-8296149
 - ... and 6 more: https://git.openjdk.org/jdk/compare/7be0c7e6...515002c7

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10924/files
  - new: https://git.openjdk.org/jdk/pull/10924/files/89731cb2..515002c7

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

  Stats: 14769 lines in 190 files changed: 1917 ins; 12471 del; 381 mod
  Patch: https://git.openjdk.org/jdk/pull/10924.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10924/head:pull/10924

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

From alanb at openjdk.org  Sun Dec  4 17:17:02 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 4 Dec 2022 17:17:02 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v4]
In-Reply-To: <01thVeD5joKRB8oex093EUINsuSrfs2HHXEL_MMEtJU=.83c39abd-0f31-4609-b7ed-731f3ed8f342@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <01thVeD5joKRB8oex093EUINsuSrfs2HHXEL_MMEtJU=.83c39abd-0f31-4609-b7ed-731f3ed8f342@github.com>
Message-ID: <hqHxUOYYwCX6hwRyijObfuLqEycrWhYQuNlk5i1ayV4=.76a1e3d1-fb08-4e89-a5d9-fe30b22e154b@github.com>

On Sat, 3 Dec 2022 19:18:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed the expected behavior when the SecurityManager is enabled

This is well done. I've been through all the latest src changes.

src/java.base/share/classes/java/io/Console.java line 627:

> 625:         });
> 626:     }
> 627:     private static Console cons;

The initialization of cons is replaced in this PR so maybe we can make it final at the same time.

src/java.base/share/classes/jdk/internal/io/JdkConsole.java line 33:

> 31: /**
> 32:  * Delegate interface for custom Console implementations.
> 33:  * Methods defined here are duplicating ones in Console class.

There's a typo here, probably should be be "duplicates the" or "are duplicates of the methods".

src/java.base/share/classes/jdk/internal/io/JdkConsoleProvider.java line 40:

> 38:      * The default provider of JdkConsole.
> 39:      */
> 40:     String DEFAULT_PROVIDER = "jdk.internal.le";

This is really the module name of the preferred provider, maybe it should have _MODULE_NAME as the suffix.

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

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

From serb at openjdk.org  Mon Dec  5 06:10:04 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 5 Dec 2022 06:10:04 GMT
Subject: RFR: 8298047: Remove all non-significant trailing whitespace from
 properties files
In-Reply-To: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
References: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
Message-ID: <WPo83xTHqjvUb3Gn342Yy6RUZUjWaFk5kLVV5oJkaoo=.9f954462-1def-40fd-a38a-c74533cee090@github.com>

On Fri, 2 Dec 2022 17:06:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an attempt to remove all trailing whitespace from properties files, and enable a jcheck verification that they did not come back, similar to other source code. It turned out that this was not so simple, however, since trailing whitespace in values is actually significant in properties files.
> 
> To address this, I have opened four bugs on different component teams to either remove the trailing significant whitespace (if it is there erroneously), or convert it to the unicode sequence `\u0020`: [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046).
> 
> That leaves all the other trailing spaces, in blank lines and in the end of comments. These serve no purpose and should just be removed, and is what this issue concerns.
> 
> When this and the four "significant whitespace" bugs are all finally integrated, we can finally turn on the verification in jcheck for properties files as well.
> 
> The changes in this PR is based on [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), in #10792. I have restored all the "delete trailing whitespace" changes, except for those with significance. These changes were in turned created by  running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

The client changes look fine.

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

Marked as reviewed by serb (Reviewer).

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

From jpai at openjdk.org  Mon Dec  5 06:30:06 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 5 Dec 2022 06:30:06 GMT
Subject: RFR: 8297495: j.u.concurrent updates for JDK 20 [v2]
In-Reply-To: <yNV8fdFulhnQRUk6NKIuFRN-ACEExiehoHJ-EqKvce0=.f293af52-6c67-4eb0-b499-f819cf583547@github.com>
References: <HcXqonjoH0jm8K5fXlfw8YsfyNBswTwFuPD7rtEr8FI=.22189b59-24bc-44bc-add1-9587ebe60518@github.com>
 <yNV8fdFulhnQRUk6NKIuFRN-ACEExiehoHJ-EqKvce0=.f293af52-6c67-4eb0-b499-f819cf583547@github.com>
Message-ID: <y-WYFvXE04esnWb06_nFSSkZPQK3X75GBgfCm_86k2M=.08cbed0d-e55e-4288-8ae3-81c3566cf42e@github.com>

On Thu, 1 Dec 2022 14:46:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The proposed updates for JDK 20 are:
>> 
>> - ForkJoinPool.externalSubmit 
>> - ForkJoinWorkerThread.getQueuedTaskCount 
>> 
>> These methods will be used to improve the Thread.yield implementation for virtual threads. The range of alternatives explored include not exposing an API and protected methods such as "offerSubmission". The class description speaks of "external clients" and "submissions from non-ForkJoinTask clients", hence the proposed naming and javadoc text.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Expand test
>  - Adjust wording to make it clear that the number of tasks is non-negative
>  - Merge
>  - Improve javadoc
>  - Merge
>  - Initial commit

Thank you for the changes. This looks fine to me.

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

Marked as reviewed by jpai (Reviewer).

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

From aturbanov at openjdk.org  Mon Dec  5 07:02:11 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 5 Dec 2022 07:02:11 GMT
Subject: RFR: 8297976: Remove sun.net.ProgressMonitor and related classes
In-Reply-To: <yw8Q8tA8_4jUmc1gWd-xAN-m5kjFPeou3dn0qML9TQ4=.18a511ff-946f-4a8a-8fe3-3eaf00a8a396@github.com>
References: <yw8Q8tA8_4jUmc1gWd-xAN-m5kjFPeou3dn0qML9TQ4=.18a511ff-946f-4a8a-8fe3-3eaf00a8a396@github.com>
Message-ID: <jjpXbHAgVWEIykJCk7wsljUNa5Y3RiAfamHdN_Ff3Ig=.5b04f033-aa27-43ed-8d48-3415b83dcd10@github.com>

On Fri, 2 Dec 2022 08:31:25 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this patch that removes progress monitoring classes used by UrlConnection.
> Since Java 9 these classes are not used in the JDK, and are not exported from java.base. If anyone was still using them, reimplementing them in user code should be pretty straightforward.
> 
> This PR also fixes the issue where MeteredStream finalizer could resurrect an unusable connection, causing unexpected exceptions in other parts of the code.
> 
> No new regression test; since we are removing the finalizer, I don't believe we will see the issue again. I can add a test for that if you think it still makes sense.
> 
> I had to adjust `ProxyModuleMapping.java` test which used `sun.net.ProgressListener` as an example of a module-private interface; I replaced it with another public interface from the same package.
> 
> Existing tier 1-3 tests continue to pass.

src/java.base/share/classes/sun/net/www/http/KeepAliveStream.java line 58:

> 56:      * Constructor
> 57:      */
> 58:     public KeepAliveStream(InputStream is, long expected, HttpClient hc)  {

Nit:
Suggestion:

    public KeepAliveStream(InputStream is, long expected, HttpClient hc) {

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

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

From duke at openjdk.org  Mon Dec  5 07:05:03 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 5 Dec 2022 07:05:03 GMT
Subject: RFR: 8298045: Fix hidden but significant trailing whitespace in
 properties files for core-libs code
In-Reply-To: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>
References: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>
Message-ID: <p7O7axVhjrW0uR55B1J3EgTaorzOkz7lU9wVQelsgbg=.5b4102ac-af17-4c53-98f9-c90081087bdf@github.com>

On Fri, 2 Dec 2022 16:40:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the core-libs team.

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties line 281:

> 279: # Namespaces support
> 280: # 4. Using Qualified Names
> 281:         IllegalQName = L'\u00E9l\u00E9ment ou l'attribut ne correspond pas \u00E0 la production QName : QName::=(NCName':')?NCName.\u0020

XMLMessages.properties does not have a trailing space for IllegalQName. For consistency with the original, there should probably be no space (unless the original is incorrect).

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

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

From aturbanov at openjdk.org  Mon Dec  5 07:08:38 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 5 Dec 2022 07:08:38 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v4]
In-Reply-To: <01thVeD5joKRB8oex093EUINsuSrfs2HHXEL_MMEtJU=.83c39abd-0f31-4609-b7ed-731f3ed8f342@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <01thVeD5joKRB8oex093EUINsuSrfs2HHXEL_MMEtJU=.83c39abd-0f31-4609-b7ed-731f3ed8f342@github.com>
Message-ID: <dt5iQtdPZY3ZYgGq9Ol237Cp3z9DR5M6k_p1XsDHXh4=.bf2a1103-c8e8-4f7c-9b54-fcc908ece4f1@github.com>

On Sat, 3 Dec 2022 19:18:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed the expected behavior when the SecurityManager is enabled

src/java.base/share/classes/java/io/ProxyingConsole.java line 62:

> 60:      */
> 61:     @Override
> 62:     public Console format(String fmt, Object ...args) {

Suggestion:

    public Console format(String fmt, Object ... args) {

src/java.base/share/classes/jdk/internal/io/JdkConsole.java line 40:

> 38:     PrintWriter writer();
> 39:     Reader reader();
> 40:     JdkConsole format(String fmt, Object ...args);

nit
Suggestion:

    JdkConsole format(String fmt, Object ... args);

src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 67:

> 65:         }
> 66: 
> 67:         public synchronized JdkConsole format(String fmt, Object ...args) {

Nit:
Suggestion:

        public synchronized JdkConsole format(String fmt, Object ... args) {

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

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

From aturbanov at openjdk.org  Mon Dec  5 07:26:06 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 5 Dec 2022 07:26:06 GMT
Subject: RFR: JDK-8296149: Start of release updates for JDK 21 [v3]
In-Reply-To: <XGiwl-FfzsJn6_teztoT9PEtdCdByIBR7tlGjcpXpCY=.4a4bd6e9-a4d9-4985-85da-8d2ace7483a3@github.com>
References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
 <XGiwl-FfzsJn6_teztoT9PEtdCdByIBR7tlGjcpXpCY=.4a4bd6e9-a4d9-4985-85da-8d2ace7483a3@github.com>
Message-ID: <SPl9kw8GbMVLEIezNTdF6o5_S8m3dkaZo-WPNQjvTe4=.81bce95b-b3c7-4533-a877-15e4c2d3e366@github.com>

On Sat, 3 Dec 2022 23:10:48 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8296149
>  - Merge branch 'master' into JDK-8296149
>  - Update symbol information for JDK 20 build 26.
>  - Merge branch 'master' into JDK-8296149
>  - Merge branch 'master' into JDK-8296149
>  - Fix failed HotSpot regression tests.
>  - Merge branch 'master' into JDK-8296149
>  - Update symbol information to JDK 20 build 24.
>  - Merge branch 'master' into JDK-8296149
>  - Merge branch 'master' into JDK-8296149
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/c3a218e2...515002c7

test/langtools/tools/javac/versions/Versions.java line 91:

> 89:         EIGHTEEN(false,  "62.0", "18", Versions::checksrc18),
> 90:         NINETEEN(false,  "63.0", "19", Versions::checksrc19),
> 91:         TWENTY(false,  "64.0", "20", Versions::checksrc20),

nit:
Suggestion:

        TWENTY(false, "64.0", "20", Versions::checksrc20),

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

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

From jpai at openjdk.org  Mon Dec  5 09:22:04 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 5 Dec 2022 09:22:04 GMT
Subject: RFR: 8297976: Remove sun.net.ProgressMonitor and related classes
In-Reply-To: <yw8Q8tA8_4jUmc1gWd-xAN-m5kjFPeou3dn0qML9TQ4=.18a511ff-946f-4a8a-8fe3-3eaf00a8a396@github.com>
References: <yw8Q8tA8_4jUmc1gWd-xAN-m5kjFPeou3dn0qML9TQ4=.18a511ff-946f-4a8a-8fe3-3eaf00a8a396@github.com>
Message-ID: <ayd_f7IvLTQXYLx6bBpRLuxH69E_DZhQj-IU-LxCQFQ=.6b2b76fe-1403-4aa3-83ba-c82b2b115618@github.com>

On Fri, 2 Dec 2022 08:31:25 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this patch that removes progress monitoring classes used by UrlConnection.
> Since Java 9 these classes are not used in the JDK, and are not exported from java.base. If anyone was still using them, reimplementing them in user code should be pretty straightforward.
> 
> This PR also fixes the issue where MeteredStream finalizer could resurrect an unusable connection, causing unexpected exceptions in other parts of the code.
> 
> No new regression test; since we are removing the finalizer, I don't believe we will see the issue again. I can add a test for that if you think it still makes sense.
> 
> I had to adjust `ProxyModuleMapping.java` test which used `sun.net.ProgressListener` as an example of a module-private interface; I replaced it with another public interface from the same package.
> 
> Existing tier 1-3 tests continue to pass.

Looks good to me (apart from Daniel's question). 

As you note, these are internal classes and aren't exported from the java.base module (to applications) and given the context in which those classes were used, my understanding is that we won't need a CSR for this change.

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

Marked as reviewed by jpai (Reviewer).

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

From stuefe at openjdk.org  Mon Dec  5 10:04:51 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 5 Dec 2022 10:04:51 GMT
Subject: RFR: JDK-8296360: Track native memory used by zlib via NMT
Message-ID: <WW7_ad6YUZQ26hrK4idngOcwkotxiJr1PAyfP29Lj64=.5779f834-b617-4295-b69e-c37c796f5268@github.com>

This patch adds NMT tracking to the zlib.

*Please note: we currently discuss whether NMT can be expanded across the JDK in this ML discussion [1]. This PR depends on the outcome of that discussion and won't proceed unless greenlighted. But since [1] is stalled, I post the PR for RFR to get some feedback on the code itself and for people to try it out.*

NMT tracks hotspot native allocations but does not cover the JDK (apart from small exceptions). But the native memory
footprint of JDK libraries can be very significant. Recently we had a customer whose zlib footprint went into the ~40GB range. We analyzed the problem with an in-house memory tracker, but things would have been a lot simpler using NMT.

This patch instruments the zlib via zalloc hooks, which is minimally invasive. It does not touch zlib sources, so it works with both the bundled zlib and system zlib. All the instrumentation happens in the JVM zlib wrapper.


-         j.u.zip (deflate) (reserved=624, committed=624)
                            (malloc=624 #3) 
 
-         j.u.zip (inflate) (reserved=221377904, committed=221377904)
                            (malloc=221377904 #60877) 
 
-               Zip (other) (reserved=8163446896, committed=8163446896)
                            (malloc=8163446896 #182622) 


[1] https://mail.openjdk.org/pipermail/core-libs-dev/2022-November/096197.html

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

Commit messages:
 - JDK-8296360-Track-native-memory-used-by-zlib-via-NMT

Changes: https://git.openjdk.org/jdk/pull/10988/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10988&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296360
  Stats: 192 lines in 9 files changed: 179 ins; 1 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/10988.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10988/head:pull/10988

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

From duke at openjdk.org  Mon Dec  5 10:19:23 2022
From: duke at openjdk.org (Viktor Klang)
Date: Mon, 5 Dec 2022 10:19:23 GMT
Subject: RFR: 8297495: j.u.concurrent updates for JDK 20 [v2]
In-Reply-To: <yNV8fdFulhnQRUk6NKIuFRN-ACEExiehoHJ-EqKvce0=.f293af52-6c67-4eb0-b499-f819cf583547@github.com>
References: <HcXqonjoH0jm8K5fXlfw8YsfyNBswTwFuPD7rtEr8FI=.22189b59-24bc-44bc-add1-9587ebe60518@github.com>
 <yNV8fdFulhnQRUk6NKIuFRN-ACEExiehoHJ-EqKvce0=.f293af52-6c67-4eb0-b499-f819cf583547@github.com>
Message-ID: <udkaG3AwN-OrnhDEP6-8GglMnhenghusZVHW_tnGGSM=.341082c7-6195-4889-9791-6d9589e6437d@github.com>

On Thu, 1 Dec 2022 14:46:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The proposed updates for JDK 20 are:
>> 
>> - ForkJoinPool.externalSubmit 
>> - ForkJoinWorkerThread.getQueuedTaskCount 
>> 
>> These methods will be used to improve the Thread.yield implementation for virtual threads. The range of alternatives explored include not exposing an API and protected methods such as "offerSubmission". The class description speaks of "external clients" and "submissions from non-ForkJoinTask clients", hence the proposed naming and javadoc text.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Expand test
>  - Adjust wording to make it clear that the number of tasks is non-negative
>  - Merge
>  - Improve javadoc
>  - Merge
>  - Initial commit

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2920:

> 2918:      * @since 20
> 2919:      */
> 2920:     public <T> ForkJoinTask<T> externalSubmit(ForkJoinTask<T> task) {

@AlanBateman Does it make sense to check the nullness of the `task` before going into the storeStoreFence etc?

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

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

From alanb at openjdk.org  Mon Dec  5 10:21:16 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 5 Dec 2022 10:21:16 GMT
Subject: RFR: JDK-8296360: Track native memory used by zlib via NMT
In-Reply-To: <WW7_ad6YUZQ26hrK4idngOcwkotxiJr1PAyfP29Lj64=.5779f834-b617-4295-b69e-c37c796f5268@github.com>
References: <WW7_ad6YUZQ26hrK4idngOcwkotxiJr1PAyfP29Lj64=.5779f834-b617-4295-b69e-c37c796f5268@github.com>
Message-ID: <KJs409qazlVA8j2QV9nDLmyomZg3s0RTtIEkpWJxK-A=.f0f7a88c-0b68-4601-ab70-8d25c3ae4f88@github.com>

On Fri, 4 Nov 2022 14:35:00 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> This patch adds NMT tracking to the zlib.
> 
> *Please note: we currently discuss whether NMT can be expanded across the JDK in this ML discussion [1]. This PR depends on the outcome of that discussion and won't proceed unless greenlighted. But since [1] is stalled, I post the PR for RFR to get some feedback on the code itself and for people to try it out.*
> 
> NMT tracks hotspot native allocations but does not cover the JDK (apart from small exceptions). But the native memory
> footprint of JDK libraries can be very significant. Recently we had a customer whose zlib footprint went into the ~40GB range. We analyzed the problem with an in-house memory tracker, but things would have been a lot simpler using NMT.
> 
> This patch instruments the zlib via zalloc hooks, which is minimally invasive. It does not touch zlib sources, so it works with both the bundled zlib and system zlib. All the instrumentation happens in the JVM zlib wrapper.
> 
> 
> -         j.u.zip (deflate) (reserved=624, committed=624)
>                             (malloc=624 #3) 
>  
> -         j.u.zip (inflate) (reserved=221377904, committed=221377904)
>                             (malloc=221377904 #60877) 
>  
> -               Zip (other) (reserved=8163446896, committed=8163446896)
>                             (malloc=8163446896 #182622) 
> 
> 
> [1] https://mail.openjdk.org/pipermail/core-libs-dev/2022-November/096197.html

I think it's a bit premature to mark this review. The discussion thread "Extend Native Memory Tracking over the JDK ?" needs more discussion and input from others. We need to be forward looking in those discussions as it is very likely that the JNI functions and memory allocation will move to Panama in the future. Also we need to think about the maintainable and be able to manage catagories in the libs code without needing to add to allocation.hpp - I suspect this is probably something you've thought about already.

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

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

From mcimadamore at openjdk.org  Mon Dec  5 10:31:52 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 5 Dec 2022 10:31:52 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v39]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <-V_N0Cvh4J0vKNbBYdFcow9E8yFHRIjya8n69MpDSuY=.9626ee4d-95b6-41e4-b21e-395e79840388@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

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

  Fix Preview annotation for JEP 434

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/8b5dc0f0..33b834ca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=38
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=37-38

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

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

From alanb at openjdk.org  Mon Dec  5 10:36:01 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 5 Dec 2022 10:36:01 GMT
Subject: RFR: 8297495: j.u.concurrent updates for JDK 20 [v2]
In-Reply-To: <udkaG3AwN-OrnhDEP6-8GglMnhenghusZVHW_tnGGSM=.341082c7-6195-4889-9791-6d9589e6437d@github.com>
References: <HcXqonjoH0jm8K5fXlfw8YsfyNBswTwFuPD7rtEr8FI=.22189b59-24bc-44bc-add1-9587ebe60518@github.com>
 <yNV8fdFulhnQRUk6NKIuFRN-ACEExiehoHJ-EqKvce0=.f293af52-6c67-4eb0-b499-f819cf583547@github.com>
 <udkaG3AwN-OrnhDEP6-8GglMnhenghusZVHW_tnGGSM=.341082c7-6195-4889-9791-6d9589e6437d@github.com>
Message-ID: <tLiE0rc3Ec2-k5TP9VXEN5HuxB3oimWRHFiRF8YrnCc=.91003f40-8e1e-4426-958c-0433a8a8fd5f@github.com>

On Mon, 5 Dec 2022 10:16:22 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Expand test
>>  - Adjust wording to make it clear that the number of tasks is non-negative
>>  - Merge
>>  - Improve javadoc
>>  - Merge
>>  - Initial commit
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2920:
> 
>> 2918:      * @since 20
>> 2919:      */
>> 2920:     public <T> ForkJoinTask<T> externalSubmit(ForkJoinTask<T> task) {
> 
> @AlanBateman Does it make sense to check the nullness of the `task` before going into the storeStoreFence etc?

It's only to be the same as poolSubmit.

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

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

From sundar at openjdk.org  Mon Dec  5 11:03:15 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Mon, 5 Dec 2022 11:03:15 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v39]
In-Reply-To: <-V_N0Cvh4J0vKNbBYdFcow9E8yFHRIjya8n69MpDSuY=.9626ee4d-95b6-41e4-b21e-395e79840388@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <-V_N0Cvh4J0vKNbBYdFcow9E8yFHRIjya8n69MpDSuY=.9626ee4d-95b6-41e4-b21e-395e79840388@github.com>
Message-ID: <dlBXl0vH7TAofMfxNSZiciwGxWjfx4ieul41FSocySU=.a65380d2-6c91-4ce7-be9a-002c0f4b66f1@github.com>

On Mon, 5 Dec 2022 10:31:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Preview annotation for JEP 434

LGTM

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

Marked as reviewed by sundar (Reviewer).

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

From duke at openjdk.org  Mon Dec  5 11:18:08 2022
From: duke at openjdk.org (Viktor Klang)
Date: Mon, 5 Dec 2022 11:18:08 GMT
Subject: RFR: 8297495: j.u.concurrent updates for JDK 20 [v2]
In-Reply-To: <tLiE0rc3Ec2-k5TP9VXEN5HuxB3oimWRHFiRF8YrnCc=.91003f40-8e1e-4426-958c-0433a8a8fd5f@github.com>
References: <HcXqonjoH0jm8K5fXlfw8YsfyNBswTwFuPD7rtEr8FI=.22189b59-24bc-44bc-add1-9587ebe60518@github.com>
 <yNV8fdFulhnQRUk6NKIuFRN-ACEExiehoHJ-EqKvce0=.f293af52-6c67-4eb0-b499-f819cf583547@github.com>
 <udkaG3AwN-OrnhDEP6-8GglMnhenghusZVHW_tnGGSM=.341082c7-6195-4889-9791-6d9589e6437d@github.com>
 <tLiE0rc3Ec2-k5TP9VXEN5HuxB3oimWRHFiRF8YrnCc=.91003f40-8e1e-4426-958c-0433a8a8fd5f@github.com>
Message-ID: <AgjscU9oaXyv0kb2TGGwfCBo4e5kRDiSgfddW45e_uk=.95823dda-2f4a-4c3b-95c5-4c27f14180fe@github.com>

On Mon, 5 Dec 2022 10:33:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2920:
>> 
>>> 2918:      * @since 20
>>> 2919:      */
>>> 2920:     public <T> ForkJoinTask<T> externalSubmit(ForkJoinTask<T> task) {
>> 
>> @AlanBateman Does it make sense to check the nullness of the `task` before going into the storeStoreFence etc?
>
> It's only to be the same as poolSubmit.

@AlanBateman Then I presume that there's a good reason for not checking. :)

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

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

From aph at openjdk.org  Mon Dec  5 12:06:02 2022
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 5 Dec 2022 12:06:02 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v36]
In-Reply-To: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
Message-ID: <Thg5oAO4bkvHbYX2IUVCorreq5h6NKv2buMul9A-sEo=.7f3524d7-94e9-42f4-96e7-9e23181decc7@github.com>

> JEP 429 implementation.

Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 69 commits:

 - Merge https://github.com/openjdk/jdk into JDK-8286666
 - Feedback from reviewers
 - Feedback from reviewers
 - Unused variable
 - Cleanup
 - Cleanup
 - Merge branch 'JDK-8286666' of https://github.com/theRealAph/jdk into JDK-8286666
 - Update src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
 - Reviewer feedback
 - Merge branch 'JDK-8286666' of https://github.com/theRealAph/jdk into JDK-8286666
 - ... and 59 more: https://git.openjdk.org/jdk/compare/dea2161f...702d7444

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

Changes: https://git.openjdk.org/jdk/pull/10952/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=35
  Stats: 3333 lines in 62 files changed: 2909 ins; 254 del; 170 mod
  Patch: https://git.openjdk.org/jdk/pull/10952.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952

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

From jlahoda at openjdk.org  Mon Dec  5 12:09:32 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 5 Dec 2022 12:09:32 GMT
Subject: RFR: JDK-8296149: Start of release updates for JDK 21 [v3]
In-Reply-To: <XGiwl-FfzsJn6_teztoT9PEtdCdByIBR7tlGjcpXpCY=.4a4bd6e9-a4d9-4985-85da-8d2ace7483a3@github.com>
References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
 <XGiwl-FfzsJn6_teztoT9PEtdCdByIBR7tlGjcpXpCY=.4a4bd6e9-a4d9-4985-85da-8d2ace7483a3@github.com>
Message-ID: <ywUKswr0B5PnsPDUybLkFitaFpj0LkrrX4KpwdixuQk=.7cd41c9f-dca1-49ed-b34f-14b871353fb6@github.com>

On Sat, 3 Dec 2022 23:10:48 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8296149
>  - Merge branch 'master' into JDK-8296149
>  - Update symbol information for JDK 20 build 26.
>  - Merge branch 'master' into JDK-8296149
>  - Merge branch 'master' into JDK-8296149
>  - Fix failed HotSpot regression tests.
>  - Merge branch 'master' into JDK-8296149
>  - Update symbol information to JDK 20 build 24.
>  - Merge branch 'master' into JDK-8296149
>  - Merge branch 'master' into JDK-8296149
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/ea5d4b3a...515002c7

javac changes look fine to me.

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

Marked as reviewed by jlahoda (Reviewer).

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

From aph at openjdk.org  Mon Dec  5 12:31:15 2022
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 5 Dec 2022 12:31:15 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v37]
In-Reply-To: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
Message-ID: <gqONKOkeEWYFbAbSNukCiJHu4kEF4UYYyvlyvY_Ijrw=.4ed88dde-08ef-4c4f-b39c-50cbce2bb575@github.com>

> JEP 429 implementation.

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

  Add comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10952/files
  - new: https://git.openjdk.org/jdk/pull/10952/files/702d7444..dcae81b4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=36
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=35-36

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

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

From thomas.stuefe at gmail.com  Mon Dec  5 12:43:47 2022
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 5 Dec 2022 13:43:47 +0100
Subject: Extend Native Memory Tracking over the JDK ? (was: Proposal:
 track zlib native memory usage with NMT)
In-Reply-To: <5ceac3c4-4cc7-2ce5-822c-0ad498b1c476@amazon.de>
References: <CAA-vtUzvyqb_LZ9d1Z80oSvzyqpi89053O3B+oDZF4oZ85CuZg@mail.gmail.com>
 <c5db2105-3b78-0b77-779f-011c8649f476@oracle.com>
 <CAA-vtUxrP49w523EQ3yKFh4Zo5W+HMtqpGcsUxOEMkwZUOQ0zQ@mail.gmail.com>
 <CAA-vtUxB8Z1CD9EYMaMT8OJjw6unwCYd7ONBvQRCVQqO4VTUZQ@mail.gmail.com>
 <5ceac3c4-4cc7-2ce5-822c-0ad498b1c476@amazon.de>
Message-ID: <CAA-vtUwBu2PiB-0fxh0HjbEaTU=qpz7kpQ96Ud9qz3MrSsm3xg@mail.gmail.com>

Thank you for the positive encouragement, Roman :-)

Cheers, Thomas

On Mon, Dec 5, 2022 at 12:03 PM Kennke, Roman <rkennke at amazon.de> wrote:

> Hi Thomas,
>
> I very much like the idea and also your proposals how to do it. Insights
> in JDK's native memory usage is sorely lacking and would be very useful!
> I don't have all that much to add about the details beyond what you
> already covered, though :-)
>
> Cheers,
> Roman
>
>
> > Are there any opinions about whether or not to extend NMT across the JDK?
> >
> > This blocks https://bugs.openjdk.org/browse/JDK-8296360
> > <https://bugs.openjdk.org/browse/JDK-8296360>, and I had a PR prepared
> > as https://github.com/openjdk/jdk/pull/10988
> > <https://github.com/openjdk/jdk/pull/10988>. Originally I was hoping to
> > get this into JDK 20, but I don't think that is realistic anymore. I am
> > fine with postponing my work in favor of a baseline discussion, but so
> > far there is very little discussion about this topic.
> >
> > How should I proceed?
> >
> > Thanks, Thomas
> >
> >
> >
> > On Wed, Nov 9, 2022 at 8:12 AM Thomas St?fe <thomas.stuefe at gmail.com
> > <mailto:thomas.stuefe at gmail.com>> wrote:
> >
> >     Hi Alan,
> >
> >     (replaced hotspot-runtime-dev with hotspot-dev, since its more of a
> >     general topic)
> >
> >     thank you for your time!
> >
> >     I am very happy to talk this through. I think native memory
> >     observability in the JDK (and customer code!) is sorely lacking.
> >     Witness the countless "where did my native memory go" blog articles.
> >     At SAP we have been struggling with this topic for a long time and
> >     have come up with a mixture of solutions. The aforementioned tracker
> >     was one, which extended our version of NMT across the JDK. Our
> >     SapMachine MallocTracer, which allows us to trace uninstrumented
> >     customer code, another. We even experimented with exchanging the
> >     allocator (using jemalloc) to gain insights. But that is a whole
> >     different topic with deep logistical implications, I don't want to
> >     touch it here. Exchanging the allocator does not help to observe
> >     virtual memory or the brk segment, of course.
> >
> >     And to make the picture complete, another insight we currently lack
> >     is the implicit allocator overhead, which can be very significant
> >     and is hidden by the libc. We also have observability for that in
> >     the SapMachine, and I miss it in OpenJDK.
> >
> >     As you noticed, my original intent was just to instrument Zlib and
> >     possibly improve tracking for DBBs. Although, thinking beyond that,
> >     another attractive instrumentation target would be mapped NIO
> >     buffers at least.
> >
> >     So I think native memory observability is important. Arguably we
> >     could even extend observability to cover other OS resources, e.g.
> >     file handles. If we shift code around, to java/Panama: data that
> >     move the java heap does not need to be tracked, but other memory
> >     will always come from one of the basic system APIs, regardless of
> >     who allocates it and where in the stack allocation happens. Be it
> >     native JDK code, Panama, or even customer JNI code.
> >
> >     If we agree on the importance of native memory observability, then I
> >     believe NMT is the right tool for it. It is a good tool. The
> >     machinery is already there. It covers both C-heap and virtual memory
> >     APIs, as well as thread stacks, and could easily be extended to
> >     cover sbrk if needed. And I assume that whatever shape OpenJDK takes
> >     on in the future, there always will be a libjvm.so at its core, so
> >     we will always have it. But even if not, NMT could be separated from
> >     libjvm.so quite easily, since it has no deep ties with the JVM.
> >
> >     About coupling JVM with outside code: We don't have to directly link
> >     against libjvm.so. We can keep things loose if the intent is to be
> >     runnable without a JVM, or be JVM-version-agnostic. That could take
> >     the form of a function-pointer interface like JVMTI. Or outside code
> >     could dynamically dlsym the JVM allocation hooks. In any case
> >     gracefully falling back to system allocation routines when necessary.
> >
> >     And I agree, polluting the NMT tag space with outside meaning is
> >     ugly. I only did it because I planned to go no further than
> >     instrumenting Zlib and possibly DBBs. But if we take this further,
> >     my preferred solution would be a reserved tag range or -ranges for
> >     outside use, whose inner meaning would be opaque to the JVM. Kind of
> >     like SIGRTMIN+SIGRTMAX. Then, outside code could register tags and
> >     their meta information with the JVM, or we find a different way to
> >     convey the tag meaning to NMT (config files, or callbacks). That
> >     could even be opened up for customer use.
> >
> >     This also touches on another question, that of NMT tag space. NMT
> >     tags are very useful since they allow cheap tracking without
> >     capturing call stacks. However, tags are underused and show growing
> >     pains since they are too one-dimensional and restrictive. We had
> >     competing interests in the past about tag granularity. It is all
> >     over the place. We have coarse-grained tags like "mtThread", and
> >     very fine-grained ones like "mtObjectMonitor". There are several
> >     ways we could improve, e.g., by making them combinable like UL does,
> >     or allowing for a hierarchy of them - either a hard-wired limited
> >     one like "domain"+"tag", or an unlimited tree-like one. Technically
> >     interesting since whatever the new encoding is, they still must fit
> >     into a malloc header. I opened
> >     https://bugs.openjdk.org/browse/JDK-8281819
> >     <https://bugs.openjdk.org/browse/JDK-8281819> to track ideas like
> these.
> >
> >     Instrumenting Panama allocations, including the ability to tag
> >     allocations, would be a very good idea. For instance, if we ever
> >     remove the native Zlib layer and convert it to java using Panama, we
> >     can do the same with Panama I do now natively - use the Zlib zalloc
> >     interface to hook in JVM memory allocation functions. The result
> >     could be completely identical, and the end user looking at the NMT
> >     output need never know that anything changed.
> >
> >     And that goes for all instrumentation - if today we add it to JNI
> >     code, and that code gets removed tomorrow, we can add it to Panama
> >     code too. Unless data structures move to the heap, in which case
> >     there is no need to track them.
> >
> >     You mentioned that NMT was more of an in-house support tool. Our
> >     experience is different. Even though it was positioned as a tool for
> >     JVM developers, and we never cared for the backward compatibility or
> >     consistency, it gets used a *lot* by our customers. We have to
> >     explain its output frequently. Also, many blog articles exist
> >     documenting its use. So, maybe it would be okay to elevate it to a
> >     user-facing tool since it seems to occupy that role anyway. We may
> >     also open up consumption of NMT results via java APIs, or expose its
> >     results via MXBeans.
> >
> >     If this is to be a JEP, okay, but I'm afraid it would stall things a
> >     bit. I am interested in getting a simpler and quicker solution for
> >     older support releases at least, possibly based on my PR. I know
> >     that would be unconventional though.
> >
> >     Thank you,
> >
> >     Thomas
> >
> >
> >     On Sun, Nov 6, 2022 at 9:31 AM Alan Bateman <Alan.Bateman at oracle.com
> >     <mailto:Alan.Bateman at oracle.com>> wrote:
> >
> >         On 04/11/2022 16:54, Thomas St?fe wrote:
> >          > Hi all,
> >          >
> >          > I am currently working on
> >         https://bugs.openjdk.org/browse/JDK-8296360
> >         <https://bugs.openjdk.org/browse/JDK-8296360>;
> >          > I was preparing the final PR [1], but then Alan did ask me to
> >         discuss
> >          > this on core-libs first.
> >          >
> >          > Backstory:
> >          >
> >          > NMT tracks hotspot native allocations but does not cover the
> JDK
> >          > libraries (small exception: Unsafe.AllocateMemory). However,
> the
> >          > native memory footprint of JDK libraries can be significant.
> >         We have
> >          > no in-VM tracker for these and need tools like valgrind or our
> >          > SapMachine MallocTracer [2] to observe them.
> >
> >         Thanks for starting a discussion on this as this is a topic that
> >         requires agreement from several areas. If this is the start of
> >         something
> >         bigger, where you want to have all allocation sites in the
> >         libraries
> >         using NMT, then I think it needs a write-up, maybe a JEP.
> >
> >         For starters, I think it needs some agreement on using NMT for
> >         memory
> >         allocated outside of libjvm. You mentioned Unsafe as an
> >         exception but
> >         that is implemented in the VM so you get tracking for free,
> >         albeit I
> >         think all allocations are in the "mtOther" category.
> >
> >         A general concern is that it creates more coupling between the
> >         VM code
> >         and the libraries code. As you probably know, we've removed most
> >         of the
> >         dependences on JVM_* functions from non-core areas over many
> >         years. So I
> >         think that needs consideration as I assume we don't want
> >         memory/allocation.hpp declaring a dozen catagories for
> >         allocations done
> >         in say java.desktop module for example. Maybe your proposal will
> be
> >         strictly limited to java.base but even then, do we really want
> >         the VM
> >         even knowing about categories that are specific to zip
> >         compression or
> >         decompression?
> >
> >         There are probably longer term trends that should be part of the
> >         discussion too. One general trend is that "run time" is becoming
> >         more
> >         and more a hybrid of code in libvm and the Java libraries.
> Lambdas,
> >         module system, virtual threads implementations are a few
> >         examples in the
> >         last few release. This comes with many "Java on Java" challenges,
> >         including serviceability where users of the platform will expect
> >         tools
> >         to just work and won't care where the code is. NMT is probably
> >         more for
> >         support teams and not something that most developers will ever
> >         use but I
> >         think is part of the challenge of having serviceability
> >         solutions "just
> >         work".
> >
> >         In addition to having more of the Java runtime written in Java,
> >         there
> >         will likely be less JNI code in the future. It's very possible
> >         that the
> >         JNI code (including the JNI methods in libzip) will be replaced
> >         with
> >         code that uses Panama memory and linker APIs once they are become
> >         permanent. The effect of that would to have a lot of the memory
> >         allocations be tracked in the mtOther category again. Maybe
> >         integration
> >         with memory tracking should be looked at in conjunction with
> >         these APIs
> >         and this migration. I could imagine the proposed "Arena" API
> >         (MemorySession in Java 19) having some integration with NMT and
> >         it might
> >         be interesting to look into that.
> >
> >         So yes, this topic does need broader discussion and it might be
> >         a bit
> >         premature to start with a PR for libzip without talking about
> >         the bigger
> >         picture first.
> >
> >         -Alan
> >
> >
> >
>
>
>
> Amazon Development Center Germany GmbH
> Krausenstr. 38
> 10117 Berlin
> Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
> Sitz: Berlin
> Ust-ID: DE 289 237 879
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221205/24f5e52d/attachment-0001.htm>

From rkennke at amazon.de  Mon Dec  5 11:03:18 2022
From: rkennke at amazon.de (Kennke, Roman)
Date: Mon, 5 Dec 2022 12:03:18 +0100
Subject: Extend Native Memory Tracking over the JDK ? (was: Proposal:
 track zlib native memory usage with NMT)
In-Reply-To: <CAA-vtUxB8Z1CD9EYMaMT8OJjw6unwCYd7ONBvQRCVQqO4VTUZQ@mail.gmail.com>
References: <CAA-vtUzvyqb_LZ9d1Z80oSvzyqpi89053O3B+oDZF4oZ85CuZg@mail.gmail.com>
 <c5db2105-3b78-0b77-779f-011c8649f476@oracle.com>
 <CAA-vtUxrP49w523EQ3yKFh4Zo5W+HMtqpGcsUxOEMkwZUOQ0zQ@mail.gmail.com>
 <CAA-vtUxB8Z1CD9EYMaMT8OJjw6unwCYd7ONBvQRCVQqO4VTUZQ@mail.gmail.com>
Message-ID: <5ceac3c4-4cc7-2ce5-822c-0ad498b1c476@amazon.de>

Hi Thomas,

I very much like the idea and also your proposals how to do it. Insights 
in JDK's native memory usage is sorely lacking and would be very useful! 
I don't have all that much to add about the details beyond what you 
already covered, though :-)

Cheers,
Roman


> Are there any opinions about whether or not to extend NMT across the JDK?
> 
> This blocks https://bugs.openjdk.org/browse/JDK-8296360 
> <https://bugs.openjdk.org/browse/JDK-8296360>, and I had a PR prepared 
> as https://github.com/openjdk/jdk/pull/10988 
> <https://github.com/openjdk/jdk/pull/10988>. Originally I was hoping to 
> get this into JDK 20, but I don't think that is realistic anymore. I am 
> fine with postponing my work in favor of a baseline discussion, but so 
> far there is very little discussion about this topic.
> 
> How should I proceed?
> 
> Thanks, Thomas
> 
> 
> 
> On Wed, Nov 9, 2022 at 8:12 AM Thomas St?fe <thomas.stuefe at gmail.com 
> <mailto:thomas.stuefe at gmail.com>> wrote:
> 
>     Hi Alan,
> 
>     (replaced hotspot-runtime-dev with hotspot-dev, since its more of a
>     general topic)
> 
>     thank?you for your time!
> 
>     I am very happy to talk this through. I think native memory
>     observability in the JDK (and customer code!) is sorely lacking.
>     Witness the countless "where did my native memory go" blog articles.
>     At SAP we have been struggling with this topic for a long time and
>     have come up with a mixture of solutions. The aforementioned tracker
>     was one, which extended our version of NMT across the JDK. Our
>     SapMachine MallocTracer, which allows us to trace uninstrumented
>     customer code, another. We even experimented with exchanging the
>     allocator (using jemalloc) to gain insights. But that is a whole
>     different topic with deep logistical implications, I don't want to
>     touch it here. Exchanging the allocator does not help to observe
>     virtual memory or the brk segment, of course.
> 
>     And to make the picture complete, another insight we currently lack
>     is the implicit allocator overhead, which can be very significant
>     and is hidden by the libc. We also have observability for that in
>     the SapMachine, and I miss it in OpenJDK.
> 
>     As you noticed, my original intent was just to instrument Zlib and
>     possibly improve tracking for DBBs. Although, thinking beyond that,
>     another attractive instrumentation target would be mapped NIO
>     buffers at least.
> 
>     So I think native memory observability is important. Arguably we
>     could even extend observability to cover other OS resources, e.g.
>     file handles. If we shift code around, to java/Panama: data that
>     move the java heap does not need to be tracked, but other memory
>     will always come from one of the basic system APIs, regardless of
>     who allocates it and where in the stack allocation happens. Be it
>     native JDK code, Panama, or even customer JNI code.
> 
>     If we agree on the importance of native memory observability, then I
>     believe NMT is the right tool for it. It is a good?tool.?The
>     machinery is already there. It covers both C-heap and virtual memory
>     APIs, as well as thread stacks, and could easily be extended to
>     cover sbrk if needed. And I assume that whatever shape OpenJDK takes
>     on in the future, there always will be a libjvm.so at its core, so
>     we will always have it. But even if not, NMT could be separated from
>     libjvm.so quite easily, since it has no deep ties with the JVM.
> 
>     About coupling JVM with outside code: We don't have to directly link
>     against libjvm.so. We can keep things loose if the intent is to be
>     runnable without a JVM, or be JVM-version-agnostic. That could take
>     the form of a function-pointer interface like JVMTI. Or outside code
>     could dynamically dlsym the JVM allocation hooks. In any case
>     gracefully falling back to system allocation routines when necessary.
> 
>     And I agree, polluting the NMT tag space with outside meaning is
>     ugly. I only did it because I planned to go no further than
>     instrumenting Zlib and possibly DBBs. But if we take this further,
>     my preferred solution would be a reserved tag range or -ranges for
>     outside use, whose?inner meaning would be opaque to the JVM. Kind of
>     like SIGRTMIN+SIGRTMAX. Then, outside code could register tags and
>     their meta information with the JVM, or we find a different way to
>     convey the tag meaning to NMT (config files, or callbacks). That
>     could even be opened up for customer use.
> 
>     This also touches on another question, that of NMT tag space. NMT
>     tags are very useful since they allow cheap tracking without
>     capturing call stacks. However, tags are underused and show growing
>     pains since they are too one-dimensional and restrictive. We had
>     competing interests in the past about tag granularity. It is?all
>     over the place. We have coarse-grained tags like "mtThread", and
>     very fine-grained ones like "mtObjectMonitor". There are several
>     ways we could improve, e.g., by making them combinable like UL does,
>     or allowing for a hierarchy of them - either a hard-wired limited
>     one like "domain"+"tag", or an unlimited tree-like one. Technically
>     interesting since whatever the new encoding is, they still must fit
>     into a malloc header. I opened
>     https://bugs.openjdk.org/browse/JDK-8281819
>     <https://bugs.openjdk.org/browse/JDK-8281819> to track ideas like these.
> 
>     Instrumenting Panama allocations, including the ability to tag
>     allocations, would be a very good idea. For instance, if we ever
>     remove the native Zlib layer and convert it to java using Panama, we
>     can do the same with Panama I do now natively - use the Zlib zalloc
>     interface to hook in JVM memory allocation functions. The result
>     could be completely identical, and the end user looking at the NMT
>     output need never know that anything changed.
> 
>     And that goes for all instrumentation - if today we add it to JNI
>     code, and that code gets removed tomorrow, we can add it to Panama
>     code too. Unless data structures move to the heap, in which case
>     there is no need to track them.
> 
>     You mentioned that NMT was more of an in-house support tool. Our
>     experience is different. Even though it was positioned as a tool for
>     JVM developers, and we never cared for the backward compatibility or
>     consistency, it gets used a *lot* by our customers. We have to
>     explain its output frequently. Also, many blog articles exist
>     documenting its use. So, maybe it would be okay to elevate it to a
>     user-facing tool since it seems to occupy that role anyway. We may
>     also open up consumption of NMT results via java APIs, or expose its
>     results via MXBeans.
> 
>     If this is to be a JEP, okay, but I'm afraid it would stall things a
>     bit. I am interested in getting a simpler and quicker solution for
>     older support releases at?least, possibly based on my PR. I know
>     that would be unconventional though.
> 
>     Thank you,
> 
>     Thomas
> 
> 
>     On Sun, Nov 6, 2022 at 9:31 AM Alan Bateman <Alan.Bateman at oracle.com
>     <mailto:Alan.Bateman at oracle.com>> wrote:
> 
>         On 04/11/2022 16:54, Thomas St?fe wrote:
>          > Hi all,
>          >
>          > I am currently working on
>         https://bugs.openjdk.org/browse/JDK-8296360
>         <https://bugs.openjdk.org/browse/JDK-8296360>;
>          > I was preparing the final PR [1], but then Alan did ask me to
>         discuss
>          > this on core-libs first.
>          >
>          > Backstory:
>          >
>          > NMT tracks hotspot native allocations but does not cover the JDK
>          > libraries (small exception: Unsafe.AllocateMemory). However, the
>          > native memory footprint of JDK libraries can be significant.
>         We have
>          > no in-VM tracker for these and need tools like valgrind or our
>          > SapMachine MallocTracer [2] to observe them.
> 
>         Thanks for starting a discussion on this as this is a topic that
>         requires agreement from several areas. If this is the start of
>         something
>         bigger, where you want to have all allocation sites in the
>         libraries
>         using NMT, then I think it needs a write-up, maybe a JEP.
> 
>         For starters, I think it needs some agreement on using NMT for
>         memory
>         allocated outside of libjvm. You mentioned Unsafe as an
>         exception but
>         that is implemented in the VM so you get tracking for free,
>         albeit I
>         think all allocations are in the "mtOther" category.
> 
>         A general concern is that it creates more coupling between the
>         VM code
>         and the libraries code. As you probably know, we've removed most
>         of the
>         dependences on JVM_* functions from non-core areas over many
>         years. So I
>         think that needs consideration as I assume we don't want
>         memory/allocation.hpp declaring a dozen catagories for
>         allocations done
>         in say java.desktop module for example. Maybe your proposal will be
>         strictly limited to java.base but even then, do we really want
>         the VM
>         even knowing about categories that are specific to zip
>         compression or
>         decompression?
> 
>         There are probably longer term trends that should be part of the
>         discussion too. One general trend is that "run time" is becoming
>         more
>         and more a hybrid of code in libvm and the Java libraries. Lambdas,
>         module system, virtual threads implementations are a few
>         examples in the
>         last few release. This comes with many "Java on Java" challenges,
>         including serviceability where users of the platform will expect
>         tools
>         to just work and won't care where the code is. NMT is probably
>         more for
>         support teams and not something that most developers will ever
>         use but I
>         think is part of the challenge of having serviceability
>         solutions "just
>         work".
> 
>         In addition to having more of the Java runtime written in Java,
>         there
>         will likely be less JNI code in the future. It's very possible
>         that the
>         JNI code (including the JNI methods in libzip) will be replaced
>         with
>         code that uses Panama memory and linker APIs once they are become
>         permanent. The effect of that would to have a lot of the memory
>         allocations be tracked in the mtOther category again. Maybe
>         integration
>         with memory tracking should be looked at in conjunction with
>         these APIs
>         and this migration. I could imagine the proposed "Arena" API
>         (MemorySession in Java 19) having some integration with NMT and
>         it might
>         be interesting to look into that.
> 
>         So yes, this topic does need broader discussion and it might be
>         a bit
>         premature to start with a PR for libzip without talking about
>         the bigger
>         picture first.
> 
>         -Alan
> 
> 
> 



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



From dnsimon at openjdk.org  Mon Dec  5 13:24:59 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 5 Dec 2022 13:24:59 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at runtime
Message-ID: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>

Libgraal is compiled ahead of time and should not need any JVMCI Java code to be dynamically loaded at runtime. Prior to this PR, this is not the case due to:

* Code to copy system properties from the HotSpot heap into the libgraal heap. This is in `jdk.vm.ci.services.Services.initializeSavedProperties(byte[])` and `jdk.vm.ci.services.Services.serializeSavedProperties()`. This code should be moved to `java.base/jdk.internal.vm.VMSupport`.
* Code to translate exceptions from the HotSpot heap into the libgraal heap and vice versa. This code should be moved from `jdk.internal.vm.ci//jdk.vm.ci.hotspot.TranslatedException` to `java.base/jdk.internal.vm.VMSupport`.

This PR makes the above changes. As a result, it's possible to build a JDK image that includes (and uses) libgraal but does not include `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces footprint and better isolates the JAVMCI and the Graal compiler as accessing these components from Java code is now impossible.

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

Commit messages:
 - move JVMCI exception translation support into VMSupport
 - move JVMCITraceMark blocks within scope of C2V_BLOCK (GR-40773)
 - move JVMCI system properties support into VMSupport
 - only resolve jdk.internal.vm.ci if it is present on the file system

Changes: https://git.openjdk.org/jdk/pull/11513/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11513&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298099
  Stats: 1414 lines in 20 files changed: 607 ins; 706 del; 101 mod
  Patch: https://git.openjdk.org/jdk/pull/11513.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11513/head:pull/11513

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

From stsypanov at openjdk.org  Mon Dec  5 13:25:06 2022
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 5 Dec 2022 13:25:06 GMT
Subject: RFR: 8298033: Character.codePointAt(char[], int,
 int) doesn't do JavaDoc-specified check [v3]
In-Reply-To: <obzX6gFjzBXHa4fwPcSW80GWANmJoVx-XXQ12wn9jQA=.6595ab56-a390-4197-974c-9399f7fdd4c2@github.com>
References: <dHjviGmASssYfntfClzDC28Ppjrn3pECnO3HzbZHopY=.d9923de3-6de7-41f5-a84e-03a7c5267e2f@github.com>
 <4UxZnSr4yjQQIAFOP_Lm1n-lqQ0m1zQAp-knX42Cy-k=.124fabe0-7cf8-4f19-bdcc-234d2f2e4796@github.com>
 <YRjjKiUbkB6uXnAYMUEZxMzAztfl_KlnGxiXu1Np-Is=.5e4dadba-5886-4e46-8b81-5fa129b343f6@github.com>
 <obzX6gFjzBXHa4fwPcSW80GWANmJoVx-XXQ12wn9jQA=.6595ab56-a390-4197-974c-9399f7fdd4c2@github.com>
Message-ID: <ovN5eECaqGNK191GaW0IDDPglrMXrFJhxFjSE2dYZWo=.d1a6b387-7a90-41b2-935c-1c513048945b@github.com>

On Sat, 3 Dec 2022 18:40:59 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> test/jdk/java/lang/Character/Supplementary.java line 808:
>> 
>>> 806:                 return;
>>> 807:             }
>>> 808:             if (expectedException.isInstance(e)) { // Character.codePointBefore() throws
>> 
>> The test should fail without the fix, but this fall-through allows the test to pass.
>> 
>> The qualification added for `isAt` is hiding a second/corresponding bug in `codePointBefore` where the index is not checked and an ArrayIndexOutOfBounds occurs at codePointBeforeImpl: 9488.
>
> Yeah, this AIOOBE is exactly the reason why I added this. So should we modify `codePointBefore` in the same way as `codePointAt`?

I'm asking because counter-intuitively `codePointBefore ` doesn't specify IOOBE for negative `index`.

/**
 * @return the Unicode code point value before the given index.
 * @throws NullPointerException if {@code a} is null.
 * @throws IndexOutOfBoundsException if the {@code index}
 * argument is not greater than the {@code start} argument or
 * is greater than the length of the {@code char} array, or
 * if the {@code start} argument is negative or not less than
 * the length of the {@code char} array.
 * @since  1.5
 */
 ```

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

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

From alanb at openjdk.org  Mon Dec  5 13:35:03 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 5 Dec 2022 13:35:03 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime
In-Reply-To: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
Message-ID: <Ztw0UpACX_jczeIl57EbOa6BOpiFVWeACn3CowQSgZE=.d6776252-4478-4bb9-8555-9bb17af43051@github.com>

On Mon, 5 Dec 2022 13:16:25 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> Libgraal is compiled ahead of time and should not need any JVMCI Java code to be dynamically loaded at runtime. Prior to this PR, this is not the case due to:
> 
> * Code to copy system properties from the HotSpot heap into the libgraal heap. This is in `jdk.vm.ci.services.Services.initializeSavedProperties(byte[])` and `jdk.vm.ci.services.Services.serializeSavedProperties()`. This code should be moved to `java.base/jdk.internal.vm.VMSupport`.
> * Code to translate exceptions from the HotSpot heap into the libgraal heap and vice versa. This code should be moved from `jdk.internal.vm.ci//jdk.vm.ci.hotspot.TranslatedException` to `java.base/jdk.internal.vm.VMSupport`.
> 
> This PR makes the above changes. As a result, it's possible to build a JDK image that includes (and uses) libgraal but does not include `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces footprint and better isolates the JAVMCI and the Graal compiler as accessing these components from Java code is now impossible.

src/hotspot/share/classfile/classLoader.cpp line 1419:

> 1417: 
> 1418: // Returns true if jdk.internal.vm.ci is present on the file system.
> 1419: bool ClassLoader::has_jvmci_module() {

Would it be more useful to pass the module name so that the function tests if the module is is in the run-time image so that ClassLoader doesn't need to know the name "jdk.internal.vm.ci"?

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

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

From dnsimon at openjdk.org  Mon Dec  5 13:49:28 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 5 Dec 2022 13:49:28 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v2]
In-Reply-To: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
Message-ID: <WgaYQgGsrCaoiwDikHOB0em7NhpCugMEVevsNKByQrE=.3a67835a-633c-4b29-be22-bcb2fc2ba40a@github.com>

> Libgraal is compiled ahead of time and should not need any JVMCI Java code to be dynamically loaded at runtime. Prior to this PR, this is not the case due to:
> 
> * Code to copy system properties from the HotSpot heap into the libgraal heap. This is in `jdk.vm.ci.services.Services.initializeSavedProperties(byte[])` and `jdk.vm.ci.services.Services.serializeSavedProperties()`. This code should be moved to `java.base/jdk.internal.vm.VMSupport`.
> * Code to translate exceptions from the HotSpot heap into the libgraal heap and vice versa. This code should be moved from `jdk.internal.vm.ci//jdk.vm.ci.hotspot.TranslatedException` to `java.base/jdk.internal.vm.VMSupport`.
> 
> This PR makes the above changes. As a result, it's possible to build a JDK image that includes (and uses) libgraal but does not include `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces footprint and better isolates the JAVMCI and the Graal compiler as accessing these components from Java code is now impossible.

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

  generalized ClassLoader::has_jvmci_module to is_module_resolvable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11513/files
  - new: https://git.openjdk.org/jdk/pull/11513/files/b91f31fe..3e89d402

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

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

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

From mcimadamore at openjdk.org  Mon Dec  5 13:49:46 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 5 Dec 2022 13:49:46 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v39]
In-Reply-To: <-V_N0Cvh4J0vKNbBYdFcow9E8yFHRIjya8n69MpDSuY=.9626ee4d-95b6-41e4-b21e-395e79840388@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <-V_N0Cvh4J0vKNbBYdFcow9E8yFHRIjya8n69MpDSuY=.9626ee4d-95b6-41e4-b21e-395e79840388@github.com>
Message-ID: <hkjubM7yW4kkYAetu0kuCJy9wPQ_Llluj47lYXIc_8A=.2fc0c63b-d71f-4b18-af52-a6aa286b742d@github.com>

On Mon, 5 Dec 2022 10:31:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Preview annotation for JEP 434

Note: there are 4 tests failing in x86:
* MemoryLayoutPrincipalTotalityTest
* MemoryLayoutTypeRetentionTest
* TestLargeSegmentCopy
* TestLinker

These failures are addressed in the dependent PR: https://git.openjdk.org/jdk/pull/11019, which will be integrated immediately after these changes

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

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

From jvernee at openjdk.org  Mon Dec  5 13:51:30 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 5 Dec 2022 13:51:30 GMT
Subject: RFR: 8296477: Foreign linker implementation update following JEP
 434 [v11]
In-Reply-To: <CGd4JSefJvfEVkZEfORzthEIeV53kLk_UkZHAhJGrQ0=.7741b5f2-2227-4017-8164-d54fb9d30d10@github.com>
References: <CGd4JSefJvfEVkZEfORzthEIeV53kLk_UkZHAhJGrQ0=.7741b5f2-2227-4017-8164-d54fb9d30d10@github.com>
Message-ID: <Fo9HNIRgbhTLnJXkapP1_qjB2fEgTRHD8UarM09L5pQ=.2189d888-4987-4737-ab5b-1580a0f25b7d@github.com>

> Pull in linker implementation changes, that include non-trivial changes to VM code, from the panama-foreign repo into the main JDK.
> 
> This is split off from the main JEP integration to make reviewing easier.
> 
> This includes the following patches:
> 
> 1. https://github.com/openjdk/panama-foreign/pull/698
> 2. https://github.com/openjdk/panama-foreign/pull/699
> 3. (part of) https://github.com/openjdk/panama-foreign/pull/731
> 4. https://github.com/openjdk/panama-foreign/pull/740
> 5. https://github.com/openjdk/panama-foreign/pull/746
> 6. https://github.com/openjdk/panama-foreign/pull/742
> 7. https://github.com/openjdk/panama-foreign/pull/743
> 
> Probably the biggest change to the code comes from replacing `VMReg` - which can not represent offsets into the stack that are not a multiple of the VM's stack slot size (32-bits) - with the new `VMStorage` class, which can describe byte offsets into the stack, as well as having a register mask to indicate only certain register segments.
> 
> The only part of 3. that is in this PR is the part that turns the `VMStorage` class in Java into a record.
> 
> Please refer to the PR of each individual patch for a more detailed description.

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 26 additional commits since the last revision:

 - Merge branch 'PR_20' into VM_Changes
 - Merge branch 'PR_20' into VM_Changes
 - Merge branch 'PR_20' into VM_Changes
 - use Arena in example
 - Merge branch 'PR_20' into VM_Changes
 - drop .inline from vmstorage header names
 - 8296973: saving errno on a value-returning function crashes the JVM
   
   Reviewed-by: mcimadamore
 - fix stubs
 - constexpr some functions
 - Review pt1
 - ... and 16 more: https://git.openjdk.org/jdk/compare/7b86f7b8...2949f997

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11019/files
  - new: https://git.openjdk.org/jdk/pull/11019/files/6e94e452..2949f997

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

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

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

From mcimadamore at openjdk.org  Mon Dec  5 13:55:22 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 5 Dec 2022 13:55:22 GMT
Subject: Integrated: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview)
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <7Ara-NxY9rdQzABZPYR9T-N7b1XLY99_6J-dG3cr2NY=.4151c690-0138-4ffd-a763-ff2456754189@github.com>

On Wed, 26 Oct 2022 13:11:50 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

This pull request has now been integrated.

Changeset: 73baadce
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/73baadceb60029f6340c1327118aeb59971c2434
Stats:     13808 lines in 255 files changed: 5780 ins; 4448 del; 3580 mod

8295044: Implementation of Foreign Function and Memory API (Second Preview)

Co-authored-by: Jorn Vernee <jvernee at openjdk.org>
Co-authored-by: Per Minborg <pminborg at openjdk.org>
Co-authored-by: Maurizio Cimadamore <mcimadamore at openjdk.org>
Reviewed-by: jvernee, pminborg, psandoz, alanb, sundar

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

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

From dnsimon at openjdk.org  Mon Dec  5 13:55:50 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 5 Dec 2022 13:55:50 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v2]
In-Reply-To: <Ztw0UpACX_jczeIl57EbOa6BOpiFVWeACn3CowQSgZE=.d6776252-4478-4bb9-8555-9bb17af43051@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <Ztw0UpACX_jczeIl57EbOa6BOpiFVWeACn3CowQSgZE=.d6776252-4478-4bb9-8555-9bb17af43051@github.com>
Message-ID: <a-ppZa-5xUyxJpp5lZ30BVyVRo8HzFpXwFGHCkicExg=.3f5a3ebc-5306-4738-9f36-f2bcc2ab9f5b@github.com>

On Mon, 5 Dec 2022 13:32:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   generalized ClassLoader::has_jvmci_module to is_module_resolvable
>
> src/hotspot/share/classfile/classLoader.cpp line 1419:
> 
>> 1417: 
>> 1418: // Returns true if jdk.internal.vm.ci is present on the file system.
>> 1419: bool ClassLoader::has_jvmci_module() {
> 
> Would it be more useful to pass the module name so that the function tests if the module is is in the run-time image so that ClassLoader doesn't need to know the name "jdk.internal.vm.ci"?

Yes, good idea: [3e89d40253b70251f9a2facce4b1d8d69701c045](https://github.com/openjdk/jdk/pull/11513/commits/3e89d40253b70251f9a2facce4b1d8d69701c045)
I also fixed a bug due in the size computation of `path`. Ideally, I'd factor out and re-use the same code in `ClassLoader::add_to_exploded_build_list`. However, the latter uses a `ResourceMark` which is not available when calling `is_module_resolvable` early in VM startup before `JavaThread` is initialized.

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

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

From dnsimon at openjdk.org  Mon Dec  5 13:55:51 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 5 Dec 2022 13:55:51 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v2]
In-Reply-To: <WgaYQgGsrCaoiwDikHOB0em7NhpCugMEVevsNKByQrE=.3a67835a-633c-4b29-be22-bcb2fc2ba40a@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <WgaYQgGsrCaoiwDikHOB0em7NhpCugMEVevsNKByQrE=.3a67835a-633c-4b29-be22-bcb2fc2ba40a@github.com>
Message-ID: <y4lLPk5mDrJNa9vzgiI5WyEJmfbsSRfBBi0QQNdZeEs=.24e2a234-f42e-456f-82a0-3c7fd05dc9c5@github.com>

On Mon, 5 Dec 2022 13:49:28 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Libgraal is compiled ahead of time and should not need any JVMCI Java code to be dynamically loaded at runtime. Prior to this PR, this is not the case due to:
>> 
>> * Code to copy system properties from the HotSpot heap into the libgraal heap. This is in `jdk.vm.ci.services.Services.initializeSavedProperties(byte[])` and `jdk.vm.ci.services.Services.serializeSavedProperties()`. This code should be moved to `java.base/jdk.internal.vm.VMSupport`.
>> * Code to translate exceptions from the HotSpot heap into the libgraal heap and vice versa. This code should be moved from `jdk.internal.vm.ci//jdk.vm.ci.hotspot.TranslatedException` to `java.base/jdk.internal.vm.VMSupport`.
>> 
>> This PR makes the above changes. As a result, it's possible to build a JDK image that includes (and uses) libgraal but does not include `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces footprint and better isolates the JAVMCI and the Graal compiler as accessing these components from Java code is now impossible.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   generalized ClassLoader::has_jvmci_module to is_module_resolvable

src/hotspot/share/classfile/classLoader.hpp line 378:

> 376: 
> 377:   // Determines if the `module_name` module is resolvable.
> 378:   static bool is_module_resolvable(const char* module_name);

Is "resolvable" the right concept here? Or should it be something like "findable" instead?

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

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

From djelinski at openjdk.org  Mon Dec  5 14:06:10 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 5 Dec 2022 14:06:10 GMT
Subject: RFR: 8297976: Remove sun.net.ProgressMonitor and related classes
 [v2]
In-Reply-To: <yw8Q8tA8_4jUmc1gWd-xAN-m5kjFPeou3dn0qML9TQ4=.18a511ff-946f-4a8a-8fe3-3eaf00a8a396@github.com>
References: <yw8Q8tA8_4jUmc1gWd-xAN-m5kjFPeou3dn0qML9TQ4=.18a511ff-946f-4a8a-8fe3-3eaf00a8a396@github.com>
Message-ID: <gR6VTUu8U9hz964d8bXM6w_vURFycj5GMDt9PrrzDrU=.7600e0f0-4167-4f57-8da4-54785788f41b@github.com>

> Please review this patch that removes progress monitoring classes used by UrlConnection.
> Since Java 9 these classes are not used in the JDK, and are not exported from java.base. If anyone was still using them, reimplementing them in user code should be pretty straightforward.
> 
> This PR also fixes the issue where MeteredStream finalizer could resurrect an unusable connection, causing unexpected exceptions in other parts of the code.
> 
> No new regression test; since we are removing the finalizer, I don't believe we will see the issue again. I can add a test for that if you think it still makes sense.
> 
> I had to adjust `ProxyModuleMapping.java` test which used `sun.net.ProgressListener` as an example of a module-private interface; I replaced it with another public interface from the same package.
> 
> Existing tier 1-3 tests continue to pass.

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

  Add test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11474/files
  - new: https://git.openjdk.org/jdk/pull/11474/files/e39aae11..e0e157c7

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

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

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

From djelinski at openjdk.org  Mon Dec  5 14:09:08 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 5 Dec 2022 14:09:08 GMT
Subject: RFR: 8297976: Remove sun.net.ProgressMonitor and related classes
 [v2]
In-Reply-To: <gR6VTUu8U9hz964d8bXM6w_vURFycj5GMDt9PrrzDrU=.7600e0f0-4167-4f57-8da4-54785788f41b@github.com>
References: <yw8Q8tA8_4jUmc1gWd-xAN-m5kjFPeou3dn0qML9TQ4=.18a511ff-946f-4a8a-8fe3-3eaf00a8a396@github.com>
 <gR6VTUu8U9hz964d8bXM6w_vURFycj5GMDt9PrrzDrU=.7600e0f0-4167-4f57-8da4-54785788f41b@github.com>
Message-ID: <FStjO-v_0a6kvC9-KZ_vOd48dF13h50AZoVic5MbDHw=.7de57324-30b1-4d3e-88f8-44ef097d504f@github.com>

On Mon, 5 Dec 2022 14:06:10 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Please review this patch that removes progress monitoring classes used by UrlConnection.
>> Since Java 9 these classes are not used in the JDK, and are not exported from java.base. If anyone was still using them, reimplementing them in user code should be pretty straightforward.
>> 
>> This PR also fixes the issue where MeteredStream finalizer could resurrect an unusable connection, causing unexpected exceptions in other parts of the code.
>> 
>> No new regression test; since we are removing the finalizer, I don't believe we will see the issue again. I can add a test for that if you think it still makes sense.
>> 
>> I had to adjust `ProxyModuleMapping.java` test which used `sun.net.ProgressListener` as an example of a module-private interface; I replaced it with another public interface from the same package.
>> 
>> Existing tier 1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

The reproducer from [JDK-8240275](https://bugs.openjdk.org/browse/JDK-8240275) didn't reliably reproduce the issue because some of the finalizers were replaced by cleaners in the meantime.
I added a test that verifies that the socket used by HTTPSUrlConnection is not reused after its finalizer completes. The test passes with this PR, fails with the current master.

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

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

From djelinski at openjdk.org  Mon Dec  5 14:12:05 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 5 Dec 2022 14:12:05 GMT
Subject: RFR: 8297976: Remove sun.net.ProgressMonitor and related classes
 [v3]
In-Reply-To: <yw8Q8tA8_4jUmc1gWd-xAN-m5kjFPeou3dn0qML9TQ4=.18a511ff-946f-4a8a-8fe3-3eaf00a8a396@github.com>
References: <yw8Q8tA8_4jUmc1gWd-xAN-m5kjFPeou3dn0qML9TQ4=.18a511ff-946f-4a8a-8fe3-3eaf00a8a396@github.com>
Message-ID: <Ys_W9ri2ZoiYdLlmWSXUG427HDTuBBt-YgQlE-6ho0Y=.a136b1cd-c64b-401a-a941-22b5520f406d@github.com>

> Please review this patch that removes progress monitoring classes used by UrlConnection.
> Since Java 9 these classes are not used in the JDK, and are not exported from java.base. If anyone was still using them, reimplementing them in user code should be pretty straightforward.
> 
> This PR also fixes the issue where MeteredStream finalizer could resurrect an unusable connection, causing unexpected exceptions in other parts of the code.
> 
> No new regression test; since we are removing the finalizer, I don't believe we will see the issue again. I can add a test for that if you think it still makes sense.
> 
> I had to adjust `ProxyModuleMapping.java` test which used `sun.net.ProgressListener` as an example of a module-private interface; I replaced it with another public interface from the same package.
> 
> Existing tier 1-3 tests continue to pass.

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

  Remove double space
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11474/files
  - new: https://git.openjdk.org/jdk/pull/11474/files/e0e157c7..8d7c6e5c

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

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

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

From andrew at openjdk.org  Mon Dec  5 14:38:51 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Mon, 5 Dec 2022 14:38:51 GMT
Subject: RFR: 8297804: (tz) Update Timezone Data to 2022g [v2]
In-Reply-To: <4b1tG73Xp3BMUy2X6Ab7W2So7u4jcSu9SrAWvrHLw1g=.d6218261-7f4e-48c5-9989-eb0887e0207e@github.com>
References: <4b1tG73Xp3BMUy2X6Ab7W2So7u4jcSu9SrAWvrHLw1g=.d6218261-7f4e-48c5-9989-eb0887e0207e@github.com>
Message-ID: <LUd0Rb4G80fdee18UQItifokHjI6FI31GBVTmDu5m_M=.0dfca816-dae6-4276-ab67-6de9bec62081@github.com>

> Update to the latest tzdata, 2022g.
> 
> Primary changes:
> * `America/Ojinaga` (CST) is split, creating `America/Ciudad_Juarez` (MST/MDT)
> * `America/Pangnirtung` becomes a link to `America/Iqaluit`
> * `America/Ojinaga` gains DST (CDT)
> 
> See bug for the full details.
> 
> There will likely also be CLDR changes ([CLDR-16181](https://unicode-org.atlassian.net/browse/CLDR-16181)) that are not yet included in this change. We can either wait for these and include them in this patch, or do a separate change like [JDK-8296715](https://bugs.openjdk.org/browse/JDK-8296715)
> 
> Tests in `java/util/TimeZone`, `java/time/test` and `sun/text/resources` all pass.

Andrew John Hughes has updated the pull request incrementally with two additional commits since the last revision:

 - Add CLDR changes from https://github.com/unicode-org/cldr/commit/0bd22412b35b6e7037a39c3ad6a4dc49c699439b
 - Update tzdata version

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11438/files
  - new: https://git.openjdk.org/jdk/pull/11438/files/27bf9277..82d3453b

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

  Stats: 23 lines in 5 files changed: 19 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11438.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11438/head:pull/11438

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

From jvernee at openjdk.org  Mon Dec  5 14:43:06 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 5 Dec 2022 14:43:06 GMT
Subject: RFR: 8296477: Foreign linker implementation update following JEP
 434 [v12]
In-Reply-To: <CGd4JSefJvfEVkZEfORzthEIeV53kLk_UkZHAhJGrQ0=.7741b5f2-2227-4017-8164-d54fb9d30d10@github.com>
References: <CGd4JSefJvfEVkZEfORzthEIeV53kLk_UkZHAhJGrQ0=.7741b5f2-2227-4017-8164-d54fb9d30d10@github.com>
Message-ID: <8IKeJaZMLm4Wbr5q7RITfR6auB1raU-jzQODNKnnHCQ=.ba354806-e514-47fa-802a-0370d6fe5792@github.com>

> Pull in linker implementation changes, that include non-trivial changes to VM code, from the panama-foreign repo into the main JDK.
> 
> This is split off from the main JEP integration to make reviewing easier.
> 
> This includes the following patches:
> 
> 1. https://github.com/openjdk/panama-foreign/pull/698
> 2. https://github.com/openjdk/panama-foreign/pull/699
> 3. (part of) https://github.com/openjdk/panama-foreign/pull/731
> 4. https://github.com/openjdk/panama-foreign/pull/740
> 5. https://github.com/openjdk/panama-foreign/pull/746
> 6. https://github.com/openjdk/panama-foreign/pull/742
> 7. https://github.com/openjdk/panama-foreign/pull/743
> 
> Probably the biggest change to the code comes from replacing `VMReg` - which can not represent offsets into the stack that are not a multiple of the VM's stack slot size (32-bits) - with the new `VMStorage` class, which can describe byte offsets into the stack, as well as having a register mask to indicate only certain register segments.
> 
> The only part of 3. that is in this PR is the part that turns the `VMStorage` class in Java into a record.
> 
> Please refer to the PR of each individual patch for a more detailed description.

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

 - Merge master
 - Merge branch 'PR_20' into VM_Changes
 - Fix Preview annotation for JEP 434
 - Merge branch 'PR_20' into VM_Changes
 - Merge branch 'master' into PR_20
 - Address review comments
 - Address review comments
 - Merge branch 'PR_20' into VM_Changes
 - Merge branch 'master' into PR_20
 - Address review comment
 - ... and 88 more: https://git.openjdk.org/jdk/compare/73baadce...c153ffff

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

Changes: https://git.openjdk.org/jdk/pull/11019/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11019&range=11
  Stats: 2909 lines in 73 files changed: 1974 ins; 318 del; 617 mod
  Patch: https://git.openjdk.org/jdk/pull/11019.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11019/head:pull/11019

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

From andrew at openjdk.org  Mon Dec  5 14:46:11 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Mon, 5 Dec 2022 14:46:11 GMT
Subject: RFR: 8297804: (tz) Update Timezone Data to 2022g
In-Reply-To: <2Izs6eygJONprQg5VmOp5atywmJqZgVJnccKqcjK918=.0184672c-fc38-4b4d-b3a8-71414eddeba7@github.com>
References: <4b1tG73Xp3BMUy2X6Ab7W2So7u4jcSu9SrAWvrHLw1g=.d6218261-7f4e-48c5-9989-eb0887e0207e@github.com>
 <2Izs6eygJONprQg5VmOp5atywmJqZgVJnccKqcjK918=.0184672c-fc38-4b4d-b3a8-71414eddeba7@github.com>
Message-ID: <r69Uj2Zj-LG6BFc5hhCc-e_-eSFgEHVOwQA_5DwCalc=.6efc12c0-2604-4bdd-943a-280f87b6b8e8@github.com>

On Fri, 2 Dec 2022 01:15:49 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> The following files need to be updated with the timezone data version. src/java.base/share/data/tzdata/VERSION test/jdk/java/util/TimeZone/TimeZoneData/VERSION

Good catch. I copied over the files from the tzdb bundle, but it seems they have `version` while we have `VERSION`. Fixed now.

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

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

From andrew at openjdk.org  Mon Dec  5 14:46:12 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Mon, 5 Dec 2022 14:46:12 GMT
Subject: RFR: 8297804: (tz) Update Timezone Data to 2022g
In-Reply-To: <0N9zRcGnG_U_tr8I9Qr2L9DM0Ex2qfztxbdVDDedgcU=.b9cd95e2-afce-4d3b-943c-2582e597c0a8@github.com>
References: <4b1tG73Xp3BMUy2X6Ab7W2So7u4jcSu9SrAWvrHLw1g=.d6218261-7f4e-48c5-9989-eb0887e0207e@github.com>
 <0N9zRcGnG_U_tr8I9Qr2L9DM0Ex2qfztxbdVDDedgcU=.b9cd95e2-afce-4d3b-943c-2582e597c0a8@github.com>
Message-ID: <JvUQUDPjxgrO350Ps2PyoowCMvEKy856M5xFqKB-338=.bb9b6367-0699-417e-afea-939b75cb512b@github.com>

On Sat, 3 Dec 2022 00:21:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi Andrew, Thanks for taking on this. I think you can cherry-pick the relevant [CLDR changes](https://github.com/unicode-org/cldr/commit/0bd22412b35b6e7037a39c3ad6a4dc49c699439b) (under `common` directory) into this PR so that backporting would be easier.

Good to see CLDR included them in good time. Now in this patch.

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

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

From jvernee at openjdk.org  Mon Dec  5 14:48:24 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 5 Dec 2022 14:48:24 GMT
Subject: RFR: 8296477: Foreign linker implementation update following JEP
 434 [v13]
In-Reply-To: <CGd4JSefJvfEVkZEfORzthEIeV53kLk_UkZHAhJGrQ0=.7741b5f2-2227-4017-8164-d54fb9d30d10@github.com>
References: <CGd4JSefJvfEVkZEfORzthEIeV53kLk_UkZHAhJGrQ0=.7741b5f2-2227-4017-8164-d54fb9d30d10@github.com>
Message-ID: <ZniTDJz6929Hav9i2kSTAeHLGTwk0sKAsEQ4esSSJx0=.6f2bf536-484a-44cb-b77d-86405c3853fd@github.com>

> Pull in linker implementation changes, that include non-trivial changes to VM code, from the panama-foreign repo into the main JDK.
> 
> This is split off from the main JEP integration to make reviewing easier.
> 
> This includes the following patches:
> 
> 1. https://github.com/openjdk/panama-foreign/pull/698
> 2. https://github.com/openjdk/panama-foreign/pull/699
> 3. (part of) https://github.com/openjdk/panama-foreign/pull/731
> 4. https://github.com/openjdk/panama-foreign/pull/740
> 5. https://github.com/openjdk/panama-foreign/pull/746
> 6. https://github.com/openjdk/panama-foreign/pull/742
> 7. https://github.com/openjdk/panama-foreign/pull/743
> 
> Probably the biggest change to the code comes from replacing `VMReg` - which can not represent offsets into the stack that are not a multiple of the VM's stack slot size (32-bits) - with the new `VMStorage` class, which can describe byte offsets into the stack, as well as having a register mask to indicate only certain register segments.
> 
> The only part of 3. that is in this PR is the part that turns the `VMStorage` class in Java into a record.
> 
> Please refer to the PR of each individual patch for a more detailed description.

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

  Remove spurious imports

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11019/files
  - new: https://git.openjdk.org/jdk/pull/11019/files/c153ffff..754faca2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11019&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11019&range=11-12

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

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

From jvernee at openjdk.org  Mon Dec  5 14:50:35 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 5 Dec 2022 14:50:35 GMT
Subject: Integrated: 8296477: Foreign linker implementation update following
 JEP 434
In-Reply-To: <CGd4JSefJvfEVkZEfORzthEIeV53kLk_UkZHAhJGrQ0=.7741b5f2-2227-4017-8164-d54fb9d30d10@github.com>
References: <CGd4JSefJvfEVkZEfORzthEIeV53kLk_UkZHAhJGrQ0=.7741b5f2-2227-4017-8164-d54fb9d30d10@github.com>
Message-ID: <rSP-4Lakd5GW9U6HJZH_0sB_KPaaAP-i6_qN8lgss34=.e92cd7f8-15e8-410a-97dd-e8472fdaaaee@github.com>

On Mon, 7 Nov 2022 14:34:45 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Pull in linker implementation changes, that include non-trivial changes to VM code, from the panama-foreign repo into the main JDK.
> 
> This is split off from the main JEP integration to make reviewing easier.
> 
> This includes the following patches:
> 
> 1. https://github.com/openjdk/panama-foreign/pull/698
> 2. https://github.com/openjdk/panama-foreign/pull/699
> 3. (part of) https://github.com/openjdk/panama-foreign/pull/731
> 4. https://github.com/openjdk/panama-foreign/pull/740
> 5. https://github.com/openjdk/panama-foreign/pull/746
> 6. https://github.com/openjdk/panama-foreign/pull/742
> 7. https://github.com/openjdk/panama-foreign/pull/743
> 
> Probably the biggest change to the code comes from replacing `VMReg` - which can not represent offsets into the stack that are not a multiple of the VM's stack slot size (32-bits) - with the new `VMStorage` class, which can describe byte offsets into the stack, as well as having a register mask to indicate only certain register segments.
> 
> The only part of 3. that is in this PR is the part that turns the `VMStorage` class in Java into a record.
> 
> Please refer to the PR of each individual patch for a more detailed description.

This pull request has now been integrated.

Changeset: 0452c39f
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0452c39fecb7fa4962b00868cb20a50e5f7ab1a7
Stats:     2904 lines in 72 files changed: 1969 ins; 318 del; 617 mod

8296477: Foreign linker implementation update following JEP 434

Co-authored-by: Jorn Vernee <jvernee at openjdk.org>
Co-authored-by: Nick Gasson <ngasson at openjdk.org>
Co-authored-by: Per Minborg <pminborg at openjdk.org>
Reviewed-by: rehn, mcimadamore, vlivanov

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

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

From jvernee at openjdk.org  Mon Dec  5 14:52:16 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 5 Dec 2022 14:52:16 GMT
Subject: RFR: 8297733: Refactor Cast binding to enum [v2]
In-Reply-To: <DnvjheImlV647tEMp8StEDKTGo9UEFsJEtbpTxj3fxs=.28ad9f39-de0f-4935-8710-319e64c2bb89@github.com>
References: <DnvjheImlV647tEMp8StEDKTGo9UEFsJEtbpTxj3fxs=.28ad9f39-de0f-4935-8710-319e64c2bb89@github.com>
Message-ID: <QkPyC7yFufwHhw4XUnIV1SQcJAgv8sfCj9vR1YwH3LY=.a6c8151b-17b2-41aa-9ce6-1d95b3b73969@github.com>

> Refactor the cast binding to an enum, which clearly enumerates all supported conversions.
> 
> This also fixes a bug where `java/foreign/normalize/TestNormalize` was failing when running in interpreted mode (`-Djdk.internal.foreign.DowncallLinker.USE_SPEC=false`), for conversions from `int` to `byte` because the `explicitCast` method handle that was used only considers the least significant bit, while we want to look at all of the least significant byte.
> 
> As mentioned in the JBS issue, doing this will also make it easier going forward to support multiple conversions with the same from and to types, but requiring different semantics.
> 
> Testing: jdk_foreign test suite.

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

 - Refactor cast operator to enum
 - 8296477: Foreign linker implementation update following JEP 434
   
   Co-authored-by: Jorn Vernee <jvernee at openjdk.org>
   Co-authored-by: Nick Gasson <ngasson at openjdk.org>
   Co-authored-by: Per Minborg <pminborg at openjdk.org>
   Reviewed-by: rehn, mcimadamore, vlivanov

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

Changes: https://git.openjdk.org/jdk/pull/11397/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11397&range=01
  Stats: 2986 lines in 74 files changed: 2025 ins; 332 del; 629 mod
  Patch: https://git.openjdk.org/jdk/pull/11397.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11397/head:pull/11397

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

From dnsimon at openjdk.org  Mon Dec  5 15:12:00 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 5 Dec 2022 15:12:00 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v3]
In-Reply-To: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
Message-ID: <4s8KhdEGfNlL4pFBC7oqVrXR0bqPp7eocJmd8i49YCo=.b937f324-8d14-4d0f-9bb1-36cf33a59f7b@github.com>

> Libgraal is compiled ahead of time and should not need any JVMCI Java code to be dynamically loaded at runtime. Prior to this PR, this is not the case due to:
> 
> * Code to copy system properties from the HotSpot heap into the libgraal heap. This is in `jdk.vm.ci.services.Services.initializeSavedProperties(byte[])` and `jdk.vm.ci.services.Services.serializeSavedProperties()`. This code should be moved to `java.base/jdk.internal.vm.VMSupport`.
> * Code to translate exceptions from the HotSpot heap into the libgraal heap and vice versa. This code should be moved from `jdk.internal.vm.ci//jdk.vm.ci.hotspot.TranslatedException` to `java.base/jdk.internal.vm.VMSupport`.
> 
> This PR makes the above changes. As a result, it's possible to build a JDK image that includes (and uses) libgraal but does not include `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces footprint and better isolates the JAVMCI and the Graal compiler as accessing these components from Java code is now impossible.

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

  share code to create the exploded path for a module and avoid stack-based variable length array

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11513/files
  - new: https://git.openjdk.org/jdk/pull/11513/files/3e89d402..7b147f2f

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

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

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

From alanb at openjdk.org  Mon Dec  5 15:23:24 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 5 Dec 2022 15:23:24 GMT
Subject: Integrated: 8297495: j.u.concurrent updates for JDK 20
In-Reply-To: <HcXqonjoH0jm8K5fXlfw8YsfyNBswTwFuPD7rtEr8FI=.22189b59-24bc-44bc-add1-9587ebe60518@github.com>
References: <HcXqonjoH0jm8K5fXlfw8YsfyNBswTwFuPD7rtEr8FI=.22189b59-24bc-44bc-add1-9587ebe60518@github.com>
Message-ID: <if9XlVrYsGoKHlqfo0glmNUSP82glSLHizvyaUB7wYY=.1e85e1eb-20b0-4896-a7ee-39f9cb11e268@github.com>

On Wed, 23 Nov 2022 12:40:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The proposed updates for JDK 20 are:
> 
> - ForkJoinPool.externalSubmit 
> - ForkJoinWorkerThread.getQueuedTaskCount 
> 
> These methods will be used to improve the Thread.yield implementation for virtual threads. The range of alternatives explored include not exposing an API and protected methods such as "offerSubmission". The class description speaks of "external clients" and "submissions from non-ForkJoinTask clients", hence the proposed naming and javadoc text.

This pull request has now been integrated.

Changeset: 19d84988
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/19d849884bd7a9718a5050b9709657f231a1ddbc
Stats:     276 lines in 4 files changed: 272 ins; 0 del; 4 mod

8297495: j.u.concurrent updates for JDK 20

Reviewed-by: jpai

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

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

From jvernee at openjdk.org  Mon Dec  5 15:32:40 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 5 Dec 2022 15:32:40 GMT
Subject: Integrated: 8297733: Refactor Cast binding to enum
In-Reply-To: <DnvjheImlV647tEMp8StEDKTGo9UEFsJEtbpTxj3fxs=.28ad9f39-de0f-4935-8710-319e64c2bb89@github.com>
References: <DnvjheImlV647tEMp8StEDKTGo9UEFsJEtbpTxj3fxs=.28ad9f39-de0f-4935-8710-319e64c2bb89@github.com>
Message-ID: <69XvceiJjD3JiJJ_NukV1kVI8aHusRFzlXqxh9vKzJQ=.c3f7c94c-1a28-4515-9564-798d42308505@github.com>

On Mon, 28 Nov 2022 20:13:35 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Refactor the cast binding to an enum, which clearly enumerates all supported conversions.
> 
> This also fixes a bug where `java/foreign/normalize/TestNormalize` was failing when running in interpreted mode (`-Djdk.internal.foreign.DowncallLinker.USE_SPEC=false`), for conversions from `int` to `byte` because the `explicitCast` method handle that was used only considers the least significant bit, while we want to look at all of the least significant byte.
> 
> As mentioned in the JBS issue, doing this will also make it easier going forward to support multiple conversions with the same from and to types, but requiring different semantics.
> 
> Testing: jdk_foreign test suite.

This pull request has now been integrated.

Changeset: a38c63da
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a38c63da5632fe727838ff1ed88d9601bf954801
Stats:     82 lines in 2 files changed: 56 ins; 14 del; 12 mod

8297733: Refactor Cast binding to enum

Reviewed-by: mcimadamore

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

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

From alanb at openjdk.org  Mon Dec  5 16:02:11 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 5 Dec 2022 16:02:11 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v2]
In-Reply-To: <y4lLPk5mDrJNa9vzgiI5WyEJmfbsSRfBBi0QQNdZeEs=.24e2a234-f42e-456f-82a0-3c7fd05dc9c5@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <WgaYQgGsrCaoiwDikHOB0em7NhpCugMEVevsNKByQrE=.3a67835a-633c-4b29-be22-bcb2fc2ba40a@github.com>
 <y4lLPk5mDrJNa9vzgiI5WyEJmfbsSRfBBi0QQNdZeEs=.24e2a234-f42e-456f-82a0-3c7fd05dc9c5@github.com>
Message-ID: <QYgHuAV90EyFwfNKauCVbQlKfWn9eBywsWGk57WrAgI=.21985534-6c5a-4bba-a35d-b727a6ae4ba4@github.com>

On Mon, 5 Dec 2022 13:53:07 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   generalized ClassLoader::has_jvmci_module to is_module_resolvable
>
> src/hotspot/share/classfile/classLoader.hpp line 378:
> 
>> 376: 
>> 377:   // Determines if the `module_name` module is resolvable.
>> 378:   static bool is_module_resolvable(const char* module_name);
> 
> Is "resolvable" the right concept here? Or should it be something like "findable" instead?

Assuming --limit-modules isn't used, it is testing if the module is "observable".

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

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

From errael at raelity.com  Mon Dec  5 17:11:00 2022
From: errael at raelity.com (Ernie Rael)
Date: Mon, 5 Dec 2022 09:11:00 -0800
Subject: CachedRowSet findColumn(string), getObject(string), ... should use
 label, not name
In-Reply-To: <74f1e7a3-9b84-c5e3-063e-bfdca6b384ef@raelity.com>
References: <e826438d-261b-5b7c-684b-b74aac0bb96c@raelity.com>
 <74f1e7a3-9b84-c5e3-063e-bfdca6b384ef@raelity.com>
Message-ID: <d8ed59ed-e79f-3144-e7a6-52f0e86c180c@raelity.com>

And to make the noise worse, I posted from the wrong account.

On 22/12/05 9:09 AM, Ernie Rael wrote:
> Apologies, accidentally hit send. Those links are notes. The 
> stackoverflow link is the best summary I've seen and references a bug 
> that can't be seen from the outside.
>
> I'm hoping to find a way to handle the situation from a database/swing 
> library so that any rowset can be accepted.
>
> Something in the metadata that distinguishes the problem or ...
>
> -ernie
>
> On 22/12/05 9:03 AM, Ernie Rael wrote:
>> Came across
>>
>> http://javadocs.mirthcorp.com/connect/3.0.2/user-api/com/mirth/connect/server/userutil/MirthCachedRowSet.html 
>>
>>
>> https://stackoverflow.com/questions/15184709/cachedrowsetimpl-getstring-based-on-column-label-throws-invalid-column-name 
>>
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7046875
>>
>


From dnsimon at openjdk.org  Mon Dec  5 17:21:18 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 5 Dec 2022 17:21:18 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v2]
In-Reply-To: <QYgHuAV90EyFwfNKauCVbQlKfWn9eBywsWGk57WrAgI=.21985534-6c5a-4bba-a35d-b727a6ae4ba4@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <WgaYQgGsrCaoiwDikHOB0em7NhpCugMEVevsNKByQrE=.3a67835a-633c-4b29-be22-bcb2fc2ba40a@github.com>
 <y4lLPk5mDrJNa9vzgiI5WyEJmfbsSRfBBi0QQNdZeEs=.24e2a234-f42e-456f-82a0-3c7fd05dc9c5@github.com>
 <QYgHuAV90EyFwfNKauCVbQlKfWn9eBywsWGk57WrAgI=.21985534-6c5a-4bba-a35d-b727a6ae4ba4@github.com>
Message-ID: <0olqajdnsOZJqQC5xBjXS3ckays3qNmgcYk4at6tsCc=.baeb2628-eee8-430c-a101-b93ad7a51e58@github.com>

On Mon, 5 Dec 2022 15:58:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/hotspot/share/classfile/classLoader.hpp line 378:
>> 
>>> 376: 
>>> 377:   // Determines if the `module_name` module is resolvable.
>>> 378:   static bool is_module_resolvable(const char* module_name);
>> 
>> Is "resolvable" the right concept here? Or should it be something like "findable" instead?
>
> Assuming --limit-modules isn't used, it is testing if the module is "observable".

I assume this function should therefore be named `is_module_observable`?

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

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

From dnsimon at openjdk.org  Mon Dec  5 17:33:50 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 5 Dec 2022 17:33:50 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v2]
In-Reply-To: <0olqajdnsOZJqQC5xBjXS3ckays3qNmgcYk4at6tsCc=.baeb2628-eee8-430c-a101-b93ad7a51e58@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <WgaYQgGsrCaoiwDikHOB0em7NhpCugMEVevsNKByQrE=.3a67835a-633c-4b29-be22-bcb2fc2ba40a@github.com>
 <y4lLPk5mDrJNa9vzgiI5WyEJmfbsSRfBBi0QQNdZeEs=.24e2a234-f42e-456f-82a0-3c7fd05dc9c5@github.com>
 <QYgHuAV90EyFwfNKauCVbQlKfWn9eBywsWGk57WrAgI=.21985534-6c5a-4bba-a35d-b727a6ae4ba4@github.com>
 <0olqajdnsOZJqQC5xBjXS3ckays3qNmgcYk4at6tsCc=.baeb2628-eee8-430c-a101-b93ad7a51e58@github.com>
Message-ID: <34Xd2rKs-dAQSCf2dNwwrTZ3uFmFjCYsqagEF3aE0Z8=.e689feb9-dc85-4d24-af4a-e43f46276eb0@github.com>

On Mon, 5 Dec 2022 17:17:16 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Assuming --limit-modules isn't used, it is testing if the module is "observable".
>
> I assume this function should therefore be named `is_module_observable`?

How about this:

// Determines if the named module is present in the
// modules jimage file or in the exploded modules directory.
static bool is_module_observable(const char* module_name);

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

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

From dnsimon at openjdk.org  Mon Dec  5 17:45:25 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 5 Dec 2022 17:45:25 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v4]
In-Reply-To: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
Message-ID: <nm5MBsIexi02WmVomf-rKb-xWg064Pqg9WMKxb18PBw=.9d5209a3-675e-4ee2-a4d5-05ff14934fb3@github.com>

> Libgraal is compiled ahead of time and should not need any JVMCI Java code to be dynamically loaded at runtime. Prior to this PR, this is not the case due to:
> 
> * Code to copy system properties from the HotSpot heap into the libgraal heap. This is in `jdk.vm.ci.services.Services.initializeSavedProperties(byte[])` and `jdk.vm.ci.services.Services.serializeSavedProperties()`. This code should be moved to `java.base/jdk.internal.vm.VMSupport`.
> * Code to translate exceptions from the HotSpot heap into the libgraal heap and vice versa. This code should be moved from `jdk.internal.vm.ci//jdk.vm.ci.hotspot.TranslatedException` to `java.base/jdk.internal.vm.VMSupport`.
> 
> This PR makes the above changes. As a result, it's possible to build a JDK image that includes (and uses) libgraal but does not include `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces footprint and better isolates the JAVMCI and the Graal compiler as accessing these components from Java code is now impossible.

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

  renamed is_module_resolvable to is_module_observable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11513/files
  - new: https://git.openjdk.org/jdk/pull/11513/files/7b147f2f..29e100b3

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

  Stats: 9 lines in 4 files changed: 1 ins; 4 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/11513.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11513/head:pull/11513

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

From naoto at openjdk.org  Mon Dec  5 18:26:17 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 5 Dec 2022 18:26:17 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v5]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <ynj7DlOjqZgdAGPXz_J-CMPBPLJk6jsLCLpPPYKlDKg=.906b2710-397c-4411-831a-783000cf70cf@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

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

  Addressing review comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/7c0740aa..00a0e3fc

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

  Stats: 57 lines in 5 files changed: 26 ins; 22 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/11421.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11421/head:pull/11421

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

From naoto at openjdk.org  Mon Dec  5 18:33:10 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 5 Dec 2022 18:33:10 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v6]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <i01UZeZ93eF1q8deXQp1wjxZ7O3smDi9ZdVIU6uSBwg=.413f8efc-b873-4f8b-962c-4b8a0ba6441d@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

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

  oleole -> ole

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/00a0e3fc..31656331

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

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

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

From jlaskey at openjdk.org  Mon Dec  5 19:10:40 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 5 Dec 2022 19:10:40 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v6]
In-Reply-To: <i01UZeZ93eF1q8deXQp1wjxZ7O3smDi9ZdVIU6uSBwg=.413f8efc-b873-4f8b-962c-4b8a0ba6441d@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <i01UZeZ93eF1q8deXQp1wjxZ7O3smDi9ZdVIU6uSBwg=.413f8efc-b873-4f8b-962c-4b8a0ba6441d@github.com>
Message-ID: <za2uEjGQFEz5J5OE0DGGh4CM8ReMsVWDEH1CP3tqn0Q=.ade0c382-0cba-4807-9590-ceae0ee59876@github.com>

On Mon, 5 Dec 2022 18:33:10 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   oleole -> ole

LGTM

src/java.base/share/classes/jdk/internal/access/JavaIOAccess.java line 26:

> 24:  */
> 25: 
> 26: package jdk.internal.access;

Update copyright

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

Marked as reviewed by jlaskey (Reviewer).

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

From bhuang at openjdk.org  Mon Dec  5 19:17:07 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Mon, 5 Dec 2022 19:17:07 GMT
Subject: RFR: JDK-8295859: Update Manual Test Groups [v2]
In-Reply-To: <bUsd4joncS3tnsUtEw4mGU-vaE0SArUNLvO86VaxALo=.abfd97fc-ce01-45d7-bcca-b929c1232f13@github.com>
References: <bUsd4joncS3tnsUtEw4mGU-vaE0SArUNLvO86VaxALo=.abfd97fc-ce01-45d7-bcca-b929c1232f13@github.com>
Message-ID: <GSwpSS6wq9z9BGYybt4T83e8Ov-JQtAkhaltBVWY3nQ=.d98c3dbf-9b9d-431a-a290-349525044b33@github.com>

> This task is created to add manual tests to the manual test groups.
> 
> In addition, fix is provided for TestMatrix.java#Downcall-F and TestMatrix.java#Downcall-T which are failing due to missing TestDowncall.java ([JDK-8287158](https://bugs.openjdk.org/browse/JDK-8287158)).

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

 - Merge branch 'master' into JDK-8295859
 - Updated Manual Test Groups

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10864/files
  - new: https://git.openjdk.org/jdk/pull/10864/files/ec9951c5..2c0bf381

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

  Stats: 151531 lines in 2242 files changed: 50384 ins; 83055 del; 18092 mod
  Patch: https://git.openjdk.org/jdk/pull/10864.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10864/head:pull/10864

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

From duke at openjdk.org  Mon Dec  5 19:50:15 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 5 Dec 2022 19:50:15 GMT
Subject: RFR: 8298045: Fix hidden but significant trailing whitespace in
 properties files for core-libs code
In-Reply-To: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>
References: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>
Message-ID: <H-oM4Aas2MEYORLUsUE03ay3ewD3OLnFeTly7dQSesw=.f385a1ac-22c4-4645-a04d-d9a219ea8082@github.com>

On Fri, 2 Dec 2022 16:40:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the core-libs team.

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties line 160:

> 158: xmlrch.errupdate = \u5EFA\u69CB\u66F4\u65B0\u5217\u6642\u767C\u751F\u932F\u8AA4: {0}
> 159: xmlrch.errupdrow = \u66F4\u65B0\u5217\u6642\u767C\u751F\u932F\u8AA4: {0}
> 160: xmlrch.chars = \u5B57\u5143:\u0020

Likely not needed, since the original and all other l10n versions of RowSetResourceBundle.properties do not have a trailing space for `xmlrch.chars`

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties line 24:

> 22: 
> 23:         BadMessageKey = The error message corresponding to the message key can not be found.
> 24:         FormatFailed = An internal error occurred while formatting the following message:\n\u0020\u0020

Likely a mistake, since as you stated, it is not in the format ?foo:\u0020? as there is a newline before the trailing spaces.

However if intentional it should probably be `FormatFailed = An internal error occurred while formatting the following message:\n\u0020`

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties line 139:

> 137:         EncodingByteOrderUnsupported = Given byte order for encoding \"{0}\" is not supported.
> 138:         InvalidByte = Invalid byte {0} of {1}-byte UTF-8 sequence.
> 139:         ExpectedByte = Expected byte {0} of {1}-byte UTF-8 sequence.\u0020\u0020

Same here as well, either a mistake or should be ` ExpectedByte = Expected byte {0} of {1}-byte UTF-8 sequence.\u0020`

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties line 219:

> 217:         MSG_NOTATION_NAME_REQUIRED_FOR_UNPARSED_ENTITYDECL = The notation name is required after \"NDATA\" in the declaration for the entity \"{0}\".
> 218:         EntityDeclUnterminated = The declaration for the entity \"{0}\" must end with ''>''.
> 219: 	MSG_DUPLICATE_ENTITY_DEFINITION = Entity \"{0}\" is declared more than once.\u0020\u0020\u0020\u0020\u0020\u0020\u0020\u0020

Likely not intentional, but if it is then perhaps `MSG_DUPLICATE_ENTITY_DEFINITION = Entity "{0}" is declared more than once.\u0009` instead.

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

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

From bpb at openjdk.org  Mon Dec  5 19:51:19 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 5 Dec 2022 19:51:19 GMT
Subject: RFR: JDK-8297298 - SequenceInputStream should override transferTo
 [v2]
In-Reply-To: <Ike0eQ9Ie59ga1NR7B1tECSMhPIjSKpXqdZCGUBtDL4=.761ef92f-260a-41ab-a483-aa2a2f6c9b69@github.com>
References: <f29hhy9J107mH2fJNTnIkR4u8JDXaHym8Mt_H9rwo8Y=.159e4f3e-e38f-496e-a6e2-65b3635bd897@github.com>
 <Ike0eQ9Ie59ga1NR7B1tECSMhPIjSKpXqdZCGUBtDL4=.761ef92f-260a-41ab-a483-aa2a2f6c9b69@github.com>
Message-ID: <F6eAl7jxzmSj577gvVp54QKB_udCemJL_mfyxh5iQMQ=.e599efa7-f0d1-49fc-ae90-55598f4f1bc3@github.com>

On Sun, 20 Nov 2022 09:41:47 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Since JDK 18 some implementations of InputStream.transferTo, namely FileInputStream and ChannelInputStream, offload work to lower layers using NIO channels. This provides shorter execution time and reduced resource consumption. Unfortunately, this effect is prevented once the input stream itself is wrapped by a SequenceInputStream. While compared to other InputStreams the SequenceInputStream is a rather edge case (e. g. used to merge two files into one), nevertheless it makes sense to get rid of this obstacle simply by implementing transferTo (e. g. by allowing to offload the file merge, or parts of the file merge, to the operating system). As a result, more existing applications will experience the offloading-improvements made by JDK 18.
>> 
>> To provide enhanced performance to existing applications, it makes sense to address this impediment: SequenceInputStream.transferTo should be implemented in a way that iteratively calls transferTo on each enumerated InputStream of the SequenceInputStream in ordered sequence.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed bug number

test/jdk/java/io/SequenceInputStream/TransferTo.java line 206:

> 204:     }
> 205: 
> 206: }

As auto-detected, there is no newline at the end of this file. Otherwise it appears all right.

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

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

From bhuang at openjdk.org  Mon Dec  5 19:52:18 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Mon, 5 Dec 2022 19:52:18 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v5]
In-Reply-To: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
Message-ID: <uw2kQJPBcg5iPyVZGL-BiSMkIK7S2htYcOyOTSi_1-w=.2b19fdf9-5978-4ded-b2e9-3d228c586fd6@github.com>

> This task converts 5 manual tests to automated tests.
> 
> sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java 
> sun/security/provider/PolicyParser/ExtDirsChange.java 
> sun/security/provider/PolicyParser/ExtDirs.java 
> java/security/Policy/Root/Root.javajava/security/Policy/Root/Root.java 
> javax/crypto/CryptoPermissions/InconsistentEntries.java

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

 - Merge branch 'master' into JDK-8295087
 - Added an extra line to the end of the policy file.
 - AssertThrows an exception in InconsistentEntries test.
 - Refactored to use testng framework for test enviroment setup.
 - Converted security manual tests to automated tests.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10637/files
  - new: https://git.openjdk.org/jdk/pull/10637/files/8b45f39f..32b656ca

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

  Stats: 297635 lines in 3764 files changed: 148190 ins; 96710 del; 52735 mod
  Patch: https://git.openjdk.org/jdk/pull/10637.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10637/head:pull/10637

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

From rriggs at openjdk.org  Mon Dec  5 19:52:20 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 5 Dec 2022 19:52:20 GMT
Subject: RFR: 8297271: AccessFlags should be specific to class file version
 [v2]
In-Reply-To: <T91R2VWcljZdnCDmWKcuSubKtS2qk5e5sGgKEi1v3Yk=.510cef48-e0f0-4590-b7d4-c16aafe71087@github.com>
References: <T91R2VWcljZdnCDmWKcuSubKtS2qk5e5sGgKEi1v3Yk=.510cef48-e0f0-4590-b7d4-c16aafe71087@github.com>
Message-ID: <GM-fUW61FhxC-eKiH54AZLHU_V_DVFntZomHK-4LrKo=.5eb42e6d-2df0-4030-a462-9c13f59234cf@github.com>

> The accessFlags() methods added (in JDK 20, the current release) to java.lang.Class, java.lang.reflect.Executable, and java.lang.reflect.Field implicitly uses the access flags from the current/most recent class file format version. For current and past class file format versions there are few significant variations but future changes are anticipated that change the meaning of some access flag mask bits.
> 
> The accessFlags() methods are clarified to return the access flags that are applicable to the class file format version of the class. The existing AccessFlag.Locations API already contains information about the locations that are applicable to a class file format version. That information should be used to construct the set of AccessFlags returned. A method is added to AccessFlag that returns the applicable flags for a particular mask, Location, and class file format version:

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

 - Updated the descriptions of AccessFlags being dependent on the class file version number.
   Removed unnecessary tests of ACC_SYNTHETIC, the class file format version
   tests for strictfp cover them sufficiently.
 - WIP: simplify

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11399/files
  - new: https://git.openjdk.org/jdk/pull/11399/files/8aeecfba..3be38680

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

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

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

From naoto at openjdk.org  Mon Dec  5 19:53:03 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 5 Dec 2022 19:53:03 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v4]
In-Reply-To: <hqHxUOYYwCX6hwRyijObfuLqEycrWhYQuNlk5i1ayV4=.76a1e3d1-fb08-4e89-a5d9-fe30b22e154b@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <01thVeD5joKRB8oex093EUINsuSrfs2HHXEL_MMEtJU=.83c39abd-0f31-4609-b7ed-731f3ed8f342@github.com>
 <hqHxUOYYwCX6hwRyijObfuLqEycrWhYQuNlk5i1ayV4=.76a1e3d1-fb08-4e89-a5d9-fe30b22e154b@github.com>
Message-ID: <RmT1uDPVJaVYkXuvqLhsNo2qMYrJ6INV5Q84sREuzp8=.23beb44f-4e94-499b-9e0f-f6b07d789558@github.com>

On Sun, 4 Dec 2022 17:09:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changed the expected behavior when the SecurityManager is enabled
>
> src/java.base/share/classes/java/io/Console.java line 627:
> 
>> 625:         });
>> 626:     }
>> 627:     private static Console cons;
> 
> The initialization of cons is replaced in this PR so maybe we can make it final at the same time.

Changed it to final

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

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

From naoto at openjdk.org  Mon Dec  5 19:52:59 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 5 Dec 2022 19:52:59 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

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

  Fixed the copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/31656331..8b6859ed

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

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

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

From jlaskey at openjdk.org  Mon Dec  5 20:07:45 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 5 Dec 2022 20:07:45 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
Message-ID: <UR7qa0ZKDOWbPDheSyV0-EdLU1f5RQn1eLUFbG-VWsQ=.b6701fd3-6968-4b9f-9506-0a866f095b1e@github.com>

On Mon, 5 Dec 2022 19:52:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the copyright year

Marked as reviewed by jlaskey (Reviewer).

Marked as reviewed by jlaskey (Reviewer).

LGTM

Marked as reviewed by jlaskey (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11421Marked as reviewed by jlaskey (Reviewer).

From naoto at openjdk.org  Mon Dec  5 20:40:05 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 5 Dec 2022 20:40:05 GMT
Subject: RFR: 8297804: (tz) Update Timezone Data to 2022g [v2]
In-Reply-To: <LUd0Rb4G80fdee18UQItifokHjI6FI31GBVTmDu5m_M=.0dfca816-dae6-4276-ab67-6de9bec62081@github.com>
References: <4b1tG73Xp3BMUy2X6Ab7W2So7u4jcSu9SrAWvrHLw1g=.d6218261-7f4e-48c5-9989-eb0887e0207e@github.com>
 <LUd0Rb4G80fdee18UQItifokHjI6FI31GBVTmDu5m_M=.0dfca816-dae6-4276-ab67-6de9bec62081@github.com>
Message-ID: <N7uA6nzmUYfTOesVLna5uFv_p8g9FwgryUyaOCEacis=.97212a2c-04e5-484e-b38c-e992c4b79ec1@github.com>

On Mon, 5 Dec 2022 14:38:51 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> Update to the latest tzdata, 2022g.
>> 
>> Primary changes:
>> * `America/Ojinaga` (CST) is split, creating `America/Ciudad_Juarez` (MST/MDT)
>> * `America/Pangnirtung` becomes a link to `America/Iqaluit`
>> * `America/Ojinaga` gains DST (CDT)
>> 
>> See bug for the full details.
>> 
>> There will likely also be CLDR changes ([CLDR-16181](https://unicode-org.atlassian.net/browse/CLDR-16181)) that are not yet included in this change. We can either wait for these and include them in this patch, or do a separate change like [JDK-8296715](https://bugs.openjdk.org/browse/JDK-8296715)
>> 
>> Tests in `java/util/TimeZone`, `java/time/test` and `sun/text/resources` all pass.
>
> Andrew John Hughes has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add CLDR changes from https://github.com/unicode-org/cldr/commit/0bd22412b35b6e7037a39c3ad6a4dc49c699439b
>  - Update tzdata version

Have you run tests under `sun.util.calendar`? Tests like `TestZoneInfo310.java` sometimes fail with tzdata updates.

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

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

From bhuang at openjdk.org  Mon Dec  5 20:42:05 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Mon, 5 Dec 2022 20:42:05 GMT
Subject: RFR: JDK-8295756 Improve NonLocalRegistry Manual Test Process [v7]
In-Reply-To: <zimo9_4V7yIIQ80Etwuvzqy7sRZvsJw5zbaeYv6J8gM=.67e06cf4-0f42-4f2c-9081-9fd5461b7b12@github.com>
References: <zimo9_4V7yIIQ80Etwuvzqy7sRZvsJw5zbaeYv6J8gM=.67e06cf4-0f42-4f2c-9081-9fd5461b7b12@github.com>
Message-ID: <RvvBp3vQGu4sgtynhdd6yVveHE3xUf47MJrZwZWSCOQ=.787f2f91-fab5-4ec9-b66a-9b9098a56f90@github.com>

> The current non local registry tests require a manual process that runs rmiregitrty on a different machine and changes the -Dregistry.host property in the source before running the tests on the local machine. This task is created to improve this manual process and provide a clearer instruction to the test engineer about the test requirement. 
> 
> Tests include: 
> java/rmi/registry/nonLocalRegistry/NonLocalSkeletonTest.java 
> java/rmi/registry/nonLocalRegistry/NonLocalRegistryTest.java 
> javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.java

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

  Reduced host input timeout to 20 minutes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10825/files
  - new: https://git.openjdk.org/jdk/pull/10825/files/3ae1f797..c5648165

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

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

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

From rriggs at openjdk.org  Mon Dec  5 20:52:20 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 5 Dec 2022 20:52:20 GMT
Subject: RFR: 8298033: Character.codePointAt(char[], int,
 int) doesn't do JavaDoc-specified check [v3]
In-Reply-To: <ovN5eECaqGNK191GaW0IDDPglrMXrFJhxFjSE2dYZWo=.d1a6b387-7a90-41b2-935c-1c513048945b@github.com>
References: <dHjviGmASssYfntfClzDC28Ppjrn3pECnO3HzbZHopY=.d9923de3-6de7-41f5-a84e-03a7c5267e2f@github.com>
 <4UxZnSr4yjQQIAFOP_Lm1n-lqQ0m1zQAp-knX42Cy-k=.124fabe0-7cf8-4f19-bdcc-234d2f2e4796@github.com>
 <YRjjKiUbkB6uXnAYMUEZxMzAztfl_KlnGxiXu1Np-Is=.5e4dadba-5886-4e46-8b81-5fa129b343f6@github.com>
 <obzX6gFjzBXHa4fwPcSW80GWANmJoVx-XXQ12wn9jQA=.6595ab56-a390-4197-974c-9399f7fdd4c2@github.com>
 <ovN5eECaqGNK191GaW0IDDPglrMXrFJhxFjSE2dYZWo=.d1a6b387-7a90-41b2-935c-1c513048945b@github.com>
Message-ID: <Rj5XT4NoROKxyFzULa7PFt10Jc1tN_sENRLMA1BAwXg=.1585117b-6ef1-4214-9539-2bd6c656e251@github.com>

On Mon, 5 Dec 2022 13:22:36 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Yeah, this AIOOBE is exactly the reason why I added this. So should we modify `codePointBefore` in the same way as `codePointAt`?
>
> I'm asking because counter-intuitively `codePointBefore ` doesn't specify IOOBE for negative `index`.
> 
> /**
>  * @return the Unicode code point value before the given index.
>  * @throws NullPointerException if {@code a} is null.
>  * @throws IndexOutOfBoundsException if the {@code index}
>  * argument is not greater than the {@code start} argument or
>  * is greater than the length of the {@code char} array, or
>  * if the {@code start} argument is negative or not less than
>  * the length of the {@code char} array.
>  * @since  1.5
>  */
>  ```

The corresponding test case for `codePointBefore` is:

        callCodePoint(Before, a, a.length+1, a.length-1, IndexOutOfBoundsException.class);

The implementation is checking that `start` does not exceed the length but it should be checking that `index` does not exceed the length.

Since `start` must be non-negative and `index` must be greater than `start, it follows that `index` must non-negative and then checked against the length.

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

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

From bhuang at openjdk.org  Mon Dec  5 21:23:00 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Mon, 5 Dec 2022 21:23:00 GMT
Subject: RFR: JDK-8295859: Update Manual Test Groups [v3]
In-Reply-To: <bUsd4joncS3tnsUtEw4mGU-vaE0SArUNLvO86VaxALo=.abfd97fc-ce01-45d7-bcca-b929c1232f13@github.com>
References: <bUsd4joncS3tnsUtEw4mGU-vaE0SArUNLvO86VaxALo=.abfd97fc-ce01-45d7-bcca-b929c1232f13@github.com>
Message-ID: <bZuqjiR59JSP02PEPOLzNR0Rle6QfcJdV_nSUwiLKF8=.20729a43-56c8-42a2-91c6-679191c89ec7@github.com>

> This task is created to add manual tests to the manual test groups.
> 
> In addition, fix is provided for TestMatrix.java#Downcall-F and TestMatrix.java#Downcall-T which are failing due to missing TestDowncall.java ([JDK-8287158](https://bugs.openjdk.org/browse/JDK-8287158)).

Bill Huang 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 master
 - Merge branch 'master' into JDK-8295859
 - Updated Manual Test Groups

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

Changes: https://git.openjdk.org/jdk/pull/10864/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10864&range=02
  Stats: 14 lines in 1 file changed: 13 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10864.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10864/head:pull/10864

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

From duke at openjdk.org  Mon Dec  5 21:38:20 2022
From: duke at openjdk.org (Oliver Kopp)
Date: Mon, 5 Dec 2022 21:38:20 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v6]
In-Reply-To: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
References: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
Message-ID: <Ouly-NyXJMLpyNiBnUNkO0Zhus8EZc3S03_PsCP40vk=.47c03775-acc8-4aa4-a09d-75e9337f915e@github.com>

> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image".
> 
> Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods

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

  Refine test
  
  Co-authored-by: Christoph <siedlerkiller at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10704/files
  - new: https://git.openjdk.org/jdk/pull/10704/files/8e94741a..16fa5292

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

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

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

From darcy at openjdk.org  Mon Dec  5 21:45:24 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 5 Dec 2022 21:45:24 GMT
Subject: RFR: 8297271: AccessFlags should be specific to class file version
 [v2]
In-Reply-To: <GM-fUW61FhxC-eKiH54AZLHU_V_DVFntZomHK-4LrKo=.5eb42e6d-2df0-4030-a462-9c13f59234cf@github.com>
References: <T91R2VWcljZdnCDmWKcuSubKtS2qk5e5sGgKEi1v3Yk=.510cef48-e0f0-4590-b7d4-c16aafe71087@github.com>
 <GM-fUW61FhxC-eKiH54AZLHU_V_DVFntZomHK-4LrKo=.5eb42e6d-2df0-4030-a462-9c13f59234cf@github.com>
Message-ID: <ss4Jjd_Vf8-JXpZ3uOXCi8dp2TfanzHW8ySGAggWBFU=.3122ea56-e9eb-4c1c-ba67-d1241c499dd4@github.com>

On Mon, 5 Dec 2022 19:52:20 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The accessFlags() methods added (in JDK 20, the current release) to java.lang.Class, java.lang.reflect.Executable, and java.lang.reflect.Field implicitly uses the access flags from the current/most recent class file format version. For current and past class file format versions there are few significant variations but future changes are anticipated that change the meaning of some access flag mask bits.
>> 
>> The accessFlags() methods are clarified to return the access flags that are applicable to the class file format version of the class. The existing AccessFlag.Locations API already contains information about the locations that are applicable to a class file format version. That information should be used to construct the set of AccessFlags returned. A method is added to AccessFlag that returns the applicable flags for a particular mask, Location, and class file format version:
>
> Roger Riggs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Updated the descriptions of AccessFlags being dependent on the class file version number.
>    Removed unnecessary tests of ACC_SYNTHETIC, the class file format version
>    tests for strictfp cover them sufficiently.
>  - WIP: simplify

src/java.base/share/classes/java/lang/Class.java line 1345:

> 1343:      * <li> its {@code INTERFACE} flag is absent, even when the
> 1344:      *      component type is an interface
> 1345:      * <li> its class file format version is that of the component class

Please remove this requirement.

First, I'm not sure if it is true of the implementation. Even if it were true today, I don't think it is necessary to guarantee this as the class file format version is not directly retrievable by end-users (nor do I think it should be).

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

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

From darcy at openjdk.org  Mon Dec  5 21:51:24 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 5 Dec 2022 21:51:24 GMT
Subject: RFR: 8297271: AccessFlags should be specific to class file version
 [v2]
In-Reply-To: <GM-fUW61FhxC-eKiH54AZLHU_V_DVFntZomHK-4LrKo=.5eb42e6d-2df0-4030-a462-9c13f59234cf@github.com>
References: <T91R2VWcljZdnCDmWKcuSubKtS2qk5e5sGgKEi1v3Yk=.510cef48-e0f0-4590-b7d4-c16aafe71087@github.com>
 <GM-fUW61FhxC-eKiH54AZLHU_V_DVFntZomHK-4LrKo=.5eb42e6d-2df0-4030-a462-9c13f59234cf@github.com>
Message-ID: <vRsNbQt2rIPfcBAnT5uVPGJnFdvkBEk7OumsHZZ4Ius=.a3384cef-6ae2-4e1e-95c8-e491773b6300@github.com>

On Mon, 5 Dec 2022 19:52:20 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The accessFlags() methods added (in JDK 20, the current release) to java.lang.Class, java.lang.reflect.Executable, and java.lang.reflect.Field implicitly uses the access flags from the current/most recent class file format version. For current and past class file format versions there are few significant variations but future changes are anticipated that change the meaning of some access flag mask bits.
>> 
>> The accessFlags() methods are clarified to return the access flags that are applicable to the class file format version of the class. The existing AccessFlag.Locations API already contains information about the locations that are applicable to a class file format version. That information should be used to construct the set of AccessFlags returned. A method is added to AccessFlag that returns the applicable flags for a particular mask, Location, and class file format version:
>
> Roger Riggs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Updated the descriptions of AccessFlags being dependent on the class file version number.
>    Removed unnecessary tests of ACC_SYNTHETIC, the class file format version
>    tests for strictfp cover them sufficiently.
>  - WIP: simplify

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 519:

> 517:      * @param cffv the class file format version
> 518:      */
> 519:     public static Set<AccessFlag> maskToAccessFlags(int mask, Location location,

The difference in exception handling behavior compared to the method w/o a ClassFileFormatVersion argument should at least be discussed.

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

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

From asemenyuk at openjdk.org  Mon Dec  5 22:32:37 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 5 Dec 2022 22:32:37 GMT
Subject: RFR: 8296489: tools/jpackage/windows/WinL10nTest.java fails with
 timeout
Message-ID: <k_OYY4Lu5qiQUPgtd-1NbkY6ypJ1qR-974RJTPM0B58=.d70ec2ce-1332-4ced-8755-b0023be543cb@github.com>

Simply increase timeout limit to make test pass on slower/loaded hosts

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

Commit messages:
 - 8296489: tools/jpackage/windows/WinL10nTest.java fails with timeout

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

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

From asemenyuk at openjdk.org  Mon Dec  5 22:33:09 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 5 Dec 2022 22:33:09 GMT
Subject: RFR: 8293453: tools/jpackage/share/AddLShortcutTest.java
 "Failed: Check the number of mismatched pixels [1024] of [1024] is <
 [0.100000] threshold"
Message-ID: <qwmSE9xWH4cU-DsvNGC96vuxAe0DN6xmZZz_B1GKubg=.0ffea997-13cf-4ca1-803d-f1bb86a0f1b2@github.com>

- throw an exception if icon swap fails with the corresponding l10n message;
- add retries to the jpackage test routine that extracts an icon from a launcher

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

Commit messages:
 - 8293453: tools/jpackage/share/AddLShortcutTest.java "Failed: Check the number of mismatched pixels [1024] of [1024] is < [0.100000] threshold"

Changes: https://git.openjdk.org/jdk/pull/11521/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11521&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293453
  Stats: 45 lines in 6 files changed: 34 ins; 2 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/11521.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11521/head:pull/11521

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

From almatvee at openjdk.org  Mon Dec  5 22:48:32 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 5 Dec 2022 22:48:32 GMT
Subject: RFR: 8296489: tools/jpackage/windows/WinL10nTest.java fails with
 timeout
In-Reply-To: <k_OYY4Lu5qiQUPgtd-1NbkY6ypJ1qR-974RJTPM0B58=.d70ec2ce-1332-4ced-8755-b0023be543cb@github.com>
References: <k_OYY4Lu5qiQUPgtd-1NbkY6ypJ1qR-974RJTPM0B58=.d70ec2ce-1332-4ced-8755-b0023be543cb@github.com>
Message-ID: <yCob6tWCLgt90l8Z4thNqIjwl0aP0Mxq0URBQgzeLw8=.6062e1f7-3890-40f2-88c4-0457c0bc5519@github.com>

On Mon, 5 Dec 2022 22:20:19 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Simply increase timeout limit to make test pass on slower/loaded hosts

Marked as reviewed by almatvee (Reviewer).

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

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

From almatvee at openjdk.org  Mon Dec  5 22:59:39 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 5 Dec 2022 22:59:39 GMT
Subject: RFR: 8293453: tools/jpackage/share/AddLShortcutTest.java
 "Failed: Check the number of mismatched pixels [1024] of [1024] is <
 [0.100000] threshold"
In-Reply-To: <qwmSE9xWH4cU-DsvNGC96vuxAe0DN6xmZZz_B1GKubg=.0ffea997-13cf-4ca1-803d-f1bb86a0f1b2@github.com>
References: <qwmSE9xWH4cU-DsvNGC96vuxAe0DN6xmZZz_B1GKubg=.0ffea997-13cf-4ca1-803d-f1bb86a0f1b2@github.com>
Message-ID: <wbrcklyJA_nhLLDAWUSEMJ29xVT9t-j3SdsiaKaJrKA=.5391f578-380b-4f74-ac2d-a479a97077f8@github.com>

On Mon, 5 Dec 2022 22:14:50 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - throw an exception if icon swap fails with the corresponding l10n message;
> - add retries to the jpackage test routine that extracts an icon from a launcher

Marked as reviewed by almatvee (Reviewer).

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

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

From rriggs at openjdk.org  Mon Dec  5 23:12:25 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 5 Dec 2022 23:12:25 GMT
Subject: RFR: 8297271: AccessFlags should be specific to class file version
 [v2]
In-Reply-To: <ss4Jjd_Vf8-JXpZ3uOXCi8dp2TfanzHW8ySGAggWBFU=.3122ea56-e9eb-4c1c-ba67-d1241c499dd4@github.com>
References: <T91R2VWcljZdnCDmWKcuSubKtS2qk5e5sGgKEi1v3Yk=.510cef48-e0f0-4590-b7d4-c16aafe71087@github.com>
 <GM-fUW61FhxC-eKiH54AZLHU_V_DVFntZomHK-4LrKo=.5eb42e6d-2df0-4030-a462-9c13f59234cf@github.com>
 <ss4Jjd_Vf8-JXpZ3uOXCi8dp2TfanzHW8ySGAggWBFU=.3122ea56-e9eb-4c1c-ba67-d1241c499dd4@github.com>
Message-ID: <VQCuEjdSATmCSlJ226dBlIsnBAs-Kv8WAX0vNfIWSvk=.414e6cb5-71b6-43c0-8ac8-430326b9ff60@github.com>

On Mon, 5 Dec 2022 21:43:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Updated the descriptions of AccessFlags being dependent on the class file version number.
>>    Removed unnecessary tests of ACC_SYNTHETIC, the class file format version
>>    tests for strictfp cover them sufficiently.
>>  - WIP: simplify
>
> src/java.base/share/classes/java/lang/Class.java line 1345:
> 
>> 1343:      * <li> its {@code INTERFACE} flag is absent, even when the
>> 1344:      *      component type is an interface
>> 1345:      * <li> its class file format version is that of the component class
> 
> Please remove this requirement.
> 
> First, I'm not sure if it is true of the implementation. Even if it were true today, I don't think it is necessary to guarantee this as the class file format version is not directly retrievable by end-users (nor do I think it should be).

For arrays, the implementation does use the cffv of the element type and it is a natural extension of the description of Class.accessFlags() using some of the modifiers (public, protected, and private) of the component type (as written a couple of lines above).  But it may be a bit of overreach to say that its appropriate for other modifiers of an array to have the same behavior.

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

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

From rriggs at openjdk.org  Mon Dec  5 23:35:27 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 5 Dec 2022 23:35:27 GMT
Subject: RFR: 8297271: AccessFlags should be specific to class file version
 [v2]
In-Reply-To: <vRsNbQt2rIPfcBAnT5uVPGJnFdvkBEk7OumsHZZ4Ius=.a3384cef-6ae2-4e1e-95c8-e491773b6300@github.com>
References: <T91R2VWcljZdnCDmWKcuSubKtS2qk5e5sGgKEi1v3Yk=.510cef48-e0f0-4590-b7d4-c16aafe71087@github.com>
 <GM-fUW61FhxC-eKiH54AZLHU_V_DVFntZomHK-4LrKo=.5eb42e6d-2df0-4030-a462-9c13f59234cf@github.com>
 <vRsNbQt2rIPfcBAnT5uVPGJnFdvkBEk7OumsHZZ4Ius=.a3384cef-6ae2-4e1e-95c8-e491773b6300@github.com>
Message-ID: <rz_WZRrsb7a4GS0mtKJ_wSlBkOqlp17_MaqD9myJXco=.93b5b84c-f626-45f6-ab34-8506b42a2f92@github.com>

On Mon, 5 Dec 2022 21:47:29 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Updated the descriptions of AccessFlags being dependent on the class file version number.
>>    Removed unnecessary tests of ACC_SYNTHETIC, the class file format version
>>    tests for strictfp cover them sufficiently.
>>  - WIP: simplify
>
> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 519:
> 
>> 517:      * @param cffv the class file format version
>> 518:      */
>> 519:     public static Set<AccessFlag> maskToAccessFlags(int mask, Location location,
> 
> The difference in exception handling behavior compared to the method w/o a ClassFileFormatVersion argument should at least be discussed.

I would propose to say:
     
    Mask bits that do not match an {@code AccessFlag} for the location and 
    class file format version are ignored.

The case arises when the mask argument contains mask bits that are not consistent with the locations defined for any AccessFlag.
The current method throws IllegalArgumentException, while the added method returns a set of AccessFlags appropriate to the location and cffv and ignores the undefined mask bits.

If the source of the error/inconsistency is an application developer calling `maskToAccessFlags()` then IAE makes sense.
However, it would puzzling if a call to Class.accessFlags() threw IllegalArgumentException; in that case the mask bits are those of a loaded class, presumed to be conforming to the spec, but none the less having unexpected mask bits.
Such an recurrence is likely very rare but might be the result of a class file created by some means other than the javac compiler. The declaration of each AccessFlag implements the location and cffv information and corresponding mask bits according the JVM spec. If the VM loads the class, then the question is whether the inconsistency should be reported and if so how.

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

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

From asemenyuk at openjdk.org  Tue Dec  6 00:17:44 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 6 Dec 2022 00:17:44 GMT
Subject: Integrated: 8293453: tools/jpackage/share/AddLShortcutTest.java
 "Failed: Check the number of mismatched pixels [1024] of [1024] is <
 [0.100000] threshold"
In-Reply-To: <qwmSE9xWH4cU-DsvNGC96vuxAe0DN6xmZZz_B1GKubg=.0ffea997-13cf-4ca1-803d-f1bb86a0f1b2@github.com>
References: <qwmSE9xWH4cU-DsvNGC96vuxAe0DN6xmZZz_B1GKubg=.0ffea997-13cf-4ca1-803d-f1bb86a0f1b2@github.com>
Message-ID: <lZYM3y5B6xxUmwvetO_ROsQ3qqez7Kn-BdIcKrPrLzQ=.35addbfd-f375-447a-a024-a478bfc59425@github.com>

On Mon, 5 Dec 2022 22:14:50 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - throw an exception if icon swap fails with the corresponding l10n message;
> - add retries to the jpackage test routine that extracts an icon from a launcher

This pull request has now been integrated.

Changeset: 884b9ade
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/884b9ade41c9803076f55f44cd5efd3530e92ab2
Stats:     45 lines in 6 files changed: 34 ins; 2 del; 9 mod

8293453: tools/jpackage/share/AddLShortcutTest.java "Failed: Check the number of mismatched pixels [1024] of [1024] is < [0.100000] threshold"

Reviewed-by: almatvee

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

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

From asemenyuk at openjdk.org  Tue Dec  6 00:18:44 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 6 Dec 2022 00:18:44 GMT
Subject: Integrated: 8296489: tools/jpackage/windows/WinL10nTest.java fails
 with timeout
In-Reply-To: <k_OYY4Lu5qiQUPgtd-1NbkY6ypJ1qR-974RJTPM0B58=.d70ec2ce-1332-4ced-8755-b0023be543cb@github.com>
References: <k_OYY4Lu5qiQUPgtd-1NbkY6ypJ1qR-974RJTPM0B58=.d70ec2ce-1332-4ced-8755-b0023be543cb@github.com>
Message-ID: <g816v60mbBKFSYEUH94l-91Q6E0635jdXY2IdPGse4E=.ca801346-04e2-41d1-b87e-fa25faed5b3c@github.com>

On Mon, 5 Dec 2022 22:20:19 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Simply increase timeout limit to make test pass on slower/loaded hosts

This pull request has now been integrated.

Changeset: 8d8a28ff
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8d8a28ffcbd974bb1a5389839a7e3046a232f85d
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8296489: tools/jpackage/windows/WinL10nTest.java fails with timeout

Reviewed-by: almatvee

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

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

From andrew at openjdk.org  Tue Dec  6 01:53:07 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Tue, 6 Dec 2022 01:53:07 GMT
Subject: RFR: 8297804: (tz) Update Timezone Data to 2022g [v2]
In-Reply-To: <N7uA6nzmUYfTOesVLna5uFv_p8g9FwgryUyaOCEacis=.97212a2c-04e5-484e-b38c-e992c4b79ec1@github.com>
References: <4b1tG73Xp3BMUy2X6Ab7W2So7u4jcSu9SrAWvrHLw1g=.d6218261-7f4e-48c5-9989-eb0887e0207e@github.com>
 <LUd0Rb4G80fdee18UQItifokHjI6FI31GBVTmDu5m_M=.0dfca816-dae6-4276-ab67-6de9bec62081@github.com>
 <N7uA6nzmUYfTOesVLna5uFv_p8g9FwgryUyaOCEacis=.97212a2c-04e5-484e-b38c-e992c4b79ec1@github.com>
Message-ID: <VGqJTczk37rsxgaaHnhvbFiXeDgy_WnIHAqMTHWJnY4=.6cafbd20-b403-43f9-9667-ff11741cb4a0@github.com>

On Mon, 5 Dec 2022 20:37:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Have you run tests under `sun.util.calendar`? Tests like `TestZoneInfo310.java` sometimes fail with tzdata updates.

Yes

~~~
Passed: sun/util/calendar/zi/Beyond2037.java
Passed: sun/util/calendar/zi/TestZoneInfo310.java
Passed: sun/util/calendar/Bug6653944.java
Passed: sun/util/calendar/Bug8176160.java
Passed: sun/util/calendar/CalendarSystemDeadLockTest.java
~~~

`sun/util` and `java/util` are also in `jdk_util_other` which is covered by `tier1_part2` in the PR checks: https://github.com/gnu-andrew/jdk/actions/runs/3621042294/jobs/6104922328#step:9:5925

Only `java.time` and `sun.text` are not covered by the PR (`tier2_part2`)

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

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

From darcy at openjdk.org  Tue Dec  6 02:25:01 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 6 Dec 2022 02:25:01 GMT
Subject: RFR: 8297271: AccessFlags should be specific to class file version
 [v2]
In-Reply-To: <VQCuEjdSATmCSlJ226dBlIsnBAs-Kv8WAX0vNfIWSvk=.414e6cb5-71b6-43c0-8ac8-430326b9ff60@github.com>
References: <T91R2VWcljZdnCDmWKcuSubKtS2qk5e5sGgKEi1v3Yk=.510cef48-e0f0-4590-b7d4-c16aafe71087@github.com>
 <GM-fUW61FhxC-eKiH54AZLHU_V_DVFntZomHK-4LrKo=.5eb42e6d-2df0-4030-a462-9c13f59234cf@github.com>
 <ss4Jjd_Vf8-JXpZ3uOXCi8dp2TfanzHW8ySGAggWBFU=.3122ea56-e9eb-4c1c-ba67-d1241c499dd4@github.com>
 <VQCuEjdSATmCSlJ226dBlIsnBAs-Kv8WAX0vNfIWSvk=.414e6cb5-71b6-43c0-8ac8-430326b9ff60@github.com>
Message-ID: <ew5dPuxiBxC5zxyPP8OKYzk_4eF8XBX5L5E96S2k9ns=.f185f4b8-d81f-48b3-929c-1394cc4c6cca@github.com>

On Mon, 5 Dec 2022 23:10:20 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Class.java line 1345:
>> 
>>> 1343:      * <li> its {@code INTERFACE} flag is absent, even when the
>>> 1344:      *      component type is an interface
>>> 1345:      * <li> its class file format version is that of the component class
>> 
>> Please remove this requirement.
>> 
>> First, I'm not sure if it is true of the implementation. Even if it were true today, I don't think it is necessary to guarantee this as the class file format version is not directly retrievable by end-users (nor do I think it should be).
>
> For arrays, the implementation does use the cffv of the element type and it is a natural extension of the description of Class.accessFlags() using some of the modifiers (public, protected, and private) of the component type (as written a couple of lines above).  But it may be a bit of overreach to say that its appropriate for other modifiers of an array to have the same behavior.

For the purposes at hand of specifying the access flags as dependent on the class file format version, if the access flags are already completely specified, there is no need to mention a possible dependence on the class file format version, especially give the spec from a few lines down:

* For {@code Class} objects representing void, primitive types, and 
* arrays, access flags are absent other than as specified above.

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

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

From darcy at openjdk.org  Tue Dec  6 03:36:00 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 6 Dec 2022 03:36:00 GMT
Subject: RFR: 8297271: AccessFlags should be specific to class file version
 [v2]
In-Reply-To: <rz_WZRrsb7a4GS0mtKJ_wSlBkOqlp17_MaqD9myJXco=.93b5b84c-f626-45f6-ab34-8506b42a2f92@github.com>
References: <T91R2VWcljZdnCDmWKcuSubKtS2qk5e5sGgKEi1v3Yk=.510cef48-e0f0-4590-b7d4-c16aafe71087@github.com>
 <GM-fUW61FhxC-eKiH54AZLHU_V_DVFntZomHK-4LrKo=.5eb42e6d-2df0-4030-a462-9c13f59234cf@github.com>
 <vRsNbQt2rIPfcBAnT5uVPGJnFdvkBEk7OumsHZZ4Ius=.a3384cef-6ae2-4e1e-95c8-e491773b6300@github.com>
 <rz_WZRrsb7a4GS0mtKJ_wSlBkOqlp17_MaqD9myJXco=.93b5b84c-f626-45f6-ab34-8506b42a2f92@github.com>
Message-ID: <XdUUD-XugxmR9m9vdsmlLGNvkZJ9IymbtyvBcWO_Kr0=.90f077aa-6edc-442d-b5ad-1e2a88e80c35@github.com>

On Mon, 5 Dec 2022 23:33:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 519:
>> 
>>> 517:      * @param cffv the class file format version
>>> 518:      */
>>> 519:     public static Set<AccessFlag> maskToAccessFlags(int mask, Location location,
>> 
>> The difference in exception handling behavior compared to the method w/o a ClassFileFormatVersion argument should at least be discussed.
>
> I would propose to say:
>      
>     Mask bits that do not match an {@code AccessFlag} for the location and 
>     class file format version are ignored.
> 
> The case arises when the mask argument contains mask bits that are not consistent with the locations defined for any AccessFlag.
> The current method throws IllegalArgumentException, while the added method returns a set of AccessFlags appropriate to the location and cffv and ignores the undefined mask bits.
> 
> If the source of the error/inconsistency is an application developer calling `maskToAccessFlags()` then IAE makes sense.
> However, it would puzzling if a call to Class.accessFlags() threw IllegalArgumentException; in that case the mask bits are those of a loaded class, presumed to be conforming to the spec, but none the less having unexpected mask bits.
> Such an recurrence is likely very rare but might be the result of a class file created by some means other than the javac compiler. The declaration of each AccessFlag implements the location and cffv information and corresponding mask bits according the JVM spec. If the VM loads the class, then the question is whether the inconsistency should be reported and if so how.

>From an end-user perspective, "the system" should screen out or otherwise take care of undefined/inappropriate modifier bits and access flags in loaded class files.

In the JDK implementation, there is a separation between the HotSpot JVM and the class libraries, in this case core reflection. One could argue -- and as a maintainer of the core reflection libraries I would argue -- that HotSpot should screen out undefined/inappropriate access flag bits before presenting them to the user. If that is not done, with the non-public method to return the class file format version of the class file, the Java libraries side of core reflection has enough information to do such screening on its own. (IIRC, from some off-list discussions @RogerRiggs ran into cases where a hand-crafted class file could have the ACC_SYNTHETIC flag set on a class for a version of the class file format where ACC_SYNTHETIC wasn't defined. This flag was passed from HotSpot to the core libraries, running afoul of the stricter checking on the existing maskToAccessFlags method.)

There are class file / byte code processing APIs where showing all the access flag bits, even when not defined for a class file versions, is the right answer. However, I don't think core reflection is one of those APIs. In the spirit of JVMS "4.1. The ClassFile Structure":

"All bits of the access_flags item not assigned in [Table 4.1-B](https://docs.oracle.com/javase/specs/jvms/se19/html/jvms-4.html#jvms-4.1-200-E.1) are reserved for future use. They should be set to zero in generated class files and should be ignored by Java Virtual Machine implementations."

I think it would be reasonable to mask out undefined bits either in HotSpot or the core reflection libraries.

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

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

From dholmes at openjdk.org  Tue Dec  6 06:04:08 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 6 Dec 2022 06:04:08 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v4]
In-Reply-To: <nm5MBsIexi02WmVomf-rKb-xWg064Pqg9WMKxb18PBw=.9d5209a3-675e-4ee2-a4d5-05ff14934fb3@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <nm5MBsIexi02WmVomf-rKb-xWg064Pqg9WMKxb18PBw=.9d5209a3-675e-4ee2-a4d5-05ff14934fb3@github.com>
Message-ID: <l12fdSbAv-DiEfAt29C4mOXFRoNaWjTVuW3_aSElIiI=.f8ec8d7e-84ec-4551-a9f3-e9aa116bb84e@github.com>

On Mon, 5 Dec 2022 17:45:25 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Libgraal is compiled ahead of time and should not need any JVMCI Java code to be dynamically loaded at runtime. Prior to this PR, this is not the case due to:
>> 
>> * Code to copy system properties from the HotSpot heap into the libgraal heap. This is in `jdk.vm.ci.services.Services.initializeSavedProperties(byte[])` and `jdk.vm.ci.services.Services.serializeSavedProperties()`. This code should be moved to `java.base/jdk.internal.vm.VMSupport`.
>> * Code to translate exceptions from the HotSpot heap into the libgraal heap and vice versa. This code should be moved from `jdk.internal.vm.ci//jdk.vm.ci.hotspot.TranslatedException` to `java.base/jdk.internal.vm.VMSupport`.
>> 
>> This PR makes the above changes. As a result, it's possible to build a JDK image that includes (and uses) libgraal but does not include `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces footprint and better isolates the JAVMCI and the Graal compiler as accessing these components from Java code is now impossible.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   renamed is_module_resolvable to is_module_observable

Sorry Doug not a full review (not familiar enough with code) but a few drive-by nits.

Thanks.

src/hotspot/share/jvmci/jvmci.cpp line 233:

> 231:     Thread* thread = Thread::current_or_null_safe();
> 232:     if (thread != nullptr && thread->is_Java_thread()) {
> 233:       ResourceMark rm;

You can pass `thread` to the rm constructor to save an internal lookup.

src/hotspot/share/jvmci/jvmci.cpp line 234:

> 232:     if (thread != nullptr && thread->is_Java_thread()) {
> 233:       ResourceMark rm;
> 234:       JavaThreadState state = ((JavaThread*) thread)->thread_state();

Please use `JavaThread::cast(thread)`

src/hotspot/share/jvmci/jvmci.cpp line 241:

> 239:         // resolve the j.l.Thread object unless the thread is in
> 240:         // one of the states above.
> 241:         tty->print("JVMCITrace-%d[%s@" INTPTR_FORMAT "]:%*c", level, thread->type_name(), p2i(thread), level, ' ');

I think the current preferred style is to use PTR_FORMAT here.

src/hotspot/share/runtime/arguments.cpp line 1958:

> 1956:         AddProperty, UnwriteableProperty, InternalProperty);
> 1957:     if (ClassLoader::is_module_observable("jdk.internal.vm.ci")) {
> 1958:       if(!create_numbered_module_property("jdk.module.addmods", "jdk.internal.vm.ci", addmods_count++)) {

Nit: space after `if` please

src/java.base/share/classes/jdk/internal/vm/TranslatedException.java line 2:

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

If you just moved the file the original copyright year should remain - this is not new code.

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

Changes requested by dholmes (Reviewer).

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

From jpai at openjdk.org  Tue Dec  6 06:06:44 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Dec 2022 06:06:44 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
Message-ID: <jCZcWYzVC1Sp_rkTvRHeSBUowXx1BCkTA_HnB8Be9KQ=.af7eb51a-5d9a-4666-bf34-65d48dae1319@github.com>

On Mon, 5 Dec 2022 19:52:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the copyright year

src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 50:

> 48:      * {@inheritDoc}
> 49:      */
> 50:     public JdkConsole console(boolean isTTY) {

Hello Naoto, this is missing a `@Override`.

src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 58:

> 56:      * public Console class.
> 57:      */
> 58:     public static class JdkConsoleImpl implements JdkConsole {

Can this be `private` class? Also, the methods in this class are missing the `@Override`.

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

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

From jpai at openjdk.org  Tue Dec  6 06:16:09 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Dec 2022 06:16:09 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
Message-ID: <WOH-ibxViM4sSleRr3z7nWv1y_MsN7M6EZCNZhUBfbU=.ad011b20-1bd1-4b75-9926-29c8ce6317d9@github.com>

On Mon, 5 Dec 2022 19:52:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the copyright year

src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 113:

> 111:         public JdkConsoleImpl() {
> 112:             try {
> 113:                 terminal = TerminalBuilder.builder().build();

The `java.io.Console` in its static initialization code has some logic to determine the `Charset` to use. Should that same `Charset` (or logic) be used here to build the terminal? Something like `TerminalBuilder.builder().encoding(fooBarCharset).build();`.

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

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

From jpai at openjdk.org  Tue Dec  6 06:22:02 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Dec 2022 06:22:02 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
Message-ID: <NBdqUPP-JYFqnssVlTqDa60SOyWjyrJvXPQ8DDWSImQ=.d07abcf6-b1e5-461b-81b9-07f5d4406907@github.com>

On Mon, 5 Dec 2022 19:52:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the copyright year

src/java.base/share/classes/java/io/Console.java line 99:

> 97:  */
> 98: 
> 99: public class Console implements Flushable

Should we perhaps `seal` this class and only `permit` `ProxyingConsole` to `extend` it?

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

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

From jpai at openjdk.org  Tue Dec  6 07:02:17 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Dec 2022 07:02:17 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
Message-ID: <CkmM7v_Lh-rsQ8_sRfxIuHqsonz2GzXleEQ44vTD0Ig=.d3b44b2c-6d14-4f12-aeba-805ad2a62539@github.com>

On Mon, 5 Dec 2022 19:52:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the copyright year

src/java.base/share/classes/java/io/Console.java line 615:

> 613:                 var consModName = System.getProperty("jdk.console",
> 614:                         JdkConsoleProvider.DEFAULT_PROVIDER_MODULE_NAME);
> 615:                 return ServiceLoader.load(JdkConsoleProvider.class).stream()

Are we intentionally using thread context classloader (which can be different depending on which caller ends up first accessing/initializing the `java.io.Console` class) to load these services?

I initially thought that `java.io.Console` might be used/initialized early in the bootstrap process of Java so the classloader could perhaps be deterministic, but running a trivial Java application with `-verbose:class` shows that `java.io.Console` doesn't get instantiated during the launch, so that leaves this code to "first access wins" situation and maybe an "incorrect" context classloader which doesn't have access the configured `jdk.console` module may end up causing this code to default to `java.io.Console`?


public class Hello {
	public static void main(final String[] args) {
	}
}


java -verbose:class Hello.java


Instead, should we perhaps use the ModuleLayer to find this configured module and then use its classloader to load the `JdkConsoleProvider` service provider? Something like:


final Optional<Module> mod = ModuleLayer.boot().findModule(consModName);
// ... if not present default to java.io.Console else use the module's classloader to try and load the JdkConsoleProvider
return ServiceLoader.load(JdkConsoleProvider.class, mod.get().getClassLoader()).stream()......

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

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

From jpai at openjdk.org  Tue Dec  6 07:11:17 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Dec 2022 07:11:17 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
Message-ID: <rzPVmUKQdK06b_4r9uiV6v_HM26LkdVGmf2BzpdGBXQ=.d882201a-01bf-429c-9ab5-4946a71b02b4@github.com>

On Mon, 5 Dec 2022 19:52:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the copyright year

src/java.base/share/classes/java/io/Console.java line 616:

> 614:                         JdkConsoleProvider.DEFAULT_PROVIDER_MODULE_NAME);
> 615:                 return ServiceLoader.load(JdkConsoleProvider.class).stream()
> 616:                         .map(ServiceLoader.Provider::get)

Furthermore, I think in its current form it means that this will load/instantiate any `JdkConsoleProvider` implementations that are accessible to the thread context classloader but may not have been from the module configured through `jdk.console` system property. That could potentially mean, in the best case, unnecessary classloading of additional classes and in the worst case, could result in `ServiceLoader.Provider::get` throwing a `ServiceConfigurationError` error for any of such unused provider implementations, thus forcing us to use `java.io.Console` instance.

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

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

From jpai at openjdk.org  Tue Dec  6 07:18:14 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Dec 2022 07:18:14 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
Message-ID: <GATX3t9zGQviww5AKhDFAkThUgIg6Woa04HuZw3ZlsA=.d580348b-e014-4020-aec3-034cff83d1e6@github.com>

On Mon, 5 Dec 2022 19:52:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the copyright year

src/java.base/share/classes/java/io/Console.java line 625:

> 623:             };
> 624:             return AccessController.doPrivileged(pa);
> 625:         } catch (ServiceConfigurationError ignore) {

Should we perhaps just catch `Throwable` here since it's possible that the `PrivelegedAction` code could throw unchecked exception (for example the call to `JdkConsoleProvider.console()` could, in theory, lead to any kind of unchecked exceptions or errors like `NoClassDefFoundError`).

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

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

From jpai at openjdk.org  Tue Dec  6 07:38:52 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Dec 2022 07:38:52 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
Message-ID: <zThZp7wk1n91h_yRdhoZXu839z0MV1cstLA-G7YOqlQ=.5822f9c8-e932-446f-885a-0e00b7405800@github.com>

On Mon, 5 Dec 2022 19:52:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the copyright year

Hello Naoto, the class level javadoc of `java.io.Console` currently specifies synchronization expectations in the context of multithreaded use:

>  Read and write operations are synchronized to guarantee the atomic
>  completion of critical operations; therefore invoking methods
>  {@link #readLine()}, {@link #readPassword()}, {@link #format format()},
>  {@link #printf printf()} as well as the read, format and write operations
>  on the objects returned by {@link #reader()} and {@link #writer()} may
>  block in multithreaded scenarios.

So the `Console` instance returned from `System.console()`, thus far, follows these semantics. However, with the change proposed in this PR, the default implementation will now be the jline backed `JdkConsoleImpl` implementation. From what I can see there, we don't seem to have any similar guarantees around multithreaded access. Do we need similar locking constructs in that implementation to guarantee/verify it works as per the expectations of `java.io.Console` API?

While we are at it, the Console class level javadoc also states:

> If the virtual machine is started from an
> interactive command line without redirecting the standard input and
> output streams then its console will exist and will typically be
> connected to the keyboard and display from which the virtual machine
> was launched.

With this proposed change, to by default use the jline backed implementation, would we need to reword/update that javadoc?

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

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

From alanb at openjdk.org  Tue Dec  6 07:38:55 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 Dec 2022 07:38:55 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <rzPVmUKQdK06b_4r9uiV6v_HM26LkdVGmf2BzpdGBXQ=.d882201a-01bf-429c-9ab5-4946a71b02b4@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
 <rzPVmUKQdK06b_4r9uiV6v_HM26LkdVGmf2BzpdGBXQ=.d882201a-01bf-429c-9ab5-4946a71b02b4@github.com>
Message-ID: <aRStSfbyYDxmNb1dKkfmvu2sLsOygInBUAZiWyQ0q4A=.81384435-4139-4761-af05-66a9d24cb2e4@github.com>

On Tue, 6 Dec 2022 07:08:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Furthermore, I think in its current form it means that this will load/instantiate any `JdkConsoleProvider` implementations that are accessible to the thread context classloader but may not have been from the module configured through `jdk.console` system property. That could potentially mean, in the best case, unnecessary classloading of additional classes and in the worst case, could result in `ServiceLoader.Provider::get` throwing a `ServiceConfigurationError` error for any of such unused provider implementations, thus forcing us to use `java.io.Console` instance.

You are right that the ServiceLoader.load should specify the system class loader or the boot layer. However, there isn't an accessibility issue as a class loader just load classes so it's more about visibility and whether the TCCL will ultimately delegate to the application class loader.

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

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

From stsypanov at openjdk.org  Tue Dec  6 07:42:28 2022
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 6 Dec 2022 07:42:28 GMT
Subject: RFR: 8298033: Character.codePointAt(char[], int,
 int) doesn't do JavaDoc-specified check [v4]
In-Reply-To: <dHjviGmASssYfntfClzDC28Ppjrn3pECnO3HzbZHopY=.d9923de3-6de7-41f5-a84e-03a7c5267e2f@github.com>
References: <dHjviGmASssYfntfClzDC28Ppjrn3pECnO3HzbZHopY=.d9923de3-6de7-41f5-a84e-03a7c5267e2f@github.com>
Message-ID: <M5uC8EyKLy3dYsxs6fo1YCqikFZ10cMZWAUxOKVxG3w=.52aa26d2-4279-435b-b0da-0eb48995c76c@github.com>

> I found out that this code
> 
> public class Main {
>     public static void main(String[] args) {
>         String s = "Hello world!";
>         char[] chars = s.toCharArray();
>         int point = Character.codePointAt(chars, -1, 1);
>     }
> }
> 
> throws `ArrayIndexOutOfBoundsException` instead of JavaDoc-specified `IndexOutOfBoundsException`: 
> 
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds for length 12
> 	at java.base/java.lang.Character.codePointAtImpl(Character.java:9254)
> 	at java.base/java.lang.Character.codePointAt(Character.java:9249)
> 	at org.example.Main.main(Main.java:7)
> 
> and the method doesn't check whether `index` parameter is negative:
> 
> public static int codePointAt(char[] a, int index, int limit) {
>     if (index >= limit || limit < 0 || limit > a.length) {
>         throw new IndexOutOfBoundsException();
>     }
>     return codePointAtImpl(a, index, limit);
> }
> 
> I suggest to check the `index` parameter explicitly instead of relying on AIOOBE thrown from accessing the array with negative index.

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

  8298033: Fix Character.codePointBefore()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11480/files
  - new: https://git.openjdk.org/jdk/pull/11480/files/39ab3401..5ed82ac0

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

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

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

From dnsimon at openjdk.org  Tue Dec  6 08:59:02 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 6 Dec 2022 08:59:02 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v4]
In-Reply-To: <l12fdSbAv-DiEfAt29C4mOXFRoNaWjTVuW3_aSElIiI=.f8ec8d7e-84ec-4551-a9f3-e9aa116bb84e@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <nm5MBsIexi02WmVomf-rKb-xWg064Pqg9WMKxb18PBw=.9d5209a3-675e-4ee2-a4d5-05ff14934fb3@github.com>
 <l12fdSbAv-DiEfAt29C4mOXFRoNaWjTVuW3_aSElIiI=.f8ec8d7e-84ec-4551-a9f3-e9aa116bb84e@github.com>
Message-ID: <sJOLTlt6mjfVSLsXdLQMgirI06mdYjGW0tuO2Ueht8s=.e3d8eb38-c4a6-4e43-9e01-3b9ecb385b41@github.com>

On Tue, 6 Dec 2022 05:28:24 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   renamed is_module_resolvable to is_module_observable
>
> src/hotspot/share/jvmci/jvmci.cpp line 234:
> 
>> 232:     if (thread != nullptr && thread->is_Java_thread()) {
>> 233:       ResourceMark rm;
>> 234:       JavaThreadState state = ((JavaThread*) thread)->thread_state();
> 
> Please use `JavaThread::cast(thread)`

I've made this change. Out of interest, I grep'ed through `src/hotspot` and found a few other instances of `(JavaThread*)` style casts. While most of these are probably older code, I'm wondering what the guidelines are in this area. I assume `JavaThread::cast` should be preferred always given the assertion checking it does?

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

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

From dnsimon at openjdk.org  Tue Dec  6 09:47:29 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 6 Dec 2022 09:47:29 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v5]
In-Reply-To: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
Message-ID: <kU-NHwhiGEJLa7-o38UCemcxhU8WR_ijQBMGOAknOTs=.57d0341c-30af-4c39-ab42-4278fdfb2e5d@github.com>

> Libgraal is compiled ahead of time and should not need any JVMCI Java code to be dynamically loaded at runtime. Prior to this PR, this is not the case due to:
> 
> * Code to copy system properties from the HotSpot heap into the libgraal heap. This is in `jdk.vm.ci.services.Services.initializeSavedProperties(byte[])` and `jdk.vm.ci.services.Services.serializeSavedProperties()`. This code should be moved to `java.base/jdk.internal.vm.VMSupport`.
> * Code to translate exceptions from the HotSpot heap into the libgraal heap and vice versa. This code should be moved from `jdk.internal.vm.ci//jdk.vm.ci.hotspot.TranslatedException` to `java.base/jdk.internal.vm.VMSupport`.
> 
> This PR makes the above changes. As a result, it's possible to build a JDK image that includes (and uses) libgraal but does not include `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces footprint and better isolates the JAVMCI and the Graal compiler as accessing these components from Java code is now impossible.

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

 - incorporate review feedback [skip ci]
 - removed hard-coded module name [skip ci]

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11513/files
  - new: https://git.openjdk.org/jdk/pull/11513/files/29e100b3..342d5e3c

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

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

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

From pminborg at openjdk.org  Tue Dec  6 10:06:28 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 6 Dec 2022 10:06:28 GMT
Subject: RFR: 8296024: Usage of DirectBuffer::address should be guarded
 [v18]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <qPCDfZtLtQZXFvPU1SADYcB_V6t0TKVyhTlHi98_CZ8=.055b5ef4-44b0-4c16-8111-d483c027da82@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a ~~try-with-resources~~ *try-finally* friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned ~~TwR~~ TF is using a ~~"session acquisition" that is not used explicitly in the try block itself~~ session used in the *finally* block. ~~This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`.~~
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

Per Minborg 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 master
 - Remove session exposure
 - Re-introduce yet another address vairable
 - Re-introduce address variables
 - Reformat and fix comment
 - Remove redundant method
 - Cleanup
 - Refactor to try-finally handling
 - Remove redundant guard and fix comment permanently
 - Rework Acquisition
 - ... and 9 more: https://git.openjdk.org/jdk/compare/a6139985...cd95bc86

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

Changes: https://git.openjdk.org/jdk/pull/11260/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=17
  Stats: 809 lines in 24 files changed: 377 ins; 172 del; 260 mod
  Patch: https://git.openjdk.org/jdk/pull/11260.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260

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

From pminborg at openjdk.org  Tue Dec  6 10:47:59 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 6 Dec 2022 10:47:59 GMT
Subject: Integrated: 8296024: Usage of DirectBuffer::address should be guarded
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <qx7uCPevkZ16sZWBJ3TC0_USr-FcMYAxOMNx6WDlYyg=.6681bd04-2dbf-4c06-9098-f05e067c4e25@github.com>

On Mon, 21 Nov 2022 10:53:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a ~~try-with-resources~~ *try-finally* friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned ~~TwR~~ TF is using a ~~"session acquisition" that is not used explicitly in the try block itself~~ session used in the *finally* block. ~~This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`.~~
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

This pull request has now been integrated.

Changeset: 84b927a0
Author:    Per Minborg <pminborg at openjdk.org>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/84b927a05bcb7bf32a12829070ffd3a5670066d2
Stats:     809 lines in 24 files changed: 377 ins; 172 del; 260 mod

8296024: Usage of DirectBuffer::address should be guarded

Reviewed-by: mcimadamore, alanb, psandoz, bpb

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

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

From alanb at openjdk.org  Tue Dec  6 12:11:08 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 Dec 2022 12:11:08 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <zThZp7wk1n91h_yRdhoZXu839z0MV1cstLA-G7YOqlQ=.5822f9c8-e932-446f-885a-0e00b7405800@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
 <zThZp7wk1n91h_yRdhoZXu839z0MV1cstLA-G7YOqlQ=.5822f9c8-e932-446f-885a-0e00b7405800@github.com>
Message-ID: <qHY5N00TioxM21y-BFNYHepWP6wM7O-0xBvTMkHmiGM=.6897a418-7b87-44f4-aa76-ee206a2d29ac@github.com>

On Tue, 6 Dec 2022 07:35:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> So the `Console` instance returned from `System.console()`, thus far, follows these semantics. However, with the change proposed in this PR, the default implementation will now be the jline backed `JdkConsoleImpl` implementation. From what I can see there, we don't seem to have any similar guarantees around multithreaded access. Do we need similar locking constructs in that implementation to guarantee/verify it works as per the expectations of `java.io.Console` API?

As it happens I was chatting with Naoto about this area yesterday. There are effectively two Console implementations, the base implementation in Console, and the subclass in ProxyingConsole. When using ProxyingConsole then the state/implementation in the superclass isn't used. So either the locks are exposed to the subclass or there is a bit more surgery done so there are two subclasses, each with their own read and write locks. Subclasses might be cleaned as there is state in Console that is not interesting for the new implementation.

> With this proposed change, to by default use the jline backed implementation, would we need to reword/update that javadoc?

That is a good observation, instead of "will typically not have a console" then it should probably say "may not have a console".

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

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

From jpai at openjdk.org  Tue Dec  6 12:12:05 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Dec 2022 12:12:05 GMT
Subject: RFR: 8297976: Remove sun.net.ProgressMonitor and related classes
 [v2]
In-Reply-To: <gR6VTUu8U9hz964d8bXM6w_vURFycj5GMDt9PrrzDrU=.7600e0f0-4167-4f57-8da4-54785788f41b@github.com>
References: <yw8Q8tA8_4jUmc1gWd-xAN-m5kjFPeou3dn0qML9TQ4=.18a511ff-946f-4a8a-8fe3-3eaf00a8a396@github.com>
 <gR6VTUu8U9hz964d8bXM6w_vURFycj5GMDt9PrrzDrU=.7600e0f0-4167-4f57-8da4-54785788f41b@github.com>
Message-ID: <fxpZnsTpUj8kJ--GKaSWbuEQmXcEsHm2qNI1I5lQ3-g=.3a21b13d-2228-4694-b673-53a8111c1373@github.com>

On Mon, 5 Dec 2022 14:06:10 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Please review this patch that removes progress monitoring classes used by UrlConnection.
>> Since Java 9 these classes are not used in the JDK, and are not exported from java.base. If anyone was still using them, reimplementing them in user code should be pretty straightforward.
>> 
>> This PR also fixes the issue where MeteredStream finalizer could resurrect an unusable connection, causing unexpected exceptions in other parts of the code.
>> 
>> No new regression test; since we are removing the finalizer, I don't believe we will see the issue again. I can add a test for that if you think it still makes sense.
>> 
>> I had to adjust `ProxyModuleMapping.java` test which used `sun.net.ProgressListener` as an example of a module-private interface; I replaced it with another public interface from the same package.
>> 
>> Existing tier 1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

test/jdk/sun/net/www/http/KeepAliveStream/KeepAliveStreamFinalizer.java line 28:

> 26:  * @bug 8240275
> 27:  * @library /test/lib
> 28:  * @run main/othervm KeepAliveStreamFinalizer

Hello Daniel, it doesn't look like we are doing anything JVM specific in this  test. Is the `othervm` intentional here?

test/jdk/sun/net/www/http/KeepAliveStream/KeepAliveStreamFinalizer.java line 175:

> 173:         public InputStream getInputStream() throws IOException {
> 174:             if (finalized) {
> 175:                 System.out.println(failureReason = "getInputStream called after finalize");

For ease of debugging, perhaps use `System.err.println` instead of `System.out`? That way the `Thread.dumpStack()` which is done on the next line will appear in the same jtreg section as this message.

Same comment in few other places where we have this construct.

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

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

From dfuchs at openjdk.org  Tue Dec  6 12:41:14 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 6 Dec 2022 12:41:14 GMT
Subject: RFR: 8297976: Remove sun.net.ProgressMonitor and related classes
 [v2]
In-Reply-To: <fxpZnsTpUj8kJ--GKaSWbuEQmXcEsHm2qNI1I5lQ3-g=.3a21b13d-2228-4694-b673-53a8111c1373@github.com>
References: <yw8Q8tA8_4jUmc1gWd-xAN-m5kjFPeou3dn0qML9TQ4=.18a511ff-946f-4a8a-8fe3-3eaf00a8a396@github.com>
 <gR6VTUu8U9hz964d8bXM6w_vURFycj5GMDt9PrrzDrU=.7600e0f0-4167-4f57-8da4-54785788f41b@github.com>
 <fxpZnsTpUj8kJ--GKaSWbuEQmXcEsHm2qNI1I5lQ3-g=.3a21b13d-2228-4694-b673-53a8111c1373@github.com>
Message-ID: <Mph9r2xR9iIVHlugkt_ezQlh-lwqC-V0UU75FDrtIYk=.b7d797df-09b4-4092-81df-b94e632a8717@github.com>

On Tue, 6 Dec 2022 12:07:35 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add test
>
> test/jdk/sun/net/www/http/KeepAliveStream/KeepAliveStreamFinalizer.java line 28:
> 
>> 26:  * @bug 8240275
>> 27:  * @library /test/lib
>> 28:  * @run main/othervm KeepAliveStreamFinalizer
> 
> Hello Daniel, it doesn't look like we are doing anything JVM specific in this  test. Is the `othervm` intentional here?

The test calls `HttpsURLConnection.setDefaultSSLSocketFactor` which requires using `/othervm`

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

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

From dfuchs at openjdk.org  Tue Dec  6 12:48:13 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 6 Dec 2022 12:48:13 GMT
Subject: RFR: 8297976: Remove sun.net.ProgressMonitor and related classes
 [v3]
In-Reply-To: <Ys_W9ri2ZoiYdLlmWSXUG427HDTuBBt-YgQlE-6ho0Y=.a136b1cd-c64b-401a-a941-22b5520f406d@github.com>
References: <yw8Q8tA8_4jUmc1gWd-xAN-m5kjFPeou3dn0qML9TQ4=.18a511ff-946f-4a8a-8fe3-3eaf00a8a396@github.com>
 <Ys_W9ri2ZoiYdLlmWSXUG427HDTuBBt-YgQlE-6ho0Y=.a136b1cd-c64b-401a-a941-22b5520f406d@github.com>
Message-ID: <t8W4WH6DbYXSB8jjot6L2Ew-liu6FQQcehUJFCogftg=.d933fd09-f5cb-42a2-8fb9-b50abab0827d@github.com>

On Mon, 5 Dec 2022 14:12:05 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Please review this patch that removes progress monitoring classes used by UrlConnection.
>> Since Java 9 these classes are not used in the JDK, and are not exported from java.base. If anyone was still using them, reimplementing them in user code should be pretty straightforward.
>> 
>> This PR also fixes the issue where MeteredStream finalizer could resurrect an unusable connection, causing unexpected exceptions in other parts of the code.
>> 
>> No new regression test; since we are removing the finalizer, I don't believe we will see the issue again. I can add a test for that if you think it still makes sense.
>> 
>> I had to adjust `ProxyModuleMapping.java` test which used `sun.net.ProgressListener` as an example of a module-private interface; I replaced it with another public interface from the same package.
>> 
>> Existing tier 1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove double space
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

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

From dfuchs at openjdk.org  Tue Dec  6 12:48:18 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 6 Dec 2022 12:48:18 GMT
Subject: RFR: 8297976: Remove sun.net.ProgressMonitor and related classes
 [v2]
In-Reply-To: <fxpZnsTpUj8kJ--GKaSWbuEQmXcEsHm2qNI1I5lQ3-g=.3a21b13d-2228-4694-b673-53a8111c1373@github.com>
References: <yw8Q8tA8_4jUmc1gWd-xAN-m5kjFPeou3dn0qML9TQ4=.18a511ff-946f-4a8a-8fe3-3eaf00a8a396@github.com>
 <gR6VTUu8U9hz964d8bXM6w_vURFycj5GMDt9PrrzDrU=.7600e0f0-4167-4f57-8da4-54785788f41b@github.com>
 <fxpZnsTpUj8kJ--GKaSWbuEQmXcEsHm2qNI1I5lQ3-g=.3a21b13d-2228-4694-b673-53a8111c1373@github.com>
Message-ID: <lM1H2TakeWuulsNEvQkVPd6bxxjZhi4EMvEddji4vRA=.b579d77a-0248-4bf6-b3e5-b729ee105a8e@github.com>

On Tue, 6 Dec 2022 12:05:26 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add test
>
> test/jdk/sun/net/www/http/KeepAliveStream/KeepAliveStreamFinalizer.java line 175:
> 
>> 173:         public InputStream getInputStream() throws IOException {
>> 174:             if (finalized) {
>> 175:                 System.out.println(failureReason = "getInputStream called after finalize");
> 
> For ease of debugging, perhaps use `System.err.println` instead of `System.out`? That way the `Thread.dumpStack()` which is done on the next line will appear in the same jtreg section as this message.
> 
> Same comment in few other places where we have this construct.

I agree with Jaikiran that since we're not using testng here using `System.err` consistently is probably better.

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

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

From alanb at openjdk.org  Tue Dec  6 13:16:43 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 Dec 2022 13:16:43 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v5]
In-Reply-To: <kU-NHwhiGEJLa7-o38UCemcxhU8WR_ijQBMGOAknOTs=.57d0341c-30af-4c39-ab42-4278fdfb2e5d@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <kU-NHwhiGEJLa7-o38UCemcxhU8WR_ijQBMGOAknOTs=.57d0341c-30af-4c39-ab42-4278fdfb2e5d@github.com>
Message-ID: <-vjDxNaafm1m5UERR31dFXH7jdljWTKzsDjntS8v6zs=.4c777f1e-695f-42de-a4b5-0cb0f332243c@github.com>

On Tue, 6 Dec 2022 09:47:29 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Libgraal is compiled ahead of time and should not need any JVMCI Java code to be dynamically loaded at runtime. Prior to this PR, this is not the case due to:
>> 
>> * Code to copy system properties from the HotSpot heap into the libgraal heap. This is in `jdk.vm.ci.services.Services.initializeSavedProperties(byte[])` and `jdk.vm.ci.services.Services.serializeSavedProperties()`. This code should be moved to `java.base/jdk.internal.vm.VMSupport`.
>> * Code to translate exceptions from the HotSpot heap into the libgraal heap and vice versa. This code should be moved from `jdk.internal.vm.ci//jdk.vm.ci.hotspot.TranslatedException` to `java.base/jdk.internal.vm.VMSupport`.
>> 
>> This PR makes the above changes. As a result, it's possible to build a JDK image that includes (and uses) libgraal but does not include `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces footprint and better isolates the JAVMCI and the Graal compiler as accessing these components from Java code is now impossible.
>
> Doug Simon has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - incorporate review feedback [skip ci]
>  - removed hard-coded module name [skip ci]

src/java.base/share/classes/jdk/internal/vm/TranslatedException.java line 44:

> 42:  */
> 43: @SuppressWarnings("serial")
> 44: final class TranslatedException extends Exception {

Would it be possible to re-format this to avoid the wildly long (150+) lines? This seems to be moving jdk.vm.ci.hotspot.TranslatedException and hard to see what is going on.

src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 66:

> 64:      *               only contains String keys and values.
> 65:      */
> 66:     private static byte[] serializePropertiesToByteArray(Properties p, boolean filter) throws IOException {

I think we need more context as to why there are non-String system properties in use here.

src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 106:

> 104:         }
> 105:         if (props.get("oome") != null) {
> 106:             throw new OutOfMemoryError("forced OOME");

I don't think code in java.base should be checking for a property named "oome".  Is this for a test that sets this system property on the command line?

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

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

From jpai at openjdk.org  Tue Dec  6 13:18:27 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Dec 2022 13:18:27 GMT
Subject: RFR: 8297976: Remove sun.net.ProgressMonitor and related classes
 [v2]
In-Reply-To: <Mph9r2xR9iIVHlugkt_ezQlh-lwqC-V0UU75FDrtIYk=.b7d797df-09b4-4092-81df-b94e632a8717@github.com>
References: <yw8Q8tA8_4jUmc1gWd-xAN-m5kjFPeou3dn0qML9TQ4=.18a511ff-946f-4a8a-8fe3-3eaf00a8a396@github.com>
 <gR6VTUu8U9hz964d8bXM6w_vURFycj5GMDt9PrrzDrU=.7600e0f0-4167-4f57-8da4-54785788f41b@github.com>
 <fxpZnsTpUj8kJ--GKaSWbuEQmXcEsHm2qNI1I5lQ3-g=.3a21b13d-2228-4694-b673-53a8111c1373@github.com>
 <Mph9r2xR9iIVHlugkt_ezQlh-lwqC-V0UU75FDrtIYk=.b7d797df-09b4-4092-81df-b94e632a8717@github.com>
Message-ID: <b-FJzozAWoM4iVlnbJsH5IbNy_fyrWwe2ChMC9HcYSg=.4670b845-0414-4e3a-92d3-9d03359df338@github.com>

On Tue, 6 Dec 2022 12:38:42 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/sun/net/www/http/KeepAliveStream/KeepAliveStreamFinalizer.java line 28:
>> 
>>> 26:  * @bug 8240275
>>> 27:  * @library /test/lib
>>> 28:  * @run main/othervm KeepAliveStreamFinalizer
>> 
>> Hello Daniel, it doesn't look like we are doing anything JVM specific in this  test. Is the `othervm` intentional here?
>
> The test calls `HttpsURLConnection.setDefaultSSLSocketFactor` which requires using `/othervm`

Ah yes, overlooked that part.

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

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

From djelinski at openjdk.org  Tue Dec  6 13:42:04 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 6 Dec 2022 13:42:04 GMT
Subject: RFR: 8297976: Remove sun.net.ProgressMonitor and related classes
 [v4]
In-Reply-To: <yw8Q8tA8_4jUmc1gWd-xAN-m5kjFPeou3dn0qML9TQ4=.18a511ff-946f-4a8a-8fe3-3eaf00a8a396@github.com>
References: <yw8Q8tA8_4jUmc1gWd-xAN-m5kjFPeou3dn0qML9TQ4=.18a511ff-946f-4a8a-8fe3-3eaf00a8a396@github.com>
Message-ID: <--xZGrc9oA7pnqyvUDWRUvTNxVLtZsDoe-r0xhyDuKI=.761cc499-2463-457c-9f4a-881c198893df@github.com>

> Please review this patch that removes progress monitoring classes used by UrlConnection.
> Since Java 9 these classes are not used in the JDK, and are not exported from java.base. If anyone was still using them, reimplementing them in user code should be pretty straightforward.
> 
> This PR also fixes the issue where MeteredStream finalizer could resurrect an unusable connection, causing unexpected exceptions in other parts of the code.
> 
> No new regression test; since we are removing the finalizer, I don't believe we will see the issue again. I can add a test for that if you think it still makes sense.
> 
> I had to adjust `ProxyModuleMapping.java` test which used `sun.net.ProgressListener` as an example of a module-private interface; I replaced it with another public interface from the same package.
> 
> Existing tier 1-3 tests continue to pass.

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

  Use System.err

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11474/files
  - new: https://git.openjdk.org/jdk/pull/11474/files/8d7c6e5c..9be8eea7

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

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

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

From djelinski at openjdk.org  Tue Dec  6 13:42:08 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 6 Dec 2022 13:42:08 GMT
Subject: RFR: 8297976: Remove sun.net.ProgressMonitor and related classes
 [v2]
In-Reply-To: <lM1H2TakeWuulsNEvQkVPd6bxxjZhi4EMvEddji4vRA=.b579d77a-0248-4bf6-b3e5-b729ee105a8e@github.com>
References: <yw8Q8tA8_4jUmc1gWd-xAN-m5kjFPeou3dn0qML9TQ4=.18a511ff-946f-4a8a-8fe3-3eaf00a8a396@github.com>
 <gR6VTUu8U9hz964d8bXM6w_vURFycj5GMDt9PrrzDrU=.7600e0f0-4167-4f57-8da4-54785788f41b@github.com>
 <fxpZnsTpUj8kJ--GKaSWbuEQmXcEsHm2qNI1I5lQ3-g=.3a21b13d-2228-4694-b673-53a8111c1373@github.com>
 <lM1H2TakeWuulsNEvQkVPd6bxxjZhi4EMvEddji4vRA=.b579d77a-0248-4bf6-b3e5-b729ee105a8e@github.com>
Message-ID: <o4G5LB1xlTx-QFM9holhAcxGaJgZsI9fi6EWIhCsJEs=.4e5fe8c6-751a-43ee-a199-56131de2dbab@github.com>

On Tue, 6 Dec 2022 12:43:44 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/sun/net/www/http/KeepAliveStream/KeepAliveStreamFinalizer.java line 175:
>> 
>>> 173:         public InputStream getInputStream() throws IOException {
>>> 174:             if (finalized) {
>>> 175:                 System.out.println(failureReason = "getInputStream called after finalize");
>> 
>> For ease of debugging, perhaps use `System.err.println` instead of `System.out`? That way the `Thread.dumpStack()` which is done on the next line will appear in the same jtreg section as this message.
>> 
>> Same comment in few other places where we have this construct.
>
> I agree with Jaikiran that since we're not using testng here using `System.err` consistently is probably better.

Good point. Replaced `System.out` with `System.err` everywhere.

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

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

From michaelm at openjdk.org  Tue Dec  6 13:49:13 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 6 Dec 2022 13:49:13 GMT
Subject: RFR: 8297976: Remove sun.net.ProgressMonitor and related classes
 [v4]
In-Reply-To: <--xZGrc9oA7pnqyvUDWRUvTNxVLtZsDoe-r0xhyDuKI=.761cc499-2463-457c-9f4a-881c198893df@github.com>
References: <yw8Q8tA8_4jUmc1gWd-xAN-m5kjFPeou3dn0qML9TQ4=.18a511ff-946f-4a8a-8fe3-3eaf00a8a396@github.com>
 <--xZGrc9oA7pnqyvUDWRUvTNxVLtZsDoe-r0xhyDuKI=.761cc499-2463-457c-9f4a-881c198893df@github.com>
Message-ID: <VIGyJiC8WG5vQ3l_CjdlPP0XU8E5pEkvW1asnYBJN1c=.67e815b5-5a2c-4cbd-a956-7a37489b0ad8@github.com>

On Tue, 6 Dec 2022 13:42:04 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Please review this patch that removes progress monitoring classes used by UrlConnection.
>> Since Java 9 these classes are not used in the JDK, and are not exported from java.base. If anyone was still using them, reimplementing them in user code should be pretty straightforward.
>> 
>> This PR also fixes the issue where MeteredStream finalizer could resurrect an unusable connection, causing unexpected exceptions in other parts of the code.
>> 
>> No new regression test; since we are removing the finalizer, I don't believe we will see the issue again. I can add a test for that if you think it still makes sense.
>> 
>> I had to adjust `ProxyModuleMapping.java` test which used `sun.net.ProgressListener` as an example of a module-private interface; I replaced it with another public interface from the same package.
>> 
>> Existing tier 1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use System.err

Looks fine to me.

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

Marked as reviewed by michaelm (Reviewer).

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

From dsamersoff at openjdk.org  Tue Dec  6 14:08:03 2022
From: dsamersoff at openjdk.org (Dmitry Samersoff)
Date: Tue, 6 Dec 2022 14:08:03 GMT
Subject: RFR: 8293806: JDK_JAVA_OPTIONS picked up twice if launcher
 re-executes it self
In-Reply-To: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
References: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
Message-ID: <0SffICjPTaLOAFskwWav0O79RwtVZTeUq9_pQAjTMEA=.66df8fbb-8089-4cf4-8de0-0cdf3cec97ce@github.com>

On Mon, 26 Sep 2022 18:15:17 GMT, Dmitry Samersoff <dsamersoff at openjdk.org> wrote:

> If the user has set LD_LIBRARY_PATH to use a particular libjvm.so, options from the JDK_JAVA_OPTIONS environment variable are picked up twice.
> 
> If an option cannot be accepted twice (e.g., -agentlib), the application fails to start.
> 
> The same happens on operating systems that doesn't support $RPATH/$ORIGIN and always have to set LD_LIBRARY_PATH and re-exec the launcher.
> 
> The fix adds one additional argument - orig_argv to JLI_Launch() and use it in on relaunch in execv() call.
> 
> All relevant jtreg tests are passed.

Take the approach to re-launch as early as possible.

https://github.com/openjdk/jdk/pull/11538

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

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

From dsamersoff at openjdk.org  Tue Dec  6 14:08:04 2022
From: dsamersoff at openjdk.org (Dmitry Samersoff)
Date: Tue, 6 Dec 2022 14:08:04 GMT
Subject: Withdrawn: 8293806: JDK_JAVA_OPTIONS picked up twice if launcher
 re-executes it self
In-Reply-To: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
References: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
Message-ID: <rXUTdcwKm0UQg0u4CryLQ2lOUrjPh4CjqI7vrucMZGQ=.a96ef5ca-49f0-4dc2-8aa0-31ed5f948d31@github.com>

On Mon, 26 Sep 2022 18:15:17 GMT, Dmitry Samersoff <dsamersoff at openjdk.org> wrote:

> If the user has set LD_LIBRARY_PATH to use a particular libjvm.so, options from the JDK_JAVA_OPTIONS environment variable are picked up twice.
> 
> If an option cannot be accepted twice (e.g., -agentlib), the application fails to start.
> 
> The same happens on operating systems that doesn't support $RPATH/$ORIGIN and always have to set LD_LIBRARY_PATH and re-exec the launcher.
> 
> The fix adds one additional argument - orig_argv to JLI_Launch() and use it in on relaunch in execv() call.
> 
> All relevant jtreg tests are passed.

This pull request has been closed without being integrated.

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

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

From alanb at openjdk.org  Tue Dec  6 14:48:36 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 Dec 2022 14:48:36 GMT
Subject: RFR: 8296896: Change virtual Thread.yield to use external submit
Message-ID: <S0emMR0JXtg41aa6ITXJg7IlxJljzGwPGuyjOdH98Gc=.691bc53c-d851-414f-8261-020f96dbde93@github.com>

The implementation of Thread.yield for virtual threads is currently a "lazy submit". This means the task for the virtual thread is queued to the carrier/worker local queue without signalling other threads. This behavior can be surprising/unfair when there are tasks in the submission queues, say when a platform thread has started or unparked a virtual thread.

Ron, Doug Lea, Viktor Klang and I have discussed this topic and propose to change Thread.yield to  use "external submit" when the local task queue is empty, and to push to the local queue when not empty. The change improves the fairness but will of course increase the chances that repeated Thread.yield will bounce between carriers.

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

Commit messages:
 - Reduce instanceof checks
 - Update
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/11533/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11533&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296896
  Stats: 188 lines in 3 files changed: 161 ins; 12 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/11533.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11533/head:pull/11533

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

From alanb at openjdk.org  Tue Dec  6 14:54:50 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 Dec 2022 14:54:50 GMT
Subject: RFR: 8296672: Implementation of Virtual Threads (Second Preview)
 [v2]
In-Reply-To: <3xn4pJmY7VbtV47kZiR7L3c6-C-0vR5fVQ-y-SXlSx0=.56d8f675-e215-4457-b48e-13babb0d7ae7@github.com>
References: <3xn4pJmY7VbtV47kZiR7L3c6-C-0vR5fVQ-y-SXlSx0=.56d8f675-e215-4457-b48e-13babb0d7ae7@github.com>
Message-ID: <aHBwzBBWrMBD5d1aqT3w0_Ug08lTaI64a22oVaEWQCY=.f7a631d8-e686-43cb-90f5-191b26d9fdd2@github.com>

> JEP 436 proposes a second preview of Virtual Threads to allow time for more feedback and to get more experience with this feature. There is no change in direction, no API changes, and no bulk update of the implementation. For the implementation, there has been ~35 changes/issues pushed to the main line, and a few more coming. For this PR, we just bump the JEP number used by javadoc from 425 to 436.

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

 - Merge
 - JEP 425 -> JEP 436

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11235/files
  - new: https://git.openjdk.org/jdk/pull/11235/files/4d3460ad..99525fd4

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

  Stats: 108818 lines in 1721 files changed: 51177 ins; 38916 del; 18725 mod
  Patch: https://git.openjdk.org/jdk/pull/11235.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11235/head:pull/11235

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

From alanb at openjdk.org  Tue Dec  6 14:55:27 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 Dec 2022 14:55:27 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v37]
In-Reply-To: <gqONKOkeEWYFbAbSNukCiJHu4kEF4UYYyvlyvY_Ijrw=.4ed88dde-08ef-4c4f-b39c-50cbce2bb575@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <gqONKOkeEWYFbAbSNukCiJHu4kEF4UYYyvlyvY_Ijrw=.4ed88dde-08ef-4c4f-b39c-50cbce2bb575@github.com>
Message-ID: <RSMGtY27a9G3yWykX4UU2ebj4r-Uqw0pJIvDTJ7w3Ck=.c9f2e6b6-7a87-4189-9458-37a415eb2fa7@github.com>

On Mon, 5 Dec 2022 12:31:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> JEP 429 implementation.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment

Marked as reviewed by alanb (Reviewer).

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

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

From stsypanov at openjdk.org  Tue Dec  6 15:28:24 2022
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 6 Dec 2022 15:28:24 GMT
Subject: RFR: 8298033: Character.codePointAt(char[], int,
 int) doesn't do JavaDoc-specified check [v5]
In-Reply-To: <dHjviGmASssYfntfClzDC28Ppjrn3pECnO3HzbZHopY=.d9923de3-6de7-41f5-a84e-03a7c5267e2f@github.com>
References: <dHjviGmASssYfntfClzDC28Ppjrn3pECnO3HzbZHopY=.d9923de3-6de7-41f5-a84e-03a7c5267e2f@github.com>
Message-ID: <dhRgJ-zezWDACDdiVj2agQqPREyBYjm5TxV-hUP7d54=.e6e366af-b980-4cf3-aaac-4defae072dd6@github.com>

> I found out that this code
> 
> public class Main {
>     public static void main(String[] args) {
>         String s = "Hello world!";
>         char[] chars = s.toCharArray();
>         int point = Character.codePointAt(chars, -1, 1);
>     }
> }
> 
> throws `ArrayIndexOutOfBoundsException` instead of JavaDoc-specified `IndexOutOfBoundsException`: 
> 
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds for length 12
> 	at java.base/java.lang.Character.codePointAtImpl(Character.java:9254)
> 	at java.base/java.lang.Character.codePointAt(Character.java:9249)
> 	at org.example.Main.main(Main.java:7)
> 
> and the method doesn't check whether `index` parameter is negative:
> 
> public static int codePointAt(char[] a, int index, int limit) {
>     if (index >= limit || limit < 0 || limit > a.length) {
>         throw new IndexOutOfBoundsException();
>     }
>     return codePointAtImpl(a, index, limit);
> }
> 
> I suggest to check the `index` parameter explicitly instead of relying on AIOOBE thrown from accessing the array with negative index.

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

  8298033: Fix Character.codePointBefore()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11480/files
  - new: https://git.openjdk.org/jdk/pull/11480/files/5ed82ac0..9a40f08c

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

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

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

From mbaesken at openjdk.org  Tue Dec  6 15:30:08 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 6 Dec 2022 15:30:08 GMT
Subject: RFR: JDK-8298170 : Introduce a macro for exception check,
 free and return
Message-ID: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>

We have a number of places in the codebase  where a macro could help when we check an exception and afterwrads free something and return.

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

Commit messages:
 - JDK-8298170

Changes: https://git.openjdk.org/jdk/pull/11539/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11539&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298170
  Stats: 87 lines in 7 files changed: 32 ins; 39 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/11539.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11539/head:pull/11539

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

From redestad at openjdk.org  Tue Dec  6 15:31:58 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 6 Dec 2022 15:31:58 GMT
Subject: RFR: 8298177: Various java.lang.invoke cleanups
Message-ID: <lM8wzo_N6Mi4Gc63G82Mhii_OuNcYj0skA5fyR5HsYQ=.3cd9341e-27a2-40d4-ae66-2821e1f5d5f6@github.com>

Various code cleanups around java.lang.invoke code. Started out with dead code removal in `jli.MemberName`, then piled on to fix a set of minor inefficiencies (excessive vararg array allocations, unnecessary defensive cloning of parameter arrays etc).

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

Commit messages:
 - Restore but rename test*Flags
 - Various cleanups in java.lang.invoke

Changes: https://git.openjdk.org/jdk/pull/11540/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11540&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298177
  Stats: 259 lines in 9 files changed: 18 ins; 184 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/11540.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11540/head:pull/11540

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

From dfuchs at openjdk.org  Tue Dec  6 15:41:04 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 6 Dec 2022 15:41:04 GMT
Subject: RFR: 8297976: Remove sun.net.ProgressMonitor and related classes
 [v4]
In-Reply-To: <--xZGrc9oA7pnqyvUDWRUvTNxVLtZsDoe-r0xhyDuKI=.761cc499-2463-457c-9f4a-881c198893df@github.com>
References: <yw8Q8tA8_4jUmc1gWd-xAN-m5kjFPeou3dn0qML9TQ4=.18a511ff-946f-4a8a-8fe3-3eaf00a8a396@github.com>
 <--xZGrc9oA7pnqyvUDWRUvTNxVLtZsDoe-r0xhyDuKI=.761cc499-2463-457c-9f4a-881c198893df@github.com>
Message-ID: <L_65SasAE3Pz36NpvoUG2AFQMnDWrKUjhL7CWoBHUs4=.27e33c8d-1167-4a1b-800a-b326d65f755c@github.com>

On Tue, 6 Dec 2022 13:42:04 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Please review this patch that removes progress monitoring classes used by UrlConnection.
>> Since Java 9 these classes are not used in the JDK, and are not exported from java.base. If anyone was still using them, reimplementing them in user code should be pretty straightforward.
>> 
>> This PR also fixes the issue where MeteredStream finalizer could resurrect an unusable connection, causing unexpected exceptions in other parts of the code.
>> 
>> No new regression test; since we are removing the finalizer, I don't believe we will see the issue again. I can add a test for that if you think it still makes sense.
>> 
>> I had to adjust `ProxyModuleMapping.java` test which used `sun.net.ProgressListener` as an example of a module-private interface; I replaced it with another public interface from the same package.
>> 
>> Existing tier 1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use System.err

Marked as reviewed by dfuchs (Reviewer).

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

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

From dnsimon at openjdk.org  Tue Dec  6 15:46:47 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 6 Dec 2022 15:46:47 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v5]
In-Reply-To: <-vjDxNaafm1m5UERR31dFXH7jdljWTKzsDjntS8v6zs=.4c777f1e-695f-42de-a4b5-0cb0f332243c@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <kU-NHwhiGEJLa7-o38UCemcxhU8WR_ijQBMGOAknOTs=.57d0341c-30af-4c39-ab42-4278fdfb2e5d@github.com>
 <-vjDxNaafm1m5UERR31dFXH7jdljWTKzsDjntS8v6zs=.4c777f1e-695f-42de-a4b5-0cb0f332243c@github.com>
Message-ID: <ZSSq3Pl4Nu-BlC_ccliJcYZ9j297sAFUoybpgBrw0Uo=.5aeec02c-d235-4e07-bb23-bc038d512221@github.com>

On Tue, 6 Dec 2022 13:02:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Doug Simon has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - incorporate review feedback [skip ci]
>>  - removed hard-coded module name [skip ci]
>
> src/java.base/share/classes/jdk/internal/vm/TranslatedException.java line 44:
> 
>> 42:  */
>> 43: @SuppressWarnings("serial")
>> 44: final class TranslatedException extends Exception {
> 
> Would it be possible to re-format this to avoid the wildly long (150+) lines? This seems to be moving jdk.vm.ci.hotspot.TranslatedException and hard to see what is going on.

Is there some tool support for formatting Java source code to meet OpenJDK coding guidelines? Rather unfortunate that one has to do this manually and reviewers have to spend time manually checking it.

> src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 66:
> 
>> 64:      *               only contains String keys and values.
>> 65:      */
>> 66:     private static byte[] serializePropertiesToByteArray(Properties p, boolean filter) throws IOException {
> 
> I think we need more context as to why there are non-String system properties in use here.

This parameter exists to allow a caller to pass in a `Properties` object that is guaranteed to have only String keys and so does not need the extra filtering done in this method. I'll refactor the code to make it clearer.

> src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 106:
> 
>> 104:         }
>> 105:         if (props.get("oome") != null) {
>> 106:             throw new OutOfMemoryError("forced OOME");
> 
> I don't think code in java.base should be checking for a property named "oome".  Is this for a test that sets this system property on the command line?

Sorry, that's debug code that I will remove.

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

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

From mcimadamore at openjdk.org  Tue Dec  6 15:47:11 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 6 Dec 2022 15:47:11 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v37]
In-Reply-To: <gqONKOkeEWYFbAbSNukCiJHu4kEF4UYYyvlyvY_Ijrw=.4ed88dde-08ef-4c4f-b39c-50cbce2bb575@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <gqONKOkeEWYFbAbSNukCiJHu4kEF4UYYyvlyvY_Ijrw=.4ed88dde-08ef-4c4f-b39c-50cbce2bb575@github.com>
Message-ID: <zQWHj3qsDpB_8k0Myg0DiKy79YEXjeqkEqfr6_aqYOQ=.f6eb337e-d84b-44ed-9c33-5650da147602@github.com>

On Mon, 5 Dec 2022 12:31:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> JEP 429 implementation.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment

Marked as reviewed by mcimadamore (Reviewer).

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

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

From rriggs at openjdk.org  Tue Dec  6 15:49:29 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 6 Dec 2022 15:49:29 GMT
Subject: RFR: 8297271: AccessFlags should be specific to class file version
 [v3]
In-Reply-To: <T91R2VWcljZdnCDmWKcuSubKtS2qk5e5sGgKEi1v3Yk=.510cef48-e0f0-4590-b7d4-c16aafe71087@github.com>
References: <T91R2VWcljZdnCDmWKcuSubKtS2qk5e5sGgKEi1v3Yk=.510cef48-e0f0-4590-b7d4-c16aafe71087@github.com>
Message-ID: <Orv3q9A6Ca37lUx_0AEtBD1D1S7tMS-3qZnxrKEce4U=.1bf02722-5888-460a-9f5c-1ddfee783423@github.com>

> The accessFlags() methods added (in JDK 20, the current release) to java.lang.Class, java.lang.reflect.Executable, and java.lang.reflect.Field implicitly uses the access flags from the current/most recent class file format version. For current and past class file format versions there are few significant variations but future changes are anticipated that change the meaning of some access flag mask bits.
> 
> The accessFlags() methods are clarified to return the access flags that are applicable to the class file format version of the class. The existing AccessFlag.Locations API already contains information about the locations that are applicable to a class file format version. That information should be used to construct the set of AccessFlags returned. A method is added to AccessFlag that returns the applicable flags for a particular mask, Location, and class file format version:

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

  Class.accessFlags(): Remove an overeaching requirement on array component type
  AccessFlag.maskToAccessFlags(mask, location, cffv): clarify the handling of undefined mask flags

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11399/files
  - new: https://git.openjdk.org/jdk/pull/11399/files/3be38680..99931651

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

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

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

From dnsimon at openjdk.org  Tue Dec  6 16:06:34 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 6 Dec 2022 16:06:34 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v6]
In-Reply-To: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
Message-ID: <7f0PjG00BGhLCA3Kjlohhp3YGB_Xv8BPexToz66PxWc=.cb042f58-79b2-4c80-a5d4-245e95227858@github.com>

> Libgraal is compiled ahead of time and should not need any JVMCI Java code to be dynamically loaded at runtime. Prior to this PR, this is not the case due to:
> 
> * Code to copy system properties from the HotSpot heap into the libgraal heap. This is in `jdk.vm.ci.services.Services.initializeSavedProperties(byte[])` and `jdk.vm.ci.services.Services.serializeSavedProperties()`. This code should be moved to `java.base/jdk.internal.vm.VMSupport`.
> * Code to translate exceptions from the HotSpot heap into the libgraal heap and vice versa. This code should be moved from `jdk.internal.vm.ci//jdk.vm.ci.hotspot.TranslatedException` to `java.base/jdk.internal.vm.VMSupport`.
> 
> This PR makes the above changes. As a result, it's possible to build a JDK image that includes (and uses) libgraal but does not include `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces footprint and better isolates the JAVMCI and the Graal compiler as accessing these components from Java code is now impossible.

Doug Simon has updated the pull request incrementally with four additional commits since the last revision:

 - formatting to avoid very long lines [skip ci]
 - removed debug code [skip ci]
 - clarify Properties filtering [skip ci]
 - remove debug code [skip ci]

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11513/files
  - new: https://git.openjdk.org/jdk/pull/11513/files/342d5e3c..bdbe7cf2

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

  Stats: 66 lines in 2 files changed: 23 ins; 14 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/11513.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11513/head:pull/11513

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

From cstein at openjdk.org  Tue Dec  6 16:18:39 2022
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 6 Dec 2022 16:18:39 GMT
Subject: RFR: 8298178: Update to use jtreg 7.1.1
Message-ID: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>

Please review the change to update to using jtreg 7.1.1.

The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.

This pull request was created by copying the following and using 7.1.1 at appropriate places:
- https://github.com/openjdk/jdk/pull/11416

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

Commit messages:
 - 8298178: Update to use jtreg 7.1.1

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

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

From cstein at openjdk.org  Tue Dec  6 16:18:40 2022
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 6 Dec 2022 16:18:40 GMT
Subject: RFR: 8298178: Update to use jtreg 7.1.1
In-Reply-To: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
References: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
Message-ID: <DpjzUNDkTEhe5okO87rinHGfKI_5TdH_YcF3i0sVkq8=.bcec390d-771b-4fc4-a092-d5cf8685a542@github.com>

On Tue, 6 Dec 2022 16:07:44 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.1.1.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
> 
> This pull request was created by copying the following and using 7.1.1 at appropriate places:
> - https://github.com/openjdk/jdk/pull/11416

Fails due to missing tag `jtreg-7.1.1+1` at https://github.com/openjdk/jtreg/commit/3ea7f9f8fe7389d0eadc8cd02df38431043dd6fe

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

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

From jvernee at openjdk.org  Tue Dec  6 16:22:47 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 6 Dec 2022 16:22:47 GMT
Subject: RFR: 8298177: Various java.lang.invoke cleanups
In-Reply-To: <lM8wzo_N6Mi4Gc63G82Mhii_OuNcYj0skA5fyR5HsYQ=.3cd9341e-27a2-40d4-ae66-2821e1f5d5f6@github.com>
References: <lM8wzo_N6Mi4Gc63G82Mhii_OuNcYj0skA5fyR5HsYQ=.3cd9341e-27a2-40d4-ae66-2821e1f5d5f6@github.com>
Message-ID: <DsU5Lu0leJ8luksEFP5e76InAxfVs75qQzDX2Lh_qxA=.38029c56-bd3d-4316-9867-c589d0426cc4@github.com>

On Tue, 6 Dec 2022 15:22:27 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Various code cleanups around java.lang.invoke code. Started out with dead code removal in `jli.MemberName`, then piled on to fix a set of minor inefficiencies (excessive vararg array allocations, unnecessary defensive cloning of parameter arrays etc).

src/java.base/share/classes/java/lang/invoke/MemberName.java line 578:

> 576:             throw new LinkageError(m.toString());
> 577:         }
> 578:         assert(isResolved());

I don't see why this can be removed. Can you explain?

src/java.base/share/classes/java/lang/invoke/MemberName.java line 657:

> 655:         this.name = fld.getName();
> 656:         this.type = fld.getType();
> 657:         // assert((REF_putStatic - REF_getStatic) == (REF_putField - REF_getField));

Intellij says this is always true. Maybe it could be put in the `static {}` block instead?

Also, I think this should just be removed if it's not needed. (instead of commented out)

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

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

From bpb at openjdk.org  Tue Dec  6 16:23:03 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 6 Dec 2022 16:23:03 GMT
Subject: RFR: JDK-8297298 - SequenceInputStream should override transferTo
 [v2]
In-Reply-To: <F6eAl7jxzmSj577gvVp54QKB_udCemJL_mfyxh5iQMQ=.e599efa7-f0d1-49fc-ae90-55598f4f1bc3@github.com>
References: <f29hhy9J107mH2fJNTnIkR4u8JDXaHym8Mt_H9rwo8Y=.159e4f3e-e38f-496e-a6e2-65b3635bd897@github.com>
 <Ike0eQ9Ie59ga1NR7B1tECSMhPIjSKpXqdZCGUBtDL4=.761ef92f-260a-41ab-a483-aa2a2f6c9b69@github.com>
 <F6eAl7jxzmSj577gvVp54QKB_udCemJL_mfyxh5iQMQ=.e599efa7-f0d1-49fc-ae90-55598f4f1bc3@github.com>
Message-ID: <z4ZRDUbpzJKP7yHpSuFnmYfKvKRpkh6nb93EncLIBB4=.22395784-316b-4434-9a99-1915d9c58baf@github.com>

On Mon, 5 Dec 2022 19:42:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed bug number
>
> test/jdk/java/io/SequenceInputStream/TransferTo.java line 206:
> 
>> 204:     }
>> 205: 
>> 206: }
> 
> As auto-detected, there is no newline at the end of this file. Otherwise it appears all right.

@mkarg Please take account of the JDK 20 rampdown at 16:00 UTC Thursday and that Pacific Time is eight hours behind. Thanks.

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

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

From redestad at openjdk.org  Tue Dec  6 16:28:49 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 6 Dec 2022 16:28:49 GMT
Subject: RFR: 8298177: Various java.lang.invoke cleanups
In-Reply-To: <DsU5Lu0leJ8luksEFP5e76InAxfVs75qQzDX2Lh_qxA=.38029c56-bd3d-4316-9867-c589d0426cc4@github.com>
References: <lM8wzo_N6Mi4Gc63G82Mhii_OuNcYj0skA5fyR5HsYQ=.3cd9341e-27a2-40d4-ae66-2821e1f5d5f6@github.com>
 <DsU5Lu0leJ8luksEFP5e76InAxfVs75qQzDX2Lh_qxA=.38029c56-bd3d-4316-9867-c589d0426cc4@github.com>
Message-ID: <PYR1Mj-onJFMX61iI3HuiwVbYaMXDd9M9cme6DRiseQ=.11788be0-6872-4af5-8c81-8716acd6b76b@github.com>

On Tue, 6 Dec 2022 16:13:12 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Various code cleanups around java.lang.invoke code. Started out with dead code removal in `jli.MemberName`, then piled on to fix a set of minor inefficiencies (excessive vararg array allocations, unnecessary defensive cloning of parameter arrays etc).
>
> src/java.base/share/classes/java/lang/invoke/MemberName.java line 578:
> 
>> 576:             throw new LinkageError(m.toString());
>> 577:         }
>> 578:         assert(isResolved());
> 
> I don't see why this can be removed. Can you explain?

the `if (clazz == null)` block above either returns or throws an error, so intellij was marking this as always true.

> src/java.base/share/classes/java/lang/invoke/MemberName.java line 657:
> 
>> 655:         this.name = fld.getName();
>> 656:         this.type = fld.getType();
>> 657:         // assert((REF_putStatic - REF_getStatic) == (REF_putField - REF_getField));
> 
> Intellij says this is always true. Maybe it could be put in the `static {}` block instead?
> 
> Also, I think this should just be removed if it's not needed. (instead of commented out)

Will fix by extracting to a `static` block above

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

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

From redestad at openjdk.org  Tue Dec  6 16:36:26 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 6 Dec 2022 16:36:26 GMT
Subject: RFR: 8298177: Various java.lang.invoke cleanups [v2]
In-Reply-To: <lM8wzo_N6Mi4Gc63G82Mhii_OuNcYj0skA5fyR5HsYQ=.3cd9341e-27a2-40d4-ae66-2821e1f5d5f6@github.com>
References: <lM8wzo_N6Mi4Gc63G82Mhii_OuNcYj0skA5fyR5HsYQ=.3cd9341e-27a2-40d4-ae66-2821e1f5d5f6@github.com>
Message-ID: <9-VXwGkWUeOUmK3HGgN-as_roFPlf5wJFPhJo4Ro3cY=.23a2058f-ae1c-46b8-901e-a5aa618bff2d@github.com>

> Various code cleanups around java.lang.invoke code. Started out with dead code removal in `jli.MemberName`, then piled on to fix a set of minor inefficiencies (excessive vararg array allocations, unnecessary defensive cloning of parameter arrays etc).

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

  Address review comment, remove more code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11540/files
  - new: https://git.openjdk.org/jdk/pull/11540/files/a02cb50e..c29ce261

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

  Stats: 26 lines in 2 files changed: 4 ins; 21 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11540.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11540/head:pull/11540

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

From alanb at openjdk.org  Tue Dec  6 16:48:38 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 Dec 2022 16:48:38 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v6]
In-Reply-To: <Ouly-NyXJMLpyNiBnUNkO0Zhus8EZc3S03_PsCP40vk=.47c03775-acc8-4aa4-a09d-75e9337f915e@github.com>
References: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
 <Ouly-NyXJMLpyNiBnUNkO0Zhus8EZc3S03_PsCP40vk=.47c03775-acc8-4aa4-a09d-75e9337f915e@github.com>
Message-ID: <iS9jjhVy4BtehQablwAX9B2fbOF6M_nfP7O_TGpppqY=.3c0cc6a4-dbbf-48fb-a09c-c9c2ce8d4aee@github.com>

On Mon, 5 Dec 2022 21:38:20 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image".
>> 
>> Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods
>
> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refine test
>   
>   Co-authored-by: Christoph <siedlerkiller at gmail.com>

Would it be possible to paste in a summary on the VerifyError with the previous iteration? If I read the latest update then the limit per helper method has been bump to avoid it, is that right?

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

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

From rriggs at openjdk.org  Tue Dec  6 16:49:37 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 6 Dec 2022 16:49:37 GMT
Subject: RFR: 8298033: Character.codePointAt(char[], int,
 int) doesn't do JavaDoc-specified check [v5]
In-Reply-To: <dhRgJ-zezWDACDdiVj2agQqPREyBYjm5TxV-hUP7d54=.e6e366af-b980-4cf3-aaac-4defae072dd6@github.com>
References: <dHjviGmASssYfntfClzDC28Ppjrn3pECnO3HzbZHopY=.d9923de3-6de7-41f5-a84e-03a7c5267e2f@github.com>
 <dhRgJ-zezWDACDdiVj2agQqPREyBYjm5TxV-hUP7d54=.e6e366af-b980-4cf3-aaac-4defae072dd6@github.com>
Message-ID: <n_5DdGq4c_qUAHFZLNPW3P-dohFloZWoERw4Mmqq3q0=.ef688a85-c6b0-4cd0-afdf-4a5784760ce8@github.com>

On Tue, 6 Dec 2022 15:28:24 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> I found out that this code
>> 
>> public class Main {
>>     public static void main(String[] args) {
>>         String s = "Hello world!";
>>         char[] chars = s.toCharArray();
>>         int point = Character.codePointAt(chars, -1, 1);
>>     }
>> }
>> 
>> throws `ArrayIndexOutOfBoundsException` instead of JavaDoc-specified `IndexOutOfBoundsException`: 
>> 
>> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds for length 12
>> 	at java.base/java.lang.Character.codePointAtImpl(Character.java:9254)
>> 	at java.base/java.lang.Character.codePointAt(Character.java:9249)
>> 	at org.example.Main.main(Main.java:7)
>> 
>> and the method doesn't check whether `index` parameter is negative:
>> 
>> public static int codePointAt(char[] a, int index, int limit) {
>>     if (index >= limit || limit < 0 || limit > a.length) {
>>         throw new IndexOutOfBoundsException();
>>     }
>>     return codePointAtImpl(a, index, limit);
>> }
>> 
>> I suggest to check the `index` parameter explicitly instead of relying on AIOOBE thrown from accessing the array with negative index.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8298033: Fix Character.codePointBefore()

src/java.base/share/classes/java/lang/Character.java line 9480:

> 9478:      */
> 9479:     public static int codePointBefore(char[] a, int index, int start) {
> 9480:         if (index <= start || start < 0 || start >= a.length || index > a.length) {

Since `index > start` it is sufficient to throw `index > a.length`.
The check `start >= a.length` is redundant.

`0 <= start < index <= a.length`

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

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

From naoto at openjdk.org  Tue Dec  6 16:51:12 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Dec 2022 16:51:12 GMT
Subject: RFR: 8297804: (tz) Update Timezone Data to 2022g [v2]
In-Reply-To: <LUd0Rb4G80fdee18UQItifokHjI6FI31GBVTmDu5m_M=.0dfca816-dae6-4276-ab67-6de9bec62081@github.com>
References: <4b1tG73Xp3BMUy2X6Ab7W2So7u4jcSu9SrAWvrHLw1g=.d6218261-7f4e-48c5-9989-eb0887e0207e@github.com>
 <LUd0Rb4G80fdee18UQItifokHjI6FI31GBVTmDu5m_M=.0dfca816-dae6-4276-ab67-6de9bec62081@github.com>
Message-ID: <UcmSMlYIhAH0trJwDZhYIW7jaeA5VyPAzD6FkAoaEt8=.c8d7c08c-3198-4ba3-9cf4-bb4cb2a16dde@github.com>

On Mon, 5 Dec 2022 14:38:51 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> Update to the latest tzdata, 2022g.
>> 
>> Primary changes:
>> * `America/Ojinaga` (CST) is split, creating `America/Ciudad_Juarez` (MST/MDT)
>> * `America/Pangnirtung` becomes a link to `America/Iqaluit`
>> * `America/Ojinaga` gains DST (CDT)
>> 
>> See bug for the full details.
>> 
>> There will likely also be CLDR changes ([CLDR-16181](https://unicode-org.atlassian.net/browse/CLDR-16181)) that are not yet included in this change. We can either wait for these and include them in this patch, or do a separate change like [JDK-8296715](https://bugs.openjdk.org/browse/JDK-8296715)
>> 
>> Tests in `java/util/TimeZone`, `java/time/test` and `sun/text/resources` all pass.
>
> Andrew John Hughes has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add CLDR changes from https://github.com/unicode-org/cldr/commit/0bd22412b35b6e7037a39c3ad6a4dc49c699439b
>  - Update tzdata version

Thanks for confirming. Looks good to me.

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

Marked as reviewed by naoto (Reviewer).

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

From dnsimon at openjdk.org  Tue Dec  6 16:53:21 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 6 Dec 2022 16:53:21 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v5]
In-Reply-To: <ZSSq3Pl4Nu-BlC_ccliJcYZ9j297sAFUoybpgBrw0Uo=.5aeec02c-d235-4e07-bb23-bc038d512221@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <kU-NHwhiGEJLa7-o38UCemcxhU8WR_ijQBMGOAknOTs=.57d0341c-30af-4c39-ab42-4278fdfb2e5d@github.com>
 <-vjDxNaafm1m5UERR31dFXH7jdljWTKzsDjntS8v6zs=.4c777f1e-695f-42de-a4b5-0cb0f332243c@github.com>
 <ZSSq3Pl4Nu-BlC_ccliJcYZ9j297sAFUoybpgBrw0Uo=.5aeec02c-d235-4e07-bb23-bc038d512221@github.com>
Message-ID: <YYb6ipJjooXfXoFyWhz_Sus76yoDgkB5OIKvFTsYsWA=.c1a15d4f-c6b1-4610-b110-dbab35b14667@github.com>

On Tue, 6 Dec 2022 15:41:20 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 66:
>> 
>>> 64:      *               only contains String keys and values.
>>> 65:      */
>>> 66:     private static byte[] serializePropertiesToByteArray(Properties p, boolean filter) throws IOException {
>> 
>> I think we need more context as to why there are non-String system properties in use here.
>
> This parameter exists to allow a caller to pass in a `Properties` object that is guaranteed to have only String keys and so does not need the extra filtering done in this method. I'll refactor the code to make it clearer.

Hopefully this makes it clearer: https://github.com/openjdk/jdk/pull/11513/commits/5c610798fe4eaed7efeb2eebcf1e5db47714caee

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

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

From psandoz at openjdk.org  Tue Dec  6 16:56:23 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 6 Dec 2022 16:56:23 GMT
Subject: RFR: JDK-8277074: Qualified exported types show up in JavaDoc
In-Reply-To: <xR3kgCjjyFNOCQ2zSYEkv5HjktzCsFsahCsbNGs5Tw4=.ec8b3808-fe12-41b1-986a-64dd67073c3c@github.com>
References: <xR3kgCjjyFNOCQ2zSYEkv5HjktzCsFsahCsbNGs5Tw4=.ec8b3808-fe12-41b1-986a-64dd67073c3c@github.com>
Message-ID: <cnMmMWmODGQdRHy2J3zQat-bPyoLNgOCnkfdGoy-iTg=.b1dba0b8-3490-463e-9080-4a2d9c1324d0@github.com>

On Tue, 15 Nov 2022 12:15:42 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a simple change to hide internal classes in generated documentation by adding doc comments containing a `@hidden` tag. I verified the fix by making sure `grep -r jdk.internal` returns no matches in the generated documentation tree.

Changes for the Vector API are good.

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

Marked as reviewed by psandoz (Reviewer).

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

From darcy at openjdk.org  Tue Dec  6 17:05:16 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 6 Dec 2022 17:05:16 GMT
Subject: RFR: JDK-8296149: Start of release updates for JDK 21 [v4]
In-Reply-To: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
Message-ID: <UECiEmgmeZJITMUwqB3jhQJMET3cdxeUca6Be0VUaPc=.a605d399-63db-4c13-8700-415ca3f4b11e@github.com>

> Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21.

Joe Darcy 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-8296149
 - Merge branch 'master' into JDK-8296149
 - Merge branch 'master' into JDK-8296149
 - Merge branch 'master' into JDK-8296149
 - Merge branch 'master' into JDK-8296149
 - Update symbol information for JDK 20 build 26.
 - Merge branch 'master' into JDK-8296149
 - Merge branch 'master' into JDK-8296149
 - Fix failed HotSpot regression tests.
 - Merge branch 'master' into JDK-8296149
 - ... and 9 more: https://git.openjdk.org/jdk/compare/0d2a9ee5...e252e83a

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

Changes: https://git.openjdk.org/jdk/pull/10924/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10924&range=03
  Stats: 3717 lines in 70 files changed: 3672 ins; 1 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/10924.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10924/head:pull/10924

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

From erikj at openjdk.org  Tue Dec  6 17:24:43 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 6 Dec 2022 17:24:43 GMT
Subject: RFR: 8298178: Update to use jtreg 7.1.1
In-Reply-To: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
References: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
Message-ID: <WaxaNiKlHmIKgFGXDqswGhrbLjtfezJ0ceIFR2gCo7M=.7bb864d4-b3d4-473a-977e-83c410d9bceb@github.com>

On Tue, 6 Dec 2022 16:07:44 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.1.1.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
> 
> This pull request was created by copying the following and using 7.1.1 at appropriate places:
> - https://github.com/openjdk/jdk/pull/11416

Marked as reviewed by erikj (Reviewer).

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

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

From iris at openjdk.org  Tue Dec  6 17:26:07 2022
From: iris at openjdk.org (Iris Clark)
Date: Tue, 6 Dec 2022 17:26:07 GMT
Subject: RFR: JDK-8296149: Start of release updates for JDK 21 [v4]
In-Reply-To: <UECiEmgmeZJITMUwqB3jhQJMET3cdxeUca6Be0VUaPc=.a605d399-63db-4c13-8700-415ca3f4b11e@github.com>
References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
 <UECiEmgmeZJITMUwqB3jhQJMET3cdxeUca6Be0VUaPc=.a605d399-63db-4c13-8700-415ca3f4b11e@github.com>
Message-ID: <6e9IQwG-3a6fzbD13_qpOZOob8vsFke3z1ecLQBZcYo=.e80a76b1-87c5-42a1-b2d2-fab62476b985@github.com>

On Tue, 6 Dec 2022 17:05:16 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21.
>
> Joe Darcy 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-8296149
>  - Merge branch 'master' into JDK-8296149
>  - Merge branch 'master' into JDK-8296149
>  - Merge branch 'master' into JDK-8296149
>  - Merge branch 'master' into JDK-8296149
>  - Update symbol information for JDK 20 build 26.
>  - Merge branch 'master' into JDK-8296149
>  - Merge branch 'master' into JDK-8296149
>  - Fix failed HotSpot regression tests.
>  - Merge branch 'master' into JDK-8296149
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/0d2a9ee5...e252e83a

Still looks good.

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

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

From cstein at openjdk.org  Tue Dec  6 17:31:03 2022
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 6 Dec 2022 17:31:03 GMT
Subject: RFR: 8298178: Update to use jtreg 7.1.1
In-Reply-To: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
References: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
Message-ID: <442ULv75pFX-axmZePsFEhAqdTqj0ms-Sn6WpZXB8Bw=.e6997aac-9b1f-4f81-9af0-864ba1dfd853@github.com>

On Tue, 6 Dec 2022 16:07:44 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.1.1.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
> 
> This pull request was created by copying the following and using 7.1.1 at appropriate places:
> - https://github.com/openjdk/jdk/pull/11416

Tag [jtreg-7.1.1+1](https://github.com/openjdk/jtreg/releases/tag/jtreg-7.1.1+1) was just added. Is it possible to restart "pre-submit tests" without performing a "noop" (touching a file) commit?

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

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

From darcy at openjdk.org  Tue Dec  6 17:38:29 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 6 Dec 2022 17:38:29 GMT
Subject: RFR: JDK-8296149: Start of release updates for JDK 21 [v5]
In-Reply-To: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
Message-ID: <R3u4O7-zTndZc3wG4kUwdC2rRhV-KvsVzDjF6eDlwjY=.b34f30cb-ec77-40e6-b110-fe731bde5a52@github.com>

> Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21.

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

  Respond to review feedback; reformat test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10924/files
  - new: https://git.openjdk.org/jdk/pull/10924/files/e252e83a..fc28c49a

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

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

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

From cstein at openjdk.org  Tue Dec  6 17:45:06 2022
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 6 Dec 2022 17:45:06 GMT
Subject: RFR: 8298178: Update to use jtreg 7.1.1 [v2]
In-Reply-To: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
References: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
Message-ID: <_4nUcA_FoL0cLK-FE825zUMfVQ15bM0e0YNPmxe0reA=.799970b2-9770-4f5a-9cee-9a1197a6d431@github.com>

> Please review the change to update to using jtreg 7.1.1.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
> 
> This pull request was created by copying the following and using 7.1.1 at appropriate places:
> - https://github.com/openjdk/jdk/pull/11416

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

 - Restart actions
 - [skip ci] Prepare restart of actions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11542/files
  - new: https://git.openjdk.org/jdk/pull/11542/files/35c49b7e..de8f785e

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

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

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

From cstein at openjdk.org  Tue Dec  6 17:48:25 2022
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 6 Dec 2022 17:48:25 GMT
Subject: RFR: 8298178: Update to use jtreg 7.1.1 [v3]
In-Reply-To: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
References: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
Message-ID: <htSNzX0Tc8YPWY-ufy1AIfJxj_tpeGmjnang73y75Mg=.9c106ab7-1ddc-40df-8e30-b31d29c69b2c@github.com>

> Please review the change to update to using jtreg 7.1.1.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
> 
> This pull request was created by copying the following and using 7.1.1 at appropriate places:
> - https://github.com/openjdk/jdk/pull/11416

Christian Stein has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains two commits:

 - [skip ci] Prepare restart of actions
 - 8298178: Update to use jtreg 7.1.1

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11542/files
  - new: https://git.openjdk.org/jdk/pull/11542/files/de8f785e..96fcbf96

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

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

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

From cstein at openjdk.org  Tue Dec  6 17:50:14 2022
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 6 Dec 2022 17:50:14 GMT
Subject: RFR: 8298178: Update to use jtreg 7.1.1 [v2]
In-Reply-To: <_4nUcA_FoL0cLK-FE825zUMfVQ15bM0e0YNPmxe0reA=.799970b2-9770-4f5a-9cee-9a1197a6d431@github.com>
References: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
 <_4nUcA_FoL0cLK-FE825zUMfVQ15bM0e0YNPmxe0reA=.799970b2-9770-4f5a-9cee-9a1197a6d431@github.com>
Message-ID: <sh57rFLn0TBgSOd48dEAsELiZwLskYyjHqU95JqEedA=.6de2e612-53c9-4956-855f-4b6f2d5bb235@github.com>

On Tue, 6 Dec 2022 17:45:06 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review the change to update to using jtreg 7.1.1.
>> 
>> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
>> 
>> This pull request was created by copying the following and using 7.1.1 at appropriate places:
>> - https://github.com/openjdk/jdk/pull/11416
>
> Christian Stein has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restart actions
>  - [skip ci] Prepare restart of actions

Restarted actions are running at: https://github.com/sormuras/jdk/actions/runs/3632002366

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

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

From naoto at openjdk.org  Tue Dec  6 18:01:27 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Dec 2022 18:01:27 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v8]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <Hgi1xIbIUO4QdDPDs3iYPYBi5j6iXb5BGXa6sbuNm7w=.741f911f-e343-4a52-9e01-41549509fb9e@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

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

 - Addressing review comments
 - Merge branch 'master' into JDK-8295803-PluginConsole
 - Fixed the copyright year
 - oleole -> ole
 - Addressing review comments.
 - Changed the expected behavior when the SecurityManager is enabled
 - Added more tests, loading with doPrivileged()
 - Adds a test
 - Removed JavaIOAccess.charset() which is no longer needed
 - Minor fixup
 - ... and 12 more: https://git.openjdk.org/jdk/compare/ce6f50f2...204690cf

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/8b6859ed..204690cf

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

  Stats: 47908 lines in 1086 files changed: 19444 ins; 21552 del; 6912 mod
  Patch: https://git.openjdk.org/jdk/pull/11421.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11421/head:pull/11421

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

From redestad at openjdk.org  Tue Dec  6 18:06:36 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 6 Dec 2022 18:06:36 GMT
Subject: RFR: 8298177: Various java.lang.invoke cleanups [v3]
In-Reply-To: <lM8wzo_N6Mi4Gc63G82Mhii_OuNcYj0skA5fyR5HsYQ=.3cd9341e-27a2-40d4-ae66-2821e1f5d5f6@github.com>
References: <lM8wzo_N6Mi4Gc63G82Mhii_OuNcYj0skA5fyR5HsYQ=.3cd9341e-27a2-40d4-ae66-2821e1f5d5f6@github.com>
Message-ID: <HVQ0pa8CBsuvGO3Jzc5oVbof9rqPr2Mq2b9sBaxG74c=.6df56921-23ab-4930-976c-681605fff684@github.com>

> Various code cleanups around java.lang.invoke code. Started out with dead code removal in `jli.MemberName`, then piled on to fix a set of minor inefficiencies (excessive vararg array allocations, unnecessary defensive cloning of parameter arrays etc).

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

  Fix 8284363, more code removal

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11540/files
  - new: https://git.openjdk.org/jdk/pull/11540/files/c29ce261..5a04e500

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

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

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

From naoto at openjdk.org  Tue Dec  6 18:13:21 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Dec 2022 18:13:21 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <NBdqUPP-JYFqnssVlTqDa60SOyWjyrJvXPQ8DDWSImQ=.d07abcf6-b1e5-461b-81b9-07f5d4406907@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
 <NBdqUPP-JYFqnssVlTqDa60SOyWjyrJvXPQ8DDWSImQ=.d07abcf6-b1e5-461b-81b9-07f5d4406907@github.com>
Message-ID: <dWZf8Ig6HVqq-7sHncITq__8v0Bl3kYpCJdu-WUZn1o=.18639d8a-bdb3-47ea-8ab8-e29096886878@github.com>

On Tue, 6 Dec 2022 06:19:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed the copyright year
>
> src/java.base/share/classes/java/io/Console.java line 99:
> 
>> 97:  */
>> 98: 
>> 99: public class Console implements Flushable
> 
> Should we perhaps `seal` this class and only `permit` `ProxyingConsole` to `extend` it?

Right. Will address it after this PR.

> src/java.base/share/classes/java/io/Console.java line 615:
> 
>> 613:                 var consModName = System.getProperty("jdk.console",
>> 614:                         JdkConsoleProvider.DEFAULT_PROVIDER_MODULE_NAME);
>> 615:                 return ServiceLoader.load(JdkConsoleProvider.class).stream()
> 
> Are we intentionally using thread context classloader (which can be different depending on which caller ends up first accessing/initializing the `java.io.Console` class) to load these services?
> 
> I initially thought that `java.io.Console` might be used/initialized early in the bootstrap process of Java so the classloader could perhaps be deterministic, but running a trivial Java application with `-verbose:class` shows that `java.io.Console` doesn't get instantiated during the launch, so that leaves this code to "first access wins" situation and maybe an "incorrect" context classloader which doesn't have access the configured `jdk.console` module may end up causing this code to default to `java.io.Console`?
> 
> 
> public class Hello {
> 	public static void main(final String[] args) {
> 	}
> }
> 
> 
> java -verbose:class Hello.java
> 
> 
> Instead, should we perhaps use the ModuleLayer to find this configured module and then use its classloader to load the `JdkConsoleProvider` service provider? Something like:
> 
> 
> final Optional<Module> mod = ModuleLayer.boot().findModule(consModName);
> // ... if not present default to java.io.Console else use the module's classloader to try and load the JdkConsoleProvider
> return ServiceLoader.load(JdkConsoleProvider.class, mod.get().getClassLoader()).stream()......

Changed it to use the boot layer `ServiceLoader.load(ModuleLayer.boot(), JdkConsoleProvider.class)`

> src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 113:
> 
>> 111:         public JdkConsoleImpl() {
>> 112:             try {
>> 113:                 terminal = TerminalBuilder.builder().build();
> 
> The `java.io.Console` in its static initialization code has some logic to determine the `Charset` to use. Should that same `Charset` (or logic) be used here to build the terminal? Something like `TerminalBuilder.builder().encoding(fooBarCharset).build();`.

Initially, I thought of having charset as an argument to the constructor but realized jline would delve into the platform and figure out the same encoding, so I omitted it. However now I realized that the user could specify the standard out encoding via the `stdout/err.encoding` system property. So I revived the charset argument, as in your suggestion.

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

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

From naoto at openjdk.org  Tue Dec  6 18:13:22 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Dec 2022 18:13:22 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <aRStSfbyYDxmNb1dKkfmvu2sLsOygInBUAZiWyQ0q4A=.81384435-4139-4761-af05-66a9d24cb2e4@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
 <rzPVmUKQdK06b_4r9uiV6v_HM26LkdVGmf2BzpdGBXQ=.d882201a-01bf-429c-9ab5-4946a71b02b4@github.com>
 <aRStSfbyYDxmNb1dKkfmvu2sLsOygInBUAZiWyQ0q4A=.81384435-4139-4761-af05-66a9d24cb2e4@github.com>
Message-ID: <2uHRKaMBaLaQmhYzbo1yOetB4DYyrbm7rxW-sFGg0n8=.4e8e537d-e6a3-4299-81a2-b93147359be0@github.com>

On Tue, 6 Dec 2022 07:34:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Console.java line 616:
>> 
>>> 614:                         JdkConsoleProvider.DEFAULT_PROVIDER_MODULE_NAME);
>>> 615:                 return ServiceLoader.load(JdkConsoleProvider.class).stream()
>>> 616:                         .map(ServiceLoader.Provider::get)
>> 
>> Furthermore, I think in its current form it means that this will load/instantiate any `JdkConsoleProvider` implementations that are accessible to the thread context classloader but may not have been from the module configured through `jdk.console` system property. That could potentially mean, in the best case, unnecessary classloading of additional classes and in the worst case, could result in `ServiceLoader.Provider::get` throwing a `ServiceConfigurationError` error for any of such unused provider implementations, thus forcing us to use `java.io.Console` instance.
>
>> Furthermore, I think in its current form it means that this will load/instantiate any `JdkConsoleProvider` implementations that are accessible to the thread context classloader but may not have been from the module configured through `jdk.console` system property. That could potentially mean, in the best case, unnecessary classloading of additional classes and in the worst case, could result in `ServiceLoader.Provider::get` throwing a `ServiceConfigurationError` error for any of such unused provider implementations, thus forcing us to use `java.io.Console` instance.
> 
> You are right that the ServiceLoader.load should specify the system class loader or the boot layer. However, there isn't an accessibility issue as a class loader just load classes so it's more about visibility and whether the TCCL will ultimately delegate to the application class loader.

`module-info.java` in the java.base only allows `jdk.internal.le` and `jdk.jshell` modules to access the `jdk.internal.io.JdkConsoleProvider` interface. So unless the user intentionally exports it, no other implementations are effectively instantiated.

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

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

From prr at openjdk.org  Tue Dec  6 18:35:05 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 6 Dec 2022 18:35:05 GMT
Subject: RFR: JDK-8298170 : Introduce a macro for exception check,
 free and return
In-Reply-To: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
References: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
Message-ID: <P4RXObyKU5mTlOUCcSUCrvu4eDFBpoMIV6uJrwsQiwA=.715ee905-2079-446d-a4c6-e92af67f5bcf@github.com>

On Tue, 6 Dec 2022 15:20:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have a number of places in the codebase  where a macro could help when we check an exception and afterwrads free something and return.

I'm OK with the idea and the specific desktop change.
I'll leave the rest to the appropriate component teams.
Seems this needs > 1 reviewer tho' because of the different areas.

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

Marked as reviewed by prr (Reviewer).

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

From stsypanov at openjdk.org  Tue Dec  6 18:39:28 2022
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 6 Dec 2022 18:39:28 GMT
Subject: RFR: 8298033: Character.codePointAt(char[], int,
 int) doesn't do JavaDoc-specified check [v6]
In-Reply-To: <dHjviGmASssYfntfClzDC28Ppjrn3pECnO3HzbZHopY=.d9923de3-6de7-41f5-a84e-03a7c5267e2f@github.com>
References: <dHjviGmASssYfntfClzDC28Ppjrn3pECnO3HzbZHopY=.d9923de3-6de7-41f5-a84e-03a7c5267e2f@github.com>
Message-ID: <VftnfWbHQbak_oaF8D4eULvTMUj7mzDm8gaWl8qXdjE=.92a052a8-1474-4a92-ac4b-bf827a5f9154@github.com>

> I found out that this code
> 
> public class Main {
>     public static void main(String[] args) {
>         String s = "Hello world!";
>         char[] chars = s.toCharArray();
>         int point = Character.codePointAt(chars, -1, 1);
>     }
> }
> 
> throws `ArrayIndexOutOfBoundsException` instead of JavaDoc-specified `IndexOutOfBoundsException`: 
> 
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds for length 12
> 	at java.base/java.lang.Character.codePointAtImpl(Character.java:9254)
> 	at java.base/java.lang.Character.codePointAt(Character.java:9249)
> 	at org.example.Main.main(Main.java:7)
> 
> and the method doesn't check whether `index` parameter is negative:
> 
> public static int codePointAt(char[] a, int index, int limit) {
>     if (index >= limit || limit < 0 || limit > a.length) {
>         throw new IndexOutOfBoundsException();
>     }
>     return codePointAtImpl(a, index, limit);
> }
> 
> I suggest to check the `index` parameter explicitly instead of relying on AIOOBE thrown from accessing the array with negative index.

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

  8298033: Polish

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11480/files
  - new: https://git.openjdk.org/jdk/pull/11480/files/9a40f08c..b4b6e897

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

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

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

From naoto at openjdk.org  Tue Dec  6 19:17:44 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Dec 2022 19:17:44 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v9]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <NH-VgRl9JdgGTj1jxQPiyUsKyh5X-zEHyLMWIa47zu0=.611a1828-80b9-4aac-8c1d-82f93ce4e4e4@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

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

  Further addressing review comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/204690cf..6cd9843e

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

  Stats: 27 lines in 2 files changed: 20 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/11421.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11421/head:pull/11421

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

From naoto at openjdk.org  Tue Dec  6 19:24:20 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Dec 2022 19:24:20 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v9]
In-Reply-To: <NH-VgRl9JdgGTj1jxQPiyUsKyh5X-zEHyLMWIa47zu0=.611a1828-80b9-4aac-8c1d-82f93ce4e4e4@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <NH-VgRl9JdgGTj1jxQPiyUsKyh5X-zEHyLMWIa47zu0=.611a1828-80b9-4aac-8c1d-82f93ce4e4e4@github.com>
Message-ID: <IxAskDLUnZ5MlMZA2jJlX3U5oAFCOD6r1Fk1X5_LSG0=.aa91a045-dfee-4698-ab4b-d494893c426d@github.com>

On Tue, 6 Dec 2022 19:17:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Further addressing review comments.

Provided separate independent locks in `ProxyingConsole` for now. Later it can be re-org'ed as Alan suggested for cleaner implementation/interface separation.

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

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

From jvernee at openjdk.org  Tue Dec  6 19:26:03 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 6 Dec 2022 19:26:03 GMT
Subject: RFR: 8298177: Various java.lang.invoke cleanups [v3]
In-Reply-To: <HVQ0pa8CBsuvGO3Jzc5oVbof9rqPr2Mq2b9sBaxG74c=.6df56921-23ab-4930-976c-681605fff684@github.com>
References: <lM8wzo_N6Mi4Gc63G82Mhii_OuNcYj0skA5fyR5HsYQ=.3cd9341e-27a2-40d4-ae66-2821e1f5d5f6@github.com>
 <HVQ0pa8CBsuvGO3Jzc5oVbof9rqPr2Mq2b9sBaxG74c=.6df56921-23ab-4930-976c-681605fff684@github.com>
Message-ID: <V_oeJ0rUJvKbNdEskc5GTv1IqjZ90alGXOwq0ZoeQfE=.a0d6d9e5-25bf-4480-8e49-97a1e790ef97@github.com>

On Tue, 6 Dec 2022 18:06:36 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Various code cleanups around java.lang.invoke code. Started out with dead code removal in `jli.MemberName`, then piled on to fix a set of minor inefficiencies (excessive vararg array allocations, unnecessary defensive cloning of parameter arrays etc).
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix 8284363, more code removal

Marked as reviewed by jvernee (Reviewer).

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

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

From jvernee at openjdk.org  Tue Dec  6 19:26:08 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 6 Dec 2022 19:26:08 GMT
Subject: RFR: 8298177: Various java.lang.invoke cleanups [v3]
In-Reply-To: <PYR1Mj-onJFMX61iI3HuiwVbYaMXDd9M9cme6DRiseQ=.11788be0-6872-4af5-8c81-8716acd6b76b@github.com>
References: <lM8wzo_N6Mi4Gc63G82Mhii_OuNcYj0skA5fyR5HsYQ=.3cd9341e-27a2-40d4-ae66-2821e1f5d5f6@github.com>
 <DsU5Lu0leJ8luksEFP5e76InAxfVs75qQzDX2Lh_qxA=.38029c56-bd3d-4316-9867-c589d0426cc4@github.com>
 <PYR1Mj-onJFMX61iI3HuiwVbYaMXDd9M9cme6DRiseQ=.11788be0-6872-4af5-8c81-8716acd6b76b@github.com>
Message-ID: <wo3Dq96Pk16QOHTdcirZFf_VpQ1m2pMOHVFDt07bVbk=.f177255a-ee51-4ba6-9040-d232472fbef4@github.com>

On Tue, 6 Dec 2022 16:25:12 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/MemberName.java line 578:
>> 
>>> 576:             throw new LinkageError(m.toString());
>>> 577:         }
>>> 578:         assert(isResolved());
>> 
>> I don't see why this can be removed. Can you explain?
>
> the `if (clazz == null)` block above either returns or throws an error, so intellij was marking this as always true.

Ok, I see. Thanks

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

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

From duke at openjdk.org  Tue Dec  6 20:08:15 2022
From: duke at openjdk.org (jfoster-twilio)
Date: Tue, 6 Dec 2022 20:08:15 GMT
Subject: RFR: 8282280: Update Xerces to Version 2.12.2
In-Reply-To: <Y1BKwBR1K9NcqaObuSwhjPSKTLUHLRti3hIrmWc4c5E=.80c04572-6248-4681-a422-d2a3b4c4ee87@github.com>
References: <3m9Wx6mtyPIETeAvTmxJvoz2lJDUsrtGNMup02w3vEA=.23476abf-fc2b-4614-8b49-88d620f32fa4@github.com>
 <Y1BKwBR1K9NcqaObuSwhjPSKTLUHLRti3hIrmWc4c5E=.80c04572-6248-4681-a422-d2a3b4c4ee87@github.com>
Message-ID: <c3Cs5MYgtAzVlcS5ZyJV3hDAPiMauird28V22TZV4FE=.d688bc64-f5ae-4b8f-a386-5253a034d59a@github.com>

On Mon, 16 May 2022 21:21:28 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Update to Xerces 2.12.2.
>> 
>> The update also fixes JDK-8144117. Added a test.
>> 
>> Tests: local XML tests passed. Tier2 passed. Two JCK tests failed with this update. See related issue report.
>
> Thanks Lance.
> 
> Yes, I've notified the JCK team, will wait till they've resolved the issue (or at least put them in the known list). Meanwhile, just want to get the patch reviewed.

@JoeWang-Java https://github.com/openjdk/jdk/pull/8732/files#diff-559485fb84e5da2f5c0db2e967e6522895fb398da4d2eca9bd0f571461585b01R3224-R3235 introduces a bug where `reportSchemaError(
                        "cvc-complex-type.4",
                        new Object[] { element.rawname, currDecl.fName });` may be emitted twice.

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

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

From rriggs at openjdk.org  Tue Dec  6 20:42:40 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 6 Dec 2022 20:42:40 GMT
Subject: RFR: JDK-8298170 : Introduce a macro for exception check,
 free and return
In-Reply-To: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
References: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
Message-ID: <by8PjHk056eNArwawtCAKY29CJNuEHDkGuDR3DeoeNE=.2c31ba49-5c88-477d-98a7-5b10dc51d702@github.com>

On Tue, 6 Dec 2022 15:20:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have a number of places in the codebase  where a macro could help when we check an exception and afterwrads free something and return.

The existing (and new) macro naming doesn't make clear that it always returns from the function.  The presence of "RETURN" in the name only means there is a return value.
The existing code more obviously handles memory deallocation.

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

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

From cstein at openjdk.org  Tue Dec  6 20:54:52 2022
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 6 Dec 2022 20:54:52 GMT
Subject: Integrated: 8298178: Update to use jtreg 7.1.1
In-Reply-To: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
References: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
Message-ID: <bZ95FikXXwOfFnn7nor8EnwNTmcPK1yc6djOUS8PmQc=.2f8fb567-dde6-474a-b583-8f201a8bc65e@github.com>

On Tue, 6 Dec 2022 16:07:44 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.1.1.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
> 
> This pull request was created by copying the following and using 7.1.1 at appropriate places:
> - https://github.com/openjdk/jdk/pull/11416

This pull request has now been integrated.

Changeset: 2cdc0195
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2cdc0195655317cb0b04f76fd8dce5e40bf52774
Stats:     9 lines in 8 files changed: 0 ins; 0 del; 9 mod

8298178: Update to use jtreg 7.1.1

Reviewed-by: erikj

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

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

From aph at openjdk.org  Tue Dec  6 21:14:07 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 6 Dec 2022 21:14:07 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v38]
In-Reply-To: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
Message-ID: <YtZE5ynehR7OS2NxVjxuouIiIO4JwvEdzNiDQn-04NE=.5dd48b0f-5473-4ce3-a2cf-006ad428d997@github.com>

> JEP 429 implementation.

Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 71 commits:

 - Merge from JDK mainline
 - Add comment
 - Merge https://github.com/openjdk/jdk into JDK-8286666
 - Feedback from reviewers
 - Feedback from reviewers
 - Unused variable
 - Cleanup
 - Cleanup
 - Merge branch 'JDK-8286666' of https://github.com/theRealAph/jdk into JDK-8286666
 - Update src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
 - ... and 61 more: https://git.openjdk.org/jdk/compare/2cdc0195...46fa1389

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

Changes: https://git.openjdk.org/jdk/pull/10952/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=37
  Stats: 3336 lines in 62 files changed: 2913 ins; 254 del; 169 mod
  Patch: https://git.openjdk.org/jdk/pull/10952.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952

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

From naoto at openjdk.org  Tue Dec  6 21:48:36 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Dec 2022 21:48:36 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v10]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <lpDoiTBG0BCmcakQz2tdNL5nt_mAdbbJdhdzhsb5Vhc=.5b6e55fa-a606-464b-a623-bd5181dffa32@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

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

  Synchronize reader/writer by wrapping them

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/6cd9843e..a54aed5f

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

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

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

From bchristi at openjdk.org  Tue Dec  6 22:04:19 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 6 Dec 2022 22:04:19 GMT
Subject: RFR: 8295857: Clarify that cleanup code can be skipped when the
 JVM terminates (e.g. when calling halt()) [v5]
In-Reply-To: <K5xYZSxaq80NneeRv23ju8tWsvFaLms3kuzcIqngtN0=.5364fd95-d495-49ed-9cdf-bf949ed95dcd@github.com>
References: <hHSImvhd-Yg6AcPkSrYBFxBOx4jBg079lx4sRjR3AZc=.65cd47c4-b34a-4475-8b35-069627999eed@github.com>
 <K5xYZSxaq80NneeRv23ju8tWsvFaLms3kuzcIqngtN0=.5364fd95-d495-49ed-9cdf-bf949ed95dcd@github.com>
Message-ID: <HwL8WlbgMPcZFa1jCsy7Q5qmbAgbY3NZuyfxGOt9gQI=.5c0e95eb-ec4c-4534-b7ef-d3123284cffb@github.com>

On Wed, 30 Nov 2022 01:15:54 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036) documented the shutdown sequence, noting that calling Runtime.halt() skips the shutdown sequence and immediately terminates the VM. Thus, "threads' current methods do not complete normally or abruptly; no finally clause of any method is executed".
>> 
>> One ramification of this is that resources within try-with-resource blocks will not be released. It would be good to state this explicitly.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   put examples into a list, in class doc only, not halt()

What do people think of the latest changes?

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

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

From dcubed at openjdk.org  Tue Dec  6 22:04:54 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 6 Dec 2022 22:04:54 GMT
Subject: Integrated: 8298214: ProblemList
 java/util/concurrent/forkjoin/AsyncShutdownNow.java
In-Reply-To: <v-6QFccVbI1L8n-p53Dcl8OwaZ6kF89uW_8lH4tSHPo=.eab68505-a4b0-44e7-88d4-a5202b3f803f@github.com>
References: <v-6QFccVbI1L8n-p53Dcl8OwaZ6kF89uW_8lH4tSHPo=.eab68505-a4b0-44e7-88d4-a5202b3f803f@github.com>
Message-ID: <vC0HOYy7qv_xqYJP_d1NQFQWDkXO-IqWnI5Mr6mFwmc=.fb5a3367-fd85-456d-b339-9ec5f928e5c5@github.com>

On Tue, 6 Dec 2022 21:38:45 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList 4 different tests:
> [JDK-8298214](https://bugs.openjdk.org/browse/JDK-8298214) ProblemList java/util/concurrent/forkjoin/AsyncShutdownNow.java
> [JDK-8298218](https://bugs.openjdk.org/browse/JDK-8298218) ProblemList java/awt/Focus/NonFocusableWindowTest/NonfocusableOwnerTest.java on windows-x64
> [JDK-8298220](https://bugs.openjdk.org/browse/JDK-8298220) ProblemList java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java on windows-x64
> [JDK-8298222](https://bugs.openjdk.org/browse/JDK-8298222) ProblemList java/awt/Mixing/AWT_Mixing/ViewportOverlapping.java on windows-x64

This pull request has now been integrated.

Changeset: 16a59018
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/16a5901845de170e2e6f9ea13f19bb2a34c1da85
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8298214: ProblemList java/util/concurrent/forkjoin/AsyncShutdownNow.java
8298218: ProblemList java/awt/Focus/NonFocusableWindowTest/NonfocusableOwnerTest.java on windows-x64
8298222: ProblemList java/awt/Mixing/AWT_Mixing/ViewportOverlapping.java on windows-x64
8298220: ProblemList java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java on windows-x64

Reviewed-by: rriggs

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

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

From rriggs at openjdk.org  Tue Dec  6 22:06:00 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 6 Dec 2022 22:06:00 GMT
Subject: RFR: 8298033: Character.codePointAt(char[], int,
 int) doesn't do JavaDoc-specified check [v6]
In-Reply-To: <VftnfWbHQbak_oaF8D4eULvTMUj7mzDm8gaWl8qXdjE=.92a052a8-1474-4a92-ac4b-bf827a5f9154@github.com>
References: <dHjviGmASssYfntfClzDC28Ppjrn3pECnO3HzbZHopY=.d9923de3-6de7-41f5-a84e-03a7c5267e2f@github.com>
 <VftnfWbHQbak_oaF8D4eULvTMUj7mzDm8gaWl8qXdjE=.92a052a8-1474-4a92-ac4b-bf827a5f9154@github.com>
Message-ID: <D4EqdRUtTgsuqZlNlsB3t7be8TjFlJi8EX1JSFfOCM0=.78bf3522-76fb-42e2-8aa6-49dcd7002aad@github.com>

On Tue, 6 Dec 2022 18:39:28 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> I found out that this code
>> 
>> public class Main {
>>     public static void main(String[] args) {
>>         String s = "Hello world!";
>>         char[] chars = s.toCharArray();
>>         int point = Character.codePointAt(chars, -1, 1);
>>     }
>> }
>> 
>> throws `ArrayIndexOutOfBoundsException` instead of JavaDoc-specified `IndexOutOfBoundsException`: 
>> 
>> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds for length 12
>> 	at java.base/java.lang.Character.codePointAtImpl(Character.java:9254)
>> 	at java.base/java.lang.Character.codePointAt(Character.java:9249)
>> 	at org.example.Main.main(Main.java:7)
>> 
>> and the method doesn't check whether `index` parameter is negative:
>> 
>> public static int codePointAt(char[] a, int index, int limit) {
>>     if (index >= limit || limit < 0 || limit > a.length) {
>>         throw new IndexOutOfBoundsException();
>>     }
>>     return codePointAtImpl(a, index, limit);
>> }
>> 
>> I suggest to check the `index` parameter explicitly instead of relying on AIOOBE thrown from accessing the array with negative index.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8298033: Polish

LGTM, thanks for the cleanup.

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

Marked as reviewed by rriggs (Reviewer).

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

From naoto at openjdk.org  Tue Dec  6 22:45:52 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Dec 2022 22:45:52 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v11]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <l6LdCakkTqmWO4D-om35LxcrFtrGDaKNeNdLtQjD6Ac=.d61eb655-dfee-4d75-89ae-10faae3978fb@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

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

  Making the wrapper classes static

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/a54aed5f..40de5d0a

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

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

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

From andrew at openjdk.org  Wed Dec  7 00:35:07 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 7 Dec 2022 00:35:07 GMT
Subject: RFR: 8297804: (tz) Update Timezone Data to 2022g [v2]
In-Reply-To: <LUd0Rb4G80fdee18UQItifokHjI6FI31GBVTmDu5m_M=.0dfca816-dae6-4276-ab67-6de9bec62081@github.com>
References: <4b1tG73Xp3BMUy2X6Ab7W2So7u4jcSu9SrAWvrHLw1g=.d6218261-7f4e-48c5-9989-eb0887e0207e@github.com>
 <LUd0Rb4G80fdee18UQItifokHjI6FI31GBVTmDu5m_M=.0dfca816-dae6-4276-ab67-6de9bec62081@github.com>
Message-ID: <Unca6SN4a77hWel3h1hBYboWA7XE4Efz1qcU845Afew=.2b15eb2d-a83f-4cc8-9dba-6da5cfb36795@github.com>

On Mon, 5 Dec 2022 14:38:51 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> Update to the latest tzdata, 2022g.
>> 
>> Primary changes:
>> * `America/Ojinaga` (CST) is split, creating `America/Ciudad_Juarez` (MST/MDT)
>> * `America/Pangnirtung` becomes a link to `America/Iqaluit`
>> * `America/Ojinaga` gains DST (CDT)
>> 
>> See bug for the full details.
>> 
>> There will likely also be CLDR changes ([CLDR-16181](https://unicode-org.atlassian.net/browse/CLDR-16181)) that are not yet included in this change. We can either wait for these and include them in this patch, or do a separate change like [JDK-8296715](https://bugs.openjdk.org/browse/JDK-8296715)
>> 
>> Tests in `java/util/TimeZone`, `java/time/test` and `sun/text/resources` all pass.
>
> Andrew John Hughes has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add CLDR changes from https://github.com/unicode-org/cldr/commit/0bd22412b35b6e7037a39c3ad6a4dc49c699439b
>  - Update tzdata version

Thanks.

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

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

From andrew at openjdk.org  Wed Dec  7 00:37:02 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 7 Dec 2022 00:37:02 GMT
Subject: Integrated: 8297804: (tz) Update Timezone Data to 2022g
In-Reply-To: <4b1tG73Xp3BMUy2X6Ab7W2So7u4jcSu9SrAWvrHLw1g=.d6218261-7f4e-48c5-9989-eb0887e0207e@github.com>
References: <4b1tG73Xp3BMUy2X6Ab7W2So7u4jcSu9SrAWvrHLw1g=.d6218261-7f4e-48c5-9989-eb0887e0207e@github.com>
Message-ID: <lxtmsWtPcoOMqDDxlLwiI_Y1CyvW8pZ9lMybE3b5JGY=.6e836cec-9dbc-46d8-b060-5dcfd84ed4fe@github.com>

On Wed, 30 Nov 2022 18:07:07 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Update to the latest tzdata, 2022g.
> 
> Primary changes:
> * `America/Ojinaga` (CST) is split, creating `America/Ciudad_Juarez` (MST/MDT)
> * `America/Pangnirtung` becomes a link to `America/Iqaluit`
> * `America/Ojinaga` gains DST (CDT)
> 
> See bug for the full details.
> 
> There will likely also be CLDR changes ([CLDR-16181](https://unicode-org.atlassian.net/browse/CLDR-16181)) that are not yet included in this change. We can either wait for these and include them in this patch, or do a separate change like [JDK-8296715](https://bugs.openjdk.org/browse/JDK-8296715)
> 
> Tests in `java/util/TimeZone`, `java/time/test` and `sun/text/resources` all pass.

This pull request has now been integrated.

Changeset: ce896731
Author:    Andrew John Hughes <andrew at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ce896731d38866c2bf99cd49525062e150d94160
Stats:     240 lines in 26 files changed: 144 ins; 57 del; 39 mod

8297804: (tz) Update Timezone Data to 2022g

Reviewed-by: naoto

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

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

From dholmes at openjdk.org  Wed Dec  7 02:43:58 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 7 Dec 2022 02:43:58 GMT
Subject: RFR: 8295857: Clarify that cleanup code can be skipped when the
 JVM terminates (e.g. when calling halt()) [v5]
In-Reply-To: <K5xYZSxaq80NneeRv23ju8tWsvFaLms3kuzcIqngtN0=.5364fd95-d495-49ed-9cdf-bf949ed95dcd@github.com>
References: <hHSImvhd-Yg6AcPkSrYBFxBOx4jBg079lx4sRjR3AZc=.65cd47c4-b34a-4475-8b35-069627999eed@github.com>
 <K5xYZSxaq80NneeRv23ju8tWsvFaLms3kuzcIqngtN0=.5364fd95-d495-49ed-9cdf-bf949ed95dcd@github.com>
Message-ID: <3_LKQFso5Bl3u6mLfJ6mKi5lb5bLECRgVY_gHN664Is=.02709ef7-b163-46e6-93e1-092776479a04@github.com>

On Wed, 30 Nov 2022 01:15:54 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036) documented the shutdown sequence, noting that calling Runtime.halt() skips the shutdown sequence and immediately terminates the VM. Thus, "threads' current methods do not complete normally or abruptly; no finally clause of any method is executed".
>> 
>> One ramification of this is that resources within try-with-resource blocks will not be released. It would be good to state this explicitly.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   put examples into a list, in class doc only, not halt()

One nit but otherwise seems fine to me.

Thanks.

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

> 96:  * <li>{@code finally} clauses are not executed;</li>
> 97:  * <li>{@linkplain Thread.UncaughtExceptionHandler uncaught exception handlers} are not run; and</li>
> 98:  * <li>resources opened with try-with-resources are not {@linkplain AutoCloseable close}d;</li>

Having the 'd' outside the link text looks very odd to me.

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

Marked as reviewed by dholmes (Reviewer).

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

From dholmes at openjdk.org  Wed Dec  7 04:36:01 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 7 Dec 2022 04:36:01 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v4]
In-Reply-To: <sJOLTlt6mjfVSLsXdLQMgirI06mdYjGW0tuO2Ueht8s=.e3d8eb38-c4a6-4e43-9e01-3b9ecb385b41@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <nm5MBsIexi02WmVomf-rKb-xWg064Pqg9WMKxb18PBw=.9d5209a3-675e-4ee2-a4d5-05ff14934fb3@github.com>
 <l12fdSbAv-DiEfAt29C4mOXFRoNaWjTVuW3_aSElIiI=.f8ec8d7e-84ec-4551-a9f3-e9aa116bb84e@github.com>
 <sJOLTlt6mjfVSLsXdLQMgirI06mdYjGW0tuO2Ueht8s=.e3d8eb38-c4a6-4e43-9e01-3b9ecb385b41@github.com>
Message-ID: <kydwXWlhR6pT95VvYlGgd3Hk0JIRxJxUFsO2gOceiLY=.b65421ab-8965-422f-b55c-9a1bb1f26b73@github.com>

On Tue, 6 Dec 2022 08:56:47 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> src/hotspot/share/jvmci/jvmci.cpp line 234:
>> 
>>> 232:     if (thread != nullptr && thread->is_Java_thread()) {
>>> 233:       ResourceMark rm;
>>> 234:       JavaThreadState state = ((JavaThread*) thread)->thread_state();
>> 
>> Please use `JavaThread::cast(thread)`
>
> I've made this change. Out of interest, I grep'ed through `src/hotspot` and found a few other instances of `(JavaThread*)` style casts. While most of these are probably older code, I'm wondering what the guidelines are in this area. I assume `JavaThread::cast` should be preferred always given the assertion checking it does?

Yes `JavaThread::cast(t)` is preferred. We did a lot of cleanup work ensuring we use `JavaThread` when always dealing with a `JavaThread`, and so reduce the places we need to cast. I'm a little surprised we still have some raw casts left as I thought we had cleaned them all up. I will check and file another cleanup RFE. Thanks.

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

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

From never at openjdk.org  Wed Dec  7 06:09:57 2022
From: never at openjdk.org (Tom Rodriguez)
Date: Wed, 7 Dec 2022 06:09:57 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v6]
In-Reply-To: <7f0PjG00BGhLCA3Kjlohhp3YGB_Xv8BPexToz66PxWc=.cb042f58-79b2-4c80-a5d4-245e95227858@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <7f0PjG00BGhLCA3Kjlohhp3YGB_Xv8BPexToz66PxWc=.cb042f58-79b2-4c80-a5d4-245e95227858@github.com>
Message-ID: <E3RhlFkSBKQAdsidbcRTWny4F-oUEuHOfO0mMyCzORI=.3114bd9d-5e93-4e07-8244-fc0570607161@github.com>

On Tue, 6 Dec 2022 16:06:34 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Libgraal is compiled ahead of time and should not need any JVMCI Java code to be dynamically loaded at runtime. Prior to this PR, this is not the case due to:
>> 
>> * Code to copy system properties from the HotSpot heap into the libgraal heap. This is in `jdk.vm.ci.services.Services.initializeSavedProperties(byte[])` and `jdk.vm.ci.services.Services.serializeSavedProperties()`. This code should be moved to `java.base/jdk.internal.vm.VMSupport`.
>> * Code to translate exceptions from the HotSpot heap into the libgraal heap and vice versa. This code should be moved from `jdk.internal.vm.ci//jdk.vm.ci.hotspot.TranslatedException` to `java.base/jdk.internal.vm.VMSupport`.
>> 
>> This PR makes the above changes. As a result, it's possible to build a JDK image that includes (and uses) libgraal but does not include `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces footprint and better isolates the JAVMCI and the Graal compiler as accessing these components from Java code is now impossible.
>
> Doug Simon has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - formatting to avoid very long lines [skip ci]
>  - removed debug code [skip ci]
>  - clarify Properties filtering [skip ci]
>  - remove debug code [skip ci]

Marked as reviewed by never (Reviewer).

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

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

From jpai at openjdk.org  Wed Dec  7 06:54:20 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 7 Dec 2022 06:54:20 GMT
Subject: RFR: 8296896: Change virtual Thread.yield to use external submit
In-Reply-To: <S0emMR0JXtg41aa6ITXJg7IlxJljzGwPGuyjOdH98Gc=.691bc53c-d851-414f-8261-020f96dbde93@github.com>
References: <S0emMR0JXtg41aa6ITXJg7IlxJljzGwPGuyjOdH98Gc=.691bc53c-d851-414f-8261-020f96dbde93@github.com>
Message-ID: <uEbLajk8NC-2LLlYZcX5HWQlZvxnYosDgKSGxSjQUg8=.d7081e2c-8845-4b07-bb45-d51154cd69e0@github.com>

On Tue, 6 Dec 2022 10:16:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The implementation of Thread.yield for virtual threads is currently a "lazy submit". This means the task for the virtual thread is queued to the carrier/worker local queue without signalling other threads. This behavior can be surprising/unfair when there are tasks in the submission queues, say when a platform thread has started or unparked a virtual thread.
> 
> Ron, Doug Lea, Viktor Klang and I have discussed this topic and propose to change Thread.yield to  use "external submit" when the local task queue is empty, and to push to the local queue when not empty. The change improves the fairness but will of course increase the chances that repeated Thread.yield will bounce between carriers.

I'm not too familiar with the local queue and submission queues of the ForkJoinPool, but the PR description and the inline comments in the code/tests helped understand this change. With my limited knowledge of this area, this change looks OK to me.

I'm guessing the change to the existing `YieldALot` test to reduce the number of iterations from `500000` to `350000` is intentional to bring down the duration of that test?

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

Marked as reviewed by jpai (Reviewer).

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

From jpai at openjdk.org  Wed Dec  7 07:07:59 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 7 Dec 2022 07:07:59 GMT
Subject: RFR: 8297976: Remove sun.net.ProgressMonitor and related classes
 [v4]
In-Reply-To: <--xZGrc9oA7pnqyvUDWRUvTNxVLtZsDoe-r0xhyDuKI=.761cc499-2463-457c-9f4a-881c198893df@github.com>
References: <yw8Q8tA8_4jUmc1gWd-xAN-m5kjFPeou3dn0qML9TQ4=.18a511ff-946f-4a8a-8fe3-3eaf00a8a396@github.com>
 <--xZGrc9oA7pnqyvUDWRUvTNxVLtZsDoe-r0xhyDuKI=.761cc499-2463-457c-9f4a-881c198893df@github.com>
Message-ID: <QgckKjmoSBX-e1Je3fW7yaG8Ji5jsQ-4vs350Cns3xw=.ec6f68f8-77e7-465a-8838-762ba65385ed@github.com>

On Tue, 6 Dec 2022 13:42:04 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Please review this patch that removes progress monitoring classes used by UrlConnection.
>> Since Java 9 these classes are not used in the JDK, and are not exported from java.base. If anyone was still using them, reimplementing them in user code should be pretty straightforward.
>> 
>> This PR also fixes the issue where MeteredStream finalizer could resurrect an unusable connection, causing unexpected exceptions in other parts of the code.
>> 
>> No new regression test; since we are removing the finalizer, I don't believe we will see the issue again. I can add a test for that if you think it still makes sense.
>> 
>> I had to adjust `ProxyModuleMapping.java` test which used `sun.net.ProgressListener` as an example of a module-private interface; I replaced it with another public interface from the same package.
>> 
>> Existing tier 1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use System.err

Looks good to me.

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

Marked as reviewed by jpai (Reviewer).

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

From alanb at openjdk.org  Wed Dec  7 07:09:14 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Dec 2022 07:09:14 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v11]
In-Reply-To: <l6LdCakkTqmWO4D-om35LxcrFtrGDaKNeNdLtQjD6Ac=.d61eb655-dfee-4d75-89ae-10faae3978fb@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <l6LdCakkTqmWO4D-om35LxcrFtrGDaKNeNdLtQjD6Ac=.d61eb655-dfee-4d75-89ae-10faae3978fb@github.com>
Message-ID: <3c0_fD_pzDxeZ6ikjh0LlCmtpI6JqY0OJyXeLvT694w=.bfe0d4ad-313c-4094-a526-d2d29902fa6b@github.com>

On Tue, 6 Dec 2022 22:45:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Making the wrapper classes static

src/java.base/share/classes/java/io/ProxyingConsole.java line 153:

> 151: 
> 152:         WrappingReader(Reader r, Object lock) {
> 153:             this.r = r;

I think you need super(lock) here to ensure that the Reader uses the same lock.

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

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

From alanb at openjdk.org  Wed Dec  7 07:12:16 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Dec 2022 07:12:16 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v11]
In-Reply-To: <l6LdCakkTqmWO4D-om35LxcrFtrGDaKNeNdLtQjD6Ac=.d61eb655-dfee-4d75-89ae-10faae3978fb@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <l6LdCakkTqmWO4D-om35LxcrFtrGDaKNeNdLtQjD6Ac=.d61eb655-dfee-4d75-89ae-10faae3978fb@github.com>
Message-ID: <fQcZuAPbgcoiXN9XADjzVLxEaYP8u3TciMbkzsmH5xc=.c9c58b39-28d3-458a-b4f4-97065bcaef65@github.com>

On Tue, 6 Dec 2022 22:45:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Making the wrapper classes static

src/java.base/share/classes/java/io/ProxyingConsole.java line 175:

> 173: 
> 174:         public WrappingWriter(PrintWriter pw, Object lock) {
> 175:             super(pw);

PrintWriter doesn't provide a way to provide to lock object so this means the overridden methods will synchronize on "lock", the non-overridden methods will synchronize on "pw". So we will need to look at this.

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

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

From mbaesken at openjdk.org  Wed Dec  7 08:45:01 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 7 Dec 2022 08:45:01 GMT
Subject: RFR: JDK-8298170 : Introduce a macro for exception check,
 free and return
In-Reply-To: <by8PjHk056eNArwawtCAKY29CJNuEHDkGuDR3DeoeNE=.2c31ba49-5c88-477d-98a7-5b10dc51d702@github.com>
References: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
 <by8PjHk056eNArwawtCAKY29CJNuEHDkGuDR3DeoeNE=.2c31ba49-5c88-477d-98a7-5b10dc51d702@github.com>
Message-ID: <kdOQP_mWI4xmIwFRQXP46G_ZZPUQLGVwFZQSmWL3T4k=.5c28947e-a124-4f62-a2db-87018f6a5830@github.com>

On Tue, 6 Dec 2022 20:40:34 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The existing code more obviously handles memory deallocation.

Thomas Stuefe suggested something like this


JNU_CHECK_EXCEPTION_DO(env, action)
JNU_CHECK_EXCEPTION_DO_AND_RETURN(env, action, retval)


usage example: 
`JNU_CHECK_EXCEPTION_DO(env, { free(tab); })`

This would make the free-ing more clear, and should also work for 2 free-calls, we a have places like this in the codebase. What do you think about this?

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

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

From djelinski at openjdk.org  Wed Dec  7 08:57:16 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 7 Dec 2022 08:57:16 GMT
Subject: RFR: 8297976: Remove sun.net.ProgressMonitor and related classes
 [v4]
In-Reply-To: <--xZGrc9oA7pnqyvUDWRUvTNxVLtZsDoe-r0xhyDuKI=.761cc499-2463-457c-9f4a-881c198893df@github.com>
References: <yw8Q8tA8_4jUmc1gWd-xAN-m5kjFPeou3dn0qML9TQ4=.18a511ff-946f-4a8a-8fe3-3eaf00a8a396@github.com>
 <--xZGrc9oA7pnqyvUDWRUvTNxVLtZsDoe-r0xhyDuKI=.761cc499-2463-457c-9f4a-881c198893df@github.com>
Message-ID: <u0dE5IR1xB4GrjxQAGsY1HCAC1ZjoQYsvgdeZO_tc1Q=.95e12f98-151f-49c7-858d-761f94f08eb4@github.com>

On Tue, 6 Dec 2022 13:42:04 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Please review this patch that removes progress monitoring classes used by UrlConnection.
>> Since Java 9 these classes are not used in the JDK, and are not exported from java.base. If anyone was still using them, reimplementing them in user code should be pretty straightforward.
>> 
>> This PR also fixes the issue where MeteredStream finalizer could resurrect an unusable connection, causing unexpected exceptions in other parts of the code.
>> 
>> No new regression test; since we are removing the finalizer, I don't believe we will see the issue again. I can add a test for that if you think it still makes sense.
>> 
>> I had to adjust `ProxyModuleMapping.java` test which used `sun.net.ProgressListener` as an example of a module-private interface; I replaced it with another public interface from the same package.
>> 
>> Existing tier 1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use System.err

Thanks for the reviews!

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

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

From djelinski at openjdk.org  Wed Dec  7 08:59:22 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 7 Dec 2022 08:59:22 GMT
Subject: Integrated: 8297976: Remove sun.net.ProgressMonitor and related
 classes
In-Reply-To: <yw8Q8tA8_4jUmc1gWd-xAN-m5kjFPeou3dn0qML9TQ4=.18a511ff-946f-4a8a-8fe3-3eaf00a8a396@github.com>
References: <yw8Q8tA8_4jUmc1gWd-xAN-m5kjFPeou3dn0qML9TQ4=.18a511ff-946f-4a8a-8fe3-3eaf00a8a396@github.com>
Message-ID: <TRPONZ3TmThshWEwjRwIz9WzO2hMWX6xfo2u2cIVaCg=.a87e3a1e-027b-479b-8296-77d3dc73bae9@github.com>

On Fri, 2 Dec 2022 08:31:25 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this patch that removes progress monitoring classes used by UrlConnection.
> Since Java 9 these classes are not used in the JDK, and are not exported from java.base. If anyone was still using them, reimplementing them in user code should be pretty straightforward.
> 
> This PR also fixes the issue where MeteredStream finalizer could resurrect an unusable connection, causing unexpected exceptions in other parts of the code.
> 
> No new regression test; since we are removing the finalizer, I don't believe we will see the issue again. I can add a test for that if you think it still makes sense.
> 
> I had to adjust `ProxyModuleMapping.java` test which used `sun.net.ProgressListener` as an example of a module-private interface; I replaced it with another public interface from the same package.
> 
> Existing tier 1-3 tests continue to pass.

This pull request has now been integrated.

Changeset: 27bbe7be
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/27bbe7be2c43a22e8cf55aa403d8018346ae3e37
Stats:     1188 lines in 14 files changed: 294 ins; 875 del; 19 mod

8297976: Remove sun.net.ProgressMonitor and related classes
8240275: Occasional errors in HttpURLConnection due to race with GC

Reviewed-by: jpai, dfuchs, michaelm

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

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

From stsypanov at openjdk.org  Wed Dec  7 09:17:16 2022
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 7 Dec 2022 09:17:16 GMT
Subject: RFR: 8298033: Character.codePointAt(char[], int,
 int) doesn't do JavaDoc-specified check [v5]
In-Reply-To: <n_5DdGq4c_qUAHFZLNPW3P-dohFloZWoERw4Mmqq3q0=.ef688a85-c6b0-4cd0-afdf-4a5784760ce8@github.com>
References: <dHjviGmASssYfntfClzDC28Ppjrn3pECnO3HzbZHopY=.d9923de3-6de7-41f5-a84e-03a7c5267e2f@github.com>
 <dhRgJ-zezWDACDdiVj2agQqPREyBYjm5TxV-hUP7d54=.e6e366af-b980-4cf3-aaac-4defae072dd6@github.com>
 <n_5DdGq4c_qUAHFZLNPW3P-dohFloZWoERw4Mmqq3q0=.ef688a85-c6b0-4cd0-afdf-4a5784760ce8@github.com>
Message-ID: <FdYRzv5X6Czm01TY9Cmp6yHo6OMFcCEEazlSWOPc9jA=.686df391-e823-4ad5-88e6-764aedf4b0c2@github.com>

On Tue, 6 Dec 2022 16:47:05 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8298033: Fix Character.codePointBefore()
>
> src/java.base/share/classes/java/lang/Character.java line 9480:
> 
>> 9478:      */
>> 9479:     public static int codePointBefore(char[] a, int index, int start) {
>> 9480:         if (index <= start || start < 0 || start >= a.length || index > a.length) {
> 
> Since `index > start` it is sufficient to throw `index > a.length`.
> The check `start >= a.length` is redundant.
> 
> `0 <= start < index <= a.length`

Done. I think we should rename the ticket as soon as we modify two methods now

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

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

From jpai at openjdk.org  Wed Dec  7 09:27:16 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 7 Dec 2022 09:27:16 GMT
Subject: RFR: 8296477: Foreign linker implementation update following JEP
 434 [v2]
In-Reply-To: <adPNJWEXLNY6LPaqX2N0eeiYUQDyRlp4rfJBqZYWoNI=.5ee36196-7bb8-4e28-adde-3cdd09eab781@github.com>
References: <CGd4JSefJvfEVkZEfORzthEIeV53kLk_UkZHAhJGrQ0=.7741b5f2-2227-4017-8164-d54fb9d30d10@github.com>
 <dMQ238rubrgCcyRv-456L2yibOvwrz1gWFPUOQTM5TQ=.31dcad26-a466-4806-ab72-33eb1c89a6ef@github.com>
 <i6cFFRmj8BY5ykF4ROioLuh1J0kFrKTRgyHf4fIFeSM=.aeeba4fe-3efa-4b3d-b31e-3f428b0c33f5@github.com>
 <adPNJWEXLNY6LPaqX2N0eeiYUQDyRlp4rfJBqZYWoNI=.5ee36196-7bb8-4e28-adde-3cdd09eab781@github.com>
Message-ID: <-hS98wCfpghUkzWuyf0MzhpIpCIjOiDDitZ39kx4aeU=.c2dbc3eb-a649-489e-b0cb-eb14d7f55dbf@github.com>

On Thu, 10 Nov 2022 15:22:45 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> test/jdk/ProblemList.txt line 484:
>> 
>>> 482: # jdk_foreign
>>> 483: 
>>> 484: java/foreign/callarranger/TestAarch64CallArranger.java generic-x86
>> 
>> Should we exclude these tests on 32 bits in the jtreg header (as I think we do for other tests) ?
>
> I'm not sure what the conventional move here would be. Adding them to the problem list doesn't seem to make the failures go away in GHA at least. I can exclude them with `@requires` as well.

Hello Jorn,

> Adding them to the problem list doesn't seem to make the failures go away in GHA at least.

It appears that these 2 problem listed lines are malformed (it's missing a bug id in each of these lines https://openjdk.org/guide/#problemlisting-jtreg-tests) Maybe that's why those tests didn't get problem listed in the GHA runs?

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

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

From alanb at openjdk.org  Wed Dec  7 10:17:05 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Dec 2022 10:17:05 GMT
Subject: Integrated: 8296672: Implementation of Virtual Threads (Second
 Preview)
In-Reply-To: <3xn4pJmY7VbtV47kZiR7L3c6-C-0vR5fVQ-y-SXlSx0=.56d8f675-e215-4457-b48e-13babb0d7ae7@github.com>
References: <3xn4pJmY7VbtV47kZiR7L3c6-C-0vR5fVQ-y-SXlSx0=.56d8f675-e215-4457-b48e-13babb0d7ae7@github.com>
Message-ID: <BfrFeXeO08Y8NQPM6tO8rrRyy4bceA7FiYnP7T4rlAI=.264a93a6-a7ed-43b2-9175-39c40e682bdb@github.com>

On Fri, 18 Nov 2022 09:57:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> JEP 436 proposes a second preview of Virtual Threads to allow time for more feedback and to get more experience with this feature. There is no change in direction, no API changes, and no bulk update of the implementation. For the implementation, there has been ~35 changes/issues pushed to the main line, and a few more coming. For this PR, we just bump the JEP number used by javadoc from 425 to 436.

This pull request has now been integrated.

Changeset: ccc69af9
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ccc69af966cf4395d75b2018490cafc47dcad90f
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8296672: Implementation of Virtual Threads (Second Preview)

Reviewed-by: mchung, jpai

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

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

From aph at openjdk.org  Wed Dec  7 10:17:17 2022
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 7 Dec 2022 10:17:17 GMT
Subject: Integrated: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator)
In-Reply-To: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
Message-ID: <6WicDtGmG6FUGBr116x5HgTN4uUo_ATSOJLKDbhfU1U=.996af1fa-d13b-41e5-853e-dfe242823baf@github.com>

On Wed, 2 Nov 2022 16:23:34 GMT, Andrew Haley <aph at openjdk.org> wrote:

> JEP 429 implementation.

This pull request has now been integrated.

Changeset: 221e1a42
Author:    Andrew Haley <aph at openjdk.org>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/221e1a426070088b819ddc37b7ca77d9d8626eb4
Stats:     3336 lines in 62 files changed: 2913 ins; 254 del; 169 mod

8286666: JEP 429: Implementation of Scoped Values (Incubator)

Reviewed-by: psandoz, dlong, alanb, mcimadamore

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

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

From alanb at openjdk.org  Wed Dec  7 11:58:10 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Dec 2022 11:58:10 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v11]
In-Reply-To: <l6LdCakkTqmWO4D-om35LxcrFtrGDaKNeNdLtQjD6Ac=.d61eb655-dfee-4d75-89ae-10faae3978fb@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <l6LdCakkTqmWO4D-om35LxcrFtrGDaKNeNdLtQjD6Ac=.d61eb655-dfee-4d75-89ae-10faae3978fb@github.com>
Message-ID: <X70i0DJuWySlOcLcVntBQZ5Oq2_5y_Cmd1RNP4ud6Vw=.2c84f607-cc40-43cf-88cc-4c4599ad03ba@github.com>

On Tue, 6 Dec 2022 22:45:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Making the wrapper classes static

src/java.base/share/classes/java/io/Console.java line 625:

> 623:             };
> 624:             return AccessController.doPrivileged(pa);
> 625:         } catch (Throwable ignore) {

I don't think we should be catching and ignoring throwable here. The only case that would be okay to ignore here is SCE due to SecurityException as the jline provider doesn't work with a SM set.

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

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

From duke at openjdk.org  Wed Dec  7 12:41:19 2022
From: duke at openjdk.org (Markus KARG)
Date: Wed, 7 Dec 2022 12:41:19 GMT
Subject: RFR: JDK-8297298 - SequenceInputStream should override transferTo
 [v3]
In-Reply-To: <f29hhy9J107mH2fJNTnIkR4u8JDXaHym8Mt_H9rwo8Y=.159e4f3e-e38f-496e-a6e2-65b3635bd897@github.com>
References: <f29hhy9J107mH2fJNTnIkR4u8JDXaHym8Mt_H9rwo8Y=.159e4f3e-e38f-496e-a6e2-65b3635bd897@github.com>
Message-ID: <JOLqPTs1JtesPdIu5C5J7dGNo6mOcA0YtAYW36DPRvo=.456a2f2f-3684-4520-a3ce-2665a75af684@github.com>

> Since JDK 18 some implementations of InputStream.transferTo, namely FileInputStream and ChannelInputStream, offload work to lower layers using NIO channels. This provides shorter execution time and reduced resource consumption. Unfortunately, this effect is prevented once the input stream itself is wrapped by a SequenceInputStream. While compared to other InputStreams the SequenceInputStream is a rather edge case (e. g. used to merge two files into one), nevertheless it makes sense to get rid of this obstacle simply by implementing transferTo (e. g. by allowing to offload the file merge, or parts of the file merge, to the operating system). As a result, more existing applications will experience the offloading-improvements made by JDK 18.
> 
> To provide enhanced performance to existing applications, it makes sense to address this impediment: SequenceInputStream.transferTo should be implemented in a way that iteratively calls transferTo on each enumerated InputStream of the SequenceInputStream in ordered sequence.

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

  EOL missing in last line

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11248/files
  - new: https://git.openjdk.org/jdk/pull/11248/files/22d99ba0..c5ba626e

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

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

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

From duke at openjdk.org  Wed Dec  7 12:41:19 2022
From: duke at openjdk.org (Markus KARG)
Date: Wed, 7 Dec 2022 12:41:19 GMT
Subject: RFR: JDK-8297298 - SequenceInputStream should override transferTo
 [v2]
In-Reply-To: <z4ZRDUbpzJKP7yHpSuFnmYfKvKRpkh6nb93EncLIBB4=.22395784-316b-4434-9a99-1915d9c58baf@github.com>
References: <f29hhy9J107mH2fJNTnIkR4u8JDXaHym8Mt_H9rwo8Y=.159e4f3e-e38f-496e-a6e2-65b3635bd897@github.com>
 <Ike0eQ9Ie59ga1NR7B1tECSMhPIjSKpXqdZCGUBtDL4=.761ef92f-260a-41ab-a483-aa2a2f6c9b69@github.com>
 <F6eAl7jxzmSj577gvVp54QKB_udCemJL_mfyxh5iQMQ=.e599efa7-f0d1-49fc-ae90-55598f4f1bc3@github.com>
 <z4ZRDUbpzJKP7yHpSuFnmYfKvKRpkh6nb93EncLIBB4=.22395784-316b-4434-9a99-1915d9c58baf@github.com>
Message-ID: <tB0OPXZ57yWOZQBCqm3eaGZKSywKFYxqg_EOnjnM4e0=.04712fc2-b262-4b1c-90ca-01cdc5c053d8@github.com>

On Tue, 6 Dec 2022 16:20:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> test/jdk/java/io/SequenceInputStream/TransferTo.java line 206:
>> 
>>> 204:     }
>>> 205: 
>>> 206: }
>> 
>> As auto-detected, there is no newline at the end of this file. Otherwise it appears all right.
>
> @mkarg Please take account of the JDK 20 rampdown at 16:00 UTC Thursday and that Pacific Time is eight hours behind. Thanks.

@bplb Thank you for your review. I have added the missing EOL and would be happy if you would mark this PR as reviewed, so I can integrate it into JDK 20. Thanks! :-)

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

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

From redestad at openjdk.org  Wed Dec  7 14:08:28 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 7 Dec 2022 14:08:28 GMT
Subject: RFR: 8298177: Various java.lang.invoke cleanups [v4]
In-Reply-To: <lM8wzo_N6Mi4Gc63G82Mhii_OuNcYj0skA5fyR5HsYQ=.3cd9341e-27a2-40d4-ae66-2821e1f5d5f6@github.com>
References: <lM8wzo_N6Mi4Gc63G82Mhii_OuNcYj0skA5fyR5HsYQ=.3cd9341e-27a2-40d4-ae66-2821e1f5d5f6@github.com>
Message-ID: <6fJb8nQYKwvyTIq0vHsrrShfouB70PzW1wdEIWzkL_o=.b9fa0d59-cf19-4ad2-8c1e-0fb1727b280d@github.com>

> Various code cleanups around java.lang.invoke code. Started out with dead code removal in `jli.MemberName`, then piled on to fix a set of minor inefficiencies (excessive vararg array allocations, unnecessary defensive cloning of parameter arrays etc).

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

  Cleanup more unused imports. Further code removals.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11540/files
  - new: https://git.openjdk.org/jdk/pull/11540/files/5a04e500..5988749c

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

  Stats: 95 lines in 4 files changed: 0 ins; 93 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11540.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11540/head:pull/11540

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

From jvernee at openjdk.org  Wed Dec  7 14:22:15 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 7 Dec 2022 14:22:15 GMT
Subject: RFR: 8298177: Various java.lang.invoke cleanups [v4]
In-Reply-To: <6fJb8nQYKwvyTIq0vHsrrShfouB70PzW1wdEIWzkL_o=.b9fa0d59-cf19-4ad2-8c1e-0fb1727b280d@github.com>
References: <lM8wzo_N6Mi4Gc63G82Mhii_OuNcYj0skA5fyR5HsYQ=.3cd9341e-27a2-40d4-ae66-2821e1f5d5f6@github.com>
 <6fJb8nQYKwvyTIq0vHsrrShfouB70PzW1wdEIWzkL_o=.b9fa0d59-cf19-4ad2-8c1e-0fb1727b280d@github.com>
Message-ID: <8KM5XxKD3wYLjRVFcH3DCTxlAL5smPdOwCbxk4P5w4w=.48043088-b481-48d8-924f-922592943421@github.com>

On Wed, 7 Dec 2022 14:08:28 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Various code cleanups around java.lang.invoke code. Started out with dead code removal in `jli.MemberName`, then piled on to fix a set of minor inefficiencies (excessive vararg array allocations, unnecessary defensive cloning of parameter arrays etc).
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup more unused imports. Further code removals.

Marked as reviewed by jvernee (Reviewer).

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

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

From redestad at openjdk.org  Wed Dec  7 15:38:24 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 7 Dec 2022 15:38:24 GMT
Subject: RFR: 8298177: Various java.lang.invoke cleanups [v4]
In-Reply-To: <6fJb8nQYKwvyTIq0vHsrrShfouB70PzW1wdEIWzkL_o=.b9fa0d59-cf19-4ad2-8c1e-0fb1727b280d@github.com>
References: <lM8wzo_N6Mi4Gc63G82Mhii_OuNcYj0skA5fyR5HsYQ=.3cd9341e-27a2-40d4-ae66-2821e1f5d5f6@github.com>
 <6fJb8nQYKwvyTIq0vHsrrShfouB70PzW1wdEIWzkL_o=.b9fa0d59-cf19-4ad2-8c1e-0fb1727b280d@github.com>
Message-ID: <XY-uqK9nEyXhv_DKvjF47MwXFcGJVrFTImEUmdkbQ_M=.62e83ef2-1679-47c0-80ee-4528ca02ac8d@github.com>

On Wed, 7 Dec 2022 14:08:28 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Various code cleanups around java.lang.invoke code. Started out with dead code removal in `jli.MemberName`, then piled on to fix a set of minor inefficiencies (excessive vararg array allocations, unnecessary defensive cloning of parameter arrays etc).
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup more unused imports. Further code removals.

Ran through tier1+2 and all java.lang.invoke tests locally without surprises

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

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

From redestad at openjdk.org  Wed Dec  7 15:42:16 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 7 Dec 2022 15:42:16 GMT
Subject: Integrated: 8298177: Various java.lang.invoke cleanups
In-Reply-To: <lM8wzo_N6Mi4Gc63G82Mhii_OuNcYj0skA5fyR5HsYQ=.3cd9341e-27a2-40d4-ae66-2821e1f5d5f6@github.com>
References: <lM8wzo_N6Mi4Gc63G82Mhii_OuNcYj0skA5fyR5HsYQ=.3cd9341e-27a2-40d4-ae66-2821e1f5d5f6@github.com>
Message-ID: <H1fSLSOd0snP0lH7R2yWkPBOvR25tRE7ZhUKiW2C5-E=.dc04b036-aa9d-4b14-88a9-a334d5dbccb9@github.com>

On Tue, 6 Dec 2022 15:22:27 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Various code cleanups around java.lang.invoke code. Started out with dead code removal in `jli.MemberName`, then piled on to fix a set of minor inefficiencies (excessive vararg array allocations, unnecessary defensive cloning of parameter arrays etc).

This pull request has now been integrated.

Changeset: 3de77509
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3de775094dab3c375a32ddabdd24456d177d3009
Stats:     397 lines in 11 files changed: 22 ins; 317 del; 58 mod

8298177: Various java.lang.invoke cleanups
8284363: Redundant imports in BoundMethodHandle

Reviewed-by: jvernee

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

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

From duke at openjdk.org  Wed Dec  7 15:54:58 2022
From: duke at openjdk.org (Markus KARG)
Date: Wed, 7 Dec 2022 15:54:58 GMT
Subject: RFR: JDK-8297298 - SequenceInputStream should override transferTo
 [v2]
In-Reply-To: <z4ZRDUbpzJKP7yHpSuFnmYfKvKRpkh6nb93EncLIBB4=.22395784-316b-4434-9a99-1915d9c58baf@github.com>
References: <f29hhy9J107mH2fJNTnIkR4u8JDXaHym8Mt_H9rwo8Y=.159e4f3e-e38f-496e-a6e2-65b3635bd897@github.com>
 <Ike0eQ9Ie59ga1NR7B1tECSMhPIjSKpXqdZCGUBtDL4=.761ef92f-260a-41ab-a483-aa2a2f6c9b69@github.com>
 <F6eAl7jxzmSj577gvVp54QKB_udCemJL_mfyxh5iQMQ=.e599efa7-f0d1-49fc-ae90-55598f4f1bc3@github.com>
 <z4ZRDUbpzJKP7yHpSuFnmYfKvKRpkh6nb93EncLIBB4=.22395784-316b-4434-9a99-1915d9c58baf@github.com>
Message-ID: <7HQmRG__f8M4ZgiMpw2T_mEqfNabxDg9tGuh0uiUGnI=.abc034eb-a8ff-4d39-8348-394e26dcd059@github.com>

On Tue, 6 Dec 2022 16:20:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> test/jdk/java/io/SequenceInputStream/TransferTo.java line 206:
>> 
>>> 204:     }
>>> 205: 
>>> 206: }
>> 
>> As auto-detected, there is no newline at the end of this file. Otherwise it appears all right.
>
> @mkarg Please take account of the JDK 20 rampdown at 16:00 UTC Thursday and that Pacific Time is eight hours behind. Thanks.

@bplb @AlanBateman All checks have passed. As time runs out, can you please set the review mark in Github? Thanks! :-)

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

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

From bpb at openjdk.org  Wed Dec  7 16:23:56 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 7 Dec 2022 16:23:56 GMT
Subject: RFR: JDK-8297298 - SequenceInputStream should override transferTo
 [v3]
In-Reply-To: <JOLqPTs1JtesPdIu5C5J7dGNo6mOcA0YtAYW36DPRvo=.456a2f2f-3684-4520-a3ce-2665a75af684@github.com>
References: <f29hhy9J107mH2fJNTnIkR4u8JDXaHym8Mt_H9rwo8Y=.159e4f3e-e38f-496e-a6e2-65b3635bd897@github.com>
 <JOLqPTs1JtesPdIu5C5J7dGNo6mOcA0YtAYW36DPRvo=.456a2f2f-3684-4520-a3ce-2665a75af684@github.com>
Message-ID: <yT0gMD5MlKlsdsd1kEtUEXRUV2l2lUtLBqIZ-JBYhFg=.35c8a437-d396-47dc-b712-c999db62d302@github.com>

On Wed, 7 Dec 2022 12:41:19 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Since JDK 18 some implementations of InputStream.transferTo, namely FileInputStream and ChannelInputStream, offload work to lower layers using NIO channels. This provides shorter execution time and reduced resource consumption. Unfortunately, this effect is prevented once the input stream itself is wrapped by a SequenceInputStream. While compared to other InputStreams the SequenceInputStream is a rather edge case (e. g. used to merge two files into one), nevertheless it makes sense to get rid of this obstacle simply by implementing transferTo (e. g. by allowing to offload the file merge, or parts of the file merge, to the operating system). As a result, more existing applications will experience the offloading-improvements made by JDK 18.
>> 
>> To provide enhanced performance to existing applications, it makes sense to address this impediment: SequenceInputStream.transferTo should be implemented in a way that iteratively calls transferTo on each enumerated InputStream of the SequenceInputStream in ordered sequence.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   EOL missing in last line

Marked as reviewed by bpb (Reviewer).

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

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

From duke at openjdk.org  Wed Dec  7 16:23:57 2022
From: duke at openjdk.org (Markus KARG)
Date: Wed, 7 Dec 2022 16:23:57 GMT
Subject: RFR: JDK-8297298 - SequenceInputStream should override transferTo
 [v3]
In-Reply-To: <JOLqPTs1JtesPdIu5C5J7dGNo6mOcA0YtAYW36DPRvo=.456a2f2f-3684-4520-a3ce-2665a75af684@github.com>
References: <f29hhy9J107mH2fJNTnIkR4u8JDXaHym8Mt_H9rwo8Y=.159e4f3e-e38f-496e-a6e2-65b3635bd897@github.com>
 <JOLqPTs1JtesPdIu5C5J7dGNo6mOcA0YtAYW36DPRvo=.456a2f2f-3684-4520-a3ce-2665a75af684@github.com>
Message-ID: <39lgf4n1PDl7X24ffsAy8l1sX5heLaj5-gu2BztuYuk=.49191883-3a9a-4c55-a658-37f5c614e60d@github.com>

On Wed, 7 Dec 2022 12:41:19 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Since JDK 18 some implementations of InputStream.transferTo, namely FileInputStream and ChannelInputStream, offload work to lower layers using NIO channels. This provides shorter execution time and reduced resource consumption. Unfortunately, this effect is prevented once the input stream itself is wrapped by a SequenceInputStream. While compared to other InputStreams the SequenceInputStream is a rather edge case (e. g. used to merge two files into one), nevertheless it makes sense to get rid of this obstacle simply by implementing transferTo (e. g. by allowing to offload the file merge, or parts of the file merge, to the operating system). As a result, more existing applications will experience the offloading-improvements made by JDK 18.
>> 
>> To provide enhanced performance to existing applications, it makes sense to address this impediment: SequenceInputStream.transferTo should be implemented in a way that iteratively calls transferTo on each enumerated InputStream of the SequenceInputStream in ordered sequence.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   EOL missing in last line

Thank you, Brian.

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

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

From duke at openjdk.org  Wed Dec  7 16:29:28 2022
From: duke at openjdk.org (Markus KARG)
Date: Wed, 7 Dec 2022 16:29:28 GMT
Subject: RFR: JDK-8297298 - SequenceInputStream should override transferTo
 [v2]
In-Reply-To: <eY7jWrOjwJR6YTsJGN3oDhD-v8aYw9aadCeOHJUxKbo=.3d5e92af-f846-4378-88f9-870ef99dbaf1@github.com>
References: <f29hhy9J107mH2fJNTnIkR4u8JDXaHym8Mt_H9rwo8Y=.159e4f3e-e38f-496e-a6e2-65b3635bd897@github.com>
 <Ike0eQ9Ie59ga1NR7B1tECSMhPIjSKpXqdZCGUBtDL4=.761ef92f-260a-41ab-a483-aa2a2f6c9b69@github.com>
 <eY7jWrOjwJR6YTsJGN3oDhD-v8aYw9aadCeOHJUxKbo=.3d5e92af-f846-4378-88f9-870ef99dbaf1@github.com>
Message-ID: <TU7f_4WvHerIxtZN6sBlG4nry-Ib1nBdk5cdgK33kA8=.890d1e17-5f53-4fd0-a20f-6bf12fc2e61d@github.com>

On Tue, 29 Nov 2022 23:40:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed bug number
>
>> > Please take note of the changes proposed in #11403.
>> 
>> It might make sense to merge _this_ PR as-is _first_, but then add the needed fix to #11403 afterwards?
> 
> I concur. I will take a look at the test soon.

@bplb Brian, I would be happy if you could sponsor this PR. :-)

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

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

From rriggs at openjdk.org  Wed Dec  7 16:30:14 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 7 Dec 2022 16:30:14 GMT
Subject: RFR: JDK-8298170 : Introduce a macro for exception check,
 free and return
In-Reply-To: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
References: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
Message-ID: <A1uT4hPZxgKW7wK02bmXt_NDnnUV-6coQ8Z1wtBKYjw=.10d27751-2aab-45c4-becf-974ed9f3e4fc@github.com>

On Tue, 6 Dec 2022 15:20:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have a number of places in the codebase  where a macro could help when we check an exception and afterwrads free something and return.

Good idea, though perhaps the return (and value if any) could be explicit in the macro invocation, instead of implicit (plus arg).  A single macro would suffice, instead of multiples.

Usage Example:

    JNU_CHECK_EXCEPTION_DO(env, { 
             free(tab); 
             return;
           })

Or put the invocation and return all on one line.

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

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

From duke at openjdk.org  Wed Dec  7 16:35:09 2022
From: duke at openjdk.org (Markus KARG)
Date: Wed, 7 Dec 2022 16:35:09 GMT
Subject: RFR: JDK-8297298 - SequenceInputStream should override transferTo
 [v2]
In-Reply-To: <eY7jWrOjwJR6YTsJGN3oDhD-v8aYw9aadCeOHJUxKbo=.3d5e92af-f846-4378-88f9-870ef99dbaf1@github.com>
References: <f29hhy9J107mH2fJNTnIkR4u8JDXaHym8Mt_H9rwo8Y=.159e4f3e-e38f-496e-a6e2-65b3635bd897@github.com>
 <Ike0eQ9Ie59ga1NR7B1tECSMhPIjSKpXqdZCGUBtDL4=.761ef92f-260a-41ab-a483-aa2a2f6c9b69@github.com>
 <eY7jWrOjwJR6YTsJGN3oDhD-v8aYw9aadCeOHJUxKbo=.3d5e92af-f846-4378-88f9-870ef99dbaf1@github.com>
Message-ID: <_NfwcolodnScpjTDMkz-BI1qtbDSwXS8TVjdBRwzgpg=.17db8902-c452-46bd-92c7-1582aadab7a5@github.com>

On Tue, 29 Nov 2022 23:40:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed bug number
>
>> > Please take note of the changes proposed in #11403.
>> 
>> It might make sense to merge _this_ PR as-is _first_, but then add the needed fix to #11403 afterwards?
> 
> I concur. I will take a look at the test soon.

@bplb Thank you so much! Seems we won the price for the most short-notice commit to JDK 20. ;-)

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

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

From duke at openjdk.org  Wed Dec  7 16:35:12 2022
From: duke at openjdk.org (Markus KARG)
Date: Wed, 7 Dec 2022 16:35:12 GMT
Subject: Integrated: JDK-8297298 - SequenceInputStream should override
 transferTo
In-Reply-To: <f29hhy9J107mH2fJNTnIkR4u8JDXaHym8Mt_H9rwo8Y=.159e4f3e-e38f-496e-a6e2-65b3635bd897@github.com>
References: <f29hhy9J107mH2fJNTnIkR4u8JDXaHym8Mt_H9rwo8Y=.159e4f3e-e38f-496e-a6e2-65b3635bd897@github.com>
Message-ID: <lm0o7eUb5j7_p9fIaCNiWCvgOdFjBInbCmKCeTsp1eI=.fbdf409e-fd05-455a-95b5-1ed3edfbac1a@github.com>

On Sat, 19 Nov 2022 16:36:28 GMT, Markus KARG <duke at openjdk.org> wrote:

> Since JDK 18 some implementations of InputStream.transferTo, namely FileInputStream and ChannelInputStream, offload work to lower layers using NIO channels. This provides shorter execution time and reduced resource consumption. Unfortunately, this effect is prevented once the input stream itself is wrapped by a SequenceInputStream. While compared to other InputStreams the SequenceInputStream is a rather edge case (e. g. used to merge two files into one), nevertheless it makes sense to get rid of this obstacle simply by implementing transferTo (e. g. by allowing to offload the file merge, or parts of the file merge, to the operating system). As a result, more existing applications will experience the offloading-improvements made by JDK 18.
> 
> To provide enhanced performance to existing applications, it makes sense to address this impediment: SequenceInputStream.transferTo should be implemented in a way that iteratively calls transferTo on each enumerated InputStream of the SequenceInputStream in ordered sequence.

This pull request has now been integrated.

Changeset: 389b8f4b
Author:    Markus KARG <markus at headcrashing.eu>
Committer: Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/389b8f4b788375821a8bb4b017e50f905abdad2d
Stats:     37 lines in 2 files changed: 19 ins; 7 del; 11 mod

8297298: SequenceInputStream should override transferTo

Reviewed-by: bpb

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

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

From stuefe at openjdk.org  Wed Dec  7 16:45:02 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 7 Dec 2022 16:45:02 GMT
Subject: RFR: JDK-8298170 : Introduce a macro for exception check,
 free and return
In-Reply-To: <A1uT4hPZxgKW7wK02bmXt_NDnnUV-6coQ8Z1wtBKYjw=.10d27751-2aab-45c4-becf-974ed9f3e4fc@github.com>
References: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
 <A1uT4hPZxgKW7wK02bmXt_NDnnUV-6coQ8Z1wtBKYjw=.10d27751-2aab-45c4-becf-974ed9f3e4fc@github.com>
Message-ID: <4zHedrkH9jgKyqCdI__dW2Ce31J6K28vyXSzv3LFONY=.397d9792-06b8-4642-a7cf-6a43c7609cc1@github.com>

On Wed, 7 Dec 2022 16:27:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> 
> Good idea, though perhaps the return (and value if any) could be explicit in the macro invocation, instead of implicit (plus arg). A single macro would suffice, instead of multiples.
> 
> Usage Example:
> 
> ```
>     JNU_CHECK_EXCEPTION_DO(env, { 
>              free(tab); 
>              return;
>            })
> ```

Neat. I like that.

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

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

From naoto at openjdk.org  Wed Dec  7 17:09:53 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 7 Dec 2022 17:09:53 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v12]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <Ca17Ww15KaZI94Q1s3B96D6noH9CGM7aY-SxlHoCu6A=.35df9f1c-2518-40a4-b384-028a4e134bb8@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

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

  Addressing review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/40de5d0a..187f94fb

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

  Stats: 10 lines in 3 files changed: 8 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11421.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11421/head:pull/11421

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

From naoto at openjdk.org  Wed Dec  7 17:09:56 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 7 Dec 2022 17:09:56 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v11]
In-Reply-To: <X70i0DJuWySlOcLcVntBQZ5Oq2_5y_Cmd1RNP4ud6Vw=.2c84f607-cc40-43cf-88cc-4c4599ad03ba@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <l6LdCakkTqmWO4D-om35LxcrFtrGDaKNeNdLtQjD6Ac=.d61eb655-dfee-4d75-89ae-10faae3978fb@github.com>
 <X70i0DJuWySlOcLcVntBQZ5Oq2_5y_Cmd1RNP4ud6Vw=.2c84f607-cc40-43cf-88cc-4c4599ad03ba@github.com>
Message-ID: <byXWsns6Ak-qqqiCaBka1snSKZd2Cov3tmuz3SBt1MA=.b6f6045a-eced-4a78-b279-fc3043082680@github.com>

On Wed, 7 Dec 2022 11:54:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Making the wrapper classes static
>
> src/java.base/share/classes/java/io/Console.java line 625:
> 
>> 623:             };
>> 624:             return AccessController.doPrivileged(pa);
>> 625:         } catch (Throwable ignore) {
> 
> I don't think we should be catching and ignoring throwable here. The only case that would be okay to ignore here is SCE due to SecurityException as the jline provider doesn't work with a SM set.

OK, reverted the catch clause.

> src/java.base/share/classes/java/io/ProxyingConsole.java line 175:
> 
>> 173: 
>> 174:         public WrappingWriter(PrintWriter pw, Object lock) {
>> 175:             super(pw);
> 
> PrintWriter doesn't provide a way to provide to lock object so this means the overridden methods will synchronize on "lock", the non-overridden methods will synchronize on "pw". So we will need to look at this.

Created a package private constructor just for `ProxyingConsole` to synchronize on the specified lock object.

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

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

From bchristi at openjdk.org  Wed Dec  7 17:33:11 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 7 Dec 2022 17:33:11 GMT
Subject: RFR: 8295857: Clarify that cleanup code can be skipped when the
 JVM terminates (e.g. when calling halt()) [v6]
In-Reply-To: <hHSImvhd-Yg6AcPkSrYBFxBOx4jBg079lx4sRjR3AZc=.65cd47c4-b34a-4475-8b35-069627999eed@github.com>
References: <hHSImvhd-Yg6AcPkSrYBFxBOx4jBg079lx4sRjR3AZc=.65cd47c4-b34a-4475-8b35-069627999eed@github.com>
Message-ID: <ucA3RepMYAqwbF9bciR6okxdgyJCdj_udGe8DI22OSQ=.daf6eea0-853e-45c2-86e5-43e45b02520f@github.com>

> [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036) documented the shutdown sequence, noting that calling Runtime.halt() skips the shutdown sequence and immediately terminates the VM. Thus, "threads' current methods do not complete normally or abruptly; no finally clause of any method is executed".
> 
> One ramification of this is that resources within try-with-resource blocks will not be released. It would be good to state this explicitly.

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

  'close' -> 'closed' in AutoCloseable link

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11218/files
  - new: https://git.openjdk.org/jdk/pull/11218/files/4f2fb241..db0ea778

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

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

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

From bchristi at openjdk.org  Wed Dec  7 17:33:13 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 7 Dec 2022 17:33:13 GMT
Subject: RFR: 8295857: Clarify that cleanup code can be skipped when the
 JVM terminates (e.g. when calling halt()) [v5]
In-Reply-To: <3_LKQFso5Bl3u6mLfJ6mKi5lb5bLECRgVY_gHN664Is=.02709ef7-b163-46e6-93e1-092776479a04@github.com>
References: <hHSImvhd-Yg6AcPkSrYBFxBOx4jBg079lx4sRjR3AZc=.65cd47c4-b34a-4475-8b35-069627999eed@github.com>
 <K5xYZSxaq80NneeRv23ju8tWsvFaLms3kuzcIqngtN0=.5364fd95-d495-49ed-9cdf-bf949ed95dcd@github.com>
 <3_LKQFso5Bl3u6mLfJ6mKi5lb5bLECRgVY_gHN664Is=.02709ef7-b163-46e6-93e1-092776479a04@github.com>
Message-ID: <NjnxajT4gHYGL4ck4TsFcjA8fipvRlN9nLrUDOlozRA=.e451a3ee-da66-4c3c-9536-26d064da9852@github.com>

On Wed, 7 Dec 2022 02:39:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   put examples into a list, in class doc only, not halt()
>
> src/java.base/share/classes/java/lang/Runtime.java line 98:
> 
>> 96:  * <li>{@code finally} clauses are not executed;</li>
>> 97:  * <li>{@linkplain Thread.UncaughtExceptionHandler uncaught exception handlers} are not run; and</li>
>> 98:  * <li>resources opened with try-with-resources are not {@linkplain AutoCloseable close}d;</li>
> 
> Having the 'd' outside the link text looks very odd to me.

Changed

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

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

From bchristi at openjdk.org  Wed Dec  7 17:38:31 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 7 Dec 2022 17:38:31 GMT
Subject: RFR: 8295857: Clarify that cleanup code can be skipped when the
 JVM terminates (e.g. when calling halt()) [v7]
In-Reply-To: <hHSImvhd-Yg6AcPkSrYBFxBOx4jBg079lx4sRjR3AZc=.65cd47c4-b34a-4475-8b35-069627999eed@github.com>
References: <hHSImvhd-Yg6AcPkSrYBFxBOx4jBg079lx4sRjR3AZc=.65cd47c4-b34a-4475-8b35-069627999eed@github.com>
Message-ID: <zUoFDkXVFWLVJv0wGr2Rhmh9pff1dcX6vuQBdt2EQL8=.2d21d1e8-1008-4cdd-8e5f-4166bd2845df@github.com>

> [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036) documented the shutdown sequence, noting that calling Runtime.halt() skips the shutdown sequence and immediately terminates the VM. Thus, "threads' current methods do not complete normally or abruptly; no finally clause of any method is executed".
> 
> One ramification of this is that resources within try-with-resource blocks will not be released. It would be good to state this explicitly.

Brent Christian has updated the pull request with a new target base 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 8295857
 - 'close' -> 'closed' in AutoCloseable link
 - put examples into a list, in class doc only, not halt()
 - Update Runtime class doc re: other unexpected behaviors
 - Mentioned effects are not a complete list
 - It's "try-with-resources"
 - Merge branch 'master' into 8295857
 - update halt() @apiNote
 - update doc changes
 - Update doc for Runtime class and halt() method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11218/files
  - new: https://git.openjdk.org/jdk/pull/11218/files/db0ea778..5d8b2615

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

  Stats: 130011 lines in 2031 files changed: 58264 ins; 52000 del; 19747 mod
  Patch: https://git.openjdk.org/jdk/pull/11218.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11218/head:pull/11218

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

From rpressler at openjdk.org  Wed Dec  7 17:56:17 2022
From: rpressler at openjdk.org (Ron Pressler)
Date: Wed, 7 Dec 2022 17:56:17 GMT
Subject: RFR: 8296896: Change virtual Thread.yield to use external submit
In-Reply-To: <S0emMR0JXtg41aa6ITXJg7IlxJljzGwPGuyjOdH98Gc=.691bc53c-d851-414f-8261-020f96dbde93@github.com>
References: <S0emMR0JXtg41aa6ITXJg7IlxJljzGwPGuyjOdH98Gc=.691bc53c-d851-414f-8261-020f96dbde93@github.com>
Message-ID: <-WhR5Xrrr6FOaubTshOOpVq4RKoAZlTSaC9n1_Tkirs=.23675a12-2c70-40f5-98d9-ce0239f4547b@github.com>

On Tue, 6 Dec 2022 10:16:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The implementation of Thread.yield for virtual threads is currently a "lazy submit". This means the task for the virtual thread is queued to the carrier/worker local queue without signalling other threads. This behavior can be surprising/unfair when there are tasks in the submission queues, say when a platform thread has started or unparked a virtual thread.
> 
> Ron, Doug Lea, Viktor Klang and I have discussed this topic and propose to change Thread.yield to  use "external submit" when the local task queue is empty, and to push to the local queue when not empty. The change improves the fairness but will of course increase the chances that repeated Thread.yield will bounce between carriers.

Marked as reviewed by rpressler (Committer).

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

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

From bhuang at openjdk.org  Wed Dec  7 17:56:25 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Wed, 7 Dec 2022 17:56:25 GMT
Subject: RFR: JDK-8295756 Improve NonLocalRegistry Manual Test Process [v8]
In-Reply-To: <zimo9_4V7yIIQ80Etwuvzqy7sRZvsJw5zbaeYv6J8gM=.67e06cf4-0f42-4f2c-9081-9fd5461b7b12@github.com>
References: <zimo9_4V7yIIQ80Etwuvzqy7sRZvsJw5zbaeYv6J8gM=.67e06cf4-0f42-4f2c-9081-9fd5461b7b12@github.com>
Message-ID: <Zo4vDXJQgrwa9N0aQs5CPrzxuONmixM-nogpsLogQBs=.f4067505-b186-4a7e-8679-9dde40a5a736@github.com>

> The current non local registry tests require a manual process that runs rmiregitrty on a different machine and changes the -Dregistry.host property in the source before running the tests on the local machine. This task is created to improve this manual process and provide a clearer instruction to the test engineer about the test requirement. 
> 
> Tests include: 
> java/rmi/registry/nonLocalRegistry/NonLocalSkeletonTest.java 
> java/rmi/registry/nonLocalRegistry/NonLocalRegistryTest.java 
> javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.java

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

  Reduced host input timeout to 5 minutes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10825/files
  - new: https://git.openjdk.org/jdk/pull/10825/files/c5648165..761cf908

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

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

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

From alanb at openjdk.org  Wed Dec  7 18:47:06 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Dec 2022 18:47:06 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v6]
In-Reply-To: <7f0PjG00BGhLCA3Kjlohhp3YGB_Xv8BPexToz66PxWc=.cb042f58-79b2-4c80-a5d4-245e95227858@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <7f0PjG00BGhLCA3Kjlohhp3YGB_Xv8BPexToz66PxWc=.cb042f58-79b2-4c80-a5d4-245e95227858@github.com>
Message-ID: <NOQNyJbhwHflQHgEMtkIZnh7FJ4K8Q095DYxACb30yg=.47ecac25-789b-4b9a-99be-7d40eeadcd2c@github.com>

On Tue, 6 Dec 2022 16:06:34 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Libgraal is compiled ahead of time and should not need any JVMCI Java code to be dynamically loaded at runtime. Prior to this PR, this is not the case due to:
>> 
>> * Code to copy system properties from the HotSpot heap into the libgraal heap. This is in `jdk.vm.ci.services.Services.initializeSavedProperties(byte[])` and `jdk.vm.ci.services.Services.serializeSavedProperties()`. This code should be moved to `java.base/jdk.internal.vm.VMSupport`.
>> * Code to translate exceptions from the HotSpot heap into the libgraal heap and vice versa. This code should be moved from `jdk.internal.vm.ci//jdk.vm.ci.hotspot.TranslatedException` to `java.base/jdk.internal.vm.VMSupport`.
>> 
>> This PR makes the above changes. As a result, it's possible to build a JDK image that includes (and uses) libgraal but does not include `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces footprint and better isolates the JAVMCI and the Graal compiler as accessing these components from Java code is now impossible.
>
> Doug Simon has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - formatting to avoid very long lines [skip ci]
>  - removed debug code [skip ci]
>  - clarify Properties filtering [skip ci]
>  - remove debug code [skip ci]

src/java.base/share/classes/jdk/internal/vm/TranslatedException.java line 128:

> 126:         // Try create with reflection first.
> 127:         try {
> 128:             Class<?> cls = Class.forName(className);

A question about the Class.forName usage here. Class.forName uses the defining class loader of the current class so I'm wondering if the exceptions to be decoded are always of a type defined to the boot loader? jdk.internal.vm.ci is defined to the boot loader so this code hasn't really changed, it's just "new" to java.base in this PR.

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

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

From alanb at openjdk.org  Wed Dec  7 18:47:09 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Dec 2022 18:47:09 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v5]
In-Reply-To: <YYb6ipJjooXfXoFyWhz_Sus76yoDgkB5OIKvFTsYsWA=.c1a15d4f-c6b1-4610-b110-dbab35b14667@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <kU-NHwhiGEJLa7-o38UCemcxhU8WR_ijQBMGOAknOTs=.57d0341c-30af-4c39-ab42-4278fdfb2e5d@github.com>
 <-vjDxNaafm1m5UERR31dFXH7jdljWTKzsDjntS8v6zs=.4c777f1e-695f-42de-a4b5-0cb0f332243c@github.com>
 <ZSSq3Pl4Nu-BlC_ccliJcYZ9j297sAFUoybpgBrw0Uo=.5aeec02c-d235-4e07-bb23-bc038d512221@github.com>
 <YYb6ipJjooXfXoFyWhz_Sus76yoDgkB5OIKvFTsYsWA=.c1a15d4f-c6b1-4610-b110-dbab35b14667@github.com>
Message-ID: <JNiF-VQnHQCFWGxrumE-PBNRklD7W4Sta9jIfucDBwY=.f55b3a62-6b23-4131-95ca-045617f4794b@github.com>

On Tue, 6 Dec 2022 16:50:47 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This parameter exists to allow a caller to pass in a `Properties` object that is guaranteed to have only String keys and so does not need the extra filtering done in this method. I'll refactor the code to make it clearer.
>
> Hopefully this makes it clearer: https://github.com/openjdk/jdk/pull/11513/commits/5c610798fe4eaed7efeb2eebcf1e5db47714caee

Thanks. I initially assumed it was done to support non-String key/values but it's actually an optimization because the save properties are always Strings.

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

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

From alanb at openjdk.org  Wed Dec  7 18:47:04 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Dec 2022 18:47:04 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v5]
In-Reply-To: <ZSSq3Pl4Nu-BlC_ccliJcYZ9j297sAFUoybpgBrw0Uo=.5aeec02c-d235-4e07-bb23-bc038d512221@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <kU-NHwhiGEJLa7-o38UCemcxhU8WR_ijQBMGOAknOTs=.57d0341c-30af-4c39-ab42-4278fdfb2e5d@github.com>
 <-vjDxNaafm1m5UERR31dFXH7jdljWTKzsDjntS8v6zs=.4c777f1e-695f-42de-a4b5-0cb0f332243c@github.com>
 <ZSSq3Pl4Nu-BlC_ccliJcYZ9j297sAFUoybpgBrw0Uo=.5aeec02c-d235-4e07-bb23-bc038d512221@github.com>
Message-ID: <f_31mygaR5hzqOiPgVY0afF-4FgQbFmgf18PcNgpHPU=.065267c4-effa-41e3-80a1-52d25e63c3d4@github.com>

On Tue, 6 Dec 2022 15:44:04 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/vm/TranslatedException.java line 44:
>> 
>>> 42:  */
>>> 43: @SuppressWarnings("serial")
>>> 44: final class TranslatedException extends Exception {
>> 
>> Would it be possible to re-format this to avoid the wildly long (150+) lines? This seems to be moving jdk.vm.ci.hotspot.TranslatedException and hard to see what is going on.
>
> Is there some tool support for formatting Java source code to meet OpenJDK coding guidelines? Rather unfortunate that one has to do this manually and reviewers have to spend time manually checking it.

There isn't a code or agreed conventions. The cleanup in the latest version looks okay.

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

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

From alanb at openjdk.org  Wed Dec  7 19:01:16 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Dec 2022 19:01:16 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v12]
In-Reply-To: <Ca17Ww15KaZI94Q1s3B96D6noH9CGM7aY-SxlHoCu6A=.35df9f1c-2518-40a4-b384-028a4e134bb8@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Ca17Ww15KaZI94Q1s3B96D6noH9CGM7aY-SxlHoCu6A=.35df9f1c-2518-40a4-b384-028a4e134bb8@github.com>
Message-ID: <JJ24W2UmLNW8Fx5HFMXce0Khjvn6pm6BBk6iO2cJP9I=.9aa7b966-96cc-4bf9-a96f-45f2ffd3abc7@github.com>

On Wed, 7 Dec 2022 17:09:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing review comments

src/java.base/share/classes/java/io/PrintWriter.java line 212:

> 210: 
> 211:     /* package private constructor specific to ProxyingConsole */
> 212:     PrintWriter(Writer out, Object lock) {

This constructor looks fine but maybe the comment should just say that it allows the lock object to be provided rather than mentioning ProxyingConsole here.

src/java.base/share/classes/java/io/ProxyingConsole.java line 167:

> 165:         @Override
> 166:         public void close() throws IOException {
> 167:             r.close();

Console specifies that the invoking close on the Reader and Writer does not close the underlying stream. So I think this close (and WrappingWriter::close) need to be a no-op too.

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

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

From naoto at openjdk.org  Wed Dec  7 19:19:25 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 7 Dec 2022 19:19:25 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v13]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <W8OZOfX1l4OTGU0n3W8anRu1Z-yH2R9-o1F4iyozFgY=.45380ebc-b3c2-4f5a-9165-4060e0bd30fe@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

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

  Refined comments, no-op in WrappingReader/Writer::close()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/187f94fb..ef1a74f2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=11-12

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

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

From naoto at openjdk.org  Wed Dec  7 19:19:28 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 7 Dec 2022 19:19:28 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v12]
In-Reply-To: <JJ24W2UmLNW8Fx5HFMXce0Khjvn6pm6BBk6iO2cJP9I=.9aa7b966-96cc-4bf9-a96f-45f2ffd3abc7@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Ca17Ww15KaZI94Q1s3B96D6noH9CGM7aY-SxlHoCu6A=.35df9f1c-2518-40a4-b384-028a4e134bb8@github.com>
 <JJ24W2UmLNW8Fx5HFMXce0Khjvn6pm6BBk6iO2cJP9I=.9aa7b966-96cc-4bf9-a96f-45f2ffd3abc7@github.com>
Message-ID: <kelivy29sGYuTkG19cOovkBz3kai5Cn_lhOGyP86uIQ=.9cd94465-4eef-4bdf-b3dc-7992a5eceb59@github.com>

On Wed, 7 Dec 2022 18:57:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing review comments
>
> src/java.base/share/classes/java/io/ProxyingConsole.java line 167:
> 
>> 165:         @Override
>> 166:         public void close() throws IOException {
>> 167:             r.close();
> 
> Console specifies that the invoking close on the Reader and Writer does not close the underlying stream. So I think this close (and WrappingWriter::close) need to be a no-op too.

Right. Made them as no-op.

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

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

From dnsimon at openjdk.org  Wed Dec  7 19:33:05 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 7 Dec 2022 19:33:05 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v6]
In-Reply-To: <NOQNyJbhwHflQHgEMtkIZnh7FJ4K8Q095DYxACb30yg=.47ecac25-789b-4b9a-99be-7d40eeadcd2c@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <7f0PjG00BGhLCA3Kjlohhp3YGB_Xv8BPexToz66PxWc=.cb042f58-79b2-4c80-a5d4-245e95227858@github.com>
 <NOQNyJbhwHflQHgEMtkIZnh7FJ4K8Q095DYxACb30yg=.47ecac25-789b-4b9a-99be-7d40eeadcd2c@github.com>
Message-ID: <GNh8FuYL1GL-KBYgrCTaed6w5Q7jLBG3U_f6oVkAyG8=.6ae80825-2b1d-4f22-a6f1-0bcb783d90c2@github.com>

On Wed, 7 Dec 2022 18:42:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Doug Simon has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - formatting to avoid very long lines [skip ci]
>>  - removed debug code [skip ci]
>>  - clarify Properties filtering [skip ci]
>>  - remove debug code [skip ci]
>
> src/java.base/share/classes/jdk/internal/vm/TranslatedException.java line 128:
> 
>> 126:         // Try create with reflection first.
>> 127:         try {
>> 128:             Class<?> cls = Class.forName(className);
> 
> A question about the Class.forName usage here. Class.forName uses the defining class loader of the current class so I'm wondering if the exceptions to be decoded are always of a type defined to the boot loader? jdk.internal.vm.ci is defined to the boot loader so this code hasn't really changed, it's just "new" to java.base in this PR.

The exceptions can be of any type and defined by any loader. In the case that Class.forName fails, the name of the original exception type is shown as part of `TranslationException.toString()`. Combined with the stack trace, this has always been sufficient to understand the origin of an exception thrown on a HotSpot/libjvmci mixed stack.

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

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

From dnsimon at openjdk.org  Wed Dec  7 19:49:47 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 7 Dec 2022 19:49:47 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v7]
In-Reply-To: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
Message-ID: <Epv-jPCuClG7VfVJjqdP3FrqzDLnvxpqSmp_nx3eZP8=.6cabdece-b484-4b24-8d5f-8bdeb222a691@github.com>

> Libgraal is compiled ahead of time and should not need any JVMCI Java code to be dynamically loaded at runtime. Prior to this PR, this is not the case due to:
> 
> * Code to copy system properties from the HotSpot heap into the libgraal heap. This is in `jdk.vm.ci.services.Services.initializeSavedProperties(byte[])` and `jdk.vm.ci.services.Services.serializeSavedProperties()`. This code should be moved to `java.base/jdk.internal.vm.VMSupport`.
> * Code to translate exceptions from the HotSpot heap into the libgraal heap and vice versa. This code should be moved from `jdk.internal.vm.ci//jdk.vm.ci.hotspot.TranslatedException` to `java.base/jdk.internal.vm.VMSupport`.
> 
> This PR makes the above changes. As a result, it's possible to build a JDK image that includes (and uses) libgraal but does not include `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces footprint and better isolates the JAVMCI and the Graal compiler as accessing these components from Java code is now impossible.

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

 - Merge remote-tracking branch 'openjdk-jdk/master' into JDK-8298099
 - formatting to avoid very long lines [skip ci]
 - removed debug code [skip ci]
 - clarify Properties filtering [skip ci]
 - remove debug code [skip ci]
 - incorporate review feedback [skip ci]
 - removed hard-coded module name [skip ci]
 - renamed is_module_resolvable to is_module_observable
 - share code to create the exploded path for a module and avoid stack-based variable length array
 - generalized ClassLoader::has_jvmci_module to is_module_resolvable
 - ... and 4 more: https://git.openjdk.org/jdk/compare/a1a75a56...f5219b20

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11513/files
  - new: https://git.openjdk.org/jdk/pull/11513/files/bdbe7cf2..f5219b20

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

  Stats: 29076 lines in 626 files changed: 16520 ins; 7341 del; 5215 mod
  Patch: https://git.openjdk.org/jdk/pull/11513.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11513/head:pull/11513

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

From rriggs at openjdk.org  Wed Dec  7 20:03:02 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 7 Dec 2022 20:03:02 GMT
Subject: RFR: 8297271: AccessFlags should be specific to class file version
 [v2]
In-Reply-To: <XdUUD-XugxmR9m9vdsmlLGNvkZJ9IymbtyvBcWO_Kr0=.90f077aa-6edc-442d-b5ad-1e2a88e80c35@github.com>
References: <T91R2VWcljZdnCDmWKcuSubKtS2qk5e5sGgKEi1v3Yk=.510cef48-e0f0-4590-b7d4-c16aafe71087@github.com>
 <GM-fUW61FhxC-eKiH54AZLHU_V_DVFntZomHK-4LrKo=.5eb42e6d-2df0-4030-a462-9c13f59234cf@github.com>
 <vRsNbQt2rIPfcBAnT5uVPGJnFdvkBEk7OumsHZZ4Ius=.a3384cef-6ae2-4e1e-95c8-e491773b6300@github.com>
 <rz_WZRrsb7a4GS0mtKJ_wSlBkOqlp17_MaqD9myJXco=.93b5b84c-f626-45f6-ab34-8506b42a2f92@github.com>
 <XdUUD-XugxmR9m9vdsmlLGNvkZJ9IymbtyvBcWO_Kr0=.90f077aa-6edc-442d-b5ad-1e2a88e80c35@github.com>
Message-ID: <49BJJNZTIFyIUCktY8m3TK_paM01lZYYTI9JPlzYKWw=.2d10570e-d589-4b59-9a68-7e77f39e250a@github.com>

On Tue, 6 Dec 2022 03:33:25 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> I would propose to say:
>>      
>>     Mask bits that do not match an {@code AccessFlag} for the location and 
>>     class file format version are ignored.
>> 
>> The case arises when the mask argument contains mask bits that are not consistent with the locations defined for any AccessFlag.
>> The current method throws IllegalArgumentException, while the added method returns a set of AccessFlags appropriate to the location and cffv and ignores the undefined mask bits.
>> 
>> If the source of the error/inconsistency is an application developer calling `maskToAccessFlags()` then IAE makes sense.
>> However, it would puzzling if a call to Class.accessFlags() threw IllegalArgumentException; in that case the mask bits are those of a loaded class, presumed to be conforming to the spec, but none the less having unexpected mask bits.
>> Such an recurrence is likely very rare but might be the result of a class file created by some means other than the javac compiler. The declaration of each AccessFlag implements the location and cffv information and corresponding mask bits according the JVM spec. If the VM loads the class, then the question is whether the inconsistency should be reported and if so how.
>
> From an end-user perspective, "the system" should screen out or otherwise take care of undefined/inappropriate modifier bits and access flags in loaded class files.
> 
> In the JDK implementation, there is a separation between the HotSpot JVM and the class libraries, in this case core reflection. One could argue -- and as a maintainer of the core reflection libraries I would argue -- that HotSpot should screen out undefined/inappropriate access flag bits before presenting them to the user. If that is not done, with the non-public method to return the class file format version of the class file, the Java libraries side of core reflection has enough information to do such screening on its own. (IIRC, from some off-list discussions @RogerRiggs ran into cases where a hand-crafted class file could have the ACC_SYNTHETIC flag set on a class for a version of the class file format where ACC_SYNTHETIC wasn't defined. This flag was passed from HotSpot to the core libraries, running afoul of the stricter checking on the existing maskToAccessFlags method.)
> 
> There are class file / byte code processing APIs where showing all the access flag bits, even when not defined for a class file versions, is the right answer. However, I don't think core reflection is one of those APIs. In the spirit of JVMS "4.1. The ClassFile Structure":
> 
> "All bits of the access_flags item not assigned in [Table 4.1-B](https://docs.oracle.com/javase/specs/jvms/se19/html/jvms-4.html#jvms-4.1-200-E.1) are reserved for future use. They should be set to zero in generated class files and should be ignored by Java Virtual Machine implementations."
> 
> I think it would be reasonable to mask out undefined bits either in HotSpot or the core reflection libraries.

Should the masking out unassigned bits that is done in this method be extended to the existing `AccessFlag.maskToAccessFlags(mask, location)`;  Instead of throwing `IllegalArgumentException`?
The two methods should be consistent in this regard and build their return values on the meta-data in each AccessFlag.

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

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

From darcy at openjdk.org  Wed Dec  7 20:19:59 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 7 Dec 2022 20:19:59 GMT
Subject: RFR: 8297271: AccessFlags should be specific to class file version
 [v2]
In-Reply-To: <49BJJNZTIFyIUCktY8m3TK_paM01lZYYTI9JPlzYKWw=.2d10570e-d589-4b59-9a68-7e77f39e250a@github.com>
References: <T91R2VWcljZdnCDmWKcuSubKtS2qk5e5sGgKEi1v3Yk=.510cef48-e0f0-4590-b7d4-c16aafe71087@github.com>
 <GM-fUW61FhxC-eKiH54AZLHU_V_DVFntZomHK-4LrKo=.5eb42e6d-2df0-4030-a462-9c13f59234cf@github.com>
 <vRsNbQt2rIPfcBAnT5uVPGJnFdvkBEk7OumsHZZ4Ius=.a3384cef-6ae2-4e1e-95c8-e491773b6300@github.com>
 <rz_WZRrsb7a4GS0mtKJ_wSlBkOqlp17_MaqD9myJXco=.93b5b84c-f626-45f6-ab34-8506b42a2f92@github.com>
 <XdUUD-XugxmR9m9vdsmlLGNvkZJ9IymbtyvBcWO_Kr0=.90f077aa-6edc-442d-b5ad-1e2a88e80c35@github.com>
 <49BJJNZTIFyIUCktY8m3TK_paM01lZYYTI9JPlzYKWw=.2d10570e-d589-4b59-9a68-7e77f39e250a@github.com>
Message-ID: <DUScC7A8NMk1ksHMLk3lBd5XFMFtp-UGO0pN6sSNXrY=.627e4783-9f4f-4bcc-9c1b-1b36a9ea77e6@github.com>

On Wed, 7 Dec 2022 19:59:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Should the masking out unassigned bits that is done in this method be extended to the existing `AccessFlag.maskToAccessFlags(mask, location)`; Instead of throwing `IllegalArgumentException`? The two methods should be consistent in this regard and build their return values on the meta-data in each AccessFlag.

My prior comment

"The difference in exception handling behavior compared to the method w/o a ClassFileFormatVersion argument should at least be discussed."

was calling attention to the differing strict vs lax handling of unexpected bits in the two overloaded methods. If the policies are not the same, there should at least be prominent text nothing and explaining the difference.

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

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

From xliu at openjdk.org  Wed Dec  7 20:28:12 2022
From: xliu at openjdk.org (Xin Liu)
Date: Wed, 7 Dec 2022 20:28:12 GMT
Subject: RFR: 8284493: Improve computeNextExponential tail performance and
 accuracy [v16]
In-Reply-To: <wbFmoH5Ezcp66xSmyKmfG2kyYL2RIJTxGcLY06MalUc=.257566db-d246-4211-8422-2638768d5943@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
 <GKQOg02og11alcCgOGPGZ2wn41zf6g5RylUm74Glr_k=.e5ad1226-a6ee-412f-8508-08946ef11eae@github.com>
 <wbFmoH5Ezcp66xSmyKmfG2kyYL2RIJTxGcLY06MalUc=.257566db-d246-4211-8422-2638768d5943@github.com>
Message-ID: <Lq6DFTk0jdokOkfvKqWoBhtpYgEGpNfKOw5epx46h-4=.e660db98-33ab-4261-b3f2-a0ff22171539@github.com>

On Fri, 2 Dec 2022 20:38:14 GMT, Chris Hennick <duke at openjdk.org> wrote:

> It's probably just a statistical fluke involving a very large return value, but to know for sure I'd need a way to gather statistics about the return values and how they correlate with running-time outliers.

Yeah, it's likely that p100 data are outliers. I think average and p50 data make more sense. 
I am not a reviewer and lack domain-specific knowledge in the algorithm. I check your code and it seems reasonable. We need reviewers to look into it.

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

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

From alanb at openjdk.org  Wed Dec  7 20:32:17 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Dec 2022 20:32:17 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v13]
In-Reply-To: <W8OZOfX1l4OTGU0n3W8anRu1Z-yH2R9-o1F4iyozFgY=.45380ebc-b3c2-4f5a-9165-4060e0bd30fe@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <W8OZOfX1l4OTGU0n3W8anRu1Z-yH2R9-o1F4iyozFgY=.45380ebc-b3c2-4f5a-9165-4060e0bd30fe@github.com>
Message-ID: <Eqp_Y4HRUt6x1S881hkgco_Fa-uu54vmlsFNjOQU8T4=.1af56400-2f72-49b6-9edd-b85b7371e2c0@github.com>

On Wed, 7 Dec 2022 19:19:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refined comments, no-op in WrappingReader/Writer::close()

Marked as reviewed by alanb (Reviewer).

Thanks for the updates, I don't have any more comments. I think should create a follow-up issue to "hollow out" Console and have two separate implementations/subclasses. I think that would make it much cleaner rather than one implementation extending the other as we have now.

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

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

From naoto at openjdk.org  Wed Dec  7 20:52:14 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 7 Dec 2022 20:52:14 GMT
Subject: Integrated: 8295803: Console should be usable in jshell and other
 environments
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <bOnY-BRcoxyu7BXfC2PxL1Jg_7Fr3LzHoDwobCMf73I=.c16e77bf-b085-4006-8e32-da26783ee5c4@github.com>

On Tue, 29 Nov 2022 19:38:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

This pull request has now been integrated.

Changeset: 8a9911ef
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8a9911ef1762ae837e427ec9d91b1399ba33b6e4
Stats:     684 lines in 17 files changed: 661 ins; 11 del; 12 mod

8295803: Console should be usable in jshell and other environments

Reviewed-by: jlaskey, alanb

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

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

From rriggs at openjdk.org  Wed Dec  7 21:38:09 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 7 Dec 2022 21:38:09 GMT
Subject: RFR: 8297271: AccessFlags should be specific to class file version
 [v2]
In-Reply-To: <DUScC7A8NMk1ksHMLk3lBd5XFMFtp-UGO0pN6sSNXrY=.627e4783-9f4f-4bcc-9c1b-1b36a9ea77e6@github.com>
References: <T91R2VWcljZdnCDmWKcuSubKtS2qk5e5sGgKEi1v3Yk=.510cef48-e0f0-4590-b7d4-c16aafe71087@github.com>
 <GM-fUW61FhxC-eKiH54AZLHU_V_DVFntZomHK-4LrKo=.5eb42e6d-2df0-4030-a462-9c13f59234cf@github.com>
 <vRsNbQt2rIPfcBAnT5uVPGJnFdvkBEk7OumsHZZ4Ius=.a3384cef-6ae2-4e1e-95c8-e491773b6300@github.com>
 <rz_WZRrsb7a4GS0mtKJ_wSlBkOqlp17_MaqD9myJXco=.93b5b84c-f626-45f6-ab34-8506b42a2f92@github.com>
 <XdUUD-XugxmR9m9vdsmlLGNvkZJ9IymbtyvBcWO_Kr0=.90f077aa-6edc-442d-b5ad-1e2a88e80c35@github.com>
 <49BJJNZTIFyIUCktY8m3TK_paM01lZYYTI9JPlzYKWw=.2d10570e-d589-4b59-9a68-7e77f39e250a@github.com>
 <DUScC7A8NMk1ksHMLk3lBd5XFMFtp-UGO0pN6sSNXrY=.627e4783-9f4f-4bcc-9c1b-1b36a9ea77e6@github.com>
Message-ID: <Erx5TAE-yQDa3Sop27D9U82OQw7aQrRuRXZCl2le-L4=.1f97dbbe-f3b4-44e5-95e1-89e7106e114b@github.com>

On Wed, 7 Dec 2022 20:17:57 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Should the masking out unassigned bits that is done in this method be extended to the existing `AccessFlag.maskToAccessFlags(mask, location)`;  Instead of throwing `IllegalArgumentException`?
>> The two methods should be consistent in this regard and build their return values on the meta-data in each AccessFlag.
>
>> Should the masking out unassigned bits that is done in this method be extended to the existing `AccessFlag.maskToAccessFlags(mask, location)`; Instead of throwing `IllegalArgumentException`? The two methods should be consistent in this regard and build their return values on the meta-data in each AccessFlag.
> 
> My prior comment
> 
> "The difference in exception handling behavior compared to the method w/o a ClassFileFormatVersion argument should at least be discussed."
> 
> was calling attention to the differing strict vs lax handling of unexpected bits in the two overloaded methods. If the policies are not the same, there should at least be prominent text nothing and explaining the difference.

I think both methods should have the same behavior, both should ignore unassigned mask bits.
The means removing the @throws from the existing method and repeating the text from the new method.
An @apiNote would give it more visibility than the current simple sentence in the method javadoc.

-------------

PR: https://git.openjdk.org/jdk/pull/11399

From pminborg at openjdk.org  Wed Dec  7 22:04:11 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 7 Dec 2022 22:04:11 GMT
Subject: RFR: 8298277: Replace "session" with "scope" for FFM access
Message-ID: <CexwefXXOExmjkTj8JOWdwKjXuUxnX6gUGc16_ZPFTk=.d6d26344-ed1f-4c26-9ef5-ab0daef3ca67@github.com>

This PR suggests renaming various names from "session" to "scope" in accordance with https://openjdk.org/jeps/434

The PRs contains changes for several sub-components.

-------------

Commit messages:
 - Rename session to scope

Changes: https://git.openjdk.org/jdk/pull/11573/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11573&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298277
  Stats: 2783 lines in 98 files changed: 954 ins; 955 del; 874 mod
  Patch: https://git.openjdk.org/jdk/pull/11573.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11573/head:pull/11573

PR: https://git.openjdk.org/jdk/pull/11573

From dnsimon at openjdk.org  Wed Dec  7 22:14:16 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 7 Dec 2022 22:14:16 GMT
Subject: Integrated: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime
In-Reply-To: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
Message-ID: <Z888XwHvLdlIcqHiBpGGMMOvNvVJQxqq8ZyTSorPe0M=.be4404cf-a383-4e95-a2c5-af5e81c57a20@github.com>

On Mon, 5 Dec 2022 13:16:25 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> Libgraal is compiled ahead of time and should not need any JVMCI Java code to be dynamically loaded at runtime. Prior to this PR, this is not the case due to:
> 
> * Code to copy system properties from the HotSpot heap into the libgraal heap. This is in `jdk.vm.ci.services.Services.initializeSavedProperties(byte[])` and `jdk.vm.ci.services.Services.serializeSavedProperties()`. This code should be moved to `java.base/jdk.internal.vm.VMSupport`.
> * Code to translate exceptions from the HotSpot heap into the libgraal heap and vice versa. This code should be moved from `jdk.internal.vm.ci//jdk.vm.ci.hotspot.TranslatedException` to `java.base/jdk.internal.vm.VMSupport`.
> 
> This PR makes the above changes. As a result, it's possible to build a JDK image that includes (and uses) libgraal but does not include `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces footprint and better isolates the JAVMCI and the Graal compiler as accessing these components from Java code is now impossible.

This pull request has now been integrated.

Changeset: 8b69a2e4
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8b69a2e434ad2fa3369079622b57afb973d5bd9a
Stats:     1438 lines in 20 files changed: 628 ins; 714 del; 96 mod

8298099: [JVMCI] decouple libgraal from JVMCI module at runtime

Reviewed-by: never

-------------

PR: https://git.openjdk.org/jdk/pull/11513

From jvernee at openjdk.org  Wed Dec  7 23:00:08 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 7 Dec 2022 23:00:08 GMT
Subject: RFR: 8298277: Replace "session" with "scope" for FFM access
In-Reply-To: <CexwefXXOExmjkTj8JOWdwKjXuUxnX6gUGc16_ZPFTk=.d6d26344-ed1f-4c26-9ef5-ab0daef3ca67@github.com>
References: <CexwefXXOExmjkTj8JOWdwKjXuUxnX6gUGc16_ZPFTk=.d6d26344-ed1f-4c26-9ef5-ab0daef3ca67@github.com>
Message-ID: <NVww6vH-lGykHhFN-FTkh9qJISEpm-_UZK0Khnyszuo=.b3b3f542-7851-4fae-a645-20851c129ad8@github.com>

On Wed, 7 Dec 2022 21:55:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests renaming various names from "session" to "scope" in accordance with https://openjdk.org/jeps/434
> 
> The PRs contains changes for several sub-components.

src/java.base/share/classes/jdk/internal/foreign/MemoryScopeImpl.java line 53:

> 51:  * access is possible when a scope is being closed (see {@link jdk.internal.misc.ScopedMemoryAccess}).
> 52:  */
> 53: public abstract sealed class MemoryScopeImpl

Since the interface is called `SegmentScope`, I think `SegmentScopeImpl` would be a better name here.

-------------

PR: https://git.openjdk.org/jdk/pull/11573

From mcimadamore at openjdk.org  Wed Dec  7 23:37:03 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 7 Dec 2022 23:37:03 GMT
Subject: RFR: 8298277: Replace "session" with "scope" for FFM access
In-Reply-To: <CexwefXXOExmjkTj8JOWdwKjXuUxnX6gUGc16_ZPFTk=.d6d26344-ed1f-4c26-9ef5-ab0daef3ca67@github.com>
References: <CexwefXXOExmjkTj8JOWdwKjXuUxnX6gUGc16_ZPFTk=.d6d26344-ed1f-4c26-9ef5-ab0daef3ca67@github.com>
Message-ID: <LQIRMsp-_xSIkyeIrGgVgumF0jv08Kloq_24W5l0PF4=.e6ccb023-35e0-4bc4-ac67-f2f42fb8b076@github.com>

On Wed, 7 Dec 2022 21:55:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests renaming various names from "session" to "scope" in accordance with https://openjdk.org/jeps/434
> 
> The PRs contains changes for several sub-components.

I think we should split this PR into multiple parts:
* there are some good javadoc changes in here to the Vector API docs
* there are some test changes, where some of the names are out of date
* the majority of changes, which is caused by MemorySessionImpl -> MemoryScopeImpl is the part I'm less sure about. I think leaving that as is might be fine for now.

-------------

PR: https://git.openjdk.org/jdk/pull/11573

From psandoz at openjdk.org  Thu Dec  8 02:25:14 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 8 Dec 2022 02:25:14 GMT
Subject: RFR: 8296896: Change virtual Thread.yield to use external submit
In-Reply-To: <S0emMR0JXtg41aa6ITXJg7IlxJljzGwPGuyjOdH98Gc=.691bc53c-d851-414f-8261-020f96dbde93@github.com>
References: <S0emMR0JXtg41aa6ITXJg7IlxJljzGwPGuyjOdH98Gc=.691bc53c-d851-414f-8261-020f96dbde93@github.com>
Message-ID: <5sp52lgzbCCOyZ9nip-JX81nzXzDVKVE7FPhlToOgaQ=.4cb754da-a05d-4e93-b647-05de54a3542b@github.com>

On Tue, 6 Dec 2022 10:16:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The implementation of Thread.yield for virtual threads is currently a "lazy submit". This means the task for the virtual thread is queued to the carrier/worker local queue without signalling other threads. This behavior can be surprising/unfair when there are tasks in the submission queues, say when a platform thread has started or unparked a virtual thread.
> 
> Ron, Doug Lea, Viktor Klang and I have discussed this topic and propose to change Thread.yield to  use "external submit" when the local task queue is empty, and to push to the local queue when not empty. The change improves the fairness but will of course increase the chances that repeated Thread.yield will bounce between carriers.

test/jdk/java/lang/Thread/virtual/YieldQueuing.java line 43:

> 41: 
> 42:     /**
> 43:      * Test Thread.yield submits the task for the current virtyal thread to a scheduler

Suggestion:

     * Test Thread.yield submits the task for the current virtual thread to a scheduler

-------------

PR: https://git.openjdk.org/jdk/pull/11533

From dholmes at openjdk.org  Thu Dec  8 02:45:59 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 8 Dec 2022 02:45:59 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v7]
In-Reply-To: <Epv-jPCuClG7VfVJjqdP3FrqzDLnvxpqSmp_nx3eZP8=.6cabdece-b484-4b24-8d5f-8bdeb222a691@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <Epv-jPCuClG7VfVJjqdP3FrqzDLnvxpqSmp_nx3eZP8=.6cabdece-b484-4b24-8d5f-8bdeb222a691@github.com>
Message-ID: <uUejDzqERXU8dOfhQ6SCZfL0ULhj39zQkLhLQXajPuY=.589ad396-46c2-43e8-9ca5-0df6e43e468c@github.com>

On Wed, 7 Dec 2022 19:49:47 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Libgraal is compiled ahead of time and should not need any JVMCI Java code to be dynamically loaded at runtime. Prior to this PR, this is not the case due to:
>> 
>> * Code to copy system properties from the HotSpot heap into the libgraal heap. This is in `jdk.vm.ci.services.Services.initializeSavedProperties(byte[])` and `jdk.vm.ci.services.Services.serializeSavedProperties()`. This code should be moved to `java.base/jdk.internal.vm.VMSupport`.
>> * Code to translate exceptions from the HotSpot heap into the libgraal heap and vice versa. This code should be moved from `jdk.internal.vm.ci//jdk.vm.ci.hotspot.TranslatedException` to `java.base/jdk.internal.vm.VMSupport`.
>> 
>> This PR makes the above changes. As a result, it's possible to build a JDK image that includes (and uses) libgraal but does not include `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces footprint and better isolates the JAVMCI and the Graal compiler as accessing these components from Java code is now impossible.
>
> Doug Simon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'openjdk-jdk/master' into JDK-8298099
>  - formatting to avoid very long lines [skip ci]
>  - removed debug code [skip ci]
>  - clarify Properties filtering [skip ci]
>  - remove debug code [skip ci]
>  - incorporate review feedback [skip ci]
>  - removed hard-coded module name [skip ci]
>  - renamed is_module_resolvable to is_module_observable
>  - share code to create the exploded path for a module and avoid stack-based variable length array
>  - generalized ClassLoader::has_jvmci_module to is_module_resolvable
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/5927a4d6...f5219b20

@dougxc Two reviews are needed for all non-trivial hotspot changes, and this also warranted a review from core-libs! Your discussions with Alan still seemed to be in-progress.

-------------

PR: https://git.openjdk.org/jdk/pull/11513

From alanb at openjdk.org  Thu Dec  8 07:17:05 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Dec 2022 07:17:05 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v2]
In-Reply-To: <34Xd2rKs-dAQSCf2dNwwrTZ3uFmFjCYsqagEF3aE0Z8=.e689feb9-dc85-4d24-af4a-e43f46276eb0@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <WgaYQgGsrCaoiwDikHOB0em7NhpCugMEVevsNKByQrE=.3a67835a-633c-4b29-be22-bcb2fc2ba40a@github.com>
 <y4lLPk5mDrJNa9vzgiI5WyEJmfbsSRfBBi0QQNdZeEs=.24e2a234-f42e-456f-82a0-3c7fd05dc9c5@github.com>
 <QYgHuAV90EyFwfNKauCVbQlKfWn9eBywsWGk57WrAgI=.21985534-6c5a-4bba-a35d-b727a6ae4ba4@github.com>
 <0olqajdnsOZJqQC5xBjXS3ckays3qNmgcYk4at6tsCc=.baeb2628-eee8-430c-a101-b93ad7a51e58@github.com>
 <34Xd2rKs-dAQSCf2dNwwrTZ3uFmFjCYsqagEF3aE0Z8=.e689feb9-dc85-4d24-af4a-e43f46276eb0@github.com>
Message-ID: <LdDnpIT5iW8JFAJtprJGs-z1U1HcTECso2eQdnpdnys=.cb280f52-91a7-4a0a-80bc-09c51a0476d5@github.com>

On Mon, 5 Dec 2022 17:30:24 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> I assume this function should therefore be named `is_module_observable`?
>
> How about this:
> 
> // Determines if the named module is present in the
> // modules jimage file or in the exploded modules directory.
> static bool is_module_observable(const char* module_name);

That looks okay to me. I don't have any other comments on this part.

-------------

PR: https://git.openjdk.org/jdk/pull/11513

From alanb at openjdk.org  Thu Dec  8 07:17:08 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Dec 2022 07:17:08 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v5]
In-Reply-To: <ZSSq3Pl4Nu-BlC_ccliJcYZ9j297sAFUoybpgBrw0Uo=.5aeec02c-d235-4e07-bb23-bc038d512221@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <kU-NHwhiGEJLa7-o38UCemcxhU8WR_ijQBMGOAknOTs=.57d0341c-30af-4c39-ab42-4278fdfb2e5d@github.com>
 <-vjDxNaafm1m5UERR31dFXH7jdljWTKzsDjntS8v6zs=.4c777f1e-695f-42de-a4b5-0cb0f332243c@github.com>
 <ZSSq3Pl4Nu-BlC_ccliJcYZ9j297sAFUoybpgBrw0Uo=.5aeec02c-d235-4e07-bb23-bc038d512221@github.com>
Message-ID: <LZfRrVFPWdDMPWQzW_NBv-_emCUGS2Ok3Uj7QKXz844=.6a761d30-318d-4ecd-994a-06d36cad4169@github.com>

On Tue, 6 Dec 2022 15:44:28 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 106:
>> 
>>> 104:         }
>>> 105:         if (props.get("oome") != null) {
>>> 106:             throw new OutOfMemoryError("forced OOME");
>> 
>> I don't think code in java.base should be checking for a property named "oome".  Is this for a test that sets this system property on the command line?
>
> Sorry, that's debug code that I will remove.

Thanks, I couldn't see it set as a property anywhere so didn't know why it was there. I don't have any comments on this area.

-------------

PR: https://git.openjdk.org/jdk/pull/11513

From alanb at openjdk.org  Thu Dec  8 07:21:13 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Dec 2022 07:21:13 GMT
Subject: RFR: 8296896: Change virtual Thread.yield to use external submit
 [v2]
In-Reply-To: <S0emMR0JXtg41aa6ITXJg7IlxJljzGwPGuyjOdH98Gc=.691bc53c-d851-414f-8261-020f96dbde93@github.com>
References: <S0emMR0JXtg41aa6ITXJg7IlxJljzGwPGuyjOdH98Gc=.691bc53c-d851-414f-8261-020f96dbde93@github.com>
Message-ID: <i5WQaPOanIZeN9BJyXLGda08kZIohl0ymFfi2tD-u60=.7ac5c2d7-a162-4c2b-9958-31586c84a203@github.com>

> The implementation of Thread.yield for virtual threads is currently a "lazy submit". This means the task for the virtual thread is queued to the carrier/worker local queue without signalling other threads. This behavior can be surprising/unfair when there are tasks in the submission queues, say when a platform thread has started or unparked a virtual thread.
> 
> Ron, Doug Lea, Viktor Klang and I have discussed this topic and propose to change Thread.yield to  use "external submit" when the local task queue is empty, and to push to the local queue when not empty. The change improves the fairness but will of course increase the chances that repeated Thread.yield will bounce between carriers.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge
 - Fix typo in test comment
 - Reduce instanceof checks
 - Update
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11533/files
  - new: https://git.openjdk.org/jdk/pull/11533/files/2e707757..151cbd0d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11533&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11533&range=00-01

  Stats: 12718 lines in 291 files changed: 8666 ins; 2982 del; 1070 mod
  Patch: https://git.openjdk.org/jdk/pull/11533.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11533/head:pull/11533

PR: https://git.openjdk.org/jdk/pull/11533

From alanb at openjdk.org  Thu Dec  8 07:21:15 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Dec 2022 07:21:15 GMT
Subject: RFR: 8296896: Change virtual Thread.yield to use external submit
 [v2]
In-Reply-To: <5sp52lgzbCCOyZ9nip-JX81nzXzDVKVE7FPhlToOgaQ=.4cb754da-a05d-4e93-b647-05de54a3542b@github.com>
References: <S0emMR0JXtg41aa6ITXJg7IlxJljzGwPGuyjOdH98Gc=.691bc53c-d851-414f-8261-020f96dbde93@github.com>
 <5sp52lgzbCCOyZ9nip-JX81nzXzDVKVE7FPhlToOgaQ=.4cb754da-a05d-4e93-b647-05de54a3542b@github.com>
Message-ID: <288Ywup1NAvID-_hFv8pdNMUtFhf7MaV3oLOxBQ8flY=.c35c3c84-f0eb-4d0c-a8bd-42825260215f@github.com>

On Thu, 8 Dec 2022 02:21:54 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge
>>  - Fix typo in test comment
>>  - Reduce instanceof checks
>>  - Update
>>  - Initial commit
>
> test/jdk/java/lang/Thread/virtual/YieldQueuing.java line 43:
> 
>> 41: 
>> 42:     /**
>> 43:      * Test Thread.yield submits the task for the current virtyal thread to a scheduler
> 
> Suggestion:
> 
>      * Test Thread.yield submits the task for the current virtual thread to a scheduler

Thanks, it's fixed now.

-------------

PR: https://git.openjdk.org/jdk/pull/11533

From alanb at openjdk.org  Thu Dec  8 07:21:29 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Dec 2022 07:21:29 GMT
Subject: RFR: 8297295: Remove ThreadGroup.allowThreadSuspension [v2]
In-Reply-To: <nzPvVaqoaUaQi2tJudlE6Nx30o1kZL_MOyafLb5iHps=.ebc94199-eec0-4a23-8e46-afa87be5735d@github.com>
References: <nzPvVaqoaUaQi2tJudlE6Nx30o1kZL_MOyafLb5iHps=.ebc94199-eec0-4a23-8e46-afa87be5735d@github.com>
Message-ID: <XCo4TovJxwAzMzppXESe2pF4aHUmC2raNNaji8Ts2Dw=.e63956df-e164-4622-bf78-8c7687e70820@github.com>

> Another small step in the multi-release/multi-year effort to remove cruft from Thread/ThreadGroup.
> 
> java.lang.ThreadGroup.allowThreadSuspension(boolean) dates from JDK 1.1 and the Classic VM. The method controlled whether threads were suspended when the GC failed. It appears to have interacted with a callback mechanism that could potentially free memory, allowing the GC to retry. The method was never specified .
> 
> The method was deprecated and changed to do nothing in JDK 1.2. It was deprecated for removal in Java 14. 
> 
> A corpus analysis of 30M classes in 130k artifacts found 0 usages of this method.
> 
> It is time to finally remove this method. The compatibility impact should be negligible. Joe, Stuart and I discussed briefly and think early in JDK 21 is a good time to do this.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge
 - Remove allowThreadSuspension

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11373/files
  - new: https://git.openjdk.org/jdk/pull/11373/files/427025eb..639b6b58

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11373&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11373&range=00-01

  Stats: 92711 lines in 1546 files changed: 45616 ins; 37873 del; 9222 mod
  Patch: https://git.openjdk.org/jdk/pull/11373.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11373/head:pull/11373

PR: https://git.openjdk.org/jdk/pull/11373

From jpai at openjdk.org  Thu Dec  8 07:31:00 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 8 Dec 2022 07:31:00 GMT
Subject: RFR: 8296896: Change virtual Thread.yield to use external submit
 [v2]
In-Reply-To: <i5WQaPOanIZeN9BJyXLGda08kZIohl0ymFfi2tD-u60=.7ac5c2d7-a162-4c2b-9958-31586c84a203@github.com>
References: <S0emMR0JXtg41aa6ITXJg7IlxJljzGwPGuyjOdH98Gc=.691bc53c-d851-414f-8261-020f96dbde93@github.com>
 <i5WQaPOanIZeN9BJyXLGda08kZIohl0ymFfi2tD-u60=.7ac5c2d7-a162-4c2b-9958-31586c84a203@github.com>
Message-ID: <Z6kkmMVsNiDoNHvF5sYR_NblP6o5f1f9Xxj5syn_t-k=.169a7ac1-feaf-4ab2-a546-01809f071c5f@github.com>

On Thu, 8 Dec 2022 07:21:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The implementation of Thread.yield for virtual threads is currently a "lazy submit". This means the task for the virtual thread is queued to the carrier/worker local queue without signalling other threads. This behavior can be surprising/unfair when there are tasks in the submission queues, say when a platform thread has started or unparked a virtual thread.
>> 
>> Ron, Doug Lea, Viktor Klang and I have discussed this topic and propose to change Thread.yield to  use "external submit" when the local task queue is empty, and to push to the local queue when not empty. The change improves the fairness but will of course increase the chances that repeated Thread.yield will bounce between carriers.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge
>  - Fix typo in test comment
>  - Reduce instanceof checks
>  - Update
>  - Initial commit

Marked as reviewed by jpai (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11533

From alanb at openjdk.org  Thu Dec  8 07:40:22 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Dec 2022 07:40:22 GMT
Subject: Integrated: 8296896: Change virtual Thread.yield to use external
 submit
In-Reply-To: <S0emMR0JXtg41aa6ITXJg7IlxJljzGwPGuyjOdH98Gc=.691bc53c-d851-414f-8261-020f96dbde93@github.com>
References: <S0emMR0JXtg41aa6ITXJg7IlxJljzGwPGuyjOdH98Gc=.691bc53c-d851-414f-8261-020f96dbde93@github.com>
Message-ID: <BFfc_a9_Ep3ug13qdnI8NNssFNgEP5IhiLaWB4GyYok=.a6be86c2-545c-48ca-873c-003486074232@github.com>

On Tue, 6 Dec 2022 10:16:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The implementation of Thread.yield for virtual threads is currently a "lazy submit". This means the task for the virtual thread is queued to the carrier/worker local queue without signalling other threads. This behavior can be surprising/unfair when there are tasks in the submission queues, say when a platform thread has started or unparked a virtual thread.
> 
> Ron, Doug Lea, Viktor Klang and I have discussed this topic and propose to change Thread.yield to  use "external submit" when the local task queue is empty, and to push to the local queue when not empty. The change improves the fairness but will of course increase the chances that repeated Thread.yield will bounce between carriers.

This pull request has now been integrated.

Changeset: 1166c8e2
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1166c8e2c0047869cd50b7ddc5355290ac2a695a
Stats:     188 lines in 3 files changed: 161 ins; 12 del; 15 mod

8296896: Change virtual Thread.yield to use external submit

Reviewed-by: jpai, rpressler

-------------

PR: https://git.openjdk.org/jdk/pull/11533

From duke at openjdk.org  Thu Dec  8 07:43:49 2022
From: duke at openjdk.org (Oliver Kopp)
Date: Thu, 8 Dec 2022 07:43:49 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v6]
In-Reply-To: <iS9jjhVy4BtehQablwAX9B2fbOF6M_nfP7O_TGpppqY=.3c0cc6a4-dbbf-48fb-a09c-c9c2ce8d4aee@github.com>
References: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
 <Ouly-NyXJMLpyNiBnUNkO0Zhus8EZc3S03_PsCP40vk=.47c03775-acc8-4aa4-a09d-75e9337f915e@github.com>
 <iS9jjhVy4BtehQablwAX9B2fbOF6M_nfP7O_TGpppqY=.3c0cc6a4-dbbf-48fb-a09c-c9c2ce8d4aee@github.com>
Message-ID: <x8UM5rQyXazsY8j3AxpIwra3hAZ89vQkjK1S5Ym5WWo=.7b490221-0c1e-49ee-9384-b27e4fe857fa@github.com>

On Tue, 6 Dec 2022 16:46:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Would it be possible to paste in a summary on the VerifyError with the previous iteration?

Isn't this https://github.com/openjdk/jdk/pull/10704#issuecomment-1286106503?

    Type top (current frame, locals[15]) is not assignable to reference type

>  If I read the latest update then the limit per helper method has been bump to avoid it, is that right?

Yes. Then, the compiler still works - and we can try to debug using the test case (yet to be finalized).

-------------

PR: https://git.openjdk.org/jdk/pull/10704

From dnsimon at openjdk.org  Thu Dec  8 07:53:14 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 8 Dec 2022 07:53:14 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v7]
In-Reply-To: <Epv-jPCuClG7VfVJjqdP3FrqzDLnvxpqSmp_nx3eZP8=.6cabdece-b484-4b24-8d5f-8bdeb222a691@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <Epv-jPCuClG7VfVJjqdP3FrqzDLnvxpqSmp_nx3eZP8=.6cabdece-b484-4b24-8d5f-8bdeb222a691@github.com>
Message-ID: <Nba9HbLP9tyLc4OMqJUYru8j77jq2F_wFZfc47diafM=.94f14e64-ab6f-4c9f-9c85-b77f3f41366c@github.com>

On Wed, 7 Dec 2022 19:49:47 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Libgraal is compiled ahead of time and should not need any JVMCI Java code to be dynamically loaded at runtime. Prior to this PR, this is not the case due to:
>> 
>> * Code to copy system properties from the HotSpot heap into the libgraal heap. This is in `jdk.vm.ci.services.Services.initializeSavedProperties(byte[])` and `jdk.vm.ci.services.Services.serializeSavedProperties()`. This code should be moved to `java.base/jdk.internal.vm.VMSupport`.
>> * Code to translate exceptions from the HotSpot heap into the libgraal heap and vice versa. This code should be moved from `jdk.internal.vm.ci//jdk.vm.ci.hotspot.TranslatedException` to `java.base/jdk.internal.vm.VMSupport`.
>> 
>> This PR makes the above changes. As a result, it's possible to build a JDK image that includes (and uses) libgraal but does not include `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces footprint and better isolates the JAVMCI and the Graal compiler as accessing these components from Java code is now impossible.
>
> Doug Simon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'openjdk-jdk/master' into JDK-8298099
>  - formatting to avoid very long lines [skip ci]
>  - removed debug code [skip ci]
>  - clarify Properties filtering [skip ci]
>  - remove debug code [skip ci]
>  - incorporate review feedback [skip ci]
>  - removed hard-coded module name [skip ci]
>  - renamed is_module_resolvable to is_module_observable
>  - share code to create the exploded path for a module and avoid stack-based variable length array
>  - generalized ClassLoader::has_jvmci_module to is_module_resolvable
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/fbca1fb5...f5219b20

Sorry I checked with Alan over Slack who said to go ahead with merging.

-------------

PR: https://git.openjdk.org/jdk/pull/11513

From alanb at openjdk.org  Thu Dec  8 07:56:14 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Dec 2022 07:56:14 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v7]
In-Reply-To: <Nba9HbLP9tyLc4OMqJUYru8j77jq2F_wFZfc47diafM=.94f14e64-ab6f-4c9f-9c85-b77f3f41366c@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <Epv-jPCuClG7VfVJjqdP3FrqzDLnvxpqSmp_nx3eZP8=.6cabdece-b484-4b24-8d5f-8bdeb222a691@github.com>
 <Nba9HbLP9tyLc4OMqJUYru8j77jq2F_wFZfc47diafM=.94f14e64-ab6f-4c9f-9c85-b77f3f41366c@github.com>
Message-ID: <6mFOj50jr2eBCcb8YkXYiyUij9h_1yUwDHehHxAkTXA=.2b014841-c6d4-4a7d-bbb0-3a1c906ed6eb@github.com>

On Thu, 8 Dec 2022 07:51:00 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> Sorry I checked with Alan over Slack who said to go ahead with merging.

Yeah, I was busy at the time and didn't get a chance to say that I didn't have any more comments/issues.

-------------

PR: https://git.openjdk.org/jdk/pull/11513

From alanb at openjdk.org  Thu Dec  8 07:59:01 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Dec 2022 07:59:01 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v6]
In-Reply-To: <x8UM5rQyXazsY8j3AxpIwra3hAZ89vQkjK1S5Ym5WWo=.7b490221-0c1e-49ee-9384-b27e4fe857fa@github.com>
References: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
 <Ouly-NyXJMLpyNiBnUNkO0Zhus8EZc3S03_PsCP40vk=.47c03775-acc8-4aa4-a09d-75e9337f915e@github.com>
 <iS9jjhVy4BtehQablwAX9B2fbOF6M_nfP7O_TGpppqY=.3c0cc6a4-dbbf-48fb-a09c-c9c2ce8d4aee@github.com>
 <x8UM5rQyXazsY8j3AxpIwra3hAZ89vQkjK1S5Ym5WWo=.7b490221-0c1e-49ee-9384-b27e4fe857fa@github.com>
Message-ID: <nNPnR-xW3hWmis0bcHSnT4yQ1M6Tkw8WItpcgFFirpg=.7dc612e6-4ba2-42ce-b64e-624195c4afdd@github.com>

On Thu, 8 Dec 2022 07:41:22 GMT, Oliver Kopp <duke at openjdk.org> wrote:

> Yes. Then, the compiler still works - and we can try to debug using the test case (yet to be finalized).

Okay, so maybe the PR should be returned to draft until it is ready.

-------------

PR: https://git.openjdk.org/jdk/pull/10704

From pminborg at openjdk.org  Thu Dec  8 08:17:44 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 8 Dec 2022 08:17:44 GMT
Subject: RFR: 8298277: Replace "session" with "scope" for FFM access [v2]
In-Reply-To: <CexwefXXOExmjkTj8JOWdwKjXuUxnX6gUGc16_ZPFTk=.d6d26344-ed1f-4c26-9ef5-ab0daef3ca67@github.com>
References: <CexwefXXOExmjkTj8JOWdwKjXuUxnX6gUGc16_ZPFTk=.d6d26344-ed1f-4c26-9ef5-ab0daef3ca67@github.com>
Message-ID: <4y6q6GtQvTrNyp-oA_DtSESbC_jNHX5v1VxOaJRaiVQ=.1b5357b1-9bd3-43e3-8d53-7f4c5714e523@github.com>

> This PR suggests renaming various names from "session" to "scope" in accordance with https://openjdk.org/jeps/434
> 
> The PRs contains changes for several sub-components.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Revert renaming of MemorySessionImpl

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11573/files
  - new: https://git.openjdk.org/jdk/pull/11573/files/71a5e29c..39f09aa0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11573&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11573&range=00-01

  Stats: 172 lines in 25 files changed: 0 ins; 0 del; 172 mod
  Patch: https://git.openjdk.org/jdk/pull/11573.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11573/head:pull/11573

PR: https://git.openjdk.org/jdk/pull/11573

From stsypanov at openjdk.org  Thu Dec  8 10:25:13 2022
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 8 Dec 2022 10:25:13 GMT
Subject: Integrated: 8298033: Character.codePoint{At|Before}(char[], int,
 int) doesn't do JavaDoc-specified check
In-Reply-To: <dHjviGmASssYfntfClzDC28Ppjrn3pECnO3HzbZHopY=.d9923de3-6de7-41f5-a84e-03a7c5267e2f@github.com>
References: <dHjviGmASssYfntfClzDC28Ppjrn3pECnO3HzbZHopY=.d9923de3-6de7-41f5-a84e-03a7c5267e2f@github.com>
Message-ID: <5frmuEPeGiTDVNW3u2fHRcFl7vB_aEUGWEk-Y9RtAIw=.0467664a-116b-4f95-b873-de34c5865db2@github.com>

On Fri, 2 Dec 2022 12:44:18 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> I found out that this code
> 
> public class Main {
>     public static void main(String[] args) {
>         String s = "Hello world!";
>         char[] chars = s.toCharArray();
>         int point = Character.codePointAt(chars, -1, 1);
>     }
> }
> 
> throws `ArrayIndexOutOfBoundsException` instead of JavaDoc-specified `IndexOutOfBoundsException`: 
> 
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds for length 12
> 	at java.base/java.lang.Character.codePointAtImpl(Character.java:9254)
> 	at java.base/java.lang.Character.codePointAt(Character.java:9249)
> 	at org.example.Main.main(Main.java:7)
> 
> and the method doesn't check whether `index` parameter is negative:
> 
> public static int codePointAt(char[] a, int index, int limit) {
>     if (index >= limit || limit < 0 || limit > a.length) {
>         throw new IndexOutOfBoundsException();
>     }
>     return codePointAtImpl(a, index, limit);
> }
> 
> I suggest to check the `index` parameter explicitly instead of relying on AIOOBE thrown from accessing the array with negative index.

This pull request has now been integrated.

Changeset: b9346e14
Author:    Sergey Tsypanov <stsypanov at openjdk.org>
Committer: Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b9346e149e6cfcaf18bfafbd262f6fed209dc644
Stats:     7 lines in 2 files changed: 0 ins; 1 del; 6 mod

8298033: Character.codePoint{At|Before}(char[], int, int) doesn't do JavaDoc-specified check

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/11480

From jpai at openjdk.org  Thu Dec  8 10:55:10 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 8 Dec 2022 10:55:10 GMT
Subject: RFR: 8298033: Character.codePoint{At|Before}(char[], int,
 int) doesn't do JavaDoc-specified check [v6]
In-Reply-To: <VftnfWbHQbak_oaF8D4eULvTMUj7mzDm8gaWl8qXdjE=.92a052a8-1474-4a92-ac4b-bf827a5f9154@github.com>
References: <dHjviGmASssYfntfClzDC28Ppjrn3pECnO3HzbZHopY=.d9923de3-6de7-41f5-a84e-03a7c5267e2f@github.com>
 <VftnfWbHQbak_oaF8D4eULvTMUj7mzDm8gaWl8qXdjE=.92a052a8-1474-4a92-ac4b-bf827a5f9154@github.com>
Message-ID: <sFIjCh3y61CyeHHVcLp3zq00az8P1ymDCD1AhgbnEhY=.8449ed67-2b14-47ba-af54-621ed1885ec3@github.com>

On Tue, 6 Dec 2022 18:39:28 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> I found out that this code
>> 
>> public class Main {
>>     public static void main(String[] args) {
>>         String s = "Hello world!";
>>         char[] chars = s.toCharArray();
>>         int point = Character.codePointAt(chars, -1, 1);
>>     }
>> }
>> 
>> throws `ArrayIndexOutOfBoundsException` instead of JavaDoc-specified `IndexOutOfBoundsException`: 
>> 
>> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds for length 12
>> 	at java.base/java.lang.Character.codePointAtImpl(Character.java:9254)
>> 	at java.base/java.lang.Character.codePointAt(Character.java:9249)
>> 	at org.example.Main.main(Main.java:7)
>> 
>> and the method doesn't check whether `index` parameter is negative:
>> 
>> public static int codePointAt(char[] a, int index, int limit) {
>>     if (index >= limit || limit < 0 || limit > a.length) {
>>         throw new IndexOutOfBoundsException();
>>     }
>>     return codePointAtImpl(a, index, limit);
>> }
>> 
>> I suggest to check the `index` parameter explicitly instead of relying on AIOOBE thrown from accessing the array with negative index.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8298033: Polish

Just a FYI - there was an issue in the copyright header of `test/jdk/java/lang/Character/Supplementary.java` in this change - a comma was missing after the `2022` year. I've filed https://bugs.openjdk.org/browse/JDK-8298375 and raised a PR to fix it.

-------------

PR: https://git.openjdk.org/jdk/pull/11480

From jpai at openjdk.org  Thu Dec  8 10:56:51 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 8 Dec 2022 10:56:51 GMT
Subject: RFR: 8298375: Bad copyright header in
 test/jdk/java/lang/Character/Supplementary.java
Message-ID: <uc4QuWIL6wRZjFaYXti76MNr8Lht7qWqZAotNQvMBQU=.53588807-bffb-496a-8df9-9ebe906dfb0f@github.com>

Can I get a review of this change which fixes the copyright header on the test file?

-------------

Commit messages:
 - 8298375: Bad copyright header in test/jdk/java/lang/Character/Supplementary.java

Changes: https://git.openjdk.org/jdk/pull/11583/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11583&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298375
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11583.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11583/head:pull/11583

PR: https://git.openjdk.org/jdk/pull/11583

From alanb at openjdk.org  Thu Dec  8 11:03:27 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Dec 2022 11:03:27 GMT
Subject: RFR: 8298375: Bad copyright header in
 test/jdk/java/lang/Character/Supplementary.java
In-Reply-To: <uc4QuWIL6wRZjFaYXti76MNr8Lht7qWqZAotNQvMBQU=.53588807-bffb-496a-8df9-9ebe906dfb0f@github.com>
References: <uc4QuWIL6wRZjFaYXti76MNr8Lht7qWqZAotNQvMBQU=.53588807-bffb-496a-8df9-9ebe906dfb0f@github.com>
Message-ID: <I_yV8w3ai14-uQA7dTCgTz55AX8wee9lo6RhRFbhqbo=.1c6baa3a-8b38-4bce-924a-5358df5fa39c@github.com>

On Thu, 8 Dec 2022 10:48:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I get a review of this change which fixes the copyright header on the test file?

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11583

From jpai at openjdk.org  Thu Dec  8 11:03:29 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 8 Dec 2022 11:03:29 GMT
Subject: RFR: 8298375: Bad copyright header in
 test/jdk/java/lang/Character/Supplementary.java
In-Reply-To: <uc4QuWIL6wRZjFaYXti76MNr8Lht7qWqZAotNQvMBQU=.53588807-bffb-496a-8df9-9ebe906dfb0f@github.com>
References: <uc4QuWIL6wRZjFaYXti76MNr8Lht7qWqZAotNQvMBQU=.53588807-bffb-496a-8df9-9ebe906dfb0f@github.com>
Message-ID: <G5I7lTsec3LY-qrR5W-3epME8JassXh-iolUVqaUI0U=.77834a41-d4f5-4a6b-9293-5d5e6daa7263@github.com>

On Thu, 8 Dec 2022 10:48:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I get a review of this change which fixes the copyright header on the test file?

Thank you Alan for the quick review. Local testing of this change shows that it works. I'll go ahead with the integration.

-------------

PR: https://git.openjdk.org/jdk/pull/11583

From jpai at openjdk.org  Thu Dec  8 11:05:18 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 8 Dec 2022 11:05:18 GMT
Subject: Integrated: 8298375: Bad copyright header in
 test/jdk/java/lang/Character/Supplementary.java
In-Reply-To: <uc4QuWIL6wRZjFaYXti76MNr8Lht7qWqZAotNQvMBQU=.53588807-bffb-496a-8df9-9ebe906dfb0f@github.com>
References: <uc4QuWIL6wRZjFaYXti76MNr8Lht7qWqZAotNQvMBQU=.53588807-bffb-496a-8df9-9ebe906dfb0f@github.com>
Message-ID: <CUFmf5wnDJip_pKqiUchnSITwnBWFOQmPQ_p3Z_M2Dw=.1b6647ec-fc1e-421b-9c35-70bcce0b681b@github.com>

On Thu, 8 Dec 2022 10:48:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I get a review of this change which fixes the copyright header on the test file?

This pull request has now been integrated.

Changeset: 2f426cd6
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2f426cd68b28c8bf50b7102f961b15fd47b63b6a
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8298375: Bad copyright header in test/jdk/java/lang/Character/Supplementary.java

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/11583

From stsypanov at openjdk.org  Thu Dec  8 12:45:29 2022
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 8 Dec 2022 12:45:29 GMT
Subject: RFR: 8298380: Clean up redundant array length checks in JDK code base
Message-ID: <pOhI85f5BwAPmV0dbQ_nCf8sNQxpIV4wF3AZHdxWr0U=.9add8736-4851-4f5a-9e04-d67430d7e123@github.com>

Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like

<T> void iterate(T[] items) {
  if (items.length == 0) {
    return;
  }
  for (T item : items) {
    //...
  }
}

Here

if (items.length == 0) {
  return;
}

is redundant and can be removed as length check is performed by for-each loop.

-------------

Commit messages:
 - 8298380: Clean up redundant array length checks in JDK code base

Changes: https://git.openjdk.org/jdk/pull/11589/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11589&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298380
  Stats: 51 lines in 8 files changed: 0 ins; 14 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/11589.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11589/head:pull/11589

PR: https://git.openjdk.org/jdk/pull/11589

From pminborg at openjdk.org  Thu Dec  8 13:05:00 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 8 Dec 2022 13:05:00 GMT
Subject: RFR: 8298277: Replace "session" with "scope" for FFM access [v2]
In-Reply-To: <4y6q6GtQvTrNyp-oA_DtSESbC_jNHX5v1VxOaJRaiVQ=.1b5357b1-9bd3-43e3-8d53-7f4c5714e523@github.com>
References: <CexwefXXOExmjkTj8JOWdwKjXuUxnX6gUGc16_ZPFTk=.d6d26344-ed1f-4c26-9ef5-ab0daef3ca67@github.com>
 <4y6q6GtQvTrNyp-oA_DtSESbC_jNHX5v1VxOaJRaiVQ=.1b5357b1-9bd3-43e3-8d53-7f4c5714e523@github.com>
Message-ID: <RlgO9nlJZIXTZ4fz3RsmY31lFV-y2rgtA32PCV-pg7E=.0ce4621b-b503-4c5a-bc4d-3e7faeacdf3d@github.com>

On Thu, 8 Dec 2022 08:17:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests renaming various names from "session" to "scope" in accordance with https://openjdk.org/jeps/434
>> 
>> The PRs contains changes for several sub-components.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert renaming of MemorySessionImpl

I am going to close this PR in favor of several other smaller ones.

-------------

PR: https://git.openjdk.org/jdk/pull/11573

From pminborg at openjdk.org  Thu Dec  8 13:05:03 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 8 Dec 2022 13:05:03 GMT
Subject: Withdrawn: 8298277: Replace "session" with "scope" for FFM access
In-Reply-To: <CexwefXXOExmjkTj8JOWdwKjXuUxnX6gUGc16_ZPFTk=.d6d26344-ed1f-4c26-9ef5-ab0daef3ca67@github.com>
References: <CexwefXXOExmjkTj8JOWdwKjXuUxnX6gUGc16_ZPFTk=.d6d26344-ed1f-4c26-9ef5-ab0daef3ca67@github.com>
Message-ID: <0LEwHE6mc-JRS1H07g0SE-jUVPFapFVFxJrreAT8EJI=.a3ed1f57-6126-4324-97c8-86d69f2b67d6@github.com>

On Wed, 7 Dec 2022 21:55:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests renaming various names from "session" to "scope" in accordance with https://openjdk.org/jeps/434
> 
> The PRs contains changes for several sub-components.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11573

From pminborg at openjdk.org  Thu Dec  8 14:20:38 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 8 Dec 2022 14:20:38 GMT
Subject: RFR: JDK-8298277: Replace "session" with "scope" for FFM access
Message-ID: <YnNzM56870Nmq9AtyXDu0ESYWwcoYVEswRImv2kn_xk=.0cc70ffd-f0f0-4855-b6fa-ff32552846a8@github.com>

This PR proposes changing variable names and text from "session" to "scope". The proposed changes are only for the FFM API and not other parts like the Vector API and test classes.

-------------

Commit messages:
 - Rename session to scope

Changes: https://git.openjdk.org/jdk/pull/11593/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11593&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298277
  Stats: 189 lines in 26 files changed: 0 ins; 0 del; 189 mod
  Patch: https://git.openjdk.org/jdk/pull/11593.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11593/head:pull/11593

PR: https://git.openjdk.org/jdk/pull/11593

From mcimadamore at openjdk.org  Thu Dec  8 14:41:06 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 8 Dec 2022 14:41:06 GMT
Subject: RFR: JDK-8298277: Replace "session" with "scope" for FFM access
In-Reply-To: <YnNzM56870Nmq9AtyXDu0ESYWwcoYVEswRImv2kn_xk=.0cc70ffd-f0f0-4855-b6fa-ff32552846a8@github.com>
References: <YnNzM56870Nmq9AtyXDu0ESYWwcoYVEswRImv2kn_xk=.0cc70ffd-f0f0-4855-b6fa-ff32552846a8@github.com>
Message-ID: <l0eQns0JA9sF6qU3a2ZgIsZIkzXkcCaqBBajF0qubZA=.58b53918-6c87-45a5-87ea-8fc488f306cb@github.com>

On Thu, 8 Dec 2022 14:11:29 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes changing variable names and text from "session" to "scope". The proposed changes are only for the FFM API and not other parts like the Vector API and test classes.

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 157:

> 155:      * Mismatch over long lengths.
> 156:      */
> 157:     public static long vectorizedMismatchLargeForBytes(MemorySessionImpl aScope, MemorySessionImpl bScope,

this seems unnecessary - note that the type is `MemorySessionImpl`

src/java.base/share/classes/jdk/internal/foreign/ConfinedSession.java line 35:

> 33: 
> 34: /**
> 35:  * A confined scope, which features an owner thread. The liveness check features an additional

This should be left as session (since we have not changed the name of the class)

src/java.base/share/classes/jdk/internal/foreign/ConfinedSession.java line 36:

> 34: /**
> 35:  * A confined scope, which features an owner thread. The liveness check features an additional
> 36:  * confinement check - that is, calling any operation on this scope from a thread other than the

Same here

src/java.base/share/classes/jdk/internal/foreign/GlobalSession.java line 31:

> 29: 
> 30: /**
> 31:  * The global, non-closeable, shared scope. Similar to a shared scope, but its {@link #close()} method throws unconditionally.

And here.

src/java.base/share/classes/jdk/internal/foreign/ImplicitSession.java line 34:

> 32: 
> 33: /**
> 34:  * This is an implicit, GC-backed memory scope. Implicit scopes cannot be closed explicitly.

These should not be changed.

src/java.base/share/classes/jdk/internal/foreign/MemorySessionImpl.java line 42:

> 40: /**
> 41:  * This class manages the temporal bounds associated with a memory segment as well
> 42:  * as thread confinement. A scope has a liveness bit, which is updated when the scope is closed

Probably all the usages of `session` here should be left as is

src/java.base/share/classes/jdk/internal/foreign/MemorySessionImpl.java line 178:

> 176:     }
> 177: 
> 178:     public static boolean sameOwnerThread(SegmentScope scope1, SegmentScope scope2) {

This renaming is the only one that should survive

src/java.base/share/classes/jdk/internal/foreign/MemorySessionImpl.java line 320:

> 318: 
> 319:     static UnsupportedOperationException nonCloseable() {
> 320:         return new UnsupportedOperationException("Attempted to close a non-closeable scope");

I wonder how much we still need this - e.g. through the API is no longer possible to get there?

src/java.base/share/classes/jdk/internal/foreign/SharedSession.java line 35:

> 33: 
> 34: /**
> 35:  * A shared scope, which can be shared across multiple threads. Closing a shared scope has to ensure that

These should not be changed

src/java.base/share/classes/jdk/internal/foreign/abi/Binding.java line 255:

> 253:          * the context's allocator is accessed.
> 254:          */
> 255:         public static Context ofScope() {

I think `ofArena` seems more apt here?

-------------

PR: https://git.openjdk.org/jdk/pull/11593

From mcimadamore at openjdk.org  Thu Dec  8 14:41:07 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 8 Dec 2022 14:41:07 GMT
Subject: RFR: JDK-8298277: Replace "session" with "scope" for FFM access
In-Reply-To: <l0eQns0JA9sF6qU3a2ZgIsZIkzXkcCaqBBajF0qubZA=.58b53918-6c87-45a5-87ea-8fc488f306cb@github.com>
References: <YnNzM56870Nmq9AtyXDu0ESYWwcoYVEswRImv2kn_xk=.0cc70ffd-f0f0-4855-b6fa-ff32552846a8@github.com>
 <l0eQns0JA9sF6qU3a2ZgIsZIkzXkcCaqBBajF0qubZA=.58b53918-6c87-45a5-87ea-8fc488f306cb@github.com>
Message-ID: <CYHzwj9DnbvaHm7sN4m3E7wWrk9egJnxBpIFjbJo5iM=.ae6898e4-b124-42fd-8aa7-ac0762d58a70@github.com>

On Thu, 8 Dec 2022 14:33:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR proposes changing variable names and text from "session" to "scope". The proposed changes are only for the FFM API and not other parts like the Vector API and test classes.
>
> src/java.base/share/classes/jdk/internal/foreign/abi/Binding.java line 255:
> 
>> 253:          * the context's allocator is accessed.
>> 254:          */
>> 255:         public static Context ofScope() {
> 
> I think `ofArena` seems more apt here?

More generally, I think that now that we can subclass Arena, Binding.Context can just become a subclass of Arena. Then we might have several implementations, some of which throw on allocate(), some other will throw on scope() and close(). Seems a more direct approach.

-------------

PR: https://git.openjdk.org/jdk/pull/11593

From alanb at openjdk.org  Thu Dec  8 14:53:45 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Dec 2022 14:53:45 GMT
Subject: RFR: 8293806: JDK_JAVA_OPTIONS picked up twice if launcher
 re-executes itself
In-Reply-To: <OW6KaT2Vfefx_KOyDhIkVxSUOFtgiu6SCn3D8WM5PF8=.143804b1-22eb-4d9b-bf7c-1d3768a98308@github.com>
References: <OW6KaT2Vfefx_KOyDhIkVxSUOFtgiu6SCn3D8WM5PF8=.143804b1-22eb-4d9b-bf7c-1d3768a98308@github.com>
Message-ID: <SbufrootYrUU0HrbOQkNVnylahFu05OhL3Eg3MjXAAU=.641a3900-82c8-4d7e-8fef-ee8443fb0470@github.com>

On Tue, 6 Dec 2022 14:04:44 GMT, Dmitry Samersoff <dsamersoff at openjdk.org> wrote:

> If the user has set LD_LIBRARY_PATH to use a particular libjvm.so, options from the JDK_JAVA_OPTIONS environment variable are picked up twice.
> 
> If an option cannot be accepted twice (e.g., -agentlib), the application fails to start.
> 
> The same happens on operating systems that doesn't support $RPATH/$ORIGIN and always have to set LD_LIBRARY_PATH and re-exec the launcher.
> 
> This fix takes the approach to re-launch as early as possible, as discussed here:
> 
> https://github.com/openjdk/jdk/pull/10430
> 
> This PR consists of three commits:
> 1. Cleanup of java_md.c
> 2. The implementation of early re-launch
> 3. Performance optimization
> 
> @AlanBateman, @dholmes-ora Alan, David - any comments are appreciated.

I skimmed through the changes and agree there is an issue with options that shouldn't be repeated. I don't think the overall approach is too bad but I suspect it will go through a few iterations. Right now, all LD_LIBRARY_PATH handling is the "unix" java_md.c and I think we should keep it there. I wonder if the SETENV_REQUIRED removal could be split out and done first as that would remove some of the changes and make it easier to understand the impact of the changes.

src/java.base/share/native/launcher/main.c line 68:

> 66: #if !defined(WINDOWS) && !defined(MACOSX)
> 67:    JLI_ReExecLauncher(argc, argv);
> 68: #endif

The naming is problematic here as it looks like it always re-execs on Unix/Linux systems. I think what you are looking for is something like ReExecLauncherIfNeeded or something that make it clear that it doesn't re-exec always.

src/java.base/share/native/libjli/java.c line 368:

> 366: #endif
> 367: 
> 368:     JLI_SetTraceLauncher();

It's confusing to call JLI_SetTraceLauncher here as that is normally done by InitiLauncher.

src/java.base/unix/native/libjli/java_md.c line 194:

> 192:     serverPatternFound = JLI_StrStr(env, serverPattern) != NULL;
> 193:     minimalPatternFound = JLI_StrStr(env, serverPattern) != NULL;
> 194:     if (clientPatternFound == JNI_FALSE && serverPatternFound == JNI_FALSE && minimalPatternFound == JNI_FALSE) {

This change (for minimal vm) doesn't seem to be related to re-execing.

test/jdk/tools/launcher/ArgsEnvVar.java line 227:

> 225:            return;
> 226:         }
> 227:         env.put(JDK_JAVA_OPTIONS, "-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005");

Tests uses hard coded ports are problematic as they will fail if the port is in used by something else, like another tests running concurrently.

-------------

PR: https://git.openjdk.org/jdk/pull/11538

From pminborg at openjdk.org  Thu Dec  8 15:28:13 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 8 Dec 2022 15:28:13 GMT
Subject: RFR: JDK-8298277: Replace "session" with "scope" for FFM access
In-Reply-To: <CYHzwj9DnbvaHm7sN4m3E7wWrk9egJnxBpIFjbJo5iM=.ae6898e4-b124-42fd-8aa7-ac0762d58a70@github.com>
References: <YnNzM56870Nmq9AtyXDu0ESYWwcoYVEswRImv2kn_xk=.0cc70ffd-f0f0-4855-b6fa-ff32552846a8@github.com>
 <l0eQns0JA9sF6qU3a2ZgIsZIkzXkcCaqBBajF0qubZA=.58b53918-6c87-45a5-87ea-8fc488f306cb@github.com>
 <CYHzwj9DnbvaHm7sN4m3E7wWrk9egJnxBpIFjbJo5iM=.ae6898e4-b124-42fd-8aa7-ac0762d58a70@github.com>
Message-ID: <Q7Zi99jRGa1qWdbkpRt9Mcs-ELHefLM5wNXbGErj1HM=.ef0c530e-601d-4592-89b8-699b4aae3272@github.com>

On Thu, 8 Dec 2022 14:36:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/abi/Binding.java line 255:
>> 
>>> 253:          * the context's allocator is accessed.
>>> 254:          */
>>> 255:         public static Context ofScope() {
>> 
>> I think `ofArena` seems more apt here?
>
> More generally, I think that now that we can subclass Arena, Binding.Context can just become a subclass of Arena. Then we might have several implementations, some of which throw on allocate(), some other will throw on scope() and close(). Seems a more direct approach.

Let's do that in a separate PR.

-------------

PR: https://git.openjdk.org/jdk/pull/11593

From pminborg at openjdk.org  Thu Dec  8 15:57:23 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 8 Dec 2022 15:57:23 GMT
Subject: RFR: JDK-8298277: Replace "session" with "scope" for FFM access
 [v2]
In-Reply-To: <YnNzM56870Nmq9AtyXDu0ESYWwcoYVEswRImv2kn_xk=.0cc70ffd-f0f0-4855-b6fa-ff32552846a8@github.com>
References: <YnNzM56870Nmq9AtyXDu0ESYWwcoYVEswRImv2kn_xk=.0cc70ffd-f0f0-4855-b6fa-ff32552846a8@github.com>
Message-ID: <FodVyBalglGphWVzdtJXGcQp-ryoEYP47zk2TXMGY2U=.a2df7764-cdf3-4590-8480-a3625f2b17e3@github.com>

> This PR proposes changing variable names and text from "session" to "scope". The proposed changes are only for the FFM API and not other parts like the Vector API and test classes.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Revert changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11593/files
  - new: https://git.openjdk.org/jdk/pull/11593/files/4c3f57f9..41c111be

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11593&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11593&range=00-01

  Stats: 38 lines in 6 files changed: 0 ins; 1 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/11593.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11593/head:pull/11593

PR: https://git.openjdk.org/jdk/pull/11593

From mcimadamore at openjdk.org  Thu Dec  8 16:06:18 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 8 Dec 2022 16:06:18 GMT
Subject: RFR: JDK-8298277: Replace "session" with "scope" for FFM access
 [v2]
In-Reply-To: <FodVyBalglGphWVzdtJXGcQp-ryoEYP47zk2TXMGY2U=.a2df7764-cdf3-4590-8480-a3625f2b17e3@github.com>
References: <YnNzM56870Nmq9AtyXDu0ESYWwcoYVEswRImv2kn_xk=.0cc70ffd-f0f0-4855-b6fa-ff32552846a8@github.com>
 <FodVyBalglGphWVzdtJXGcQp-ryoEYP47zk2TXMGY2U=.a2df7764-cdf3-4590-8480-a3625f2b17e3@github.com>
Message-ID: <sARU6TJfq_UWLwcZ_Z7ah-5Yv65NFffAfthYSAULC-A=.04ab299c-38b6-4a5a-976a-fad96cb9feec@github.com>

On Thu, 8 Dec 2022 15:57:23 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes changing variable names and text from "session" to "scope". The proposed changes are only for the FFM API and not other parts like the Vector API and test classes.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11593

From darcy at openjdk.org  Thu Dec  8 16:08:10 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 8 Dec 2022 16:08:10 GMT
Subject: Integrated: JDK-8296149: Start of release updates for JDK 21
In-Reply-To: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
Message-ID: <qMPCxRnIrpq8gEc6SoGI3iiybj5joeLV9aTu-vviXYM=.6daf4167-8194-49fe-b837-9dd09632d2c8@github.com>

On Tue, 1 Nov 2022 05:49:25 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21.

This pull request has now been integrated.

Changeset: 175e3d3f
Author:    Joe Darcy <darcy at openjdk.org>
Committer: Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/175e3d3ff332be25cca9822c58c46f1e012953c2
Stats:     3726 lines in 70 files changed: 3672 ins; 1 del; 53 mod

8296149: Start of release updates for JDK 21
8296150: Add SourceVersion.RELEASE_21
8296151: Add source 21 and target 21 to javac

Reviewed-by: dholmes, iris, erikj, vromero, jlahoda

-------------

PR: https://git.openjdk.org/jdk/pull/10924

From alanb at openjdk.org  Thu Dec  8 17:15:46 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Dec 2022 17:15:46 GMT
Subject: RFR: 8297295: Remove ThreadGroup.allowThreadSuspension [v3]
In-Reply-To: <nzPvVaqoaUaQi2tJudlE6Nx30o1kZL_MOyafLb5iHps=.ebc94199-eec0-4a23-8e46-afa87be5735d@github.com>
References: <nzPvVaqoaUaQi2tJudlE6Nx30o1kZL_MOyafLb5iHps=.ebc94199-eec0-4a23-8e46-afa87be5735d@github.com>
Message-ID: <dbbHTLcfowblTL8_SpFq750gOQcNC61lXUf5cMJ3D_M=.7af535a7-a936-49e6-89a6-e421857afe66@github.com>

> Another small step in the multi-release/multi-year effort to remove cruft from Thread/ThreadGroup.
> 
> java.lang.ThreadGroup.allowThreadSuspension(boolean) dates from JDK 1.1 and the Classic VM. The method controlled whether threads were suspended when the GC failed. It appears to have interacted with a callback mechanism that could potentially free memory, allowing the GC to retry. The method was never specified .
> 
> The method was deprecated and changed to do nothing in JDK 1.2. It was deprecated for removal in Java 14. 
> 
> A corpus analysis of 30M classes in 130k artifacts found 0 usages of this method.
> 
> It is time to finally remove this method. The compatibility impact should be negligible. Joe, Stuart and I discussed briefly and think early in JDK 21 is a good time to do this.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge
 - Merge
 - Remove allowThreadSuspension

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11373/files
  - new: https://git.openjdk.org/jdk/pull/11373/files/639b6b58..3b06acd6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11373&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11373&range=01-02

  Stats: 5249 lines in 127 files changed: 4880 ins; 87 del; 282 mod
  Patch: https://git.openjdk.org/jdk/pull/11373.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11373/head:pull/11373

PR: https://git.openjdk.org/jdk/pull/11373

From joe.darcy at oracle.com  Thu Dec  8 17:31:07 2022
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Thu, 8 Dec 2022 09:31:07 -0800
Subject: Difference in behaviour in native math library
In-Reply-To: <CADT88DuxtUt+0OYMZeSKek1GAwEQEVXMuRK+moc4xHA9w--01Q@mail.gmail.com>
References: <CADT88DtZqejo8v44NR01HTogK70azyHiCcWrTWOf8EcXBjRWgw@mail.gmail.com>
 <CADT88DuxtUt+0OYMZeSKek1GAwEQEVXMuRK+moc4xHA9w--01Q@mail.gmail.com>
Message-ID: <6bc2bc45-a730-e445-51a4-53ae6ecb653e@oracle.com>

Hello,

Okay, so it looks like the test is expected the same bit pattern to be 
used for a NaN output if a NaN was used as an input.

That isn't necessarily unreasonable, but it is *not* required by the 
specifications for the Math or StrictMath method, spec for Math.acos:

> Returns the arc cosine of a value; the returned angle is in the range 
> 0.0 through /pi/. Special case:
>
>   * If the argument is NaN or its absolute value is greater than 1,
>     then the result is NaN.
>   * If the argument is |1.0|, the result is positive zero.
>
> The computed result must be within 1 ulp of the exact result. Results 
> must be semi-monotonic.
>
https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/Math.html#acos(double)

On a NaN argument, any NaN bit pattern is valid per the spec. Even if 
you're trying to return the same NaN, there can be challenges to doing 
so depending on how the underlying processor handles signaling NaNs, a 
concept which doesn't exist in the Java platform.

HTH,

-Joe

On 12/8/2022 8:26 AM, Ludovic Henry wrote:
> Adding the right address for core-libs-dev.
>
> On Thu, Dec 8, 2022 at 12:19 PM Ludovic Henry <ludovic at rivosinc.com> 
> wrote:
>
>     Hello,
>
>     I've noticed that some Math trigonometry tests are failing in the
>     GNU Mauve test suite. From digging into it, it's related to NaN
>     values being passed to java.lang.Math trigonometry functions, and
>     how these values are handled in the native libm library.
>
>     Given the following C test case compiled and run with `gcc acos.c
>     -lm && ./a.out`
>
>     ```
>     #include <stdint.h>
>     #include <math.h>
>     #include <stdlib.h>
>     #include <stdio.h>
>
>     void main(int argc, char* argv[]) {
>     ? ? int64_t bitsNaN = 0x7fff800000000000L;
>     ? ? double valNaN = *((double*)&bitsNaN);
>
>     ? ? double resD = acos(valNaN);
>     ? ? int64_t res = *((int64_t*)&resD);
>     ? ? if (!(res == bitsNaN)) {
>     ? ? ? ? printf("expected 0x%lx but got 0x%lx\n", bitsNaN, res);
>     ? ? ? ? exit(1);
>     ? ? }
>     }
>     ```
>
>     On a Linux-x64, the test succeeds, but on Linux-RISC-V, the test
>     fails.
>
>     You've the same test failure in the equivalent Java code:
>
>     ```
>     public class acos {
>     ? ? public static void main (String[] args) {
>     ? ? ? ? long bitsNaN = 0x7fff800000000000L;
>     ? ? ? ? double valNaN = Double.longBitsToDouble(bitsNaN);
>
>     ? ? ? ? long res = Double.doubleToRawLongBits(Math.acos(valNaN));
>     ? ? ? ? if (!(res == bitsNaN)) {
>     ? ? ? ? ? ? throw new RuntimeException(String.format("expected
>     0x%x but got 0x%x", bitsNaN, res));
>     ? ? ? ? }
>     ? ? }
>     }
>     ```
>
>     What approach should we take in these cases? Is it that the test
>     case is wrong, and should assume that given a NaN, any value of
>     NaN returned is valid? Or should we make sure that the behavior is
>     the same across platforms and that we "fix" any difference in
>     behavior of the native library?
>
>     Cheers,
>     Ludovic
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221208/c5ac1eb5/attachment.htm>

From darcy at openjdk.org  Thu Dec  8 17:49:17 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 8 Dec 2022 17:49:17 GMT
Subject: RFR: 8297295: Remove ThreadGroup.allowThreadSuspension [v3]
In-Reply-To: <dbbHTLcfowblTL8_SpFq750gOQcNC61lXUf5cMJ3D_M=.7af535a7-a936-49e6-89a6-e421857afe66@github.com>
References: <nzPvVaqoaUaQi2tJudlE6Nx30o1kZL_MOyafLb5iHps=.ebc94199-eec0-4a23-8e46-afa87be5735d@github.com>
 <dbbHTLcfowblTL8_SpFq750gOQcNC61lXUf5cMJ3D_M=.7af535a7-a936-49e6-89a6-e421857afe66@github.com>
Message-ID: <YFhYa0AztYMe2XaR4cJE3v8i7PDcumi68XY_NyFtajU=.eba8e232-b5a7-4a57-968e-7e6b16d16dbd@github.com>

On Thu, 8 Dec 2022 17:15:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Another small step in the multi-release/multi-year effort to remove cruft from Thread/ThreadGroup.
>> 
>> java.lang.ThreadGroup.allowThreadSuspension(boolean) dates from JDK 1.1 and the Classic VM. The method controlled whether threads were suspended when the GC failed. It appears to have interacted with a callback mechanism that could potentially free memory, allowing the GC to retry. The method was never specified .
>> 
>> The method was deprecated and changed to do nothing in JDK 1.2. It was deprecated for removal in Java 14. 
>> 
>> A corpus analysis of 30M classes in 130k artifacts found 0 usages of this method.
>> 
>> It is time to finally remove this method. The compatibility impact should be negligible. Joe, Stuart and I discussed briefly and think early in JDK 21 is a good time to do this.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge
>  - Merge
>  - Remove allowThreadSuspension

Still looks good.

-------------

PR: https://git.openjdk.org/jdk/pull/11373

From alanb at openjdk.org  Thu Dec  8 18:22:56 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Dec 2022 18:22:56 GMT
Subject: Integrated: 8297295: Remove ThreadGroup.allowThreadSuspension
In-Reply-To: <nzPvVaqoaUaQi2tJudlE6Nx30o1kZL_MOyafLb5iHps=.ebc94199-eec0-4a23-8e46-afa87be5735d@github.com>
References: <nzPvVaqoaUaQi2tJudlE6Nx30o1kZL_MOyafLb5iHps=.ebc94199-eec0-4a23-8e46-afa87be5735d@github.com>
Message-ID: <xwuNBGHgsDJ0BYH1fseIMdowNOxH1kAffNYt6XSpK6E=.e2934856-ee9b-4277-93d3-f2d4d7762536@github.com>

On Fri, 25 Nov 2022 18:54:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Another small step in the multi-release/multi-year effort to remove cruft from Thread/ThreadGroup.
> 
> java.lang.ThreadGroup.allowThreadSuspension(boolean) dates from JDK 1.1 and the Classic VM. The method controlled whether threads were suspended when the GC failed. It appears to have interacted with a callback mechanism that could potentially free memory, allowing the GC to retry. The method was never specified .
> 
> The method was deprecated and changed to do nothing in JDK 1.2. It was deprecated for removal in Java 14. 
> 
> A corpus analysis of 30M classes in 130k artifacts found 0 usages of this method.
> 
> It is time to finally remove this method. The compatibility impact should be negligible. Joe, Stuart and I discussed briefly and think early in JDK 21 is a good time to do this.

This pull request has now been integrated.

Changeset: d35e8400
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d35e840024b80f9f686fb5522dc03b2c9233a6d3
Stats:     24 lines in 2 files changed: 0 ins; 24 del; 0 mod

8297295: Remove ThreadGroup.allowThreadSuspension

Reviewed-by: jpai, smarks, chegar, darcy

-------------

PR: https://git.openjdk.org/jdk/pull/11373

From darcy at openjdk.org  Thu Dec  8 18:26:10 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 8 Dec 2022 18:26:10 GMT
Subject: RFR: JDK-8297679: InvocationTargetException field named target is not
 declared final
Message-ID: <9r_tHpb2SsXe4Iw6zaaQDhabxLr1yHlR9IXH28eJXzk=.378d44ad-b200-4cdc-a67d-d721352637cc@github.com>

Should be an innocuous change of a private field to final; I'll run an internal round of sanity tests before any push to make sure there isn't any unexpected interaction.

-------------

Commit messages:
 - JDK-8297679: InvocationTargetException field named target is not declared fina

Changes: https://git.openjdk.org/jdk/pull/11599/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11599&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297679
  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11599.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11599/head:pull/11599

PR: https://git.openjdk.org/jdk/pull/11599

From alanb at openjdk.org  Thu Dec  8 18:36:11 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Dec 2022 18:36:11 GMT
Subject: RFR: JDK-8297679: InvocationTargetException field named target is
 not declared final
In-Reply-To: <9r_tHpb2SsXe4Iw6zaaQDhabxLr1yHlR9IXH28eJXzk=.378d44ad-b200-4cdc-a67d-d721352637cc@github.com>
References: <9r_tHpb2SsXe4Iw6zaaQDhabxLr1yHlR9IXH28eJXzk=.378d44ad-b200-4cdc-a67d-d721352637cc@github.com>
Message-ID: <PCDAxZnWahTXvGgrex2Nd0YR9zZaU1GnLvBhaBKrs08=.4fefe618-d62b-4d35-8ae8-85d027601201@github.com>

On Thu, 8 Dec 2022 18:10:12 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Should be an innocuous change of a private field to final; I'll run an internal round of sanity tests before any push to make sure there isn't any unexpected interaction.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11599

From bpb at openjdk.org  Thu Dec  8 19:40:01 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 Dec 2022 19:40:01 GMT
Subject: RFR: 8297632: InputStream.transferTo() method should specify what
 the return value should be when the number of bytes transfered is
 larger than Long.MAX_VALUE [v5]
In-Reply-To: <T38kO1hcz3rhpqOOPYmoPl1TlRORJBifQWtXLl10x8Y=.595338d3-df98-4202-95b5-eda88a4ed0a2@github.com>
References: <T38kO1hcz3rhpqOOPYmoPl1TlRORJBifQWtXLl10x8Y=.595338d3-df98-4202-95b5-eda88a4ed0a2@github.com>
Message-ID: <ZyIKzySHn7xmnKKzbpQVRozVLL9KCM3vrzSxV2yMA6E=.b8005f1d-4f42-40b8-94c7-46b6ac982177@github.com>

> `java.io.InputStream::transferTo` could conceivably return a negative value if the count of bytes transferred overflows a `long`. Modify the method to limit the number of bytes transferred to `Long.MAX_VALUE` per invocation.

Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - 8297632: Propagate change to SequenceInputStream
 - Merge
 - 8297632: Add verbiage to ZipInputStream::transferTo
 - 8297632: Add Reader::transferTo and select InputStream::transferTo overrides
 - 8297632: Transfer all bytes but clamp returned value to Long.MAX_VALUE
 - 8297632: InputStream.transferTo() method should specify what the return value should be when the number of bytes transfered is larger than Long.MAX_VALUE

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11403/files
  - new: https://git.openjdk.org/jdk/pull/11403/files/558cbc8a..446771db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11403&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11403&range=03-04

  Stats: 92528 lines in 1565 files changed: 46561 ins; 36948 del; 9019 mod
  Patch: https://git.openjdk.org/jdk/pull/11403.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11403/head:pull/11403

PR: https://git.openjdk.org/jdk/pull/11403

From naoto at openjdk.org  Thu Dec  8 19:41:18 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 8 Dec 2022 19:41:18 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <dWZf8Ig6HVqq-7sHncITq__8v0Bl3kYpCJdu-WUZn1o=.18639d8a-bdb3-47ea-8ab8-e29096886878@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
 <NBdqUPP-JYFqnssVlTqDa60SOyWjyrJvXPQ8DDWSImQ=.d07abcf6-b1e5-461b-81b9-07f5d4406907@github.com>
 <dWZf8Ig6HVqq-7sHncITq__8v0Bl3kYpCJdu-WUZn1o=.18639d8a-bdb3-47ea-8ab8-e29096886878@github.com>
Message-ID: <AoYsTXNvcGUUV_rDTPHUFJScUsjqqctuHp2Wa2l7770=.dcb7f0a9-1403-400f-a9a8-49c07cd129f8@github.com>

On Tue, 6 Dec 2022 18:10:38 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Console.java line 99:
>> 
>>> 97:  */
>>> 98: 
>>> 99: public class Console implements Flushable
>> 
>> Should we perhaps `seal` this class and only `permit` `ProxyingConsole` to `extend` it?
>
> Right. Will address it after this PR.

Filed: https://bugs.openjdk.org/browse/JDK-8298416

-------------

PR: https://git.openjdk.org/jdk/pull/11421

From smarks at openjdk.org  Thu Dec  8 23:03:22 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 8 Dec 2022 23:03:22 GMT
Subject: RFR: 8295857: Clarify that cleanup code can be skipped when the
 JVM terminates (e.g. when calling halt()) [v7]
In-Reply-To: <zUoFDkXVFWLVJv0wGr2Rhmh9pff1dcX6vuQBdt2EQL8=.2d21d1e8-1008-4cdd-8e5f-4166bd2845df@github.com>
References: <hHSImvhd-Yg6AcPkSrYBFxBOx4jBg079lx4sRjR3AZc=.65cd47c4-b34a-4475-8b35-069627999eed@github.com>
 <zUoFDkXVFWLVJv0wGr2Rhmh9pff1dcX6vuQBdt2EQL8=.2d21d1e8-1008-4cdd-8e5f-4166bd2845df@github.com>
Message-ID: <yHuU7vnB4gSZZniYrwPjdd9O7sl7F5RM-HD1kWZY458=.04552a8f-42b2-4598-92c9-57dc764af7ef@github.com>

On Wed, 7 Dec 2022 17:38:31 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036) documented the shutdown sequence, noting that calling Runtime.halt() skips the shutdown sequence and immediately terminates the VM. Thus, "threads' current methods do not complete normally or abruptly; no finally clause of any method is executed".
>> 
>> One ramification of this is that resources within try-with-resource blocks will not be released. It would be good to state this explicitly.
>
> Brent Christian has updated the pull request with a new target base 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 8295857
>  - 'close' -> 'closed' in AutoCloseable link
>  - put examples into a list, in class doc only, not halt()
>  - Update Runtime class doc re: other unexpected behaviors
>  - Mentioned effects are not a complete list
>  - It's "try-with-resources"
>  - Merge branch 'master' into 8295857
>  - update halt() @apiNote
>  - update doc changes
>  - Update doc for Runtime class and halt() method

Looks good!

-------------

Marked as reviewed by smarks (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11218

From dholmes at openjdk.org  Fri Dec  9 00:14:49 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 9 Dec 2022 00:14:49 GMT
Subject: RFR: 8298380: Clean up redundant array length checks in JDK code
 base
In-Reply-To: <pOhI85f5BwAPmV0dbQ_nCf8sNQxpIV4wF3AZHdxWr0U=.9add8736-4851-4f5a-9e04-d67430d7e123@github.com>
References: <pOhI85f5BwAPmV0dbQ_nCf8sNQxpIV4wF3AZHdxWr0U=.9add8736-4851-4f5a-9e04-d67430d7e123@github.com>
Message-ID: <xSHUc8nAR_3ZshjMhKx9srjNV94mYeUhsAF_had2ESs=.2713d4f3-4580-43d0-a23f-a2ad650cb129@github.com>

On Thu, 8 Dec 2022 12:37:17 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like
> 
> <T> void iterate(T[] items) {
>   if (items.length == 0) {
>     return;
>   }
>   for (T item : items) {
>     //...
>   }
> }
> 
> Here
> 
> if (items.length == 0) {
>   return;
> }
> 
> is redundant and can be removed as length check is performed by for-each loop.

These all seem fine to me.

You can count this as the review for hotspot and serviceability. :)

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11589

From amenkov at openjdk.org  Fri Dec  9 00:14:50 2022
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 9 Dec 2022 00:14:50 GMT
Subject: RFR: 8298380: Clean up redundant array length checks in JDK code
 base
In-Reply-To: <pOhI85f5BwAPmV0dbQ_nCf8sNQxpIV4wF3AZHdxWr0U=.9add8736-4851-4f5a-9e04-d67430d7e123@github.com>
References: <pOhI85f5BwAPmV0dbQ_nCf8sNQxpIV4wF3AZHdxWr0U=.9add8736-4851-4f5a-9e04-d67430d7e123@github.com>
Message-ID: <CMfo4XUsXp6Te2OussC0S1j_IVgbgo7WMfLRfttXsXs=.370474dd-2266-457f-b2b4-190c16d33b84@github.com>

On Thu, 8 Dec 2022 12:37:17 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like
> 
> <T> void iterate(T[] items) {
>   if (items.length == 0) {
>     return;
>   }
>   for (T item : items) {
>     //...
>   }
> }
> 
> Here
> 
> if (items.length == 0) {
>   return;
> }
> 
> is redundant and can be removed as length check is performed by for-each loop.

Marked as reviewed by amenkov (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11589

From darcy at openjdk.org  Fri Dec  9 00:34:11 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 9 Dec 2022 00:34:11 GMT
Subject: Integrated: JDK-8297679: InvocationTargetException field named target
 is not declared final
In-Reply-To: <9r_tHpb2SsXe4Iw6zaaQDhabxLr1yHlR9IXH28eJXzk=.378d44ad-b200-4cdc-a67d-d721352637cc@github.com>
References: <9r_tHpb2SsXe4Iw6zaaQDhabxLr1yHlR9IXH28eJXzk=.378d44ad-b200-4cdc-a67d-d721352637cc@github.com>
Message-ID: <OmiXtQJSZLFjCvbjotmL23p9b2o2-zRzULFMnK8M4Do=.e835f3f2-2e1c-4fa2-8ecc-1ae0338b2708@github.com>

On Thu, 8 Dec 2022 18:10:12 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Should be an innocuous change of a private field to final; I'll run an internal round of sanity tests before any push to make sure there isn't any unexpected interaction.

This pull request has now been integrated.

Changeset: 7f9c6ce3
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7f9c6ce3318aedfd85f12f4002dc442b0b468c27
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8297679: InvocationTargetException field named target is not declared final

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/11599

From serb at openjdk.org  Fri Dec  9 00:46:18 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 9 Dec 2022 00:46:18 GMT
Subject: RFR: 8298380: Clean up redundant array length checks in JDK code
 base
In-Reply-To: <pOhI85f5BwAPmV0dbQ_nCf8sNQxpIV4wF3AZHdxWr0U=.9add8736-4851-4f5a-9e04-d67430d7e123@github.com>
References: <pOhI85f5BwAPmV0dbQ_nCf8sNQxpIV4wF3AZHdxWr0U=.9add8736-4851-4f5a-9e04-d67430d7e123@github.com>
Message-ID: <FkeOVEsqaMwj6vBM76Amoo2ejo-arcOiyXXbtQcEcY4=.1bb30137-ad97-45c0-8f46-1663d918270a@github.com>

On Thu, 8 Dec 2022 12:37:17 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like
> 
> <T> void iterate(T[] items) {
>   if (items.length == 0) {
>     return;
>   }
>   for (T item : items) {
>     //...
>   }
> }
> 
> Here
> 
> if (items.length == 0) {
>   return;
> }
> 
> is redundant and can be removed as length check is performed by for-each loop.

The "client" changes in src/java.desktop looks fine

-------------

Marked as reviewed by serb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11589

From vtewari at openjdk.org  Fri Dec  9 06:24:54 2022
From: vtewari at openjdk.org (Vyom Tewari)
Date: Fri, 9 Dec 2022 06:24:54 GMT
Subject: RFR: 8298380: Clean up redundant array length checks in JDK code
 base
In-Reply-To: <pOhI85f5BwAPmV0dbQ_nCf8sNQxpIV4wF3AZHdxWr0U=.9add8736-4851-4f5a-9e04-d67430d7e123@github.com>
References: <pOhI85f5BwAPmV0dbQ_nCf8sNQxpIV4wF3AZHdxWr0U=.9add8736-4851-4f5a-9e04-d67430d7e123@github.com>
Message-ID: <QsE7sZ_-X1NMmYEgSE-TLq9lBXpTvkbC8DHnJjfbBIY=.9fd88818-1e40-4f99-926d-e339b0dc0082@github.com>

On Thu, 8 Dec 2022 12:37:17 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like
> 
> <T> void iterate(T[] items) {
>   if (items.length == 0) {
>     return;
>   }
>   for (T item : items) {
>     //...
>   }
> }
> 
> Here
> 
> if (items.length == 0) {
>   return;
> }
> 
> is redundant and can be removed as length check is performed by for-each loop.

java.base changes looks ok to me.

-------------

Marked as reviewed by vtewari (Committer).

PR: https://git.openjdk.org/jdk/pull/11589

From jcking at openjdk.org  Fri Dec  9 07:03:24 2022
From: jcking at openjdk.org (Justin King)
Date: Fri, 9 Dec 2022 07:03:24 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer
Message-ID: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>

Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.

-------------

Commit messages:
 - Remove leftover debugging logic
 - Initial implementation of UBSan

Changes: https://git.openjdk.org/jdk/pull/11604/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11604&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298448
  Stats: 54 lines in 4 files changed: 54 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11604.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11604/head:pull/11604

PR: https://git.openjdk.org/jdk/pull/11604

From mbaesken at openjdk.org  Fri Dec  9 12:27:00 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 9 Dec 2022 12:27:00 GMT
Subject: RFR: JDK-8298170 : Introduce a macro for exception check,
 free and return
In-Reply-To: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
References: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
Message-ID: <_mmRgqh9oP4GNFQEsIHjRtYwzMekhI5GTq8b8URghEE=.540c993a-fa4e-4c8e-8f6c-5372e0c74d42@github.com>

On Tue, 6 Dec 2022 15:20:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have a number of places in the codebase  where a macro could help when we check an exception and afterwrads free something and return.

Hi Roger , the new proposed version  JNU_CHECK_EXCEPTION_DO  is now almost as lengthy as the original coding, Is it really worth it introducing a macro when it gets so lengthy ?

-------------

PR: https://git.openjdk.org/jdk/pull/11539

From stsypanov at openjdk.org  Fri Dec  9 12:54:50 2022
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 9 Dec 2022 12:54:50 GMT
Subject: Integrated: 8298380: Clean up redundant array length checks in JDK
 code base
In-Reply-To: <pOhI85f5BwAPmV0dbQ_nCf8sNQxpIV4wF3AZHdxWr0U=.9add8736-4851-4f5a-9e04-d67430d7e123@github.com>
References: <pOhI85f5BwAPmV0dbQ_nCf8sNQxpIV4wF3AZHdxWr0U=.9add8736-4851-4f5a-9e04-d67430d7e123@github.com>
Message-ID: <b7nakxCOTmosMZCe5GtxG-oPMr25G3BPSaGDdza3-Fo=.22ac843f-949c-4c0d-b0cc-e81c129c7315@github.com>

On Thu, 8 Dec 2022 12:37:17 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like
> 
> <T> void iterate(T[] items) {
>   if (items.length == 0) {
>     return;
>   }
>   for (T item : items) {
>     //...
>   }
> }
> 
> Here
> 
> if (items.length == 0) {
>   return;
> }
> 
> is redundant and can be removed as length check is performed by for-each loop.

This pull request has now been integrated.

Changeset: e3c6cf8e
Author:    Sergey Tsypanov <stsypanov at openjdk.org>
Committer: Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e3c6cf8eaf931d9eb46b429a5ba8d3bbded3728a
Stats:     51 lines in 8 files changed: 0 ins; 14 del; 37 mod

8298380: Clean up redundant array length checks in JDK code base

Reviewed-by: dholmes, amenkov, serb, vtewari

-------------

PR: https://git.openjdk.org/jdk/pull/11589

From rehn at openjdk.org  Fri Dec  9 13:29:00 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 9 Dec 2022 13:29:00 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer
In-Reply-To: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
Message-ID: <DMn4071vUEwYB1gmvLS21uZuTr6pqkj8Ce7IQDAfdm8=.52e7a42a-bf92-4b00-be59-ce4381d6d2b4@github.com>

On Fri, 9 Dec 2022 06:53:31 GMT, Justin King <jcking at openjdk.org> wrote:

> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.

Two questions, this works fine for me:
`UBSAN_CFLAGS="-fsanitize=undefined -fsanitize=float-divide-by-zero -Wno-stringop-truncation -Wno-format-overflow -fno-omit-frame-pointer" ; UBSAN_LDFLAGS="-fsanitize=undefined -fsanitize=float-divide-by-zero" ; sh configure --with-conf-name=udf --with-debug-level=fastdebug --with-native-debug-symbols=internal -with-version-opt=releaserobbin --with-gtest=/home/rehn/source/gtest181/ --disable-precompiled-headers --enable-dtrace --with-extra-cflags="$UBSAN_CFLAGS" --with-extra-cxxflags="$UBSAN_CFLAGS" --with-extra-ldflags="$UBSAN_LDFLAGS" && make images CONF=udf`
I.e.build works ?

Secondly, the method __ubsan_default_options is in the java launcher.
libjvm.so is a "standalone product" that can be used by different launchers.
So I'm not sure it should be in launcher if it was needed.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From jcking at openjdk.org  Fri Dec  9 13:50:02 2022
From: jcking at openjdk.org (Justin King)
Date: Fri, 9 Dec 2022 13:50:02 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer
In-Reply-To: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
Message-ID: <xijbR1IXc535oh1-sA3u72LFoYng1ly60-rGFGUtOoc=.f7ecc5c7-165b-49d5-bb0d-7467c26f5a6d@github.com>

On Fri, 9 Dec 2022 06:53:31 GMT, Justin King <jcking at openjdk.org> wrote:

> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.

What version of GCC are you using? I'm on 12.2 which is the most recent. It
might be that I'm on a newer build with more UBSan coverage.

__ubsan_default_options is called extremely early before main, during
static initializers. IIRC the launcher uses dynamic loading to get
libjvm.so, so that won't work. But maybe I'm misremembering, I'll double
check.

On Fri, Dec 9, 2022, 6:56 PM Robbin Ehn ***@***.***> wrote:

> Two questions, this works fine for me:
> UBSAN_CFLAGS="-fsanitize=undefined -fsanitize=float-divide-by-zero
> -Wno-stringop-truncation -Wno-format-overflow -fno-omit-frame-pointer" ;
> UBSAN_LDFLAGS="-fsanitize=undefined -fsanitize=float-divide-by-zero" ; sh
> configure --with-conf-name=udf --with-debug-level=fastdebug
> --with-native-debug-symbols=internal -with-version-opt=releaserobbin
> --with-gtest=/home/rehn/source/gtest181/ --disable-precompiled-headers
> --enable-dtrace --with-extra-cflags="$UBSAN_CFLAGS"
> --with-extra-cxxflags="$UBSAN_CFLAGS" --with-extra-ldflags="$UBSAN_LDFLAGS"
> && make images CONF=udf
> I.e.build works ?
>
> Secondly, the method __ubsan_default_options is in the java launcher.
> libjvm.so is a "standalone product" that can be used by different
> launchers.
> So I'm not sure it should be in launcher if it was needed.
>
> ?
> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jdk/pull/11604#issuecomment-1344309622>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAHTURS2GYPXYGIN5D2CVZ3WMMXRFANCNFSM6AAAAAASY75DP4>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From rehn at openjdk.org  Fri Dec  9 14:18:55 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 9 Dec 2022 14:18:55 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer
In-Reply-To: <xijbR1IXc535oh1-sA3u72LFoYng1ly60-rGFGUtOoc=.f7ecc5c7-165b-49d5-bb0d-7467c26f5a6d@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <xijbR1IXc535oh1-sA3u72LFoYng1ly60-rGFGUtOoc=.f7ecc5c7-165b-49d5-bb0d-7467c26f5a6d@github.com>
Message-ID: <8hgyPlQ0YEyVTZBXJyc3Fc1FjSX4HyraPIXUAhJUIA4=.ac744f48-66c2-4147-9b5e-bb0a585ae087@github.com>

On Fri, 9 Dec 2022 13:46:07 GMT, Justin King <jcking at openjdk.org> wrote:

> What version of GCC are you using?

gcc 11.3 with libubsan 11.2

Also it seem to big overlap with -Wcast-align(=strict) for the warnings/errors I see and I do like that warning.
Do you have an idea if the coverage are pretty much the same for this particular warning?
I.e. is anyone of them better than the other?

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From burban at openjdk.org  Fri Dec  9 14:25:38 2022
From: burban at openjdk.org (Bernhard Urban-Forster)
Date: Fri, 9 Dec 2022 14:25:38 GMT
Subject: RFR: JDK-8298476: Unseal FinalReference<T>
Message-ID: <HX-wqdrbmiW_cB-wH-Qf8GlmxIJbCIm6wH3Da13QUps=.fa929a99-2016-4f16-b4ec-69682e933b17@github.com>

The change in [JDK-8283415](https://bugs.openjdk.org/browse/JDK-8283415) made use of the now available `sealed` keyword for `FinalReference<T>`.

Unfortunately this introduced a problem for the Espresso VM (Java on Truffle): Since Espresso is written in Java it uses the functionality of the "Host VM" to implement finalization. It does that however by [introducing a new subclass of `FinalReference<T>`](https://github.com/oracle/graal/blob/f195395329fba573afc6f81c5e70a18ac334dd10/espresso/src/com.oracle.truffle.espresso/src/com/oracle/truffle/espresso/ref/ClassAssembler.java#L85-L113) which does not work anymore with the changes made in JDK-8283415. We cannot use `Finalizer` itself because we want to inject an additional "Guest object".

Making `FinalReference<T>` `non-sealed` would simplify things for Espresso. Before pursuing other more involved solutions I thought I would ask how strongly the maintainers of core-libs feel about such a change. Would that be okay? Are there any implications for the GC for such a change?

-------------

Commit messages:
 - JDK-8298476: Unseal FinalReference<T>

Changes: https://git.openjdk.org/jdk/pull/11610/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11610&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298476
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11610.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11610/head:pull/11610

PR: https://git.openjdk.org/jdk/pull/11610

From erikj at openjdk.org  Fri Dec  9 14:36:48 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 9 Dec 2022 14:36:48 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer
In-Reply-To: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
Message-ID: <-1gzjFB0pjbXBXsKVQv4z0-ZSO7ZhOgPHHn4A-ix7tw=.64b4fb3d-5d8e-4450-9428-ca086cc5d3aa@github.com>

On Fri, 9 Dec 2022 06:53:31 GMT, Justin King <jcking at openjdk.org> wrote:

> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.

make/autoconf/jdk-options.m4 line 450:

> 448: ###############################################################################
> 449: #
> 450: # UndefinedBehaviorSanitizer

I think this logic fits better in `flags.m4`, otherwise this looks ok to me.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From rriggs at openjdk.org  Fri Dec  9 14:38:03 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 9 Dec 2022 14:38:03 GMT
Subject: RFR: 8298380: Clean up redundant array length checks in JDK code
 base
In-Reply-To: <pOhI85f5BwAPmV0dbQ_nCf8sNQxpIV4wF3AZHdxWr0U=.9add8736-4851-4f5a-9e04-d67430d7e123@github.com>
References: <pOhI85f5BwAPmV0dbQ_nCf8sNQxpIV4wF3AZHdxWr0U=.9add8736-4851-4f5a-9e04-d67430d7e123@github.com>
Message-ID: <Dz0VbMxEcXZnFW0IC2vgWOGbtXJeSxcPFRhZBUp5Vsg=.d7bdff79-a2fc-4951-9981-6654853d2b92@github.com>

On Thu, 8 Dec 2022 12:37:17 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like
> 
> <T> void iterate(T[] items) {
>   if (items.length == 0) {
>     return;
>   }
>   for (T item : items) {
>     //...
>   }
> }
> 
> Here
> 
> if (items.length == 0) {
>   return;
> }
> 
> is redundant and can be removed as length check is performed by for-each loop.

@stsypanov , @TheShermanTanker You jumped the gun a bit on the integration and sponsoring. There was no approval for the core-libs parts from a "R"eviewer.

-------------

PR: https://git.openjdk.org/jdk/pull/11589

From rriggs at openjdk.org  Fri Dec  9 14:43:49 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 9 Dec 2022 14:43:49 GMT
Subject: RFR: JDK-8298170 : Introduce a macro for exception check,
 free and return
In-Reply-To: <_mmRgqh9oP4GNFQEsIHjRtYwzMekhI5GTq8b8URghEE=.540c993a-fa4e-4c8e-8f6c-5372e0c74d42@github.com>
References: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
 <_mmRgqh9oP4GNFQEsIHjRtYwzMekhI5GTq8b8URghEE=.540c993a-fa4e-4c8e-8f6c-5372e0c74d42@github.com>
Message-ID: <YPj1ap6tA4UlYcuTzF7tfm1pqNC-03nnqR3Jaj-kEVY=.d7e1798a-0c84-4d8e-acb5-dff6f4d070da@github.com>

On Fri, 9 Dec 2022 12:23:04 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi Roger , the new proposed version JNU_CHECK_EXCEPTION_DO is now almost as lengthy as the original coding, Is it really worth it introducing a macro when it gets so lengthy ?

Its easier to understand the flow and cleanup being done if its visible in the source. 
I (or new readers) don't have to go unwrap the macro to know what's going to happen.

-------------

PR: https://git.openjdk.org/jdk/pull/11539

From stsypanov at openjdk.org  Fri Dec  9 14:48:02 2022
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 9 Dec 2022 14:48:02 GMT
Subject: RFR: 8298380: Clean up redundant array length checks in JDK code
 base
In-Reply-To: <Dz0VbMxEcXZnFW0IC2vgWOGbtXJeSxcPFRhZBUp5Vsg=.d7bdff79-a2fc-4951-9981-6654853d2b92@github.com>
References: <pOhI85f5BwAPmV0dbQ_nCf8sNQxpIV4wF3AZHdxWr0U=.9add8736-4851-4f5a-9e04-d67430d7e123@github.com>
 <Dz0VbMxEcXZnFW0IC2vgWOGbtXJeSxcPFRhZBUp5Vsg=.d7bdff79-a2fc-4951-9981-6654853d2b92@github.com>
Message-ID: <Bxyi6RsVLIF3CMzxULvqkw3hPPq3uL3HfLejuML4kAs=.9d6fc4b5-b3f6-4047-92be-16aeacb510ad@github.com>

On Fri, 9 Dec 2022 14:35:47 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like
>> 
>> <T> void iterate(T[] items) {
>>   if (items.length == 0) {
>>     return;
>>   }
>>   for (T item : items) {
>>     //...
>>   }
>> }
>> 
>> Here
>> 
>> if (items.length == 0) {
>>   return;
>> }
>> 
>> is redundant and can be removed as length check is performed by for-each loop.
>
> @stsypanov , @TheShermanTanker You jumped the gun a bit on the integration and sponsoring. There was no approval for the core-libs parts from a "R"eviewer.

@RogerRiggs changes are trivial. Should I revert any of them?

-------------

PR: https://git.openjdk.org/jdk/pull/11589

From rriggs at openjdk.org  Fri Dec  9 15:54:00 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 9 Dec 2022 15:54:00 GMT
Subject: RFR: 8298380: Clean up redundant array length checks in JDK code
 base
In-Reply-To: <pOhI85f5BwAPmV0dbQ_nCf8sNQxpIV4wF3AZHdxWr0U=.9add8736-4851-4f5a-9e04-d67430d7e123@github.com>
References: <pOhI85f5BwAPmV0dbQ_nCf8sNQxpIV4wF3AZHdxWr0U=.9add8736-4851-4f5a-9e04-d67430d7e123@github.com>
Message-ID: <BwPdsqhPrg0_Pu-2vG9oeI57xDndYzFgYKJmIEIzNxk=.856d70e7-734c-47d9-a988-33521a665416@github.com>

On Thu, 8 Dec 2022 12:37:17 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like
> 
> <T> void iterate(T[] items) {
>   if (items.length == 0) {
>     return;
>   }
>   for (T item : items) {
>     //...
>   }
> }
> 
> Here
> 
> if (items.length == 0) {
>   return;
> }
> 
> is redundant and can be removed as length check is performed by for-each loop.

No, just a reminder to be through in the process.

-------------

PR: https://git.openjdk.org/jdk/pull/11589

From alanb at openjdk.org  Fri Dec  9 17:43:06 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 Dec 2022 17:43:06 GMT
Subject: RFR: JDK-8298476: Unseal FinalReference<T>
In-Reply-To: <HX-wqdrbmiW_cB-wH-Qf8GlmxIJbCIm6wH3Da13QUps=.fa929a99-2016-4f16-b4ec-69682e933b17@github.com>
References: <HX-wqdrbmiW_cB-wH-Qf8GlmxIJbCIm6wH3Da13QUps=.fa929a99-2016-4f16-b4ec-69682e933b17@github.com>
Message-ID: <w1EMwAkqSjKSVoOYT7K0GB5vnpsvb-c0iNTmF7cRGvA=.bd365ba3-2de7-44d7-baa9-e856bbcbadec@github.com>

On Fri, 9 Dec 2022 14:17:24 GMT, Bernhard Urban-Forster <burban at openjdk.org> wrote:

> The change in [JDK-8283415](https://bugs.openjdk.org/browse/JDK-8283415) made use of the now available `sealed` keyword for `FinalReference<T>`.
> 
> Unfortunately this introduced a problem for the Espresso VM (Java on Truffle): Since Espresso is written in Java it uses the functionality of the "Host VM" to implement finalization. It does that however by [introducing a new subclass of `FinalReference<T>`](https://github.com/oracle/graal/blob/f195395329fba573afc6f81c5e70a18ac334dd10/espresso/src/com.oracle.truffle.espresso/src/com/oracle/truffle/espresso/ref/ClassAssembler.java#L85-L113) which does not work anymore with the changes made in JDK-8283415. We cannot use `Finalizer` itself because we want to inject an additional "Guest object".
> 
> Making `FinalReference<T>` `non-sealed` would simplify things for Espresso. Before pursuing other more involved solutions I thought I would ask how strongly the maintainers of core-libs feel about such a change. Would that be okay? Are there any implications for the GC for such a change?

It's unfortunate that Espresso has been extending this JDK internal class but the sealing of the Reference class hierarchy, and not reverting it to be open via a JDK internal class, is good for platform integrity and security. It would be shame to change that as it amounts to making this class be a kind of supported interface. It's a slippery slope. If this change goes in then it will be difficult to refuse PRs from other projects that want to extend classes in other sealed hierarchies.

-------------

PR: https://git.openjdk.org/jdk/pull/11610

From aph at openjdk.org  Fri Dec  9 19:39:27 2022
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 9 Dec 2022 19:39:27 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer
In-Reply-To: <8hgyPlQ0YEyVTZBXJyc3Fc1FjSX4HyraPIXUAhJUIA4=.ac744f48-66c2-4147-9b5e-bb0a585ae087@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <xijbR1IXc535oh1-sA3u72LFoYng1ly60-rGFGUtOoc=.f7ecc5c7-165b-49d5-bb0d-7467c26f5a6d@github.com>
 <8hgyPlQ0YEyVTZBXJyc3Fc1FjSX4HyraPIXUAhJUIA4=.ac744f48-66c2-4147-9b5e-bb0a585ae087@github.com>
Message-ID: <iEpo4m89w3Fx2gpEG-wNbDRGIl9QqBuWQYEKA2atRd8=.cc69cf15-2b06-43fa-86bc-edb1543201a0@github.com>

On Fri, 9 Dec 2022 14:16:19 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> > What version of GCC are you using?
> 
> gcc 11.3 with libubsan 11.2
> 
> Also it seem to big overlap with -Wcast-align(=strict) for the warnings/errors I see and I do like that warning. Do you have an idea if the coverage are pretty much the same for this particular warning? I.e. is anyone of them better than the other?

You can't really compare them because Undefined Behaviour is a runtime thing rather than a compile-time thing. Something like `x = *(char*)0;` is legal in a conforming C++ program as long as it's never executed.

I vastly prefer UB Sanitizer because it detects a ton of stuff that static analysis can't. But there's plenty of room for both.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From aph at openjdk.org  Fri Dec  9 19:39:33 2022
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 9 Dec 2022 19:39:33 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer
In-Reply-To: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
Message-ID: <hWKrRZ27eqEYsJ9o44iVDoW8XQ1RdcIzoJq5o9LoGJ8=.13981c67-1a4d-4029-973a-5ad53eb4f968@github.com>

On Fri, 9 Dec 2022 06:53:31 GMT, Justin King <jcking at openjdk.org> wrote:

> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.

I'm really pleased to see this.

Im working on https://github.com/openjdk/jdk/pull/10920, which fixes the last of the null pointer dereferences in x86/AArch64 HotSpot. Once that's done I'm thinking of enabling `-fsanitize=null` by default in debug builds, as long as it's not too slow.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From naoto at openjdk.org  Fri Dec  9 20:05:34 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 Dec 2022 20:05:34 GMT
Subject: [jdk20] RFR: 8297288: Example code in Scanner class
Message-ID: <wlEAB8pPH6CaWYMIyY53_vhnLQfFfe1itTbolWbbMA0=.90919c01-4984-40a7-8526-41d0b64b3889@github.com>

The example in `Scanner` directly uses `System.in` which may cause unwanted behavior when the default charset and the console charset differ. Using `Console.reader()` is more appropriate. Also changed examples into snippets.

-------------

Commit messages:
 - 8297288: Example code in Scanner class

Changes: https://git.openjdk.org/jdk20/pull/14/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=14&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297288
  Stats: 15 lines in 1 file changed: 3 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk20/pull/14.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/14/head:pull/14

PR: https://git.openjdk.org/jdk20/pull/14

From jlaskey at openjdk.org  Fri Dec  9 20:17:08 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 9 Dec 2022 20:17:08 GMT
Subject: [jdk20] RFR: 8297288: Example code in Scanner class
In-Reply-To: <wlEAB8pPH6CaWYMIyY53_vhnLQfFfe1itTbolWbbMA0=.90919c01-4984-40a7-8526-41d0b64b3889@github.com>
References: <wlEAB8pPH6CaWYMIyY53_vhnLQfFfe1itTbolWbbMA0=.90919c01-4984-40a7-8526-41d0b64b3889@github.com>
Message-ID: <Zyc13s87rqUktMrUxhHmGUelB3l1VKQYaaIl7jASFOY=.42771858-9b80-40b3-8f78-ff42f0bd3b4f@github.com>

On Fri, 9 Dec 2022 18:32:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The example in `Scanner` directly uses `System.in` which may cause unwanted behavior when the default charset and the console charset differ. Using `Console.reader()` is more appropriate. Also changed examples into snippets.

CSR?

-------------

PR: https://git.openjdk.org/jdk20/pull/14

From erikj at openjdk.org  Fri Dec  9 20:43:09 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 9 Dec 2022 20:43:09 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer
In-Reply-To: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
Message-ID: <s4KD6eRy3aPeYdfJ0y5ddHN1JaEd_vUVJ_gBYt68xoo=.ca06d5e9-6ff6-46cc-8d58-a2db7db73f40@github.com>

On Fri, 9 Dec 2022 06:53:31 GMT, Justin King <jcking at openjdk.org> wrote:

> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From erikj at openjdk.org  Fri Dec  9 20:43:12 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 9 Dec 2022 20:43:12 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer
In-Reply-To: <-1gzjFB0pjbXBXsKVQv4z0-ZSO7ZhOgPHHn4A-ix7tw=.64b4fb3d-5d8e-4450-9428-ca086cc5d3aa@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <-1gzjFB0pjbXBXsKVQv4z0-ZSO7ZhOgPHHn4A-ix7tw=.64b4fb3d-5d8e-4450-9428-ca086cc5d3aa@github.com>
Message-ID: <J-iYcVYMBl2Ub-HohIii7v7yPPG7w9Dp1i40SpAD8TY=.1cd821c5-9318-4b62-920b-3ece28047704@github.com>

On Fri, 9 Dec 2022 14:34:37 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.
>
> make/autoconf/jdk-options.m4 line 450:
> 
>> 448: ###############################################################################
>> 449: #
>> 450: # UndefinedBehaviorSanitizer
> 
> I think this logic fits better in `flags.m4`, otherwise this looks ok to me.

Ah now I understand that this compiles runtime checks into the product. In that case it does actually fit well into jdk-options.m4, so you can leave it there.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From naoto at openjdk.org  Fri Dec  9 21:10:33 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 Dec 2022 21:10:33 GMT
Subject: [jdk20] RFR: 8297288: Example code in Scanner class
In-Reply-To: <wlEAB8pPH6CaWYMIyY53_vhnLQfFfe1itTbolWbbMA0=.90919c01-4984-40a7-8526-41d0b64b3889@github.com>
References: <wlEAB8pPH6CaWYMIyY53_vhnLQfFfe1itTbolWbbMA0=.90919c01-4984-40a7-8526-41d0b64b3889@github.com>
Message-ID: <kFVFC6nm2fNO9fK5jcIj615Lx3SQYo9gzQ7GCrPmz28=.042f8394-4d5c-45b3-ab65-61ed9735e7d9@github.com>

On Fri, 9 Dec 2022 18:32:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The example in `Scanner` directly uses `System.in` which may cause unwanted behavior when the default charset and the console charset differ. Using `Console.reader()` is more appropriate. Also changed examples into snippets.

Does it require a CSR? I thought modifying the examples did not change any API/behavior thus a CSR was not needed. I am happy to file it if that's not the case.

-------------

PR: https://git.openjdk.org/jdk20/pull/14

From lancea at openjdk.org  Fri Dec  9 21:17:15 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 9 Dec 2022 21:17:15 GMT
Subject: [jdk20] RFR: 8297288: Example code in Scanner class
In-Reply-To: <wlEAB8pPH6CaWYMIyY53_vhnLQfFfe1itTbolWbbMA0=.90919c01-4984-40a7-8526-41d0b64b3889@github.com>
References: <wlEAB8pPH6CaWYMIyY53_vhnLQfFfe1itTbolWbbMA0=.90919c01-4984-40a7-8526-41d0b64b3889@github.com>
Message-ID: <Cllb5fUCnKsnwIVpt6IqbaxiL65j3YTuDsZUFpO9BRM=.4682182d-5632-4219-8ac1-2f5828797101@github.com>

On Fri, 9 Dec 2022 18:32:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The example in `Scanner` directly uses `System.in` which may cause unwanted behavior when the default charset and the console charset differ. Using `Console.reader()` is more appropriate. Also changed examples into snippets.

Looks good with the snippets Naoto,  I do not see a CSR being required

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/14

From bpb at openjdk.org  Fri Dec  9 21:32:42 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 9 Dec 2022 21:32:42 GMT
Subject: [jdk20] RFR: 8297288: Example code in Scanner class
In-Reply-To: <wlEAB8pPH6CaWYMIyY53_vhnLQfFfe1itTbolWbbMA0=.90919c01-4984-40a7-8526-41d0b64b3889@github.com>
References: <wlEAB8pPH6CaWYMIyY53_vhnLQfFfe1itTbolWbbMA0=.90919c01-4984-40a7-8526-41d0b64b3889@github.com>
Message-ID: <53kj431GnInMnr3ZuZjQE2E_oaGbTF1lRcxazQG1Eqo=.53dcbeac-77e6-480a-9d29-aad3cddb91e5@github.com>

On Fri, 9 Dec 2022 18:32:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The example in `Scanner` directly uses `System.in` which may cause unwanted behavior when the default charset and the console charset differ. Using `Console.reader()` is more appropriate. Also changed examples into snippets.

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk20/pull/14

From igraves at openjdk.org  Fri Dec  9 21:51:26 2022
From: igraves at openjdk.org (Ian Graves)
Date: Fri, 9 Dec 2022 21:51:26 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's --compress
 option
Message-ID: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>

This is an approach to adding a flag to jlink that will allow --compress to take the same types of arguments as jmod, thus bringing the two into alignment. This likely requires a CSR and a discussion on whether we should deprecate or simply remove the original numeric compression arguments.

-------------

Commit messages:
 - 8293667: Align jlink's --compress option with jmod's --compress option

Changes: https://git.openjdk.org/jdk/pull/11617/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11617&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293667
  Stats: 95 lines in 5 files changed: 87 ins; 3 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/11617.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11617/head:pull/11617

PR: https://git.openjdk.org/jdk/pull/11617

From jlaskey at openjdk.org  Fri Dec  9 22:39:52 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 9 Dec 2022 22:39:52 GMT
Subject: [jdk20] RFR: 8297288: Example code in Scanner class
In-Reply-To: <wlEAB8pPH6CaWYMIyY53_vhnLQfFfe1itTbolWbbMA0=.90919c01-4984-40a7-8526-41d0b64b3889@github.com>
References: <wlEAB8pPH6CaWYMIyY53_vhnLQfFfe1itTbolWbbMA0=.90919c01-4984-40a7-8526-41d0b64b3889@github.com>
Message-ID: <sufMe4UAgoYUk1V2sIcPQ09qzQACaB8lTmTXfcE1wAE=.e471f374-4b5a-49f2-a45d-c4317f010ffa@github.com>

On Fri, 9 Dec 2022 18:32:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The example in `Scanner` directly uses `System.in` which may cause unwanted behavior when the default charset and the console charset differ. Using `Console.reader()` is more appropriate. Also changed examples into snippets.

You're changing the example because of a change in behaviour. If that change is covered elsewhere, no issue.

-------------

PR: https://git.openjdk.org/jdk20/pull/14

From naoto at openjdk.org  Fri Dec  9 23:04:01 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 Dec 2022 23:04:01 GMT
Subject: [jdk20] RFR: 8297288: Example code in Scanner class
In-Reply-To: <wlEAB8pPH6CaWYMIyY53_vhnLQfFfe1itTbolWbbMA0=.90919c01-4984-40a7-8526-41d0b64b3889@github.com>
References: <wlEAB8pPH6CaWYMIyY53_vhnLQfFfe1itTbolWbbMA0=.90919c01-4984-40a7-8526-41d0b64b3889@github.com>
Message-ID: <m2GwP1XJOL7uU5dryi0kFXxcRXk6LPzFQUC6e8O3AUU=.9c515220-5047-4449-8bc4-38dfa9d07cdc@github.com>

On Fri, 9 Dec 2022 18:32:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The example in `Scanner` directly uses `System.in` which may cause unwanted behavior when the default charset and the console charset differ. Using `Console.reader()` is more appropriate. Also changed examples into snippets.

Yes. This issue stems from [JEP 400](https://openjdk.org/jeps/400) that went into JDK18 where spec/behavior changes are all described.

-------------

PR: https://git.openjdk.org/jdk20/pull/14

From alanb at openjdk.org  Sat Dec 10 08:18:01 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 10 Dec 2022 08:18:01 GMT
Subject: [jdk20] RFR: 8297288: Example code in Scanner class
In-Reply-To: <wlEAB8pPH6CaWYMIyY53_vhnLQfFfe1itTbolWbbMA0=.90919c01-4984-40a7-8526-41d0b64b3889@github.com>
References: <wlEAB8pPH6CaWYMIyY53_vhnLQfFfe1itTbolWbbMA0=.90919c01-4984-40a7-8526-41d0b64b3889@github.com>
Message-ID: <WMPWVP-OmuzruuotmbQ_knCORWiaQcwxeYmNYSJHjwE=.d95cd83a-615e-4c00-be40-31a027e26761@github.com>

On Fri, 9 Dec 2022 18:32:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The example in `Scanner` directly uses `System.in` which may cause unwanted behavior when the default charset and the console charset differ. Using `Console.reader()` is more appropriate. Also changed examples into snippets.

src/java.base/share/classes/java/util/Scanner.java line 58:

> 56:  *     var con = System.console();
> 57:  *     if (con != null) {
> 58:  *         Scanner sc = new Scanner(con.reader()); // @link substring="reader()" target="java.io.Console#reader()"

The link tag can be put on the previous line if you want. It just requires terminating it with a colon (":"). I've found that useful in a few places.

-------------

PR: https://git.openjdk.org/jdk20/pull/14

From stuefe at openjdk.org  Sun Dec 11 08:11:51 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sun, 11 Dec 2022 08:11:51 GMT
Subject: RFR: JDK-8296360: Track native memory used by zlib via NMT
In-Reply-To: <WW7_ad6YUZQ26hrK4idngOcwkotxiJr1PAyfP29Lj64=.5779f834-b617-4295-b69e-c37c796f5268@github.com>
References: <WW7_ad6YUZQ26hrK4idngOcwkotxiJr1PAyfP29Lj64=.5779f834-b617-4295-b69e-c37c796f5268@github.com>
Message-ID: <xhsyZ2MDoNmiagKhpZ9NiuCJAmLn3e_taiKD-FrZvOM=.2f610488-8c37-4774-b89e-b9f3118b0348@github.com>

On Fri, 4 Nov 2022 14:35:00 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> This patch adds NMT tracking to the zlib.
> 
> *Please note: we currently discuss whether NMT can be expanded across the JDK in this ML discussion [1]. This PR depends on the outcome of that discussion and won't proceed unless greenlighted. But since [1] is stalled, I post the PR for RFR to get some feedback on the code itself and for people to try it out.*
> 
> NMT tracks hotspot native allocations but does not cover the JDK (apart from small exceptions). But the native memory
> footprint of JDK libraries can be very significant. Recently we had a customer whose zlib footprint went into the ~40GB range. We analyzed the problem with an in-house memory tracker, but things would have been a lot simpler using NMT.
> 
> This patch instruments the zlib via zalloc hooks, which is minimally invasive. It does not touch zlib sources, so it works with both the bundled zlib and system zlib. All the instrumentation happens in the JVM zlib wrapper.
> 
> 
> -         j.u.zip (deflate) (reserved=624, committed=624)
>                             (malloc=624 #3) 
>  
> -         j.u.zip (inflate) (reserved=221377904, committed=221377904)
>                             (malloc=221377904 #60877) 
>  
> -               Zip (other) (reserved=8163446896, committed=8163446896)
>                             (malloc=8163446896 #182622) 
> 
> 
> [1] https://mail.openjdk.org/pipermail/core-libs-dev/2022-November/096197.html

Withdrawing for now; let's see how our discussion goes.

-------------

PR: https://git.openjdk.org/jdk/pull/10988

From dholmes at openjdk.org  Mon Dec 12 01:35:36 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 12 Dec 2022 01:35:36 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer
In-Reply-To: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
Message-ID: <tmU5uPfR7KHGP8b8c_q7HM8s5l7P0mOuLYhjC63WwNk=.0e6e317e-dd54-4623-9a42-199ea4feb4aa@github.com>

On Fri, 9 Dec 2022 06:53:31 GMT, Justin King <jcking at openjdk.org> wrote:

> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.

I think it requires much broader discussion as to whether OpenJDK is actively seen to endorse these tools. Why these tools? What if there are other tools, should we support them all?

I'm not saying use of these tools may not be useful, but actually incorporating them into OpenJDK is a decision that needs to be made at a higher-level IMO.

make/autoconf/spec.gmk.in line 459:

> 457: 
> 458: # UndefinedBehaviorSanitizer
> 459: UBSAN_ENABLED:=@UBSAN_ENABLED@

I don't see anything reading this. ??

src/java.base/share/native/launcher/main.c line 37:

> 35: #include "jni.h"
> 36: 
> 37: #ifdef UNDEFINED_BEHAVIOR_SANITIZER

I really do not like having to make source code changes to accommodate these kinds of tools.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From jcking at openjdk.org  Mon Dec 12 03:28:35 2022
From: jcking at openjdk.org (Justin King)
Date: Mon, 12 Dec 2022 03:28:35 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer
In-Reply-To: <tmU5uPfR7KHGP8b8c_q7HM8s5l7P0mOuLYhjC63WwNk=.0e6e317e-dd54-4623-9a42-199ea4feb4aa@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <tmU5uPfR7KHGP8b8c_q7HM8s5l7P0mOuLYhjC63WwNk=.0e6e317e-dd54-4623-9a42-199ea4feb4aa@github.com>
Message-ID: <_8qXKqSPn7qlnUYd8VIHqjzeM5JI1Lmvm86oxwRY-D0=.2909feb0-5ad7-4a80-bbc4-5effbebfea5d@github.com>

On Mon, 12 Dec 2022 01:31:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I think it requires much broader discussion as to whether OpenJDK is actively seen to endorse these tools. Why these tools? What if there are other tools, should we support them all?
> 
> I'm not saying use of these tools may not be useful, but actually incorporating them into OpenJDK is a decision that needs to be made at a higher-level IMO.

The sanitizers are integrated directly with GCC and Clang/LLVM and are used by projects such as the Linux kernel. They are also used by companies such as Facebook and Google, which IIRC maintain some of the largest closed source mono repositories on the planet. As the sanitizers are integrated directly with GCC and Clang/LLVM, they are extremely easy to use (no external dependencies), fast, and have no direct alternatives. An alternative would also need to be integrated with the compilers in order to be at par.

Additionally configuration options for using ASan already exist in OpenJDK, so that ship has kinda sailed.

If we feel strongly about a discussion, we should probably discuss all the sanitizers as a whole. However that discussion can be done in parallel, as ASan is already used. Just adding the options to OpenJDK does not mean it is endorsed.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From dholmes at openjdk.org  Mon Dec 12 04:37:32 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 12 Dec 2022 04:37:32 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer
In-Reply-To: <_8qXKqSPn7qlnUYd8VIHqjzeM5JI1Lmvm86oxwRY-D0=.2909feb0-5ad7-4a80-bbc4-5effbebfea5d@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <tmU5uPfR7KHGP8b8c_q7HM8s5l7P0mOuLYhjC63WwNk=.0e6e317e-dd54-4623-9a42-199ea4feb4aa@github.com>
 <_8qXKqSPn7qlnUYd8VIHqjzeM5JI1Lmvm86oxwRY-D0=.2909feb0-5ad7-4a80-bbc4-5effbebfea5d@github.com>
Message-ID: <XYFshtUdmoHp1bgJPuWEnygskSFPx2TPiqliHi0E5Nc=.48573980-ba7e-4adc-be1c-001d4d7f2a30@github.com>

On Mon, 12 Dec 2022 03:26:15 GMT, Justin King <jcking at openjdk.org> wrote:

>> I think it requires much broader discussion as to whether OpenJDK is actively seen to endorse these tools. Why these tools? What if there are other tools, should we support them all?
>> 
>> I'm not saying use of these tools may not be useful, but actually incorporating them into OpenJDK is a decision that needs to be made at a higher-level IMO.
>
>> I think it requires much broader discussion as to whether OpenJDK is actively seen to endorse these tools. Why these tools? What if there are other tools, should we support them all?
>> 
>> I'm not saying use of these tools may not be useful, but actually incorporating them into OpenJDK is a decision that needs to be made at a higher-level IMO.
> 
> The sanitizers are integrated directly with GCC and Clang/LLVM and are used by projects such as the Linux kernel. They are also used by companies such as Facebook and Google, which IIRC maintain some of the largest closed source mono repositories on the planet. As the sanitizers are integrated directly with GCC and Clang/LLVM, they are extremely easy to use (no external dependencies), fast, and have no direct alternatives. An alternative would also need to be integrated with the compilers in order to be at par.
> 
> Additionally configuration options for using ASan already exist in OpenJDK, so that ship has kinda sailed.
> 
> If we feel strongly about a discussion, we should probably discuss all the sanitizers as a whole. However that discussion can be done in parallel, as ASan is already used. Just adding the options to OpenJDK does not mean it is endorsed.

@jcking this is not ready for integration. You have one review from build team. You have no reviews from core-libs for launcher change. You haven't even bothered to address the comments I made on the actual changes.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From dholmes at openjdk.org  Mon Dec 12 05:05:39 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 12 Dec 2022 05:05:39 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer
In-Reply-To: <tmU5uPfR7KHGP8b8c_q7HM8s5l7P0mOuLYhjC63WwNk=.0e6e317e-dd54-4623-9a42-199ea4feb4aa@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <tmU5uPfR7KHGP8b8c_q7HM8s5l7P0mOuLYhjC63WwNk=.0e6e317e-dd54-4623-9a42-199ea4feb4aa@github.com>
Message-ID: <ePEek-jMaxReYZRKmTpyJc7fC-kTquaX8Eu_ofYVCYU=.ec9a3949-18d8-4c56-b32c-3c18045dbec7@github.com>

On Mon, 12 Dec 2022 01:27:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.
>
> make/autoconf/spec.gmk.in line 459:
> 
>> 457: 
>> 458: # UndefinedBehaviorSanitizer
>> 459: UBSAN_ENABLED:=@UBSAN_ENABLED@
> 
> I don't see anything reading this. ??

To be clear there was a reason that `ASAN_ENABLED` was originally added to spec.gmk.in (though there was a suggestion it could/would be removed later), and no reason has been given for `UBSAN_ENABLED` being needed.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From dholmes at openjdk.org  Mon Dec 12 05:10:14 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 12 Dec 2022 05:10:14 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer
In-Reply-To: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
Message-ID: <KVFEXaUQcczH-8pbmezDTGJ076YCfBEpxwRv4wr1w6I=.3d57d578-688f-48a0-bf28-bade1cc2aa3f@github.com>

On Fri, 9 Dec 2022 06:53:31 GMT, Justin King <jcking at openjdk.org> wrote:

> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.

src/java.base/share/native/launcher/main.c line 40:

> 38: // Override weak symbol exposed by UBSan to override default options. This is called by UBSan
> 39: // extremely early during library loading, before main is called.
> 40: JNIEXPORT const char* __ubsan_default_options() {

Why would this need `JNIEXPORT`? This is not a JNI function.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From jcking at openjdk.org  Mon Dec 12 05:59:19 2022
From: jcking at openjdk.org (Justin King)
Date: Mon, 12 Dec 2022 05:59:19 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v2]
In-Reply-To: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
Message-ID: <ihU4CnQqnCAuMg3S7Y4317dFbX4pB6F4b8yfhPQATIg=.5d49ef0d-8b72-45c8-9d3d-728ca601c7d2@github.com>

> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Remove UBSAN_ENABLED From spec.gmk.in

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11604/files
  - new: https://git.openjdk.org/jdk/pull/11604/files/d878ede0..6f8c8394

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11604&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11604&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11604.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11604/head:pull/11604

PR: https://git.openjdk.org/jdk/pull/11604

From jcking at openjdk.org  Mon Dec 12 05:59:20 2022
From: jcking at openjdk.org (Justin King)
Date: Mon, 12 Dec 2022 05:59:20 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v2]
In-Reply-To: <_8qXKqSPn7qlnUYd8VIHqjzeM5JI1Lmvm86oxwRY-D0=.2909feb0-5ad7-4a80-bbc4-5effbebfea5d@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <tmU5uPfR7KHGP8b8c_q7HM8s5l7P0mOuLYhjC63WwNk=.0e6e317e-dd54-4623-9a42-199ea4feb4aa@github.com>
 <_8qXKqSPn7qlnUYd8VIHqjzeM5JI1Lmvm86oxwRY-D0=.2909feb0-5ad7-4a80-bbc4-5effbebfea5d@github.com>
Message-ID: <Er3yNHxfm1JpHejPt-fITtb-SIM2MBXs5gHdCvRL28k=.98b6bf62-cd29-4790-a6d0-20d3e915e6da@github.com>

On Mon, 12 Dec 2022 03:26:15 GMT, Justin King <jcking at openjdk.org> wrote:

>> I think it requires much broader discussion as to whether OpenJDK is actively seen to endorse these tools. Why these tools? What if there are other tools, should we support them all?
>> 
>> I'm not saying use of these tools may not be useful, but actually incorporating them into OpenJDK is a decision that needs to be made at a higher-level IMO.
>
>> I think it requires much broader discussion as to whether OpenJDK is actively seen to endorse these tools. Why these tools? What if there are other tools, should we support them all?
>> 
>> I'm not saying use of these tools may not be useful, but actually incorporating them into OpenJDK is a decision that needs to be made at a higher-level IMO.
> 
> The sanitizers are integrated directly with GCC and Clang/LLVM and are used by projects such as the Linux kernel. They are also used by companies such as Facebook and Google, which IIRC maintain some of the largest closed source mono repositories on the planet. As the sanitizers are integrated directly with GCC and Clang/LLVM, they are extremely easy to use (no external dependencies), fast, and have no direct alternatives. An alternative would also need to be integrated with the compilers in order to be at par.
> 
> Additionally configuration options for using ASan already exist in OpenJDK, so that ship has kinda sailed.
> 
> If we feel strongly about a discussion, we should probably discuss all the sanitizers as a whole. However that discussion can be done in parallel, as ASan is already used. Just adding the options to OpenJDK does not mean it is endorsed.

> @jcking this is not ready for integration. You have one review from build team. You have no reviews from core-libs for launcher change. 

Added reviewers to be 2. I had assumed the bot would take care of getting reviews from both. Apparently it does not, will keep that in mind going forward.

> You haven't even bothered to address the comments I made on the actual changes.

I addressed the comments after integrate, my bad.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From jcking at openjdk.org  Mon Dec 12 05:59:20 2022
From: jcking at openjdk.org (Justin King)
Date: Mon, 12 Dec 2022 05:59:20 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v2]
In-Reply-To: <Er3yNHxfm1JpHejPt-fITtb-SIM2MBXs5gHdCvRL28k=.98b6bf62-cd29-4790-a6d0-20d3e915e6da@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <tmU5uPfR7KHGP8b8c_q7HM8s5l7P0mOuLYhjC63WwNk=.0e6e317e-dd54-4623-9a42-199ea4feb4aa@github.com>
 <_8qXKqSPn7qlnUYd8VIHqjzeM5JI1Lmvm86oxwRY-D0=.2909feb0-5ad7-4a80-bbc4-5effbebfea5d@github.com>
 <Er3yNHxfm1JpHejPt-fITtb-SIM2MBXs5gHdCvRL28k=.98b6bf62-cd29-4790-a6d0-20d3e915e6da@github.com>
Message-ID: <D1HSkBXcHKALqQcU6VDpwcQTFZazfghekWPgKg5A-II=.69fb2f38-469e-4ae1-a436-11c3952b9426@github.com>

On Mon, 12 Dec 2022 05:48:41 GMT, Justin King <jcking at openjdk.org> wrote:

>>> I think it requires much broader discussion as to whether OpenJDK is actively seen to endorse these tools. Why these tools? What if there are other tools, should we support them all?
>>> 
>>> I'm not saying use of these tools may not be useful, but actually incorporating them into OpenJDK is a decision that needs to be made at a higher-level IMO.
>> 
>> The sanitizers are integrated directly with GCC and Clang/LLVM and are used by projects such as the Linux kernel. They are also used by companies such as Facebook and Google, which IIRC maintain some of the largest closed source mono repositories on the planet. As the sanitizers are integrated directly with GCC and Clang/LLVM, they are extremely easy to use (no external dependencies), fast, and have no direct alternatives. An alternative would also need to be integrated with the compilers in order to be at par.
>> 
>> Additionally configuration options for using ASan already exist in OpenJDK, so that ship has kinda sailed.
>> 
>> If we feel strongly about a discussion, we should probably discuss all the sanitizers as a whole. However that discussion can be done in parallel, as ASan is already used. Just adding the options to OpenJDK does not mean it is endorsed.
>
>> @jcking this is not ready for integration. You have one review from build team. You have no reviews from core-libs for launcher change. 
> 
> Added reviewers to be 2. I had assumed the bot would take care of getting reviews from both. Apparently it does not, will keep that in mind going forward.
> 
>> You haven't even bothered to address the comments I made on the actual changes.
> 
> I addressed the comments after integrate, my bad.

> @jcking this is not ready for integration. You have one review from build team. You have no reviews from core-libs for launcher change. You haven't even bothered to address the comments I made on the actual changes.

Okay, I am dumb. I clicked resolve conversation and assumed it would auto add my comment. Apparently it just drops it and resolves it without saying anything. Sorry!

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From jcking at openjdk.org  Mon Dec 12 05:59:23 2022
From: jcking at openjdk.org (Justin King)
Date: Mon, 12 Dec 2022 05:59:23 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v2]
In-Reply-To: <ePEek-jMaxReYZRKmTpyJc7fC-kTquaX8Eu_ofYVCYU=.ec9a3949-18d8-4c56-b32c-3c18045dbec7@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <tmU5uPfR7KHGP8b8c_q7HM8s5l7P0mOuLYhjC63WwNk=.0e6e317e-dd54-4623-9a42-199ea4feb4aa@github.com>
 <ePEek-jMaxReYZRKmTpyJc7fC-kTquaX8Eu_ofYVCYU=.ec9a3949-18d8-4c56-b32c-3c18045dbec7@github.com>
Message-ID: <b1uM77s86ceWNFWRtBc39rQRmizk5QWEl_AF_8bMFgw=.103c2f18-be5c-402a-b28f-11db8ef553a9@github.com>

On Mon, 12 Dec 2022 05:02:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> make/autoconf/spec.gmk.in line 459:
>> 
>>> 457: 
>>> 458: # UndefinedBehaviorSanitizer
>>> 459: UBSAN_ENABLED:=@UBSAN_ENABLED@
>> 
>> I don't see anything reading this. ??
>
> To be clear there was a reason that `ASAN_ENABLED` was originally added to spec.gmk.in (though there was a suggestion it could/would be removed later), and no reason has been given for `UBSAN_ENABLED` being needed.

Fair. I'll remove it. My previous comment, that I dropped on the floor, was asking about that basically.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From jcking at openjdk.org  Mon Dec 12 05:59:26 2022
From: jcking at openjdk.org (Justin King)
Date: Mon, 12 Dec 2022 05:59:26 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v2]
In-Reply-To: <tmU5uPfR7KHGP8b8c_q7HM8s5l7P0mOuLYhjC63WwNk=.0e6e317e-dd54-4623-9a42-199ea4feb4aa@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <tmU5uPfR7KHGP8b8c_q7HM8s5l7P0mOuLYhjC63WwNk=.0e6e317e-dd54-4623-9a42-199ea4feb4aa@github.com>
Message-ID: <71ZbJnityJDhL_jBswDDpqj0jelx3wGy8pNJDMs-XyM=.37ccf135-7801-4c4f-bdbb-d47903bd8d1f@github.com>

On Mon, 12 Dec 2022 01:29:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Justin King has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove UBSAN_ENABLED From spec.gmk.in
>
> src/java.base/share/native/launcher/main.c line 37:
> 
>> 35: #include "jni.h"
>> 36: 
>> 37: #ifdef UNDEFINED_BEHAVIOR_SANITIZER
> 
> I really do not like having to make source code changes to accommodate these kinds of tools.

Yeah, it is unfortunate. However there is no other way to actually set the defaults nicely. The other alternative is to use environment variables, but they are easy to forget when invoking the launcher manually.

> src/java.base/share/native/launcher/main.c line 40:
> 
>> 38: // Override weak symbol exposed by UBSan to override default options. This is called by UBSan
>> 39: // extremely early during library loading, before main is called.
>> 40: JNIEXPORT const char* __ubsan_default_options() {
> 
> Why would this need `JNIEXPORT`? This is not a JNI function.

Ugh, apparently resolving doesn't add the comment. I thought it did...

So answering, JNIEXPORT is needed so that the symbol is exported and the linker doesn't remove it. It adds `__attribute__((visibility("default"))`.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From jcking at openjdk.org  Mon Dec 12 06:01:39 2022
From: jcking at openjdk.org (Justin King)
Date: Mon, 12 Dec 2022 06:01:39 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v2]
In-Reply-To: <XYFshtUdmoHp1bgJPuWEnygskSFPx2TPiqliHi0E5Nc=.48573980-ba7e-4adc-be1c-001d4d7f2a30@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <tmU5uPfR7KHGP8b8c_q7HM8s5l7P0mOuLYhjC63WwNk=.0e6e317e-dd54-4623-9a42-199ea4feb4aa@github.com>
 <_8qXKqSPn7qlnUYd8VIHqjzeM5JI1Lmvm86oxwRY-D0=.2909feb0-5ad7-4a80-bbc4-5effbebfea5d@github.com>
 <XYFshtUdmoHp1bgJPuWEnygskSFPx2TPiqliHi0E5Nc=.48573980-ba7e-4adc-be1c-001d4d7f2a30@github.com>
Message-ID: <apGPy1GYYipH7wjQS4R0dDKliz9_u3H58Ke6rN9bZVE=.e0027671-e02e-444b-9b11-9a166a40dda1@github.com>

On Mon, 12 Dec 2022 04:34:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> I think it requires much broader discussion as to whether OpenJDK is actively seen to endorse these tools. Why these tools? What if there are other tools, should we support them all?
>>> 
>>> I'm not saying use of these tools may not be useful, but actually incorporating them into OpenJDK is a decision that needs to be made at a higher-level IMO.
>> 
>> The sanitizers are integrated directly with GCC and Clang/LLVM and are used by projects such as the Linux kernel. They are also used by companies such as Facebook and Google, which IIRC maintain some of the largest closed source mono repositories on the planet. As the sanitizers are integrated directly with GCC and Clang/LLVM, they are extremely easy to use (no external dependencies), fast, and have no direct alternatives. An alternative would also need to be integrated with the compilers in order to be at par.
>> 
>> Additionally configuration options for using ASan already exist in OpenJDK, so that ship has kinda sailed.
>> 
>> If we feel strongly about a discussion, we should probably discuss all the sanitizers as a whole. However that discussion can be done in parallel, as ASan is already used. Just adding the options to OpenJDK does not mean it is endorsed.
>
> @jcking this is not ready for integration. You have one review from build team. You have no reviews from core-libs for launcher change. You haven't even bothered to address the comments I made on the actual changes.

@dholmes-ora Also etiquette-wise, is it preferred that the commenter resolve the conversation or the author, and the commenter re-open if they feel it is not resolved? I am used to latter workflow, but OpenJDK might have different expectations and I'd like to follow them.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From dholmes at openjdk.org  Mon Dec 12 06:52:38 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 12 Dec 2022 06:52:38 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v2]
In-Reply-To: <XYFshtUdmoHp1bgJPuWEnygskSFPx2TPiqliHi0E5Nc=.48573980-ba7e-4adc-be1c-001d4d7f2a30@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <tmU5uPfR7KHGP8b8c_q7HM8s5l7P0mOuLYhjC63WwNk=.0e6e317e-dd54-4623-9a42-199ea4feb4aa@github.com>
 <_8qXKqSPn7qlnUYd8VIHqjzeM5JI1Lmvm86oxwRY-D0=.2909feb0-5ad7-4a80-bbc4-5effbebfea5d@github.com>
 <XYFshtUdmoHp1bgJPuWEnygskSFPx2TPiqliHi0E5Nc=.48573980-ba7e-4adc-be1c-001d4d7f2a30@github.com>
Message-ID: <a5Unk89fuidR1D_Ff90x_Ug5LxKAbTDO3FENugjjc-U=.d03963cc-2868-4e7c-87c3-0d3017ba501b@github.com>

On Mon, 12 Dec 2022 04:34:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> I think it requires much broader discussion as to whether OpenJDK is actively seen to endorse these tools. Why these tools? What if there are other tools, should we support them all?
>>> 
>>> I'm not saying use of these tools may not be useful, but actually incorporating them into OpenJDK is a decision that needs to be made at a higher-level IMO.
>> 
>> The sanitizers are integrated directly with GCC and Clang/LLVM and are used by projects such as the Linux kernel. They are also used by companies such as Facebook and Google, which IIRC maintain some of the largest closed source mono repositories on the planet. As the sanitizers are integrated directly with GCC and Clang/LLVM, they are extremely easy to use (no external dependencies), fast, and have no direct alternatives. An alternative would also need to be integrated with the compilers in order to be at par.
>> 
>> Additionally configuration options for using ASan already exist in OpenJDK, so that ship has kinda sailed.
>> 
>> If we feel strongly about a discussion, we should probably discuss all the sanitizers as a whole. However that discussion can be done in parallel, as ASan is already used. Just adding the options to OpenJDK does not mean it is endorsed.
>
> @jcking this is not ready for integration. You have one review from build team. You have no reviews from core-libs for launcher change. You haven't even bothered to address the comments I made on the actual changes.

> @dholmes-ora Also etiquette-wise, is it preferred that the commenter resolve the conversation or the author, and the commenter re-open if they feel it is not resolved? I am used to latter workflow, but OpenJDK might have different expectations and I'd like to follow them.

I'm not aware of any specific guidelines. Many people don't even bother with resolving conversations. To me it depends on the nature of the comments as to who should decide if the matter is resolved or not.  It is also unclear of commenting on a "resolved" conversation actually unresolves it again. I don't see an "unresolve" button.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From dholmes at openjdk.org  Mon Dec 12 06:52:41 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 12 Dec 2022 06:52:41 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v2]
In-Reply-To: <71ZbJnityJDhL_jBswDDpqj0jelx3wGy8pNJDMs-XyM=.37ccf135-7801-4c4f-bdbb-d47903bd8d1f@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <tmU5uPfR7KHGP8b8c_q7HM8s5l7P0mOuLYhjC63WwNk=.0e6e317e-dd54-4623-9a42-199ea4feb4aa@github.com>
 <71ZbJnityJDhL_jBswDDpqj0jelx3wGy8pNJDMs-XyM=.37ccf135-7801-4c4f-bdbb-d47903bd8d1f@github.com>
Message-ID: <_HlEJbRQuKrY0Y_BUcyuvOaX2pb08v3n5GOyjZoJagM=.b9e513ff-aaa7-4d05-a8bd-dc567ca44135@github.com>

On Mon, 12 Dec 2022 05:51:52 GMT, Justin King <jcking at openjdk.org> wrote:

>> src/java.base/share/native/launcher/main.c line 37:
>> 
>>> 35: #include "jni.h"
>>> 36: 
>>> 37: #ifdef UNDEFINED_BEHAVIOR_SANITIZER
>> 
>> I really do not like having to make source code changes to accommodate these kinds of tools.
>
> Yeah, it is unfortunate. However there is no other way to actually set the defaults nicely. The other alternative is to use environment variables, but they are easy to forget when invoking the launcher manually.

Does the env-var override the src declaration, or the other way around?

>> src/java.base/share/native/launcher/main.c line 40:
>> 
>>> 38: // Override weak symbol exposed by UBSan to override default options. This is called by UBSan
>>> 39: // extremely early during library loading, before main is called.
>>> 40: JNIEXPORT const char* __ubsan_default_options() {
>> 
>> Why would this need `JNIEXPORT`? This is not a JNI function.
>
> Ugh, apparently resolving doesn't add the comment. I thought it did...
> 
> So answering, JNIEXPORT is needed so that the symbol is exported and the linker doesn't remove it. It adds `__attribute__((visibility("default"))`.

Okay. The limited documentation on these `___xxx_default_options` functions didn't show the need for any export/visibility attributes.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From dholmes at openjdk.org  Mon Dec 12 06:52:43 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 12 Dec 2022 06:52:43 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v2]
In-Reply-To: <ihU4CnQqnCAuMg3S7Y4317dFbX4pB6F4b8yfhPQATIg=.5d49ef0d-8b72-45c8-9d3d-728ca601c7d2@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <ihU4CnQqnCAuMg3S7Y4317dFbX4pB6F4b8yfhPQATIg=.5d49ef0d-8b72-45c8-9d3d-728ca601c7d2@github.com>
Message-ID: <XfIu_0iqLmyRKBxxNvHf7Za-Vnhd_dXkjaxmzvZY8sw=.9e2964f5-9ae8-49bc-b669-e564fbe4ba41@github.com>

On Mon, 12 Dec 2022 05:59:19 GMT, Justin King <jcking at openjdk.org> wrote:

>> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove UBSAN_ENABLED From spec.gmk.in

src/java.base/share/native/launcher/main.c line 38:

> 36: 
> 37: #ifdef UNDEFINED_BEHAVIOR_SANITIZER
> 38: // Override weak symbol exposed by UBSan to override default options. This is called by UBSan

Please explain why we need to override the default options.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From jcking at openjdk.org  Mon Dec 12 07:02:04 2022
From: jcking at openjdk.org (Justin King)
Date: Mon, 12 Dec 2022 07:02:04 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v3]
In-Reply-To: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
Message-ID: <Jgz4iTse8EjQwWSoLLh2t4JdpnwX1OCloycHGKGY-o4=.620eb380-2b64-49c5-bf36-ecb6f633e35a@github.com>

> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Add comment explaining __ubsan_default_options and UBSAN_OPTIONS
  
  Signed-off-by: Justin King <jcking at google.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11604/files
  - new: https://git.openjdk.org/jdk/pull/11604/files/6f8c8394..e104ec05

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11604&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11604&range=01-02

  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11604.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11604/head:pull/11604

PR: https://git.openjdk.org/jdk/pull/11604

From jcking at openjdk.org  Mon Dec 12 07:02:04 2022
From: jcking at openjdk.org (Justin King)
Date: Mon, 12 Dec 2022 07:02:04 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v3]
In-Reply-To: <_HlEJbRQuKrY0Y_BUcyuvOaX2pb08v3n5GOyjZoJagM=.b9e513ff-aaa7-4d05-a8bd-dc567ca44135@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <tmU5uPfR7KHGP8b8c_q7HM8s5l7P0mOuLYhjC63WwNk=.0e6e317e-dd54-4623-9a42-199ea4feb4aa@github.com>
 <71ZbJnityJDhL_jBswDDpqj0jelx3wGy8pNJDMs-XyM=.37ccf135-7801-4c4f-bdbb-d47903bd8d1f@github.com>
 <_HlEJbRQuKrY0Y_BUcyuvOaX2pb08v3n5GOyjZoJagM=.b9e513ff-aaa7-4d05-a8bd-dc567ca44135@github.com>
Message-ID: <3tkWCqND697U-qIa8ilxRgX4oe00KBFDBEWwqCa9Xuw=.8390e95a-cafa-48ff-baae-8ebb0ba54ff5@github.com>

On Mon, 12 Dec 2022 06:47:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Yeah, it is unfortunate. However there is no other way to actually set the defaults nicely. The other alternative is to use environment variables, but they are easy to forget when invoking the launcher manually.
>
> Does the env-var override the src declaration, or the other way around?

UBSAN_OPTIONS overrides the src declaration. I added to the comment mentioning that.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From jcking at openjdk.org  Mon Dec 12 07:02:05 2022
From: jcking at openjdk.org (Justin King)
Date: Mon, 12 Dec 2022 07:02:05 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v2]
In-Reply-To: <XfIu_0iqLmyRKBxxNvHf7Za-Vnhd_dXkjaxmzvZY8sw=.9e2964f5-9ae8-49bc-b669-e564fbe4ba41@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <ihU4CnQqnCAuMg3S7Y4317dFbX4pB6F4b8yfhPQATIg=.5d49ef0d-8b72-45c8-9d3d-728ca601c7d2@github.com>
 <XfIu_0iqLmyRKBxxNvHf7Za-Vnhd_dXkjaxmzvZY8sw=.9e2964f5-9ae8-49bc-b669-e564fbe4ba41@github.com>
Message-ID: <ry9bV_rEDLm4vjJhhTBk-S2Ng3psUbAQrZxphF_3NaE=.17f7fec2-31d7-4220-b26a-42bde71b4dd8@github.com>

On Mon, 12 Dec 2022 06:48:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Justin King has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove UBSAN_ENABLED From spec.gmk.in
>
> src/java.base/share/native/launcher/main.c line 38:
> 
>> 36: 
>> 37: #ifdef UNDEFINED_BEHAVIOR_SANITIZER
>> 38: // Override weak symbol exposed by UBSan to override default options. This is called by UBSan
> 
> Please explain why we need to override the default options.

Done. Also added a comment regarding the environment variable UBSAN_OPTIONS.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From dholmes at openjdk.org  Mon Dec 12 07:29:05 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 12 Dec 2022 07:29:05 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v3]
In-Reply-To: <Jgz4iTse8EjQwWSoLLh2t4JdpnwX1OCloycHGKGY-o4=.620eb380-2b64-49c5-bf36-ecb6f633e35a@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <Jgz4iTse8EjQwWSoLLh2t4JdpnwX1OCloycHGKGY-o4=.620eb380-2b64-49c5-bf36-ecb6f633e35a@github.com>
Message-ID: <14EWI1E4WrxvZUjR945PV5fmwns3BP-hZuFXivT3TPg=.3348f36d-e375-499f-83e5-cc507143927f@github.com>

On Mon, 12 Dec 2022 07:02:04 GMT, Justin King <jcking at openjdk.org> wrote:

>> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment explaining __ubsan_default_options and UBSAN_OPTIONS
>   
>   Signed-off-by: Justin King <jcking at google.com>

src/java.base/share/native/launcher/main.c line 41:

> 39: // extremely early during library loading, before main is called. We need to override the default
> 40: // options because by default UBSan only prints a warning for each occurrence. We want jtreg tests
> 41: // to fail when undefined behavior is encountered. We also want a full stack trace for the offending

If this is primarily for tests then can't we set the env-var in the test Makefile?

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From jcking at openjdk.org  Mon Dec 12 08:07:00 2022
From: jcking at openjdk.org (Justin King)
Date: Mon, 12 Dec 2022 08:07:00 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v3]
In-Reply-To: <14EWI1E4WrxvZUjR945PV5fmwns3BP-hZuFXivT3TPg=.3348f36d-e375-499f-83e5-cc507143927f@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <Jgz4iTse8EjQwWSoLLh2t4JdpnwX1OCloycHGKGY-o4=.620eb380-2b64-49c5-bf36-ecb6f633e35a@github.com>
 <14EWI1E4WrxvZUjR945PV5fmwns3BP-hZuFXivT3TPg=.3348f36d-e375-499f-83e5-cc507143927f@github.com>
Message-ID: <74wc2Xv-cLxguIN8cR2Ro688fzzSgHdckw6hNx7vlZc=.39d0d8af-0087-492c-9829-3a56e3d423c2@github.com>

On Mon, 12 Dec 2022 07:26:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Justin King has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comment explaining __ubsan_default_options and UBSAN_OPTIONS
>>   
>>   Signed-off-by: Justin King <jcking at google.com>
>
> src/java.base/share/native/launcher/main.c line 41:
> 
>> 39: // extremely early during library loading, before main is called. We need to override the default
>> 40: // options because by default UBSan only prints a warning for each occurrence. We want jtreg tests
>> 41: // to fail when undefined behavior is encountered. We also want a full stack trace for the offending
> 
> If this is primarily for tests then can't we set the env-var in the test Makefile?

Primarily, but its not a requirement. We should also be able to invoke `java` as is. The environment variables should be used to force specific behavior for a single invocation. Otherwise, if one forgets to pass the environment variables, things may not go as expected.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From burban at openjdk.org  Mon Dec 12 08:15:50 2022
From: burban at openjdk.org (Bernhard Urban-Forster)
Date: Mon, 12 Dec 2022 08:15:50 GMT
Subject: RFR: JDK-8298476: Unseal FinalReference<T>
In-Reply-To: <w1EMwAkqSjKSVoOYT7K0GB5vnpsvb-c0iNTmF7cRGvA=.bd365ba3-2de7-44d7-baa9-e856bbcbadec@github.com>
References: <HX-wqdrbmiW_cB-wH-Qf8GlmxIJbCIm6wH3Da13QUps=.fa929a99-2016-4f16-b4ec-69682e933b17@github.com>
 <w1EMwAkqSjKSVoOYT7K0GB5vnpsvb-c0iNTmF7cRGvA=.bd365ba3-2de7-44d7-baa9-e856bbcbadec@github.com>
Message-ID: <qDpKcxSPhe2iBTkAp81xnv8tTjsSk9EeZfwYBiDJUo4=.137a5139-3053-4cbe-beea-dd30701beadc@github.com>

On Fri, 9 Dec 2022 17:40:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The change in [JDK-8283415](https://bugs.openjdk.org/browse/JDK-8283415) made use of the now available `sealed` keyword for `FinalReference<T>`.
>> 
>> Unfortunately this introduced a problem for the Espresso VM (Java on Truffle): Since Espresso is written in Java it uses the functionality of the "Host VM" to implement finalization. It does that however by [introducing a new subclass of `FinalReference<T>`](https://github.com/oracle/graal/blob/f195395329fba573afc6f81c5e70a18ac334dd10/espresso/src/com.oracle.truffle.espresso/src/com/oracle/truffle/espresso/ref/ClassAssembler.java#L85-L113) which does not work anymore with the changes made in JDK-8283415. We cannot use `Finalizer` itself because we want to inject an additional "Guest object".
>> 
>> Making `FinalReference<T>` `non-sealed` would simplify things for Espresso. Before pursuing other more involved solutions I thought I would ask how strongly the maintainers of core-libs feel about such a change. Would that be okay? Are there any implications for the GC for such a change?
>
> It's unfortunate that Espresso has been extending this JDK internal class but the sealing of the Reference class hierarchy, and not reverting it to be open via a JDK internal class, is good for platform integrity and security. It would be a shame to change that as it amounts to making this class be a kind of supported interface. It's a slippery slope. If this change goes in then it will be difficult to refuse PRs from other projects that want to extend classes in other sealed hierarchies.

Thank you @AlanBateman for having a look and your assement.  I understand, we'll try to find another way ?

-------------

PR: https://git.openjdk.org/jdk/pull/11610

From burban at openjdk.org  Mon Dec 12 08:15:51 2022
From: burban at openjdk.org (Bernhard Urban-Forster)
Date: Mon, 12 Dec 2022 08:15:51 GMT
Subject: Withdrawn: JDK-8298476: Unseal FinalReference<T>
In-Reply-To: <HX-wqdrbmiW_cB-wH-Qf8GlmxIJbCIm6wH3Da13QUps=.fa929a99-2016-4f16-b4ec-69682e933b17@github.com>
References: <HX-wqdrbmiW_cB-wH-Qf8GlmxIJbCIm6wH3Da13QUps=.fa929a99-2016-4f16-b4ec-69682e933b17@github.com>
Message-ID: <B1BybZ8VVwBxkBVIqNnNXjtm0hQ-qZqP6o7gsGAGyYc=.aac43a2b-d272-468f-8508-52c89ae4907f@github.com>

On Fri, 9 Dec 2022 14:17:24 GMT, Bernhard Urban-Forster <burban at openjdk.org> wrote:

> The change in [JDK-8283415](https://bugs.openjdk.org/browse/JDK-8283415) made use of the now available `sealed` keyword for `FinalReference<T>`.
> 
> Unfortunately this introduced a problem for the Espresso VM (Java on Truffle): Since Espresso is written in Java it uses the functionality of the "Host VM" to implement finalization. It does that however by [introducing a new subclass of `FinalReference<T>`](https://github.com/oracle/graal/blob/f195395329fba573afc6f81c5e70a18ac334dd10/espresso/src/com.oracle.truffle.espresso/src/com/oracle/truffle/espresso/ref/ClassAssembler.java#L85-L113) which does not work anymore with the changes made in JDK-8283415. We cannot use `Finalizer` itself because we want to inject an additional "Guest object".
> 
> Making `FinalReference<T>` `non-sealed` would simplify things for Espresso. Before pursuing other more involved solutions I thought I would ask how strongly the maintainers of core-libs feel about such a change. Would that be okay? Are there any implications for the GC for such a change?

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11610

From rehn at openjdk.org  Mon Dec 12 08:19:59 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 12 Dec 2022 08:19:59 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v3]
In-Reply-To: <Jgz4iTse8EjQwWSoLLh2t4JdpnwX1OCloycHGKGY-o4=.620eb380-2b64-49c5-bf36-ecb6f633e35a@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <Jgz4iTse8EjQwWSoLLh2t4JdpnwX1OCloycHGKGY-o4=.620eb380-2b64-49c5-bf36-ecb6f633e35a@github.com>
Message-ID: <ITzd0UtfSa0w5aKseF_5bEmi1c-MvEiEU8ZVoUFSPyM=.0a67c589-ad27-4908-b596-f17ffec270fa@github.com>

On Mon, 12 Dec 2022 07:02:04 GMT, Justin King <jcking at openjdk.org> wrote:

>> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment explaining __ubsan_default_options and UBSAN_OPTIONS
>   
>   Signed-off-by: Justin King <jcking at google.com>

src/java.base/share/native/launcher/main.c line 49:

> 47: #endif // UNDEFINED_BEHAVIOR_SANITIZER
> 48: 
> 49: /*

As I said we have more launcher than 'java', if you put this method here you must put it in all launchers.
I.e. all binaries that call JNI_CreateJavaVM, such our tests, e.g. jni/daemonDestroy/TestDaemonDestroy.java

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From pminborg at openjdk.org  Mon Dec 12 08:44:34 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 12 Dec 2022 08:44:34 GMT
Subject: RFR: 8298532: Declare private constructors for FFM internal
 Architecture implementations
Message-ID: <o9cDzVMigJyXXlEch3KrdgjO-Xg2-rGnHlf2GmtIPIc=.500b1d50-288f-4c03-86f9-53be37101e85@github.com>

This PR proposes declaring `AArch64Architecture` and `X86_64Architecture` `final` and creating a `private` constructor so that this redundant byte code can be eliminated:


 public jdk.internal.foreign.abi.x64.X86_64Architecture(); 
    Code: 
       0: aload_0 
       1: invokespecial #1 // Method java/lang/Object."<init>":()V 
       4: return 

 public jdk.internal.foreign.abi.aarch64.AArch64Architectur(); 
    Code: 
       0: aload_0 
       1: invokespecial #1 // Method java/lang/Object."<init>":()V 
       4: return 


and other potential optimizations can be unlocked.

-------------

Commit messages:
 - Declare constructors private and classes final

Changes: https://git.openjdk.org/jdk/pull/11629/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11629&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298532
  Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11629.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11629/head:pull/11629

PR: https://git.openjdk.org/jdk/pull/11629

From jcking at openjdk.org  Mon Dec 12 09:21:14 2022
From: jcking at openjdk.org (Justin King)
Date: Mon, 12 Dec 2022 09:21:14 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v4]
In-Reply-To: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
Message-ID: <fScMYCh248OAuaiEQyUUW7TcdoLLd8xKEnvHZ33TVDg=.6f4f61fc-b7b3-457a-b038-790ef1a43b01@github.com>

> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Move __ubsan_default_options to be automagically included via SetupNativeCompilation
  
  Signed-off-by: Justin King <jcking at google.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11604/files
  - new: https://git.openjdk.org/jdk/pull/11604/files/e104ec05..42e66fde

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11604&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11604&range=02-03

  Stats: 65 lines in 5 files changed: 51 ins; 12 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11604.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11604/head:pull/11604

PR: https://git.openjdk.org/jdk/pull/11604

From jcking at openjdk.org  Mon Dec 12 09:33:34 2022
From: jcking at openjdk.org (Justin King)
Date: Mon, 12 Dec 2022 09:33:34 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v5]
In-Reply-To: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
Message-ID: <LXptRwaW82tz079h2ZDzTxCNVqnBH6yr-abaGCBYID4=.88c8d078-3d75-40b3-abe6-46df586447ba@github.com>

> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Use RESULT for UTIL_ARG_ENABLE
  
  Signed-off-by: Justin King <jcking at google.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11604/files
  - new: https://git.openjdk.org/jdk/pull/11604/files/42e66fde..c1914d00

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11604&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11604&range=03-04

  Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11604.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11604/head:pull/11604

PR: https://git.openjdk.org/jdk/pull/11604

From jcking at openjdk.org  Mon Dec 12 09:50:33 2022
From: jcking at openjdk.org (Justin King)
Date: Mon, 12 Dec 2022 09:50:33 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v6]
In-Reply-To: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
Message-ID: <QWLad_HmE1bp_Sk1Kybw46FLFMxf5enYkNzWqYi3sBI=.046efbc3-5620-4275-9de8-634207d95997@github.com>

> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Put __ubsan_default_options in C++
  
  Signed-off-by: Justin King <jcking at google.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11604/files
  - new: https://git.openjdk.org/jdk/pull/11604/files/c1914d00..cdbb6492

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11604&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11604&range=04-05

  Stats: 1 line in 2 files changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11604.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11604/head:pull/11604

PR: https://git.openjdk.org/jdk/pull/11604

From jcking at openjdk.org  Mon Dec 12 10:01:32 2022
From: jcking at openjdk.org (Justin King)
Date: Mon, 12 Dec 2022 10:01:32 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v3]
In-Reply-To: <ITzd0UtfSa0w5aKseF_5bEmi1c-MvEiEU8ZVoUFSPyM=.0a67c589-ad27-4908-b596-f17ffec270fa@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <Jgz4iTse8EjQwWSoLLh2t4JdpnwX1OCloycHGKGY-o4=.620eb380-2b64-49c5-bf36-ecb6f633e35a@github.com>
 <ITzd0UtfSa0w5aKseF_5bEmi1c-MvEiEU8ZVoUFSPyM=.0a67c589-ad27-4908-b596-f17ffec270fa@github.com>
Message-ID: <RTxeTB5SeTS3gDJRW1fjLkQnRCkuq42rJywqBaFtiRw=.f7c2e438-6532-406a-adf8-4e7b2f9d1147@github.com>

On Mon, 12 Dec 2022 08:14:51 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Justin King has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comment explaining __ubsan_default_options and UBSAN_OPTIONS
>>   
>>   Signed-off-by: Justin King <jcking at google.com>
>
> src/java.base/share/native/launcher/main.c line 49:
> 
>> 47: #endif // UNDEFINED_BEHAVIOR_SANITIZER
>> 48: 
>> 49: /*
> 
> As I said we have more launcher than 'java', if you put this method here you must put it in all launchers.
> I.e. all binaries that call JNI_CreateJavaVM, such our tests, e.g. jni/daemonDestroy/TestDaemonDestroy.java

Attempting an approach that automatically includes `__ubsan_default_options` in binaries by "automagically" including a source file for anything using `SetupNativeCompilation` with `TYPE` being `EXECUTABLE`.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From jcking at openjdk.org  Mon Dec 12 10:17:48 2022
From: jcking at openjdk.org (Justin King)
Date: Mon, 12 Dec 2022 10:17:48 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v6]
In-Reply-To: <QWLad_HmE1bp_Sk1Kybw46FLFMxf5enYkNzWqYi3sBI=.046efbc3-5620-4275-9de8-634207d95997@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <QWLad_HmE1bp_Sk1Kybw46FLFMxf5enYkNzWqYi3sBI=.046efbc3-5620-4275-9de8-634207d95997@github.com>
Message-ID: <PvD6wGvK_ztRcUdO-KIYWtL08QPNmni56BQIQKxgAoY=.c6525844-23d8-4aae-b793-7f6c3dfb03a6@github.com>

On Mon, 12 Dec 2022 09:50:33 GMT, Justin King <jcking at openjdk.org> wrote:

>> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Put __ubsan_default_options in C++
>   
>   Signed-off-by: Justin King <jcking at google.com>

Moving back to draft while I figure out some autoconf magic.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From jcking at openjdk.org  Mon Dec 12 10:25:22 2022
From: jcking at openjdk.org (Justin King)
Date: Mon, 12 Dec 2022 10:25:22 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v7]
In-Reply-To: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
Message-ID: <7DkxGz8qL2OjVJm8tIWCG7fW8drWyBHwDcvfKhuv_20=.b6602431-2439-438f-982f-acce632be129@github.com>

> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Support both C and C++
  
  Signed-off-by: Justin King <jcking at google.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11604/files
  - new: https://git.openjdk.org/jdk/pull/11604/files/cdbb6492..a8c089cd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11604&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11604&range=05-06

  Stats: 31 lines in 3 files changed: 8 ins; 20 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11604.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11604/head:pull/11604

PR: https://git.openjdk.org/jdk/pull/11604

From jcking at openjdk.org  Mon Dec 12 10:42:22 2022
From: jcking at openjdk.org (Justin King)
Date: Mon, 12 Dec 2022 10:42:22 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v8]
In-Reply-To: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
Message-ID: <xy2Eago_3UXJFsvRNfJ4y3GLbfnvdSBEL8MEMLZLr44=.6fb62abf-a53b-4531-bcc6-42aaf74d030d@github.com>

> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Simplify logic for including __ubsan_default_options
  
  Signed-off-by: Justin King <jcking at google.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11604/files
  - new: https://git.openjdk.org/jdk/pull/11604/files/a8c089cd..f4f8c093

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11604&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11604&range=06-07

  Stats: 16 lines in 1 file changed: 7 ins; 8 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11604.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11604/head:pull/11604

PR: https://git.openjdk.org/jdk/pull/11604

From jcking at openjdk.org  Mon Dec 12 10:48:24 2022
From: jcking at openjdk.org (Justin King)
Date: Mon, 12 Dec 2022 10:48:24 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v3]
In-Reply-To: <RTxeTB5SeTS3gDJRW1fjLkQnRCkuq42rJywqBaFtiRw=.f7c2e438-6532-406a-adf8-4e7b2f9d1147@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <Jgz4iTse8EjQwWSoLLh2t4JdpnwX1OCloycHGKGY-o4=.620eb380-2b64-49c5-bf36-ecb6f633e35a@github.com>
 <ITzd0UtfSa0w5aKseF_5bEmi1c-MvEiEU8ZVoUFSPyM=.0a67c589-ad27-4908-b596-f17ffec270fa@github.com>
 <RTxeTB5SeTS3gDJRW1fjLkQnRCkuq42rJywqBaFtiRw=.f7c2e438-6532-406a-adf8-4e7b2f9d1147@github.com>
Message-ID: <C-XcKFA85j3snSYg9yJl_KpEpoY9ITNWLUnzGlqalLQ=.3b25cc07-6815-4d94-a68e-211711857fda@github.com>

On Mon, 12 Dec 2022 09:58:54 GMT, Justin King <jcking at openjdk.org> wrote:

>> src/java.base/share/native/launcher/main.c line 49:
>> 
>>> 47: #endif // UNDEFINED_BEHAVIOR_SANITIZER
>>> 48: 
>>> 49: /*
>> 
>> As I said we have more launcher than 'java', if you put this method here you must put it in all launchers.
>> I.e. all binaries that call JNI_CreateJavaVM, such our tests, e.g. jni/daemonDestroy/TestDaemonDestroy.java
>
> Attempting an approach that automatically includes `__ubsan_default_options` in binaries by "automagically" including a source file for anything using `SetupNativeCompilation` with `TYPE` being `EXECUTABLE`.

Okay, I was able to get the autoconf magic working. Instead of having to copy-paste `__ubsan_default_options` to every launcher, it is instead auto-inserted in `SetupNativeCompilation` by including a source file which exports it for anything that is `EXECUTABLE`.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From rgiulietti at openjdk.org  Mon Dec 12 11:19:59 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 12 Dec 2022 11:19:59 GMT
Subject: RFR: 8205592: BigDecimal.doubleValue() is depressingly slow
In-Reply-To: <XpbHjLD13akVXWMOh0CVfH3ZjWeWLzMenrJ0UxjMO5I=.03ec2741-0762-459d-b27a-3cc022a48a19@github.com>
References: <XpbHjLD13akVXWMOh0CVfH3ZjWeWLzMenrJ0UxjMO5I=.03ec2741-0762-459d-b27a-3cc022a48a19@github.com>
Message-ID: <R3CuQDnqapDTE61kjqMmbIRkdMp8O4OlQ9f-JIibI-w=.84d699e7-3455-4ab5-981b-b7401356020b@github.com>

On Thu, 7 Jul 2022 15:20:32 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> A reimplementation of `BigDecimal.[double|float]Value()` to enhance performance, avoiding an intermediate string and its subsequent parsing on the slow path.

waiting for review

-------------

PR: https://git.openjdk.org/jdk/pull/9410

From pminborg at openjdk.org  Mon Dec 12 12:56:15 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 12 Dec 2022 12:56:15 GMT
Subject: RFR: 8298567: Make field in RandomAccessFile final
Message-ID: <9HouiJNGBXaOv_FpyS4U6ZFvi6plkkyF1quOAXCX02Q=.a18629b5-a916-4f9e-87d2-e73effb9f361@github.com>

This PR proposes making a field in `RandomAccessFile` final. Also, it modernises a switch statement.

-------------

Commit messages:
 - Reclare field final and modernize switch

Changes: https://git.openjdk.org/jdk/pull/11632/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11632&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298567
  Stats: 15 lines in 1 file changed: 0 ins; 5 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/11632.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11632/head:pull/11632

PR: https://git.openjdk.org/jdk/pull/11632

From alanb at openjdk.org  Mon Dec 12 13:23:01 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 12 Dec 2022 13:23:01 GMT
Subject: RFR: 8298567: Make field in RandomAccessFile final
In-Reply-To: <9HouiJNGBXaOv_FpyS4U6ZFvi6plkkyF1quOAXCX02Q=.a18629b5-a916-4f9e-87d2-e73effb9f361@github.com>
References: <9HouiJNGBXaOv_FpyS4U6ZFvi6plkkyF1quOAXCX02Q=.a18629b5-a916-4f9e-87d2-e73effb9f361@github.com>
Message-ID: <YhfJWrJWEF-VGI-QAj76BZsPYEb_agMZ2N_Lg5xZECE=.3160853b-8bc7-4362-96ed-0a0d15c06724@github.com>

On Mon, 12 Dec 2022 12:48:47 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes making a field in `RandomAccessFile` final. Also, it modernises a switch statement.

Surprising that RandomAccessFile.fd was not changed to final many years ago. We can do rw at the same time.

-------------

PR: https://git.openjdk.org/jdk/pull/11632

From alanb at openjdk.org  Mon Dec 12 14:20:05 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 12 Dec 2022 14:20:05 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option
In-Reply-To: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
Message-ID: <3qBQbDWN99tyr32fbrT86WixwxSPzA235ISVqt70f5I=.b6202387-ed59-4124-809e-58771ed5bffa@github.com>

On Fri, 9 Dec 2022 21:42:15 GMT, Ian Graves <igraves at openjdk.org> wrote:

> This is an approach to adding a flag to jlink that will allow --compress to take the same types of arguments as jmod, thus bringing the two into alignment. This likely requires a CSR and a discussion on whether we should deprecate or simply remove the original numeric compression arguments.

I skimmed through this (not a detailed review) and I think it's mostly okay. It's --compress 0 and 2 that should be listed as deprecated as --compress 1 is string sharing rather than zip compression.

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From pminborg at openjdk.org  Mon Dec 12 14:26:40 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 12 Dec 2022 14:26:40 GMT
Subject: RFR: 8298567: Make field in RandomAccessFile final [v2]
In-Reply-To: <9HouiJNGBXaOv_FpyS4U6ZFvi6plkkyF1quOAXCX02Q=.a18629b5-a916-4f9e-87d2-e73effb9f361@github.com>
References: <9HouiJNGBXaOv_FpyS4U6ZFvi6plkkyF1quOAXCX02Q=.a18629b5-a916-4f9e-87d2-e73effb9f361@github.com>
Message-ID: <BdTiEsagdTXGEOQFlOUlwmuVmmp2fJQovWpLJoAYRq8=.7aefee3e-37be-4835-a7b6-b0d58645f86a@github.com>

> This PR proposes making a field in `RandomAccessFile` final. Also, it modernises a switch statement.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Make the field rw final

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11632/files
  - new: https://git.openjdk.org/jdk/pull/11632/files/aa682717..20c9d49a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11632&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11632&range=00-01

  Stats: 21 lines in 1 file changed: 12 ins; 6 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11632.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11632/head:pull/11632

PR: https://git.openjdk.org/jdk/pull/11632

From rriggs at openjdk.org  Mon Dec 12 14:58:02 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 12 Dec 2022 14:58:02 GMT
Subject: RFR: 8298567: Make field in RandomAccessFile final [v2]
In-Reply-To: <BdTiEsagdTXGEOQFlOUlwmuVmmp2fJQovWpLJoAYRq8=.7aefee3e-37be-4835-a7b6-b0d58645f86a@github.com>
References: <9HouiJNGBXaOv_FpyS4U6ZFvi6plkkyF1quOAXCX02Q=.a18629b5-a916-4f9e-87d2-e73effb9f361@github.com>
 <BdTiEsagdTXGEOQFlOUlwmuVmmp2fJQovWpLJoAYRq8=.7aefee3e-37be-4835-a7b6-b0d58645f86a@github.com>
Message-ID: <y4FeTB4ogHsJk0Zi2e-wOoD5w0KgOnwBl5JC2qVqIGY=.53bf8113-dbe3-4ec1-b813-e16202261f59@github.com>

On Mon, 12 Dec 2022 14:26:40 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes making a field in `RandomAccessFile` final. Also, it modernises a switch statement.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make the field rw final

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11632

From chegar at openjdk.org  Mon Dec 12 15:07:03 2022
From: chegar at openjdk.org (Chris Hegarty)
Date: Mon, 12 Dec 2022 15:07:03 GMT
Subject: RFR: 8298567: Make field in RandomAccessFile final [v2]
In-Reply-To: <BdTiEsagdTXGEOQFlOUlwmuVmmp2fJQovWpLJoAYRq8=.7aefee3e-37be-4835-a7b6-b0d58645f86a@github.com>
References: <9HouiJNGBXaOv_FpyS4U6ZFvi6plkkyF1quOAXCX02Q=.a18629b5-a916-4f9e-87d2-e73effb9f361@github.com>
 <BdTiEsagdTXGEOQFlOUlwmuVmmp2fJQovWpLJoAYRq8=.7aefee3e-37be-4835-a7b6-b0d58645f86a@github.com>
Message-ID: <y83sEYFU_LccnUpZmJyWeTdZnV7oIgMoptQUrY4-lPs=.d0fdcb41-cf70-4cc6-af6c-984a56a7abc5@github.com>

On Mon, 12 Dec 2022 14:26:40 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes making a field in `RandomAccessFile` final. Also, it modernises a switch statement.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make the field rw final

LGTM

-------------

Marked as reviewed by chegar (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11632

From Alan.Bateman at oracle.com  Mon Dec 12 15:26:11 2022
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 12 Dec 2022 15:26:11 +0000
Subject: jdeps - option to to analyze package-private API
In-Reply-To: <2dd880da-6ddc-302e-2e03-504b4171f484@oracle.com>
References: <2dd880da-6ddc-302e-2e03-504b4171f484@oracle.com>
Message-ID: <68ef4409-114d-b2d2-9f9f-fc3121c2f7ff@oracle.com>

On 03/12/2022 18:15, Matej Turcel wrote:
> :
>
> So far, jdeps with the --api-only flag seems like the perfect tool, 
> except
> there is a little problem -- we have packages (dozens of them) which
> exist in multiple modules. For example, package `com.foo` exists in
> three separate modules (meaning each of these modules has a class in that
> package). That means package-private "stuff" (members + 
> constructor/method
> signatures) is a part of module's API. So to infer correct types of 
> gradle
> module dependencies using jdeps, we need jdeps to consider 
> package-private
> stuff a part of the API.

The scenario seems a bit unusual in that API elements with package 
access aren't usually considered to be part of the API. Does the javadoc 
published for users of these components include the API elements with 
package access?? I realize Gradle may define "module" to mean something 
else but for the Java platform, a module is a set of packages.

I haven't seen any opinions from others but my initial reaction is that 
it wouldn't be a good idea to change --api-only to consider API elements 
with package access to be part of the API. If jdeps were changed then it 
would need a new option.


>
> On an unrelated note, I believe bounds of type parameters should be
> a part of type's API:
>
> ??? public class C<T extends Boolean> {
> ??????? T x;
> ??? }
>
> But according to jdeps they are not:
>
> ??? > jdeps --verbose C.class
> ??? C.class -> java.base
> ?????? C?????? -> java.lang.Boolean??????? java.base
> ?????? C?????? -> java.lang.Object???????? java.base
>
> ??? > jdeps --verbose --api-only C.class
> ??? C.class -> java.base
> ?????? C?????? -> java.lang.Object???????? java.base
>
> Is this behavior intended?
>
jdeps could read the Signature attribute but I think it would complicate 
the output to try to have it include the bounds.

-Alan




From pminborg at openjdk.org  Mon Dec 12 15:43:36 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 12 Dec 2022 15:43:36 GMT
Subject: RFR: 8298567: Make field in RandomAccessFile final [v3]
In-Reply-To: <9HouiJNGBXaOv_FpyS4U6ZFvi6plkkyF1quOAXCX02Q=.a18629b5-a916-4f9e-87d2-e73effb9f361@github.com>
References: <9HouiJNGBXaOv_FpyS4U6ZFvi6plkkyF1quOAXCX02Q=.a18629b5-a916-4f9e-87d2-e73effb9f361@github.com>
Message-ID: <pr_Gts5ssn-8DuVXdJqM7a6P2t5pppX0F7Uq3h3jZrs=.9ad9b8c4-6908-4cd1-a566-363bc1690c24@github.com>

> This PR proposes making a field in `RandomAccessFile` final. Also, it modernises a switch statement.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove redundant check

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11632/files
  - new: https://git.openjdk.org/jdk/pull/11632/files/20c9d49a..99c147a3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11632&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11632&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11632.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11632/head:pull/11632

PR: https://git.openjdk.org/jdk/pull/11632

From pminborg at openjdk.org  Mon Dec 12 17:09:20 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 12 Dec 2022 17:09:20 GMT
Subject: Integrated: 8298567: Make field in RandomAccessFile final
In-Reply-To: <9HouiJNGBXaOv_FpyS4U6ZFvi6plkkyF1quOAXCX02Q=.a18629b5-a916-4f9e-87d2-e73effb9f361@github.com>
References: <9HouiJNGBXaOv_FpyS4U6ZFvi6plkkyF1quOAXCX02Q=.a18629b5-a916-4f9e-87d2-e73effb9f361@github.com>
Message-ID: <GhdjzawEYmuLvX2DTldNMGkqrzD68ad6JrdQcRtkXBs=.314017a9-2663-4153-82eb-9932c71306e0@github.com>

On Mon, 12 Dec 2022 12:48:47 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes making a field in `RandomAccessFile` final. Also, it modernises a switch statement.

This pull request has now been integrated.

Changeset: 81f57d56
Author:    Per Minborg <pminborg at openjdk.org>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/81f57d568fc687a484f96a8638fa4cdd29374f0e
Stats:     40 lines in 1 file changed: 12 ins; 14 del; 14 mod

8298567: Make field in RandomAccessFile final

Reviewed-by: rriggs, chegar

-------------

PR: https://git.openjdk.org/jdk/pull/11632

From naoto at openjdk.org  Mon Dec 12 17:15:36 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 12 Dec 2022 17:15:36 GMT
Subject: [jdk20] RFR: 8297288: Example code in Scanner class [v2]
In-Reply-To: <wlEAB8pPH6CaWYMIyY53_vhnLQfFfe1itTbolWbbMA0=.90919c01-4984-40a7-8526-41d0b64b3889@github.com>
References: <wlEAB8pPH6CaWYMIyY53_vhnLQfFfe1itTbolWbbMA0=.90919c01-4984-40a7-8526-41d0b64b3889@github.com>
Message-ID: <jhU4vMJlBPxm-sJwHazhB_s-JYzLQj5fLEW9p5t8iHA=.fa32085b-13b7-4dfd-b9cf-927a5374e4c5@github.com>

> The example in `Scanner` directly uses `System.in` which may cause unwanted behavior when the default charset and the console charset differ. Using `Console.reader()` is more appropriate. Also changed examples into snippets.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Modified @link comment in the snippet

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/14/files
  - new: https://git.openjdk.org/jdk20/pull/14/files/ce1df2fd..7e2ad71d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=14&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=14&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk20/pull/14.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/14/head:pull/14

PR: https://git.openjdk.org/jdk20/pull/14

From alanb at openjdk.org  Mon Dec 12 17:15:37 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 12 Dec 2022 17:15:37 GMT
Subject: [jdk20] RFR: 8297288: Example code in Scanner class [v2]
In-Reply-To: <jhU4vMJlBPxm-sJwHazhB_s-JYzLQj5fLEW9p5t8iHA=.fa32085b-13b7-4dfd-b9cf-927a5374e4c5@github.com>
References: <wlEAB8pPH6CaWYMIyY53_vhnLQfFfe1itTbolWbbMA0=.90919c01-4984-40a7-8526-41d0b64b3889@github.com>
 <jhU4vMJlBPxm-sJwHazhB_s-JYzLQj5fLEW9p5t8iHA=.fa32085b-13b7-4dfd-b9cf-927a5374e4c5@github.com>
Message-ID: <8bUo1frVphJarEMFr7BFRPlCgUemQOB0pMjrHmUqIMA=.250aa214-2949-4b9f-a672-a5128f0e473a@github.com>

On Mon, 12 Dec 2022 17:11:54 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The example in `Scanner` directly uses `System.in` which may cause unwanted behavior when the default charset and the console charset differ. Using `Console.reader()` is more appropriate. Also changed examples into snippets.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modified @link comment in the snippet

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk20/pull/14

From naoto at openjdk.org  Mon Dec 12 17:15:39 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 12 Dec 2022 17:15:39 GMT
Subject: [jdk20] RFR: 8297288: Example code in Scanner class [v2]
In-Reply-To: <WMPWVP-OmuzruuotmbQ_knCORWiaQcwxeYmNYSJHjwE=.d95cd83a-615e-4c00-be40-31a027e26761@github.com>
References: <wlEAB8pPH6CaWYMIyY53_vhnLQfFfe1itTbolWbbMA0=.90919c01-4984-40a7-8526-41d0b64b3889@github.com>
 <WMPWVP-OmuzruuotmbQ_knCORWiaQcwxeYmNYSJHjwE=.d95cd83a-615e-4c00-be40-31a027e26761@github.com>
Message-ID: <sVXeA26RR59rtNW_MzGoqrjdpNiOKsfQTRBYW_jH8hA=.3571a43b-ae3f-49c4-a4c4-e25c44c019ea@github.com>

On Sat, 10 Dec 2022 08:15:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Modified @link comment in the snippet
>
> src/java.base/share/classes/java/util/Scanner.java line 58:
> 
>> 56:  *     var con = System.console();
>> 57:  *     if (con != null) {
>> 58:  *         Scanner sc = new Scanner(con.reader()); // @link substring="reader()" target="java.io.Console#reader()"
> 
> The link tag can be put on the previous line if you want. It just requires terminating it with a colon (":"). I've found that useful in a few places.

Thanks, Alan. It is indeed useful. Modified as suggested.

-------------

PR: https://git.openjdk.org/jdk20/pull/14

From jvernee at openjdk.org  Mon Dec 12 17:27:03 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 12 Dec 2022 17:27:03 GMT
Subject: RFR: 8298532: Declare private constructors for FFM internal
 Architecture implementations
In-Reply-To: <o9cDzVMigJyXXlEch3KrdgjO-Xg2-rGnHlf2GmtIPIc=.500b1d50-288f-4c03-86f9-53be37101e85@github.com>
References: <o9cDzVMigJyXXlEch3KrdgjO-Xg2-rGnHlf2GmtIPIc=.500b1d50-288f-4c03-86f9-53be37101e85@github.com>
Message-ID: <Lf7yYZiZRn6GwAB9jGjoPb7mKf6XvVb4AwyH7LllhKg=.5021ccdd-fc81-403f-8307-612a07af3787@github.com>

On Mon, 12 Dec 2022 08:37:02 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes declaring `AArch64Architecture` and `X86_64Architecture` `final` and creating a `private` constructor so that this redundant byte code can be eliminated:
> 
> 
>  public jdk.internal.foreign.abi.x64.X86_64Architecture(); 
>     Code: 
>        0: aload_0 
>        1: invokespecial #1 // Method java/lang/Object."<init>":()V 
>        4: return 
> 
>  public jdk.internal.foreign.abi.aarch64.AArch64Architectur(); 
>     Code: 
>        0: aload_0 
>        1: invokespecial #1 // Method java/lang/Object."<init>":()V 
>        4: return 
> 
> 
> and other potential optimizations can be unlocked.

Marked as reviewed by jvernee (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11629

From jvernee at openjdk.org  Mon Dec 12 18:31:36 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 12 Dec 2022 18:31:36 GMT
Subject: RFR: 8298590: Refactor LambdaForm constructors
Message-ID: <EVqdVtK45xq8NkbBSjQcpqi6hin9BXtcZplPDh7pjvI=.ab7c50b7-95e6-4263-8c2a-97be8890de63@github.com>

Refactor LambdaForm constructors into static factories.

In the new code, there's only 1 constructor, which simply initializes all fields. Multiple factory methods are built on top of this, which add various argument validation/pre-processing and post processing of the constructed lambda forms.

In the LambdaFrom class itself, it is easier to see which LF creation goes through which checks due to names of factory, or if all checks are bypassed by calling the constructor.

New factories can easily be added that bypass all the checks in the existing factories and just call the root constructor if they so wish to (we likely want to add several for lazy lambda form resolution https://bugs.openjdk.org/browse/JDK-8288041).

Additionally: replaced some default values literals with named constants so it's easy to see that it's just the default value for that arg at the call site.

-------------

Commit messages:
 - minor touch ups
 - Refactor LambdaForm constructors

Changes: https://git.openjdk.org/jdk/pull/11612/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11612&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298590
  Stats: 97 lines in 8 files changed: 32 ins; 13 del; 52 mod
  Patch: https://git.openjdk.org/jdk/pull/11612.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11612/head:pull/11612

PR: https://git.openjdk.org/jdk/pull/11612

From jwilhelm at openjdk.org  Mon Dec 12 18:57:38 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Mon, 12 Dec 2022 18:57:38 GMT
Subject: RFR: Merge jdk20
Message-ID: <BxIryfRtcd7M9X0vYVs-m0ZBEpqyFwvoMcArBI_Up04=.86f53b97-d454-47a1-bf25-160472090a00@github.com>

Forwardport JDK 20 -> JDK 21

-------------

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8297288: Example code in Scanner class
 - 8298271: java/security/SignedJar/spi-calendar-provider/TestSPISigned.java failing on Windows
 - 8298459: Fix msys2 linking and handling out of tree build directory for source zip creation

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=11637&range=00.0
 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=11637&range=00.1

Changes: https://git.openjdk.org/jdk/pull/11637/files
  Stats: 47 lines in 5 files changed: 25 ins; 2 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/11637.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11637/head:pull/11637

PR: https://git.openjdk.org/jdk/pull/11637

From bchristi at openjdk.org  Mon Dec 12 19:40:44 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 12 Dec 2022 19:40:44 GMT
Subject: Integrated: 8295857: Clarify that cleanup code can be skipped when the
 JVM terminates (e.g. when calling halt())
In-Reply-To: <hHSImvhd-Yg6AcPkSrYBFxBOx4jBg079lx4sRjR3AZc=.65cd47c4-b34a-4475-8b35-069627999eed@github.com>
References: <hHSImvhd-Yg6AcPkSrYBFxBOx4jBg079lx4sRjR3AZc=.65cd47c4-b34a-4475-8b35-069627999eed@github.com>
Message-ID: <HprvW541Won1dZpDdN4FhwmWh-Ob5FoU2Yd2PCCrs4U=.9fab7ad6-ea43-4488-b623-af6457c905d8@github.com>

On Thu, 17 Nov 2022 19:25:42 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036) documented the shutdown sequence, noting that calling Runtime.halt() skips the shutdown sequence and immediately terminates the VM. Thus, "threads' current methods do not complete normally or abruptly; no finally clause of any method is executed".
> 
> One ramification of this is that resources within try-with-resource blocks will not be released. It would be good to state this explicitly.

This pull request has now been integrated.

Changeset: c7aca731
Author:    Brent Christian <bchristi at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c7aca73177339f931f7dfb6627365548a32874f7
Stats:     10 lines in 1 file changed: 5 ins; 0 del; 5 mod

8295857: Clarify that cleanup code can be skipped when the JVM terminates (e.g. when calling halt())

Reviewed-by: lancea, bpb, naoto, dholmes, smarks

-------------

PR: https://git.openjdk.org/jdk/pull/11218

From bchristi at openjdk.org  Mon Dec 12 20:03:26 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 12 Dec 2022 20:03:26 GMT
Subject: [jdk20] RFR: 8295857: Clarify that cleanup code can be skipped when
 the JVM terminates (e.g. when calling halt())
Message-ID: <IKcmMhqeJ_QAby4H73oBOUoYNpxNM7hVzF9NBqJ80-M=.8f9cc1c2-f78e-411b-bfd2-5f59bdad99ff@github.com>

Backport [8295857](https://bugs.openjdk.org/browse/JDK-8295857) to jdk20

-------------

Commit messages:
 - Backport c7aca73177339f931f7dfb6627365548a32874f7

Changes: https://git.openjdk.org/jdk20/pull/19/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=19&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295857
  Stats: 10 lines in 1 file changed: 5 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk20/pull/19.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/19/head:pull/19

PR: https://git.openjdk.org/jdk20/pull/19

From naoto at openjdk.org  Mon Dec 12 18:02:21 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 12 Dec 2022 18:02:21 GMT
Subject: [jdk20] Integrated: 8297288: Example code in Scanner class
In-Reply-To: <wlEAB8pPH6CaWYMIyY53_vhnLQfFfe1itTbolWbbMA0=.90919c01-4984-40a7-8526-41d0b64b3889@github.com>
References: <wlEAB8pPH6CaWYMIyY53_vhnLQfFfe1itTbolWbbMA0=.90919c01-4984-40a7-8526-41d0b64b3889@github.com>
Message-ID: <zQKcTioiGxL4Gt5xIjp_0hCgTM4DTt5ihvusi-qPKEA=.8665f184-57e2-41fe-ae13-fde810f9eef6@github.com>

On Fri, 9 Dec 2022 18:32:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The example in `Scanner` directly uses `System.in` which may cause unwanted behavior when the default charset and the console charset differ. Using `Console.reader()` is more appropriate. Also changed examples into snippets.

This pull request has now been integrated.

Changeset: 0267aa52
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/0267aa528b83be9914fee4bea8f548b8404b31f8
Stats:     16 lines in 1 file changed: 4 ins; 0 del; 12 mod

8297288: Example code in Scanner class

Reviewed-by: lancea, bpb, alanb

-------------

PR: https://git.openjdk.org/jdk20/pull/14

From iris at openjdk.org  Mon Dec 12 20:42:52 2022
From: iris at openjdk.org (Iris Clark)
Date: Mon, 12 Dec 2022 20:42:52 GMT
Subject: [jdk20] RFR: 8295857: Clarify that cleanup code can be skipped
 when the JVM terminates (e.g. when calling halt())
In-Reply-To: <IKcmMhqeJ_QAby4H73oBOUoYNpxNM7hVzF9NBqJ80-M=.8f9cc1c2-f78e-411b-bfd2-5f59bdad99ff@github.com>
References: <IKcmMhqeJ_QAby4H73oBOUoYNpxNM7hVzF9NBqJ80-M=.8f9cc1c2-f78e-411b-bfd2-5f59bdad99ff@github.com>
Message-ID: <wJgbXDiZFV5iRRryfFZuC28NLUlS2_3k4rMRmtZs50k=.887d8c49-4bd2-456c-b4de-e12449367b35@github.com>

On Mon, 12 Dec 2022 19:51:22 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Backport [8295857](https://bugs.openjdk.org/browse/JDK-8295857) to jdk20

Changes appear to be identical to those in JDK 21.

-------------

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/19

From igraves at openjdk.org  Mon Dec 12 20:53:27 2022
From: igraves at openjdk.org (Ian Graves)
Date: Mon, 12 Dec 2022 20:53:27 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v2]
In-Reply-To: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
Message-ID: <L0YQ-HpkzstQ-kaNwoO3BxLqgcluDK5Lzt8R9c9ZGSs=.637129c6-047c-4197-8ed2-70d0a203ec90@github.com>

> This is an approach to adding a flag to jlink that will allow --compress to take the same types of arguments as jmod, thus bringing the two into alignment. This likely requires a CSR and a discussion on whether we should deprecate or simply remove the original numeric compression arguments.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Swapping deprecations in properties

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11617/files
  - new: https://git.openjdk.org/jdk/pull/11617/files/3189e5df..da25d251

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11617&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11617&range=00-01

  Stats: 6 lines in 1 file changed: 1 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11617.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11617/head:pull/11617

PR: https://git.openjdk.org/jdk/pull/11617

From bchristi at openjdk.org  Mon Dec 12 20:55:07 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 12 Dec 2022 20:55:07 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner
 [v16]
In-Reply-To: <eFt6SCXR1oCUa1Q2D7g8KIbx-_UsXJa5zU4xMvIjF8E=.e69adc7f-f489-4d77-917d-dfb4a0f73f27@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
 <eFt6SCXR1oCUa1Q2D7g8KIbx-_UsXJa5zU4xMvIjF8E=.e69adc7f-f489-4d77-917d-dfb4a0f73f27@github.com>
Message-ID: <7HZwp-HlcvvaKEuRh8gGQuZCMhieshwS8YG9B_-i31Q=.d86ac90a-bec0-4627-9786-b2af93e7a09e@github.com>

On Fri, 22 Jul 2022 20:51:59 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner.
>> 
>> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical.
>> 
>> Details of note: 
>> 1. Some operations need to change the state values (the update() method is probably the most interesting).
>> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`.
>> 
>> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency.
>> 
>> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). 
>> 
>> Thanks.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove some more tabs

Thanks for the reminder, bridgekeeper

-------------

PR: https://git.openjdk.org/jdk/pull/8311

From almatvee at openjdk.org  Mon Dec 12 22:09:52 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 12 Dec 2022 22:09:52 GMT
Subject: [jdk20] RFR: 8298488: [macos13] tools/jpackage tests failing with
 "Exit code: 137" on macOS
Message-ID: <aPeF5Q3YPQx8g6uBkiXLNXE_f9PCR5XXqi-NzUw6HI0=.b4dfd2db-22d0-4c91-9c99-be335c80c80a@github.com>

This issue is similar to JDK-8277493. Looks like macOS 13 cannot execute unsigned code and code should be at least ad hoc signed. Same as for macOS aarch64. Fixed by enabling ad hoc signing for macOS platform for both x64 and aarch64.

-------------

Commit messages:
 - 8298488: [macos13] tools/jpackage tests failing with "Exit code: 137" on macOS

Changes: https://git.openjdk.org/jdk20/pull/20/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=20&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298488
  Stats: 6 lines in 3 files changed: 0 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk20/pull/20.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/20/head:pull/20

PR: https://git.openjdk.org/jdk20/pull/20

From asemenyuk at openjdk.org  Mon Dec 12 22:32:53 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 12 Dec 2022 22:32:53 GMT
Subject: [jdk20] RFR: 8298488: [macos13] tools/jpackage tests failing with
 "Exit code: 137" on macOS
In-Reply-To: <aPeF5Q3YPQx8g6uBkiXLNXE_f9PCR5XXqi-NzUw6HI0=.b4dfd2db-22d0-4c91-9c99-be335c80c80a@github.com>
References: <aPeF5Q3YPQx8g6uBkiXLNXE_f9PCR5XXqi-NzUw6HI0=.b4dfd2db-22d0-4c91-9c99-be335c80c80a@github.com>
Message-ID: <3vqLETJqP9A4f2YpzqBtFd4q2_zJxko9ZNQErsO9LtA=.4df78519-87c0-45c6-a83f-6b2b653bf92e@github.com>

On Mon, 12 Dec 2022 21:23:50 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> This issue is similar to JDK-8277493. Looks like macOS 13 cannot execute unsigned code and code should be at least ad hoc signed. Same as for macOS aarch64. Fixed by enabling ad hoc signing for macOS platform for both x64 and aarch64.

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR: https://git.openjdk.org/jdk20/pull/20

From almatvee at openjdk.org  Mon Dec 12 22:54:10 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 12 Dec 2022 22:54:10 GMT
Subject: [jdk20] Integrated: 8298488: [macos13] tools/jpackage tests failing
 with "Exit code: 137" on macOS
In-Reply-To: <aPeF5Q3YPQx8g6uBkiXLNXE_f9PCR5XXqi-NzUw6HI0=.b4dfd2db-22d0-4c91-9c99-be335c80c80a@github.com>
References: <aPeF5Q3YPQx8g6uBkiXLNXE_f9PCR5XXqi-NzUw6HI0=.b4dfd2db-22d0-4c91-9c99-be335c80c80a@github.com>
Message-ID: <7GPwu-NpurXEbvFpel_V3DxYU_ijA-jyxHMuWjW8BE8=.c5c80f65-e3e3-4f39-b068-fd74c39cbea0@github.com>

On Mon, 12 Dec 2022 21:23:50 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> This issue is similar to JDK-8277493. Looks like macOS 13 cannot execute unsigned code and code should be at least ad hoc signed. Same as for macOS aarch64. Fixed by enabling ad hoc signing for macOS platform for both x64 and aarch64.

This pull request has now been integrated.

Changeset: 8962c723
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/8962c723a8ae62a8638e9e0a89c20001aea1549a
Stats:     6 lines in 3 files changed: 0 ins; 4 del; 2 mod

8298488: [macos13] tools/jpackage tests failing with "Exit code: 137" on macOS

Reviewed-by: asemenyuk

-------------

PR: https://git.openjdk.org/jdk20/pull/20

From naoto at openjdk.org  Mon Dec 12 23:13:35 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 12 Dec 2022 23:13:35 GMT
Subject: RFR: 8298416: Console should be declared `sealed`
Message-ID: <CGOo7D3wTII2bpEbIU4VsWjMeHJsh0hGjOe_eBQYxjY=.948b2f0c-7466-420b-9756-2dcf92363bb7@github.com>

`Console` class now has a couple of internal subclasses within `java.io` package. It should be `sealed` and subclasses be declared in the `permits` clause.

-------------

Commit messages:
 - tidying up
 - sealed Console, impl/if separation

Changes: https://git.openjdk.org/jdk/pull/11615/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11615&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298416
  Stats: 625 lines in 2 files changed: 366 ins; 237 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/11615.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11615/head:pull/11615

PR: https://git.openjdk.org/jdk/pull/11615

From dholmes at openjdk.org  Tue Dec 13 00:39:54 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 13 Dec 2022 00:39:54 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v3]
In-Reply-To: <74wc2Xv-cLxguIN8cR2Ro688fzzSgHdckw6hNx7vlZc=.39d0d8af-0087-492c-9829-3a56e3d423c2@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <Jgz4iTse8EjQwWSoLLh2t4JdpnwX1OCloycHGKGY-o4=.620eb380-2b64-49c5-bf36-ecb6f633e35a@github.com>
 <14EWI1E4WrxvZUjR945PV5fmwns3BP-hZuFXivT3TPg=.3348f36d-e375-499f-83e5-cc507143927f@github.com>
 <74wc2Xv-cLxguIN8cR2Ro688fzzSgHdckw6hNx7vlZc=.39d0d8af-0087-492c-9829-3a56e3d423c2@github.com>
Message-ID: <i1MrD8E-76ppZSSOLcuu3fL7Pz7Bwt1b8WyvaOMDR3c=.60766176-7186-444b-b33d-3f623e5c0de8@github.com>

On Mon, 12 Dec 2022 08:04:57 GMT, Justin King <jcking at openjdk.org> wrote:

>> src/java.base/share/native/launcher/main.c line 41:
>> 
>>> 39: // extremely early during library loading, before main is called. We need to override the default
>>> 40: // options because by default UBSan only prints a warning for each occurrence. We want jtreg tests
>>> 41: // to fail when undefined behavior is encountered. We also want a full stack trace for the offending
>> 
>> If this is primarily for tests then can't we set the env-var in the test Makefile?
>
> Primarily, but its not a requirement. We should also be able to invoke `java` as is. The environment variables should be used to force specific behavior for a single invocation. Otherwise, if one forgets to pass the environment variables, things may not go as expected.

It really comes down to who we expect to do these ubsan builds and how we expect them to be used. If this is something explicit then using the env-var seems fine to me. I'm not sure why it needs to be enabled by default through this source modification.

I'd like to hear other opinions on this.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From jcking at openjdk.org  Tue Dec 13 03:43:58 2022
From: jcking at openjdk.org (Justin King)
Date: Tue, 13 Dec 2022 03:43:58 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v3]
In-Reply-To: <i1MrD8E-76ppZSSOLcuu3fL7Pz7Bwt1b8WyvaOMDR3c=.60766176-7186-444b-b33d-3f623e5c0de8@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <Jgz4iTse8EjQwWSoLLh2t4JdpnwX1OCloycHGKGY-o4=.620eb380-2b64-49c5-bf36-ecb6f633e35a@github.com>
 <14EWI1E4WrxvZUjR945PV5fmwns3BP-hZuFXivT3TPg=.3348f36d-e375-499f-83e5-cc507143927f@github.com>
 <74wc2Xv-cLxguIN8cR2Ro688fzzSgHdckw6hNx7vlZc=.39d0d8af-0087-492c-9829-3a56e3d423c2@github.com>
 <i1MrD8E-76ppZSSOLcuu3fL7Pz7Bwt1b8WyvaOMDR3c=.60766176-7186-444b-b33d-3f623e5c0de8@github.com>
Message-ID: <cUbGpZp4vbRPS6Yyx2UMAouXZX5GuAeJJNCNGpa6W5o=.9fb7a0b7-915b-470e-9348-98199615f58e@github.com>

On Tue, 13 Dec 2022 00:37:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Primarily, but its not a requirement. We should also be able to invoke `java` as is. The environment variables should be used to force specific behavior for a single invocation. Otherwise, if one forgets to pass the environment variables, things may not go as expected.
>
> It really comes down to who we expect to do these ubsan builds and how we expect them to be used. If this is something explicit then using the env-var seems fine to me. I'm not sure why it needs to be enabled by default through this source modification.
> 
> I'd like to hear other opinions on this.

Sure. It should be noted that whatever we do here for default options will likely have to be repeated for LSan and ASan eventually. So it should be repeatable and easy to maintain. IMO we should enforce strict defaults and then let manual invocations make it less strict via environment variables.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From serb at openjdk.org  Tue Dec 13 04:13:20 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 Dec 2022 04:13:20 GMT
Subject: RFR: 8290899: java/lang/String/StringRepeat.java test requests too
 much heap on windows x86
Message-ID: <rbTMWm4K6IURZtk_xvrnpwPnsUwBD4XvmQzQrOS86dQ=.6cb3dac8-815b-45ec-a6b0-8731ed18991b@github.com>

The `java/lang/String/StringRepeat.java` test was updated twice after integration:

https://bugs.openjdk.org/browse/JDK-8221400 - the xmx4g was replaced by the xmx2g
https://bugs.openjdk.org/browse/JDK-8265421 - the "os.maxMemory >= 2G" was added

Unfortunately, this test still may fail on Windows x86 due to: `Could not reserve enough space for xxx object heap.`

This is a request to exclude it on win x86 since that JDK cannot allocate 2g.

-------------

Commit messages:
 - 8290899: java/lang/String/StringRepeat.java test requests too much heap on windows x86

Changes: https://git.openjdk.org/jdk/pull/11639/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11639&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8290899
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11639.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11639/head:pull/11639

PR: https://git.openjdk.org/jdk/pull/11639

From jpai at openjdk.org  Tue Dec 13 04:39:13 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 13 Dec 2022 04:39:13 GMT
Subject: RFR: 8298416: Console should be declared `sealed`
In-Reply-To: <CGOo7D3wTII2bpEbIU4VsWjMeHJsh0hGjOe_eBQYxjY=.948b2f0c-7466-420b-9756-2dcf92363bb7@github.com>
References: <CGOo7D3wTII2bpEbIU4VsWjMeHJsh0hGjOe_eBQYxjY=.948b2f0c-7466-420b-9756-2dcf92363bb7@github.com>
Message-ID: <96HzdE1gX7EJuZe3XViTnRl2Xh4ElqVfkTTk5nNYFJw=.2b00fd82-143c-4eda-b826-eb60e6384da0@github.com>

On Fri, 9 Dec 2022 20:14:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> `Console` class now has a couple of internal subclasses within `java.io` package. It should be `sealed` and subclasses be declared in the `permits` clause. The implementation resided in `Console` class is separated into `ConsoleImpl` class.

src/java.base/share/classes/java/io/Console.java line 108:

> 106:     public PrintWriter writer() {
> 107:         throw new UnsupportedOperationException(
> 108:                 "Console class itself does not provide implementation");

Hello Naoto, should we perhaps then mark this method (and thus the class too) as `abstract` and leave the sub-classes to provide this method's implementation? Same with the other methods where we now throw `UnsupportedOperationException`.

-------------

PR: https://git.openjdk.org/jdk/pull/11615

From jpai at openjdk.org  Tue Dec 13 04:50:01 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 13 Dec 2022 04:50:01 GMT
Subject: RFR: 8298416: Console should be declared `sealed`
In-Reply-To: <CGOo7D3wTII2bpEbIU4VsWjMeHJsh0hGjOe_eBQYxjY=.948b2f0c-7466-420b-9756-2dcf92363bb7@github.com>
References: <CGOo7D3wTII2bpEbIU4VsWjMeHJsh0hGjOe_eBQYxjY=.948b2f0c-7466-420b-9756-2dcf92363bb7@github.com>
Message-ID: <XwHE4X68Ygu59aAKQYeSmN0hrP5Y26rz8lTRchC2zSg=.d74ef4d2-f925-41ff-a657-9b031276ceb7@github.com>

On Fri, 9 Dec 2022 20:14:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> `Console` class now has a couple of internal subclasses within `java.io` package. It should be `sealed` and subclasses be declared in the `permits` clause. The implementation resided in `Console` class is separated into `ConsoleImpl` class.

src/java.base/share/classes/java/io/ConsoleImpl.java line 198:

> 196:     private Writer out;
> 197:     private PrintWriter pw;
> 198:     private Formatter formatter;

It looks like we can mark `readLock`, `writeLock`, `reader`, `out`, `pw` and `formatter` as `final`.

-------------

PR: https://git.openjdk.org/jdk/pull/11615

From jpai at openjdk.org  Tue Dec 13 04:56:52 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 13 Dec 2022 04:56:52 GMT
Subject: RFR: 8290899: java/lang/String/StringRepeat.java test requests too
 much heap on windows x86
In-Reply-To: <rbTMWm4K6IURZtk_xvrnpwPnsUwBD4XvmQzQrOS86dQ=.6cb3dac8-815b-45ec-a6b0-8731ed18991b@github.com>
References: <rbTMWm4K6IURZtk_xvrnpwPnsUwBD4XvmQzQrOS86dQ=.6cb3dac8-815b-45ec-a6b0-8731ed18991b@github.com>
Message-ID: <JN1b5Ef20qPSGkh1YlHWo77iGl3P6yPdqzPUh7yHgGE=.5827fde1-f06d-4930-861a-da31d891af1f@github.com>

On Tue, 13 Dec 2022 00:06:00 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The `java/lang/String/StringRepeat.java` test was updated twice after integration:
> 
> https://bugs.openjdk.org/browse/JDK-8221400 - the xmx4g was replaced by the xmx2g
> https://bugs.openjdk.org/browse/JDK-8265421 - the "os.maxMemory >= 2G" was added
> 
> Unfortunately, this test still may fail on Windows x86 due to: `Could not reserve enough space for xxx object heap.`
> 
> This is a request to exclude it on win x86 since that JDK cannot allocate 2g.

Hello Sergey, the linked JBS issues note that this test takes at most 1400M. Should there be some investigation into why it's failing even with 2GB allowance?

-------------

PR: https://git.openjdk.org/jdk/pull/11639

From serb at openjdk.org  Tue Dec 13 05:33:56 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 Dec 2022 05:33:56 GMT
Subject: RFR: 8290899: java/lang/String/StringRepeat.java test requests too
 much heap on windows x86
In-Reply-To: <JN1b5Ef20qPSGkh1YlHWo77iGl3P6yPdqzPUh7yHgGE=.5827fde1-f06d-4930-861a-da31d891af1f@github.com>
References: <rbTMWm4K6IURZtk_xvrnpwPnsUwBD4XvmQzQrOS86dQ=.6cb3dac8-815b-45ec-a6b0-8731ed18991b@github.com>
 <JN1b5Ef20qPSGkh1YlHWo77iGl3P6yPdqzPUh7yHgGE=.5827fde1-f06d-4930-861a-da31d891af1f@github.com>
Message-ID: <oT8eCqI4nDATh5AsSRQ_5UuIrC7VOravU0VHXp_1_Nw=.53487623-af43-459c-901b-cfe81eb6ecd3@github.com>

On Tue, 13 Dec 2022 04:54:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Sergey, the linked JBS issues note that this test takes at most 1400M. Should there be some investigation into why it's failing even with 2GB allowance?

On windows x86 java fails even before the start of the test, it is just impossible to allocate 2g of memory.

jdk/bin/java -mx2g --version
Error occurred during initialization of VM
Could not reserve enough space for 2097152KB object heap

The maximum it can allocate is around `-mx1650m`, but using that caused the test to fail from time to time.

-------------

PR: https://git.openjdk.org/jdk/pull/11639

From jpai at openjdk.org  Tue Dec 13 05:47:51 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 13 Dec 2022 05:47:51 GMT
Subject: RFR: 8290899: java/lang/String/StringRepeat.java test requests too
 much heap on windows x86
In-Reply-To: <rbTMWm4K6IURZtk_xvrnpwPnsUwBD4XvmQzQrOS86dQ=.6cb3dac8-815b-45ec-a6b0-8731ed18991b@github.com>
References: <rbTMWm4K6IURZtk_xvrnpwPnsUwBD4XvmQzQrOS86dQ=.6cb3dac8-815b-45ec-a6b0-8731ed18991b@github.com>
Message-ID: <4zMW5m1jwuJkoloirNAX8gjj5bqqdUUipes1BSNkPkU=.432341ee-45b9-435d-a93a-98e140e52fa5@github.com>

On Tue, 13 Dec 2022 00:06:00 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The `java/lang/String/StringRepeat.java` test was updated twice after integration:
> 
> https://bugs.openjdk.org/browse/JDK-8221400 - the xmx4g was replaced by the xmx2g
> https://bugs.openjdk.org/browse/JDK-8265421 - the "os.maxMemory >= 2G" was added
> 
> Unfortunately, this test still may fail on Windows x86 due to: `Could not reserve enough space for xxx object heap.`
> 
> This is a request to exclude it on win x86 since that JDK cannot allocate 2g.

Thank you for that detail. The change looks fine to me then. I had to look if multiple `@requires` are supported in a test definition by jtreg and apparently it does support it:

https://openjdk.org/jtreg/tag-spec.html
> The @requires tag may be used multiple times in a given test. If it is used more than once, the expressions in the individual instances will be enclosed in parentheses and combined with '&'.

Please wait for another review before integrating, since I don't have previous experience with this test.

-------------

Marked as reviewed by jpai (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11639

From dholmes at openjdk.org  Tue Dec 13 06:53:54 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 13 Dec 2022 06:53:54 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v8]
In-Reply-To: <xy2Eago_3UXJFsvRNfJ4y3GLbfnvdSBEL8MEMLZLr44=.6fb62abf-a53b-4531-bcc6-42aaf74d030d@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <xy2Eago_3UXJFsvRNfJ4y3GLbfnvdSBEL8MEMLZLr44=.6fb62abf-a53b-4531-bcc6-42aaf74d030d@github.com>
Message-ID: <lYRnNA54XT8F0QeMfJSTWNy6qNXVyiYcySAqpKK7T34=.a74779f2-5059-43b6-a536-6077d199717b@github.com>

On Mon, 12 Dec 2022 10:42:22 GMT, Justin King <jcking at openjdk.org> wrote:

>> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify logic for including __ubsan_default_options
>   
>   Signed-off-by: Justin King <jcking at google.com>

I like this approach better in principle. Not sure about the location of the file - the build folk will no doubt have more to say on that. Can we not just have a single file and use:

#ifdef __cplusplus
extern "C" {
#endif

?
Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From alanb at openjdk.org  Tue Dec 13 08:01:02 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 Dec 2022 08:01:02 GMT
Subject: RFR: 8290899: java/lang/String/StringRepeat.java test requests too
 much heap on windows x86
In-Reply-To: <rbTMWm4K6IURZtk_xvrnpwPnsUwBD4XvmQzQrOS86dQ=.6cb3dac8-815b-45ec-a6b0-8731ed18991b@github.com>
References: <rbTMWm4K6IURZtk_xvrnpwPnsUwBD4XvmQzQrOS86dQ=.6cb3dac8-815b-45ec-a6b0-8731ed18991b@github.com>
Message-ID: <LGd3EwXchHeTtFiRJ5Gc0AlUQOdG-nqg2YPv7PPNBiw=.3ed73eff-d34c-4145-aa6b-353aee665a56@github.com>

On Tue, 13 Dec 2022 00:06:00 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The `java/lang/String/StringRepeat.java` test was updated twice after integration:
> 
> https://bugs.openjdk.org/browse/JDK-8221400 - the xmx4g was replaced by the xmx2g
> https://bugs.openjdk.org/browse/JDK-8265421 - the "os.maxMemory >= 2G" was added
> 
> Unfortunately, this test still may fail on Windows x86 due to: `Could not reserve enough space for xxx object heap.`
> 
> This is a request to exclude it on win x86 since that JDK cannot allocate 2g.

What you have looks okay if only Windows 32-bit is skipped but it might be simpler to just require sun.arch.data.model == "64" so that it only runs on 64-bit systems.

-------------

PR: https://git.openjdk.org/jdk/pull/11639

From jcking at openjdk.org  Tue Dec 13 08:20:44 2022
From: jcking at openjdk.org (Justin King)
Date: Tue, 13 Dec 2022 08:20:44 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v8]
In-Reply-To: <xy2Eago_3UXJFsvRNfJ4y3GLbfnvdSBEL8MEMLZLr44=.6fb62abf-a53b-4531-bcc6-42aaf74d030d@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <xy2Eago_3UXJFsvRNfJ4y3GLbfnvdSBEL8MEMLZLr44=.6fb62abf-a53b-4531-bcc6-42aaf74d030d@github.com>
Message-ID: <DL7yq_8qEzykUXtV7bDyyOzPMdmhOlKzXG5QGU8qwFs=.f1ce6b50-5b3c-4140-9991-567c5702a20d@github.com>

On Mon, 12 Dec 2022 10:42:22 GMT, Justin King <jcking at openjdk.org> wrote:

>> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify logic for including __ubsan_default_options
>   
>   Signed-off-by: Justin King <jcking at google.com>

I tried to use a single file, but the build logic attempts to compile as either C or C++ based on file extensions, and has logic based on it. So if I use `.cpp` and the target is all `.c` odd things happen. The same for the inverse.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From dsamersoff at openjdk.org  Tue Dec 13 08:25:51 2022
From: dsamersoff at openjdk.org (Dmitry Samersoff)
Date: Tue, 13 Dec 2022 08:25:51 GMT
Subject: RFR: 8293806: JDK_JAVA_OPTIONS picked up twice if launcher
 re-executes itself
In-Reply-To: <SbufrootYrUU0HrbOQkNVnylahFu05OhL3Eg3MjXAAU=.641a3900-82c8-4d7e-8fef-ee8443fb0470@github.com>
References: <OW6KaT2Vfefx_KOyDhIkVxSUOFtgiu6SCn3D8WM5PF8=.143804b1-22eb-4d9b-bf7c-1d3768a98308@github.com>
 <SbufrootYrUU0HrbOQkNVnylahFu05OhL3Eg3MjXAAU=.641a3900-82c8-4d7e-8fef-ee8443fb0470@github.com>
Message-ID: <5J29VPaWJxGXxrvcKrwP4gU9cNzknO-RA4Hc80H6v-s=.5b4a64a3-dc02-4506-b807-27f1d9bf5486@github.com>

On Thu, 8 Dec 2022 14:21:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> If the user has set LD_LIBRARY_PATH to use a particular libjvm.so, options from the JDK_JAVA_OPTIONS environment variable are picked up twice.
>> 
>> If an option cannot be accepted twice (e.g., -agentlib), the application fails to start.
>> 
>> The same happens on operating systems that doesn't support $RPATH/$ORIGIN and always have to set LD_LIBRARY_PATH and re-exec the launcher.
>> 
>> This fix takes the approach to re-launch as early as possible, as discussed here:
>> 
>> https://github.com/openjdk/jdk/pull/10430
>> 
>> This PR consists of three commits:
>> 1. Cleanup of java_md.c
>> 2. The implementation of early re-launch
>> 3. Performance optimization
>> 
>> @AlanBateman, @dholmes-ora Alan, David - any comments are appreciated.
>
> src/java.base/share/native/libjli/java.c line 368:
> 
>> 366: #endif
>> 367: 
>> 368:     JLI_SetTraceLauncher();
> 
> It's confusing to call JLI_SetTraceLauncher here as that is normally done by InitiLauncher.

Agree. Will file a separate CR for java_md.c cleanup.

-------------

PR: https://git.openjdk.org/jdk/pull/11538

From serb at openjdk.org  Tue Dec 13 09:07:07 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 Dec 2022 09:07:07 GMT
Subject: RFR: 8290899: java/lang/String/StringRepeat.java test requests too
 much heap on windows x86
In-Reply-To: <LGd3EwXchHeTtFiRJ5Gc0AlUQOdG-nqg2YPv7PPNBiw=.3ed73eff-d34c-4145-aa6b-353aee665a56@github.com>
References: <rbTMWm4K6IURZtk_xvrnpwPnsUwBD4XvmQzQrOS86dQ=.6cb3dac8-815b-45ec-a6b0-8731ed18991b@github.com>
 <LGd3EwXchHeTtFiRJ5Gc0AlUQOdG-nqg2YPv7PPNBiw=.3ed73eff-d34c-4145-aa6b-353aee665a56@github.com>
Message-ID: <UzLkCSouQenNdmksJ-vwv7rVJ2m5tDzgkWEgGCSg5EE=.5c9d5d9f-1c5b-4780-ba47-d8fd4f6c68a0@github.com>

On Tue, 13 Dec 2022 07:58:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> What you have looks okay if only Windows 32-bit is skipped but it might be simpler to just require sun.arch.data.model == "64" so that it only runs on 64-bit systems.

Right, but one of the fix for this test explicitly added support for x86
https://bugs.openjdk.org/browse/JDK-8221400
And on Linux x86 this test works fine.

-------------

PR: https://git.openjdk.org/jdk/pull/11639

From pminborg at openjdk.org  Tue Dec 13 09:20:10 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 13 Dec 2022 09:20:10 GMT
Subject: RFR: 8298639: Perform I/O operations in bulk for RandomAccessFile
Message-ID: <CSr3MHVxoI_YzG4NXS5apLiU3VTDavZh7URxs52x9wc=.c508ecdd-dae5-4ce6-9573-7786301bcd4b@github.com>

This PR suggests improving performance for read and write operations for the longer primitives in `RandomAccessFile`.

These improvements would also propagate to other JDK classes relying on these improved `RandomAccessFile` operations.

-------------

Commit messages:
 - Perform I/O operations in bulk for RandomAccessFile

Changes: https://git.openjdk.org/jdk/pull/11644/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11644&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298639
  Stats: 61 lines in 2 files changed: 19 ins; 16 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/11644.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11644/head:pull/11644

PR: https://git.openjdk.org/jdk/pull/11644

From pminborg at openjdk.org  Tue Dec 13 09:27:24 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 13 Dec 2022 09:27:24 GMT
Subject: RFR: 8298639: Perform I/O operations in bulk for RandomAccessFile
 [v2]
In-Reply-To: <CSr3MHVxoI_YzG4NXS5apLiU3VTDavZh7URxs52x9wc=.c508ecdd-dae5-4ce6-9573-7786301bcd4b@github.com>
References: <CSr3MHVxoI_YzG4NXS5apLiU3VTDavZh7URxs52x9wc=.c508ecdd-dae5-4ce6-9573-7786301bcd4b@github.com>
Message-ID: <WQF8Oae1zo1wNYbKgFt-ntMWqTKcogyCStkfCweV1ME=.eb768f80-07c7-456b-8614-ed49853d574c@github.com>

> This PR suggests improving performance for read and write operations for the longer primitives in `RandomAccessFile`.
> 
> These improvements would also propagate to other JDK classes relying on these improved `RandomAccessFile` operations.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge master
 - Perform I/O operations in bulk for RandomAccessFile

-------------

Changes: https://git.openjdk.org/jdk/pull/11644/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11644&range=01
  Stats: 61 lines in 2 files changed: 19 ins; 16 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/11644.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11644/head:pull/11644

PR: https://git.openjdk.org/jdk/pull/11644

From alanb at openjdk.org  Tue Dec 13 09:27:26 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 Dec 2022 09:27:26 GMT
Subject: RFR: 8298639: Perform I/O operations in bulk for RandomAccessFile
In-Reply-To: <CSr3MHVxoI_YzG4NXS5apLiU3VTDavZh7URxs52x9wc=.c508ecdd-dae5-4ce6-9573-7786301bcd4b@github.com>
References: <CSr3MHVxoI_YzG4NXS5apLiU3VTDavZh7URxs52x9wc=.c508ecdd-dae5-4ce6-9573-7786301bcd4b@github.com>
Message-ID: <t-ua8wYUO6H4Sa7r5l2YGCPOkckSGYpU-dk3bZLlU70=.c18e5980-9bb5-4be3-baa0-fc64eaf4b565@github.com>

On Tue, 13 Dec 2022 09:11:10 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests improving performance for read and write operations for the longer primitives in `RandomAccessFile`.
> 
> These improvements would also propagate to other JDK classes relying on these improved `RandomAccessFile` operations.

@stsypanov is working on the same thing in JDK-8292937 / PR10031.

-------------

PR: https://git.openjdk.org/jdk/pull/11644

From stsypanov at openjdk.org  Tue Dec 13 09:35:57 2022
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 13 Dec 2022 09:35:57 GMT
Subject: RFR: 8298639: Perform I/O operations in bulk for RandomAccessFile
 [v2]
In-Reply-To: <WQF8Oae1zo1wNYbKgFt-ntMWqTKcogyCStkfCweV1ME=.eb768f80-07c7-456b-8614-ed49853d574c@github.com>
References: <CSr3MHVxoI_YzG4NXS5apLiU3VTDavZh7URxs52x9wc=.c508ecdd-dae5-4ce6-9573-7786301bcd4b@github.com>
 <WQF8Oae1zo1wNYbKgFt-ntMWqTKcogyCStkfCweV1ME=.eb768f80-07c7-456b-8614-ed49853d574c@github.com>
Message-ID: <1gZwQiNAU5RtJQLRi4WlLj62Y-G1_fjL4LtTWy2K__g=.bd4e0cea-56d1-4d4e-ace8-4b991d842f19@github.com>

On Tue, 13 Dec 2022 09:27:24 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests improving performance for read and write operations for the longer primitives in `RandomAccessFile`.
>> 
>> These improvements would also propagate to other JDK classes relying on these improved `RandomAccessFile` operations.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge master
>  - Perform I/O operations in bulk for RandomAccessFile

As far as I understood https://github.com/openjdk/jdk/pull/10031 was closed because there we doubts about whether it's safe to use shared array

-------------

PR: https://git.openjdk.org/jdk/pull/11644

From dsamersoff at openjdk.org  Tue Dec 13 09:39:18 2022
From: dsamersoff at openjdk.org (Dmitry Samersoff)
Date: Tue, 13 Dec 2022 09:39:18 GMT
Subject: RFR: 8298638: Cleanup of unix java_md.c for better re-exec handling
Message-ID: <UqitH23_LetW3nTGVU_7m5SxPsrpMojdrdYOOnWeZFI=.bc783eec-1c8d-4b80-9ef4-d92cb4131825@github.com>

Move "unix" java_md.c cleanup, which is the prerequisites for the fix for JDK-8293806 (PR https://github.com/openjdk/jdk/pull/11538), to a separate PR.

@AlanBateman, @dholmes-ora please, take a look to the changes.

-------------

Commit messages:
 - 8298638: Cleanup of unix java_md.c for better re-exec handling

Changes: https://git.openjdk.org/jdk/pull/11645/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11645&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298638
  Stats: 114 lines in 1 file changed: 37 ins; 46 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/11645.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11645/head:pull/11645

PR: https://git.openjdk.org/jdk/pull/11645

From stsypanov at openjdk.org  Tue Dec 13 10:08:52 2022
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 13 Dec 2022 10:08:52 GMT
Subject: RFR: 8298639: Perform I/O operations in bulk for RandomAccessFile
 [v2]
In-Reply-To: <WQF8Oae1zo1wNYbKgFt-ntMWqTKcogyCStkfCweV1ME=.eb768f80-07c7-456b-8614-ed49853d574c@github.com>
References: <CSr3MHVxoI_YzG4NXS5apLiU3VTDavZh7URxs52x9wc=.c508ecdd-dae5-4ce6-9573-7786301bcd4b@github.com>
 <WQF8Oae1zo1wNYbKgFt-ntMWqTKcogyCStkfCweV1ME=.eb768f80-07c7-456b-8614-ed49853d574c@github.com>
Message-ID: <2mSI0ax7E90UrvMItvWlL841U_dp90Ws9HB4TmngqJc=.0a18f95e-2616-4140-addc-6c52eb4ba7e8@github.com>

On Tue, 13 Dec 2022 09:27:24 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests improving performance for read and write operations for the longer primitives in `RandomAccessFile`.
>> 
>> These improvements would also propagate to other JDK classes relying on these improved `RandomAccessFile` operations.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge master
>  - Perform I/O operations in bulk for RandomAccessFile

src/java.base/share/classes/java/io/RandomAccessFile.java line 930:

> 928:     public final long readLong() throws IOException {
> 929:         readFully(buffer, 0, Long.BYTES);
> 930:         return (((long)(buffer[0]       ) << 56) +

I think you can use `Bits.getLong()` here

-------------

PR: https://git.openjdk.org/jdk/pull/11644

From pminborg at openjdk.org  Tue Dec 13 11:30:04 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 13 Dec 2022 11:30:04 GMT
Subject: RFR: 8298532: Declare private constructors for FFM internal
 Architecture implementations
In-Reply-To: <o9cDzVMigJyXXlEch3KrdgjO-Xg2-rGnHlf2GmtIPIc=.500b1d50-288f-4c03-86f9-53be37101e85@github.com>
References: <o9cDzVMigJyXXlEch3KrdgjO-Xg2-rGnHlf2GmtIPIc=.500b1d50-288f-4c03-86f9-53be37101e85@github.com>
Message-ID: <SrVvEAocNybYEQ8IuJNKfNn9SOVKWF42K96YT-RnFHc=.2f29fe30-8ad4-460e-b5c4-7a1b30c65add@github.com>

On Mon, 12 Dec 2022 08:37:02 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes declaring `AArch64Architecture` and `X86_64Architecture` `final` and creating a `private` constructor so that this redundant byte code can be eliminated:
> 
> 
>  public jdk.internal.foreign.abi.x64.X86_64Architecture(); 
>     Code: 
>        0: aload_0 
>        1: invokespecial #1 // Method java/lang/Object."<init>":()V 
>        4: return 
> 
>  public jdk.internal.foreign.abi.aarch64.AArch64Architectur(); 
>     Code: 
>        0: aload_0 
>        1: invokespecial #1 // Method java/lang/Object."<init>":()V 
>        4: return 
> 
> 
> and other potential optimizations can be unlocked.

Closed in favour of https://github.com/openjdk/panama-foreign/pull/760

-------------

PR: https://git.openjdk.org/jdk/pull/11629

From pminborg at openjdk.org  Tue Dec 13 11:30:04 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 13 Dec 2022 11:30:04 GMT
Subject: Withdrawn: 8298532: Declare private constructors for FFM internal
 Architecture implementations
In-Reply-To: <o9cDzVMigJyXXlEch3KrdgjO-Xg2-rGnHlf2GmtIPIc=.500b1d50-288f-4c03-86f9-53be37101e85@github.com>
References: <o9cDzVMigJyXXlEch3KrdgjO-Xg2-rGnHlf2GmtIPIc=.500b1d50-288f-4c03-86f9-53be37101e85@github.com>
Message-ID: <ykn76ClpcLDxONZ1oMWNiZEQvyJqJtkWHWKnzOhZODA=.f2cabb03-a7f8-4e65-8da1-e13e3e0b9181@github.com>

On Mon, 12 Dec 2022 08:37:02 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes declaring `AArch64Architecture` and `X86_64Architecture` `final` and creating a `private` constructor so that this redundant byte code can be eliminated:
> 
> 
>  public jdk.internal.foreign.abi.x64.X86_64Architecture(); 
>     Code: 
>        0: aload_0 
>        1: invokespecial #1 // Method java/lang/Object."<init>":()V 
>        4: return 
> 
>  public jdk.internal.foreign.abi.aarch64.AArch64Architectur(); 
>     Code: 
>        0: aload_0 
>        1: invokespecial #1 // Method java/lang/Object."<init>":()V 
>        4: return 
> 
> 
> and other potential optimizations can be unlocked.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11629

From asotona at openjdk.org  Tue Dec 13 13:18:51 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 13 Dec 2022 13:18:51 GMT
Subject: RFR: [DRAFT] 8294982: Implementation of Classfile API [v4]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <5K3E1kGEdHozxYPMNNE26c930UkNX89nZb44uAnGaQo=.a82d4e88-7683-45c8-9fef-d1e59ceeaf72@github.com>

> **This pull request is not intended for immediate integration to JDK mainline.**
> 
> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/jdk/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  javadoc cleanup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/31fa159f..5345b451

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=02-03

  Stats: 463 lines in 27 files changed: 289 ins; 109 del; 65 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

PR: https://git.openjdk.org/jdk/pull/10982

From jwilhelm at openjdk.org  Tue Dec 13 13:41:06 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 13 Dec 2022 13:41:06 GMT
Subject: Withdrawn: Merge jdk20
In-Reply-To: <BxIryfRtcd7M9X0vYVs-m0ZBEpqyFwvoMcArBI_Up04=.86f53b97-d454-47a1-bf25-160472090a00@github.com>
References: <BxIryfRtcd7M9X0vYVs-m0ZBEpqyFwvoMcArBI_Up04=.86f53b97-d454-47a1-bf25-160472090a00@github.com>
Message-ID: <d0hE0JqHnWzwnepDeN29yqmt5RZn6M3d4f8-m6SkpjM=.dc7eec0f-fe88-4fb2-9308-c0d3c8a92b31@github.com>

On Mon, 12 Dec 2022 18:49:49 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11637

From erikj at openjdk.org  Tue Dec 13 13:47:42 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 13 Dec 2022 13:47:42 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v8]
In-Reply-To: <DL7yq_8qEzykUXtV7bDyyOzPMdmhOlKzXG5QGU8qwFs=.f1ce6b50-5b3c-4140-9991-567c5702a20d@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <xy2Eago_3UXJFsvRNfJ4y3GLbfnvdSBEL8MEMLZLr44=.6fb62abf-a53b-4531-bcc6-42aaf74d030d@github.com>
 <DL7yq_8qEzykUXtV7bDyyOzPMdmhOlKzXG5QGU8qwFs=.f1ce6b50-5b3c-4140-9991-567c5702a20d@github.com>
Message-ID: <XdfPstp0F5vxdL_LN9hkv_5DjJDJa_HoJWQuU9pHKPk=.7d60f2d0-3529-4770-959f-a8704695ac8c@github.com>

On Tue, 13 Dec 2022 08:17:09 GMT, Justin King <jcking at openjdk.org> wrote:

> I tried to use a single file, but the build logic attempts to compile as either C or C++ based on file extensions, and has logic based on it. So if I use `.cpp` and the target is all `.c` odd things happen. The same for the inverse.

What happens if you just always use a `.c` file for this? Won't the linker accept that?

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From jcking at openjdk.org  Tue Dec 13 13:47:44 2022
From: jcking at openjdk.org (Justin King)
Date: Tue, 13 Dec 2022 13:47:44 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v8]
In-Reply-To: <xy2Eago_3UXJFsvRNfJ4y3GLbfnvdSBEL8MEMLZLr44=.6fb62abf-a53b-4531-bcc6-42aaf74d030d@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <xy2Eago_3UXJFsvRNfJ4y3GLbfnvdSBEL8MEMLZLr44=.6fb62abf-a53b-4531-bcc6-42aaf74d030d@github.com>
Message-ID: <AjZ5Zs38Z9gGT-UYwOTCPR1vduuGDfgkt1QsVv7j6Ks=.100d2b3a-9112-44a3-b773-6c61d053f8ae@github.com>

On Mon, 12 Dec 2022 10:42:22 GMT, Justin King <jcking at openjdk.org> wrote:

>> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify logic for including __ubsan_default_options
>   
>   Signed-off-by: Justin King <jcking at google.com>

Nope. Some targets end up passing C++ flags to the C compiler, causing a
failure.

On Tue, Dec 13, 2022, 7:13 PM Erik Joelsson ***@***.***>
wrote:

> I tried to use a single file, but the build logic attempts to compile as
> either C or C++ based on file extensions, and has logic based on it. So if
> I use .cpp and the target is all .c odd things happen. The same for the
> inverse.
>
> What happens if you just always use a .c file for this? Won't the linker
> accept that?
>
> ?
> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jdk/pull/11604#issuecomment-1348591254>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAHTURUZMU2TVYAD6DH5N63WNB4QRANCNFSM6AAAAAASY75DP4>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From jwilhelm at openjdk.org  Tue Dec 13 14:03:29 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 13 Dec 2022 14:03:29 GMT
Subject: RFR: Merge jdk20
Message-ID: <SpKZ4RayXNrZIkyJXsXpquHbpqWmaeyrPOHOKFM2Mbc=.6b7ecb89-df7a-43d6-b5dc-50bd6d2075d8@github.com>

Forwardport JDK 20 -> JDK 21

-------------

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8298084: Memory leak in Method::build_profiling_method_data
 - 8296955: Kitchensink.java failed with "double free or corruption (!prev): <addr>"
 - 8298488: [macos13] tools/jpackage tests failing with "Exit code: 137" on macOS
 - 8297288: Example code in Scanner class
 - 8298271: java/security/SignedJar/spi-calendar-provider/TestSPISigned.java failing on Windows
 - 8298459: Fix msys2 linking and handling out of tree build directory for source zip creation

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=11651&range=00.0
 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=11651&range=00.1

Changes: https://git.openjdk.org/jdk/pull/11651/files
  Stats: 181 lines in 15 files changed: 60 ins; 57 del; 64 mod
  Patch: https://git.openjdk.org/jdk/pull/11651.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11651/head:pull/11651

PR: https://git.openjdk.org/jdk/pull/11651

From aph at openjdk.org  Tue Dec 13 14:33:07 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 13 Dec 2022 14:33:07 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v8]
In-Reply-To: <xy2Eago_3UXJFsvRNfJ4y3GLbfnvdSBEL8MEMLZLr44=.6fb62abf-a53b-4531-bcc6-42aaf74d030d@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <xy2Eago_3UXJFsvRNfJ4y3GLbfnvdSBEL8MEMLZLr44=.6fb62abf-a53b-4531-bcc6-42aaf74d030d@github.com>
Message-ID: <gKvrELlJs-MpSgD2SZwmHb_M6sESJjmYCRffUDTlreY=.fce6a6e1-668e-44e4-9029-45a3c4950ee4@github.com>

On Mon, 12 Dec 2022 10:42:22 GMT, Justin King <jcking at openjdk.org> wrote:

>> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify logic for including __ubsan_default_options
>   
>   Signed-off-by: Justin King <jcking at google.com>

I guess the advantage to putting this in the build machinery (as opposed to using
`--with-extra-cflags=-fsanitize=undefined --with-extra-ldflags=-fsanitize=undefined`) is that we can turn some of these onn by default once we've fixed each category of UB. Is that right?

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From matej.turcel at oracle.com  Tue Dec 13 15:46:59 2022
From: matej.turcel at oracle.com (Matej Turcel)
Date: Tue, 13 Dec 2022 16:46:59 +0100
Subject: jdeps - option to to analyze package-private API
In-Reply-To: <68ef4409-114d-b2d2-9f9f-fc3121c2f7ff@oracle.com>
References: <2dd880da-6ddc-302e-2e03-504b4171f484@oracle.com>
 <68ef4409-114d-b2d2-9f9f-fc3121c2f7ff@oracle.com>
Message-ID: <6a9221a2-d8e2-b619-41d7-1540a1ede70b@oracle.com>

On 12.12.2022 16:26, Alan Bateman wrote:
> The scenario seems a bit unusual in that API elements with package 
> access aren't usually considered to be part of the API.

Yes, they shouldn't be. But our code is not perfect and we have many 
cases where package-private elements de-facto are a part of the API.

> I realize Gradle may define "module" to mean something else but for 
> the Java platform, a module is a set of packages.

Gradle currently does not support specifying which packages are a part 
of the API, although according to the docs [1] this should be possible 
in a future release. However, doing so would require a massive effort on 
our side since we need to figure out which packages should be a part of 
the API and our codebase is quite large. But if we were to do this (and 
we may, as an intermediate step in our transition to jigsaw), the 
functionality I propose would be very helpful in doing so.

I may note that we only consider as API those packages, which are 
actually used from another module -- not everything package-private is 
automatically in the API.

[1] 
https://docs.gradle.org/current/userguide/java_library_plugin.html#sec:java_library_recognizing_dependencies 


> I haven't seen any opinions from others but my initial reaction is 
> that it wouldn't be a good idea to change --api-only to consider API 
> elements with package access to be part of the API. If jdeps were 
> changed then it would need a new option.
Of course, that was my idea as well. FYI, I have already implemented 
this change, and I would like to make these changes directly in OpenJDK 
as well to avoid maintenance burden. For example, JDK-8294969 will break 
my changes, so I will have to rewrite them when we switch to newer JDK.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221213/f2924ba3/attachment-0001.htm>

From jcking at openjdk.org  Tue Dec 13 16:32:03 2022
From: jcking at openjdk.org (Justin King)
Date: Tue, 13 Dec 2022 16:32:03 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v8]
In-Reply-To: <xy2Eago_3UXJFsvRNfJ4y3GLbfnvdSBEL8MEMLZLr44=.6fb62abf-a53b-4531-bcc6-42aaf74d030d@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <xy2Eago_3UXJFsvRNfJ4y3GLbfnvdSBEL8MEMLZLr44=.6fb62abf-a53b-4531-bcc6-42aaf74d030d@github.com>
Message-ID: <aW5easI6jtF4OD6CmknOfQlf0tmxFvtTqkcaeD0Css4=.1f8fd314-f615-47bf-a5f8-50741a59829e@github.com>

On Mon, 12 Dec 2022 10:42:22 GMT, Justin King <jcking at openjdk.org> wrote:

>> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify logic for including __ubsan_default_options
>   
>   Signed-off-by: Justin King <jcking at google.com>

Correct. We will be able to turn it on by default and enforce it, if w so
choose, for everything.

On Tue, Dec 13, 2022, 8:01 PM Andrew Haley ***@***.***> wrote:

> I guess the advantage to putting this in the build machinery (as opposed
> to using
> --with-extra-cflags=-fsanitize=undefined
> --with-extra-ldflags=-fsanitize=undefined) is that we can turn some of
> these onn by default once we've fixed each category of UB. Is that right?
>
> ?
> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jdk/pull/11604#issuecomment-1348688955>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAHTURUVY3ID7BA6BF77WZ3WNCCCVANCNFSM6AAAAAASY75DP4>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From jwilhelm at openjdk.org  Tue Dec 13 16:46:07 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 13 Dec 2022 16:46:07 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <SpKZ4RayXNrZIkyJXsXpquHbpqWmaeyrPOHOKFM2Mbc=.6b7ecb89-df7a-43d6-b5dc-50bd6d2075d8@github.com>
References: <SpKZ4RayXNrZIkyJXsXpquHbpqWmaeyrPOHOKFM2Mbc=.6b7ecb89-df7a-43d6-b5dc-50bd6d2075d8@github.com>
Message-ID: <LENLR7kTbJlO0PXG0D_YRgHDc0zYyJrge12segDYdeY=.6cf72ca8-4535-4bf4-ade7-d901366dcde9@github.com>

On Tue, 13 Dec 2022 13:55:12 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: 23e18275
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/23e18275ac2a7297ba806a1835fabb7141949967
Stats:     181 lines in 15 files changed: 60 ins; 57 del; 64 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/11651

From rehn at openjdk.org  Tue Dec 13 16:59:02 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 13 Dec 2022 16:59:02 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v8]
In-Reply-To: <aW5easI6jtF4OD6CmknOfQlf0tmxFvtTqkcaeD0Css4=.1f8fd314-f615-47bf-a5f8-50741a59829e@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <xy2Eago_3UXJFsvRNfJ4y3GLbfnvdSBEL8MEMLZLr44=.6fb62abf-a53b-4531-bcc6-42aaf74d030d@github.com>
 <aW5easI6jtF4OD6CmknOfQlf0tmxFvtTqkcaeD0Css4=.1f8fd314-f615-47bf-a5f8-50741a59829e@github.com>
Message-ID: <WScX-MiyrqoyVwoSQr6ZfVL7iBD2P1FRSdCCqFHuVLg=.c83bdf95-182b-48a7-8b97-ade1df652142@github.com>

On Tue, 13 Dec 2022 16:29:59 GMT, Justin King <jcking at openjdk.org> wrote:

> I guess the advantage to putting this in the build machinery (as opposed to using `--with-extra-cflags=-fsanitize=undefined --with-extra-ldflags=-fsanitize=undefined`) is that we can turn some of these onn by default once we've fixed each category of UB. Is that right?

It will take a while, look a bit on align issue, we have so much code which go from pointer to large -> small -> large, e.g.

    address addr = data() + offset;
    return (ImmutableOopMap*) addr;

In this case data() needs to return something with the same alignment as a ptr and offset must be in even in ptr steps.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From erikj at openjdk.org  Tue Dec 13 17:39:00 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 13 Dec 2022 17:39:00 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v8]
In-Reply-To: <AjZ5Zs38Z9gGT-UYwOTCPR1vduuGDfgkt1QsVv7j6Ks=.100d2b3a-9112-44a3-b773-6c61d053f8ae@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <xy2Eago_3UXJFsvRNfJ4y3GLbfnvdSBEL8MEMLZLr44=.6fb62abf-a53b-4531-bcc6-42aaf74d030d@github.com>
 <AjZ5Zs38Z9gGT-UYwOTCPR1vduuGDfgkt1QsVv7j6Ks=.100d2b3a-9112-44a3-b773-6c61d053f8ae@github.com>
Message-ID: <BsZxSAKahvlW0YOWIuF5W0UzbD88eSxM1_udeorx5bw=.577d1f0c-b073-48b4-81b4-d2e648036419@github.com>

On Tue, 13 Dec 2022 13:45:04 GMT, Justin King <jcking at openjdk.org> wrote:

> Nope. Some targets end up passing C++ flags to the C compiler, causing a failure.

Ah right, we (mis)use CFLAGS (instead of CXXFLAGS) in some SetupNativeCompilation calls when all source files are C++. In that case, your suggested patch makes sense to me.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From naoto at openjdk.org  Tue Dec 13 18:29:31 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 13 Dec 2022 18:29:31 GMT
Subject: RFR: 8298416: Console should be declared `sealed` [v2]
In-Reply-To: <CGOo7D3wTII2bpEbIU4VsWjMeHJsh0hGjOe_eBQYxjY=.948b2f0c-7466-420b-9756-2dcf92363bb7@github.com>
References: <CGOo7D3wTII2bpEbIU4VsWjMeHJsh0hGjOe_eBQYxjY=.948b2f0c-7466-420b-9756-2dcf92363bb7@github.com>
Message-ID: <ZP48r7aHQab9Eiirn6tmjORBkNybO7GkHdigMA_UXSM=.56fc365a-b12d-4ad0-bb6d-27eaf52edf09@github.com>

> `Console` class now has a couple of internal subclasses within `java.io` package. It should be `sealed` and subclasses be declared in the `permits` clause. The implementation resided in `Console` class is separated into `ConsoleImpl` class.

Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Making fields final, other clean-ups
 - Merge branch 'master' into JDK-8298416-SealedConsole
 - tidying up
 - sealed Console, impl/if separation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11615/files
  - new: https://git.openjdk.org/jdk/pull/11615/files/b5bc9f5e..a21798ff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11615&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11615&range=00-01

  Stats: 5674 lines in 220 files changed: 2650 ins; 2237 del; 787 mod
  Patch: https://git.openjdk.org/jdk/pull/11615.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11615/head:pull/11615

PR: https://git.openjdk.org/jdk/pull/11615

From naoto at openjdk.org  Tue Dec 13 18:44:58 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 13 Dec 2022 18:44:58 GMT
Subject: RFR: 8298416: Console should be declared `sealed` [v2]
In-Reply-To: <96HzdE1gX7EJuZe3XViTnRl2Xh4ElqVfkTTk5nNYFJw=.2b00fd82-143c-4eda-b826-eb60e6384da0@github.com>
References: <CGOo7D3wTII2bpEbIU4VsWjMeHJsh0hGjOe_eBQYxjY=.948b2f0c-7466-420b-9756-2dcf92363bb7@github.com>
 <96HzdE1gX7EJuZe3XViTnRl2Xh4ElqVfkTTk5nNYFJw=.2b00fd82-143c-4eda-b826-eb60e6384da0@github.com>
Message-ID: <-cQOkCpdsTC_qn9UaIHyB9lPe7iEwAOkKf-cZ-kPxmE=.5ae341f5-1e68-4d96-94be-5a5318c36ad6@github.com>

On Tue, 13 Dec 2022 04:36:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Making fields final, other clean-ups
>>  - Merge branch 'master' into JDK-8298416-SealedConsole
>>  - tidying up
>>  - sealed Console, impl/if separation
>
> src/java.base/share/classes/java/io/Console.java line 108:
> 
>> 106:     public PrintWriter writer() {
>> 107:         throw new UnsupportedOperationException(
>> 108:                 "Console class itself does not provide implementation");
> 
> Hello Naoto, should we perhaps then mark this method (and thus the class too) as `abstract` and leave the sub-classes to provide this method's implementation? Same with the other methods where we now throw `UnsupportedOperationException`.

Thanks for the review, Jai. You're right that making it `abstract` would eliminate implementations in `Console` class, but I was hesitant to do so, as it is a spec change that would suggest readers to think that `Console` is generally pluggable (which is not).

> src/java.base/share/classes/java/io/ConsoleImpl.java line 198:
> 
>> 196:     private Writer out;
>> 197:     private PrintWriter pw;
>> 198:     private Formatter formatter;
> 
> It looks like we can mark `readLock`, `writeLock`, `reader`, `out`, `pw` and `formatter` as `final`.

Made them `final` along with other fix-ups.

-------------

PR: https://git.openjdk.org/jdk/pull/11615

From bchristi at openjdk.org  Tue Dec 13 19:10:46 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 13 Dec 2022 19:10:46 GMT
Subject: [jdk20] Integrated: 8295857: Clarify that cleanup code can be skipped
 when the JVM terminates (e.g. when calling halt())
In-Reply-To: <IKcmMhqeJ_QAby4H73oBOUoYNpxNM7hVzF9NBqJ80-M=.8f9cc1c2-f78e-411b-bfd2-5f59bdad99ff@github.com>
References: <IKcmMhqeJ_QAby4H73oBOUoYNpxNM7hVzF9NBqJ80-M=.8f9cc1c2-f78e-411b-bfd2-5f59bdad99ff@github.com>
Message-ID: <q4dD4kGgWgClls6NROV5J4UH2a08g5UzRKm7DTAhthM=.15061e10-a831-422f-8336-e78ef955df76@github.com>

On Mon, 12 Dec 2022 19:51:22 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Backport [8295857](https://bugs.openjdk.org/browse/JDK-8295857) to jdk20

This pull request has now been integrated.

Changeset: bf78f716
Author:    Brent Christian <bchristi at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/bf78f716bd3e58df24ff1e6f4a0104025379f821
Stats:     10 lines in 1 file changed: 5 ins; 0 del; 5 mod

8295857: Clarify that cleanup code can be skipped when the JVM terminates (e.g. when calling halt())

Reviewed-by: iris
Backport-of: c7aca73177339f931f7dfb6627365548a32874f7

-------------

PR: https://git.openjdk.org/jdk20/pull/19

From alanb at openjdk.org  Tue Dec 13 19:59:57 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 Dec 2022 19:59:57 GMT
Subject: RFR: 8298639: Perform I/O operations in bulk for RandomAccessFile
 [v2]
In-Reply-To: <WQF8Oae1zo1wNYbKgFt-ntMWqTKcogyCStkfCweV1ME=.eb768f80-07c7-456b-8614-ed49853d574c@github.com>
References: <CSr3MHVxoI_YzG4NXS5apLiU3VTDavZh7URxs52x9wc=.c508ecdd-dae5-4ce6-9573-7786301bcd4b@github.com>
 <WQF8Oae1zo1wNYbKgFt-ntMWqTKcogyCStkfCweV1ME=.eb768f80-07c7-456b-8614-ed49853d574c@github.com>
Message-ID: <wMPXttVzNMhgfmEVqLH_vRXZ21_1Oh7kjpGEnTf1xag=.5417010b-116b-449c-9ad4-1f7c296e2d80@github.com>

On Tue, 13 Dec 2022 09:27:24 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests improving performance for read and write operations for the longer primitives in `RandomAccessFile`.
>> 
>> These improvements would also propagate to other JDK classes relying on these improved `RandomAccessFile` operations.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge master
>  - Perform I/O operations in bulk for RandomAccessFile

> As far as I understand #10031 was closed because there we doubts about whether it's safe to use shared array within multiple methods. Here we use the same approach.

I think that PR was closed as it went inactive but I think where you got to is very similar to what Per's change is now.

RandomAccessFile doesn't specify it but it can't be used from several threads without external synchronization. This is because it maintains a file position that is updated when reading and writing, or it can be changed when seeking to positions in the file. So on the surface, the byte[] should be okay.

-------------

PR: https://git.openjdk.org/jdk/pull/11644

From dholmes at openjdk.org  Wed Dec 14 01:05:59 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 14 Dec 2022 01:05:59 GMT
Subject: RFR: 8298638: Cleanup of unix java_md.c for better re-exec
 handling
In-Reply-To: <UqitH23_LetW3nTGVU_7m5SxPsrpMojdrdYOOnWeZFI=.bc783eec-1c8d-4b80-9ef4-d92cb4131825@github.com>
References: <UqitH23_LetW3nTGVU_7m5SxPsrpMojdrdYOOnWeZFI=.bc783eec-1c8d-4b80-9ef4-d92cb4131825@github.com>
Message-ID: <7Qhy0FBtbbTEjb3vLLam6pPLIeIug4LH8taW0GJ8nIs=.fa0c55f3-944e-4923-91ae-850bbcecc307@github.com>

On Tue, 13 Dec 2022 09:32:11 GMT, Dmitry Samersoff <dsamersoff at openjdk.org> wrote:

> Move "unix" java_md.c cleanup, which is the prerequisites for the fix for JDK-8293806 (PR https://github.com/openjdk/jdk/pull/11538), to a separate PR.
> 
> @AlanBateman, @dholmes-ora please, take a look to the changes.

I'm okay with getting rid of SETENV_REQUIRED, but adding in MinimalVM support is not needed nor appropriate IMO.

src/java.base/unix/native/libjli/java_md.c line 177:

> 175:     char clientPattern[] = "lib/client";
> 176:     char serverPattern[] = "lib/server";
> 177:     char minimalPattern[] = "lib/minimal";

I don't see any point in adding this when the MinimalVM is not really relevant to current JDK.

-------------

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11645

From jpai at openjdk.org  Wed Dec 14 02:21:32 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 14 Dec 2022 02:21:32 GMT
Subject: RFR: 8298416: Console should be declared `sealed` [v2]
In-Reply-To: <ZP48r7aHQab9Eiirn6tmjORBkNybO7GkHdigMA_UXSM=.56fc365a-b12d-4ad0-bb6d-27eaf52edf09@github.com>
References: <CGOo7D3wTII2bpEbIU4VsWjMeHJsh0hGjOe_eBQYxjY=.948b2f0c-7466-420b-9756-2dcf92363bb7@github.com>
 <ZP48r7aHQab9Eiirn6tmjORBkNybO7GkHdigMA_UXSM=.56fc365a-b12d-4ad0-bb6d-27eaf52edf09@github.com>
Message-ID: <jCTqJPXwVy3l0CFP2qBPmN1N5H7oUJH59Rr0P2Ak_W0=.2b84d40d-0ab5-43b8-bfc5-fd4255530393@github.com>

On Tue, 13 Dec 2022 18:29:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `Console` class now has a couple of internal subclasses within `java.io` package. It should be `sealed` and subclasses be declared in the `permits` clause. The implementation resided in `Console` class is separated into `ConsoleImpl` class.
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Making fields final, other clean-ups
>  - Merge branch 'master' into JDK-8298416-SealedConsole
>  - tidying up
>  - sealed Console, impl/if separation

Thank you Naoto for the changes, this looks fine to me.

src/java.base/share/classes/java/io/ConsoleImpl.java line 306:

> 304:                                 if (cbuf == rcb) {
> 305:                                     cbuf = grow();
> 306:                                     end = cbuf.length;

Initially this looked like an unintentionally change of logic to me, but when I see the current mainline code in IntelliJ, it does note that this assignment is then never used and it's right - after assigning `end` here, it never gets used and we ultimately end up with a `return` statement which is independent of this `end` value. So this change looks fine.

-------------

Marked as reviewed by jpai (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11615

From jpai at openjdk.org  Wed Dec 14 02:21:34 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 14 Dec 2022 02:21:34 GMT
Subject: RFR: 8298416: Console should be declared `sealed` [v2]
In-Reply-To: <-cQOkCpdsTC_qn9UaIHyB9lPe7iEwAOkKf-cZ-kPxmE=.5ae341f5-1e68-4d96-94be-5a5318c36ad6@github.com>
References: <CGOo7D3wTII2bpEbIU4VsWjMeHJsh0hGjOe_eBQYxjY=.948b2f0c-7466-420b-9756-2dcf92363bb7@github.com>
 <96HzdE1gX7EJuZe3XViTnRl2Xh4ElqVfkTTk5nNYFJw=.2b00fd82-143c-4eda-b826-eb60e6384da0@github.com>
 <-cQOkCpdsTC_qn9UaIHyB9lPe7iEwAOkKf-cZ-kPxmE=.5ae341f5-1e68-4d96-94be-5a5318c36ad6@github.com>
Message-ID: <NaYj8p7QOqKgGh9hHACLWR63XeMC2A13xm44qs0q6jc=.1cdbd0c8-df95-453f-80f3-0a5524e0ee96@github.com>

On Tue, 13 Dec 2022 18:42:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Console.java line 108:
>> 
>>> 106:     public PrintWriter writer() {
>>> 107:         throw new UnsupportedOperationException(
>>> 108:                 "Console class itself does not provide implementation");
>> 
>> Hello Naoto, should we perhaps then mark this method (and thus the class too) as `abstract` and leave the sub-classes to provide this method's implementation? Same with the other methods where we now throw `UnsupportedOperationException`.
>
> Thanks for the review, Jai. You're right that making it `abstract` would eliminate implementations in `Console` class, but I was hesitant to do so, as it is a spec change that would suggest readers to think that `Console` is generally pluggable (which is not).

That's reasonable and I think the current non-abstract form is fine then.

-------------

PR: https://git.openjdk.org/jdk/pull/11615

From ethan at mccue.dev  Wed Dec 14 03:36:53 2022
From: ethan at mccue.dev (Ethan McCue)
Date: Tue, 13 Dec 2022 22:36:53 -0500
Subject: Boilerplate to add a new module
Message-ID: <CA+NR86gQB+33FtsMbPzfMg80csrzbf3vMZMnRXPKP0=6E7iaiA@mail.gmail.com>

Hey all,

I'm doodling on JEP-198, and I was wondering if anyone had a line on the
boilerplate needed to add a new module to the build.

Just adding

src/
  java.json/
    share/
      classes/
        module-info.java
        java/
          json/
            Json.java
            ...

was enough to get it to show up under the output when I run "make images",
but I can't shake the feeling that I'm missing something.

(jtreg I assume has some extra setup? Anything else?)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221213/9090ab0c/attachment-0001.htm>

From mennen at openjdk.org  Wed Dec 14 03:47:06 2022
From: mennen at openjdk.org (Michael Ennen)
Date: Wed, 14 Dec 2022 03:47:06 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v39]
In-Reply-To: <hkjubM7yW4kkYAetu0kuCJy9wPQ_Llluj47lYXIc_8A=.2fc0c63b-d71f-4b18-af52-a6aa286b742d@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <-V_N0Cvh4J0vKNbBYdFcow9E8yFHRIjya8n69MpDSuY=.9626ee4d-95b6-41e4-b21e-395e79840388@github.com>
 <hkjubM7yW4kkYAetu0kuCJy9wPQ_Llluj47lYXIc_8A=.2fc0c63b-d71f-4b18-af52-a6aa286b742d@github.com>
Message-ID: <91WlM45Ykemls6D5vtXZMIIqjjECQTLVuJFhTLYXq-I=.4e670ac0-f1ff-480e-b18e-cea98d01bd6f@github.com>

On Mon, 5 Dec 2022 13:46:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix Preview annotation for JEP 434
>
> Note: there are 4 tests failing in x86:
> * MemoryLayoutPrincipalTotalityTest
> * MemoryLayoutTypeRetentionTest
> * TestLargeSegmentCopy
> * TestLinker
> 
> These failures are addressed in the dependent PR: https://git.openjdk.org/jdk/pull/11019, which will be integrated immediately after these changes

@mcimadamore This PR made my code in [java-vulkan](https://github.com/brcolow/java-vulkan/commit/171f167782eea538b19b60d5fa73e9f75a112f6d) much cleaner! Nice work!

-------------

PR: https://git.openjdk.org/jdk/pull/10872

From jcking at openjdk.org  Wed Dec 14 05:29:46 2022
From: jcking at openjdk.org (Justin King)
Date: Wed, 14 Dec 2022 05:29:46 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v8]
In-Reply-To: <WScX-MiyrqoyVwoSQr6ZfVL7iBD2P1FRSdCCqFHuVLg=.c83bdf95-182b-48a7-8b97-ade1df652142@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <xy2Eago_3UXJFsvRNfJ4y3GLbfnvdSBEL8MEMLZLr44=.6fb62abf-a53b-4531-bcc6-42aaf74d030d@github.com>
 <aW5easI6jtF4OD6CmknOfQlf0tmxFvtTqkcaeD0Css4=.1f8fd314-f615-47bf-a5f8-50741a59829e@github.com>
 <WScX-MiyrqoyVwoSQr6ZfVL7iBD2P1FRSdCCqFHuVLg=.c83bdf95-182b-48a7-8b97-ade1df652142@github.com>
Message-ID: <vla_CzqD3DuFO8l1mKhLIKdWqES_ep13Da658rGsai0=.a6c0a3a7-ecd0-45c0-9f24-98db4fef6ffd@github.com>

On Tue, 13 Dec 2022 16:55:09 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> > I guess the advantage to putting this in the build machinery (as opposed to using `--with-extra-cflags=-fsanitize=undefined --with-extra-ldflags=-fsanitize=undefined`) is that we can turn some of these onn by default once we've fixed each category of UB. Is that right?
> 
> It will take a while, look a bit on align issue, we have so much code which go from pointer to large -> small -> large, e.g.
> 
> ```
>     address addr = data() + offset;
>     return (ImmutableOopMap*) addr;
> ```
> 
> In this case data() needs to return something with the same alignment as a ptr and offset must be in even in ptr steps.

Yeah, some of the cases we may just have to suppress if they are not feasible to fix without lots of effort. My intention is to fix all the low hanging fruit, and then suppress the remaining cases. For the suppressed cases, I'll file P4 bugs for each one. Then if somebody feels like fixing them, they can do it.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From Alan.Bateman at oracle.com  Wed Dec 14 08:13:57 2022
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 14 Dec 2022 08:13:57 +0000
Subject: Boilerplate to add a new module
In-Reply-To: <CA+NR86gQB+33FtsMbPzfMg80csrzbf3vMZMnRXPKP0=6E7iaiA@mail.gmail.com>
References: <CA+NR86gQB+33FtsMbPzfMg80csrzbf3vMZMnRXPKP0=6E7iaiA@mail.gmail.com>
Message-ID: <d9b29180-820f-7bf8-3a15-cada1eafd24d@oracle.com>

On 14/12/2022 03:36, Ethan McCue wrote:
> Hey all,
>
> I'm doodling on JEP-198, and I was wondering if anyone had a line on 
> the boilerplate needed to add a new module to the build.
>
> Just adding
>
> src/
> ? java.json/
> ? ? share/
> ? ? ? classes/
> ? ? ? ? module-info.java
> ? ? ? ? java/
> ? ? ? ? ? json/
> ? ? ? ? ? ? Json.java
> ? ? ? ? ? ? ...
>
> was enough to get it to show up under the output when I run "make 
> images", but I can't shake the feeling that I'm missing something.

Modules with java.* classes must be mapped to the boot or platform class 
loader. That mapping is defined in make/conf/module-loader-map.conf.

java.se is the aggregator module for the APIs for ava SE platform. 
You'll see it has a `requires transitive` for each of the standard modules.

That should be enough to get your doodle going. As per previous mails, 
it's very likely that JEP-198 will be withdrawn or replaced with a new 
JEP, when the time comes.

-Alan.

From alanb at openjdk.org  Wed Dec 14 08:53:09 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Dec 2022 08:53:09 GMT
Subject: RFR: 8298416: Console should be declared `sealed` [v2]
In-Reply-To: <ZP48r7aHQab9Eiirn6tmjORBkNybO7GkHdigMA_UXSM=.56fc365a-b12d-4ad0-bb6d-27eaf52edf09@github.com>
References: <CGOo7D3wTII2bpEbIU4VsWjMeHJsh0hGjOe_eBQYxjY=.948b2f0c-7466-420b-9756-2dcf92363bb7@github.com>
 <ZP48r7aHQab9Eiirn6tmjORBkNybO7GkHdigMA_UXSM=.56fc365a-b12d-4ad0-bb6d-27eaf52edf09@github.com>
Message-ID: <DWWa5sitHXvDig-FUZBsEY-y-u3Zbbv9GJKUnVRYsRE=.f748c54c-bae9-429f-a919-8e76c3d9fdef@github.com>

On Tue, 13 Dec 2022 18:29:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `Console` class now has a couple of internal subclasses within `java.io` package. It should be `sealed` and subclasses be declared in the `permits` clause. The implementation resided in `Console` class is separated into `ConsoleImpl` class.
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Making fields final, other clean-ups
>  - Merge branch 'master' into JDK-8298416-SealedConsole
>  - tidying up
>  - sealed Console, impl/if separation

src/java.base/share/classes/java/io/Console.java line 359:

> 357:      * @return true if the previous console echo status is on
> 358:      */
> 359:     static native boolean echo(boolean on) throws IOException;

I think echo should move to ConsoleImpl too. It might be okay to leave the native method in Console_md.c, then it would be just renaming the JNI function.

src/java.base/share/classes/java/io/Console.java line 417:

> 415:     private static native boolean istty();
> 416: 
> 417:     Console() {}

What would you think about moving the no-arg constructor to the top of the method as it's not easy to spot.

src/java.base/share/classes/java/io/ConsoleImpl.java line 39:

> 37: 
> 38: final class ConsoleImpl extends Console
> 39: {

I assume the "{" can be moved to the previous line, it looks odd here.

-------------

PR: https://git.openjdk.org/jdk/pull/11615

From pminborg at openjdk.org  Wed Dec 14 09:33:57 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 14 Dec 2022 09:33:57 GMT
Subject: RFR: JDK-8298277: Replace "session" with "scope" for FFM access
 [v2]
In-Reply-To: <FodVyBalglGphWVzdtJXGcQp-ryoEYP47zk2TXMGY2U=.a2df7764-cdf3-4590-8480-a3625f2b17e3@github.com>
References: <YnNzM56870Nmq9AtyXDu0ESYWwcoYVEswRImv2kn_xk=.0cc70ffd-f0f0-4855-b6fa-ff32552846a8@github.com>
 <FodVyBalglGphWVzdtJXGcQp-ryoEYP47zk2TXMGY2U=.a2df7764-cdf3-4590-8480-a3625f2b17e3@github.com>
Message-ID: <064DG_AiCWN864SP7ms7J-LYw3Vhtvl-6ogBmwrCrPM=.dccaafbb-2d59-4f6f-894f-ebdea13b1b11@github.com>

On Thu, 8 Dec 2022 15:57:23 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes changing variable names and text from "session" to "scope". The proposed changes are only for the FFM API and not other parts like the Vector API and test classes.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes

Superseded by https://github.com/openjdk/jdk20/pull/29

-------------

PR: https://git.openjdk.org/jdk/pull/11593

From pminborg at openjdk.org  Wed Dec 14 09:33:57 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 14 Dec 2022 09:33:57 GMT
Subject: Withdrawn: JDK-8298277: Replace "session" with "scope" for FFM access
In-Reply-To: <YnNzM56870Nmq9AtyXDu0ESYWwcoYVEswRImv2kn_xk=.0cc70ffd-f0f0-4855-b6fa-ff32552846a8@github.com>
References: <YnNzM56870Nmq9AtyXDu0ESYWwcoYVEswRImv2kn_xk=.0cc70ffd-f0f0-4855-b6fa-ff32552846a8@github.com>
Message-ID: <lW2cnUco9t0uWDptU6FIofDBr0CkMxFliys71Jt0PSk=.00db127c-c026-4e78-89b6-07fbdb3c6930@github.com>

On Thu, 8 Dec 2022 14:11:29 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes changing variable names and text from "session" to "scope". The proposed changes are only for the FFM API and not other parts like the Vector API and test classes.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11593

From stsypanov at openjdk.org  Wed Dec 14 09:34:49 2022
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 14 Dec 2022 09:34:49 GMT
Subject: RFR: 8298639: Perform I/O operations in bulk for RandomAccessFile
 [v2]
In-Reply-To: <wMPXttVzNMhgfmEVqLH_vRXZ21_1Oh7kjpGEnTf1xag=.5417010b-116b-449c-9ad4-1f7c296e2d80@github.com>
References: <CSr3MHVxoI_YzG4NXS5apLiU3VTDavZh7URxs52x9wc=.c508ecdd-dae5-4ce6-9573-7786301bcd4b@github.com>
 <WQF8Oae1zo1wNYbKgFt-ntMWqTKcogyCStkfCweV1ME=.eb768f80-07c7-456b-8614-ed49853d574c@github.com>
 <wMPXttVzNMhgfmEVqLH_vRXZ21_1Oh7kjpGEnTf1xag=.5417010b-116b-449c-9ad4-1f7c296e2d80@github.com>
Message-ID: <7dzhmPJWrqsJpi8caHkbTGi19l7wvAUokYZmMA9f5uE=.d4c8dab0-4ea4-4af8-a1d8-cef58f0db963@github.com>

On Tue, 13 Dec 2022 19:57:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think that PR was closed as it went inactive

Yep, I think there I did everything I could, hope this one will be merged as the changes are helpful

-------------

PR: https://git.openjdk.org/jdk/pull/11644

From pminborg at openjdk.org  Wed Dec 14 09:38:20 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 14 Dec 2022 09:38:20 GMT
Subject: [jdk20] RFR: JDK-8298277: Replace "session" with "scope" for FFM
 access
Message-ID: <Vd9aDANBb28x1Fw9gDp3YPZ2wT37aEeYXwGxn4uHEUU=.0c9c2aa5-3fa4-4da2-9105-8366ce972d56@github.com>

This PR proposes changing variable names from `session` to `scope`. The proposed changes are only for the FFM API and not other parts like the Vector API and test classes.

-------------

Commit messages:
 - Replace session with scope for FFM access

Changes: https://git.openjdk.org/jdk20/pull/29/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=29&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298277
  Stats: 131 lines in 19 files changed: 0 ins; 0 del; 131 mod
  Patch: https://git.openjdk.org/jdk20/pull/29.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/29/head:pull/29

PR: https://git.openjdk.org/jdk20/pull/29

From alanb at openjdk.org  Wed Dec 14 09:54:13 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Dec 2022 09:54:13 GMT
Subject: RFR: 8298638: Cleanup of unix java_md.c for better re-exec
 handling
In-Reply-To: <7Qhy0FBtbbTEjb3vLLam6pPLIeIug4LH8taW0GJ8nIs=.fa0c55f3-944e-4923-91ae-850bbcecc307@github.com>
References: <UqitH23_LetW3nTGVU_7m5SxPsrpMojdrdYOOnWeZFI=.bc783eec-1c8d-4b80-9ef4-d92cb4131825@github.com>
 <7Qhy0FBtbbTEjb3vLLam6pPLIeIug4LH8taW0GJ8nIs=.fa0c55f3-944e-4923-91ae-850bbcecc307@github.com>
Message-ID: <TaHshA4rGKbmy2y4ULvvf8BEDiQCY3l3n-1FwXOxt98=.0c878574-49d3-4811-a5e3-8935fceb9d7b@github.com>

On Wed, 14 Dec 2022 00:59:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Move "unix" java_md.c cleanup, which is the prerequisites for the fix for JDK-8293806 (PR https://github.com/openjdk/jdk/pull/11538), to a separate PR.
>> 
>> @AlanBateman, @dholmes-ora please, take a look to the changes.
>
> src/java.base/unix/native/libjli/java_md.c line 177:
> 
>> 175:     char clientPattern[] = "lib/client";
>> 176:     char serverPattern[] = "lib/server";
>> 177:     char minimalPattern[] = "lib/minimal";
> 
> I don't see any point in adding this when the MinimalVM is not really relevant to current JDK.

Yeah, the minimal VM build probably needs wider discussion. There are bug reports when it breaks so some people are still building it. The context here seems to be that LD_LIBRARY_PATH set to a location that includes "lib/minimal" so somewhat unusual setup. It seems like it's a separate issue for discussion.

-------------

PR: https://git.openjdk.org/jdk/pull/11645

From mcimadamore at openjdk.org  Wed Dec 14 10:21:01 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 14 Dec 2022 10:21:01 GMT
Subject: [jdk20] RFR: JDK-8298277: Replace "session" with "scope" for FFM
 access
In-Reply-To: <Vd9aDANBb28x1Fw9gDp3YPZ2wT37aEeYXwGxn4uHEUU=.0c9c2aa5-3fa4-4da2-9105-8366ce972d56@github.com>
References: <Vd9aDANBb28x1Fw9gDp3YPZ2wT37aEeYXwGxn4uHEUU=.0c9c2aa5-3fa4-4da2-9105-8366ce972d56@github.com>
Message-ID: <LUqedmNBk5-Q8Xg_Vv3VYOuMbxrKb9rFFHIxh7xdTpU=.93f29fcf-6ae2-44a5-aa14-cf5ab68b243e@github.com>

On Wed, 14 Dec 2022 09:30:21 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes changing variable names from `session` to `scope`. The proposed changes are only for the FFM API and not other parts like the Vector API and test classes.

Looks good!

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/29

From redestad at openjdk.org  Wed Dec 14 11:30:20 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 14 Dec 2022 11:30:20 GMT
Subject: RFR: 8298590: Refactor LambdaForm constructors
In-Reply-To: <EVqdVtK45xq8NkbBSjQcpqi6hin9BXtcZplPDh7pjvI=.ab7c50b7-95e6-4263-8c2a-97be8890de63@github.com>
References: <EVqdVtK45xq8NkbBSjQcpqi6hin9BXtcZplPDh7pjvI=.ab7c50b7-95e6-4263-8c2a-97be8890de63@github.com>
Message-ID: <l5NVKnXTKwnMSGT5_UgQMXIFMHZ83tJRr2vnFZ0aTRk=.e2d2fd64-bd5a-44c1-9db2-a4e24e363b73@github.com>

On Fri, 9 Dec 2022 18:02:53 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Refactor LambdaForm constructors into static factories.
> 
> In the new code, there's only 1 constructor, which simply initializes all fields. Multiple factory methods are built on top of this, which add various argument validation/pre-processing and post processing of the constructed lambda forms.
> 
> In the LambdaFrom class itself, it is easier to see which LF creation goes through which checks due to names of factory, or if all checks are bypassed by calling the constructor.
> 
> New factories can easily be added that bypass all the checks in the existing factories and just call the root constructor if they so wish to (we likely want to add several for lazy lambda form resolution https://bugs.openjdk.org/browse/JDK-8288041).
> 
> Additionally: replaced some default values literals with named constants so it's easy to see that it's just the default value for that arg at the call site.

LGTM. Nice to get rid of the in-flight side-effect of mutating `LambdaForm::names` in `normalize`, which seemed suspect as `names` is marked as `@Stable`.

src/java.base/share/classes/java/lang/invoke/LambdaForm.java line 347:

> 345:     // root factory pre/post processing and calls simple cosntructor
> 346:     private static LambdaForm create(int arity, Name[] names, int result, boolean forceInline, MethodHandle customized, Kind kind) {
> 347:         names = names.clone();

Probably not important - and not for this RFE - but looking through the calls it seems that for some uses of `create` cloning the input array is superfluous. Maybe there's a very slight efficiency gain to be had here by making cloning the responsibility of the caller.

-------------

Marked as reviewed by redestad (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11612

From ethan at mccue.dev  Wed Dec 14 17:02:24 2022
From: ethan at mccue.dev (Ethan McCue)
Date: Wed, 14 Dec 2022 12:02:24 -0500
Subject: Boilerplate to add a new module
In-Reply-To: <d9b29180-820f-7bf8-3a15-cada1eafd24d@oracle.com>
References: <CA+NR86gQB+33FtsMbPzfMg80csrzbf3vMZMnRXPKP0=6E7iaiA@mail.gmail.com>
 <d9b29180-820f-7bf8-3a15-cada1eafd24d@oracle.com>
Message-ID: <CA+NR86jr8dBbkc_nOY9SRgJNPMtm=9_b_G+XZb=64ySZ-_jtPw@mail.gmail.com>

Thank you!

And yeah - I'll send a separate email opining on the directions that can
go.

The features that should be incorporated/designed for (value classes/string
templates/pattern matching) are more clearly in view than they were three
years ago when last it was brought up and certainly more real than in 2014
when the JEP was made - so I don't think this isn't a horrible time to
start some movement.

On Wed, Dec 14, 2022 at 3:14 AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 14/12/2022 03:36, Ethan McCue wrote:
> > Hey all,
> >
> > I'm doodling on JEP-198, and I was wondering if anyone had a line on
> > the boilerplate needed to add a new module to the build.
> >
> > Just adding
> >
> > src/
> >   java.json/
> >     share/
> >       classes/
> >         module-info.java
> >         java/
> >           json/
> >             Json.java
> >             ...
> >
> > was enough to get it to show up under the output when I run "make
> > images", but I can't shake the feeling that I'm missing something.
>
> Modules with java.* classes must be mapped to the boot or platform class
> loader. That mapping is defined in make/conf/module-loader-map.conf.
>
> java.se is the aggregator module for the APIs for ava SE platform.
> You'll see it has a `requires transitive` for each of the standard modules.
>
> That should be enough to get your doodle going. As per previous mails,
> it's very likely that JEP-198 will be withdrawn or replaced with a new
> JEP, when the time comes.
>
> -Alan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221214/7fdb234c/attachment.htm>

From ethan at mccue.dev  Wed Dec 14 17:07:31 2022
From: ethan at mccue.dev (Ethan McCue)
Date: Wed, 14 Dec 2022 12:07:31 -0500
Subject: Boilerplate to add a new module
In-Reply-To: <CA+NR86jr8dBbkc_nOY9SRgJNPMtm=9_b_G+XZb=64ySZ-_jtPw@mail.gmail.com>
References: <CA+NR86gQB+33FtsMbPzfMg80csrzbf3vMZMnRXPKP0=6E7iaiA@mail.gmail.com>
 <d9b29180-820f-7bf8-3a15-cada1eafd24d@oracle.com>
 <CA+NR86jr8dBbkc_nOY9SRgJNPMtm=9_b_G+XZb=64ySZ-_jtPw@mail.gmail.com>
Message-ID: <CA+NR86huJanw_k6WTbSmYEPxYb766gzwubi5RNwcn48zfnH8ug@mail.gmail.com>

Subtract one negative from that last clause

On Wed, Dec 14, 2022 at 12:02 PM Ethan McCue <ethan at mccue.dev> wrote:

> Thank you!
>
> And yeah - I'll send a separate email opining on the directions that can
> go.
>
> The features that should be incorporated/designed for (value
> classes/string templates/pattern matching) are more clearly in view than
> they were three years ago when last it was brought up and certainly more
> real than in 2014 when the JEP was made - so I don't think this isn't a
> horrible time to start some movement.
>
> On Wed, Dec 14, 2022 at 3:14 AM Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
>
>> On 14/12/2022 03:36, Ethan McCue wrote:
>> > Hey all,
>> >
>> > I'm doodling on JEP-198, and I was wondering if anyone had a line on
>> > the boilerplate needed to add a new module to the build.
>> >
>> > Just adding
>> >
>> > src/
>> >   java.json/
>> >     share/
>> >       classes/
>> >         module-info.java
>> >         java/
>> >           json/
>> >             Json.java
>> >             ...
>> >
>> > was enough to get it to show up under the output when I run "make
>> > images", but I can't shake the feeling that I'm missing something.
>>
>> Modules with java.* classes must be mapped to the boot or platform class
>> loader. That mapping is defined in make/conf/module-loader-map.conf.
>>
>> java.se is the aggregator module for the APIs for ava SE platform.
>> You'll see it has a `requires transitive` for each of the standard
>> modules.
>>
>> That should be enough to get your doodle going. As per previous mails,
>> it's very likely that JEP-198 will be withdrawn or replaced with a new
>> JEP, when the time comes.
>>
>> -Alan.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221214/2d7b8f98/attachment-0001.htm>

From naoto at openjdk.org  Wed Dec 14 17:35:46 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 14 Dec 2022 17:35:46 GMT
Subject: RFR: 8298416: Console should be declared `sealed` [v3]
In-Reply-To: <CGOo7D3wTII2bpEbIU4VsWjMeHJsh0hGjOe_eBQYxjY=.948b2f0c-7466-420b-9756-2dcf92363bb7@github.com>
References: <CGOo7D3wTII2bpEbIU4VsWjMeHJsh0hGjOe_eBQYxjY=.948b2f0c-7466-420b-9756-2dcf92363bb7@github.com>
Message-ID: <-rOAEdXfRLE6huOK1AvrDnz43lm_MQ1BmbNGHCiSEiQ=.60dbcdb7-699e-4550-beaa-4071ede43432@github.com>

> `Console` class now has a couple of internal subclasses within `java.io` package. It should be `sealed` and subclasses be declared in the `permits` clause. The implementation resided in `Console` class is separated into `ConsoleImpl` class.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Moved echo() to ConsoleImpl, clean-ups

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11615/files
  - new: https://git.openjdk.org/jdk/pull/11615/files/a21798ff..93945d6f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11615&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11615&range=01-02

  Stats: 33 lines in 3 files changed: 14 ins; 11 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/11615.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11615/head:pull/11615

PR: https://git.openjdk.org/jdk/pull/11615

From naoto at openjdk.org  Wed Dec 14 17:35:49 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 14 Dec 2022 17:35:49 GMT
Subject: RFR: 8298416: Console should be declared `sealed` [v2]
In-Reply-To: <DWWa5sitHXvDig-FUZBsEY-y-u3Zbbv9GJKUnVRYsRE=.f748c54c-bae9-429f-a919-8e76c3d9fdef@github.com>
References: <CGOo7D3wTII2bpEbIU4VsWjMeHJsh0hGjOe_eBQYxjY=.948b2f0c-7466-420b-9756-2dcf92363bb7@github.com>
 <ZP48r7aHQab9Eiirn6tmjORBkNybO7GkHdigMA_UXSM=.56fc365a-b12d-4ad0-bb6d-27eaf52edf09@github.com>
 <DWWa5sitHXvDig-FUZBsEY-y-u3Zbbv9GJKUnVRYsRE=.f748c54c-bae9-429f-a919-8e76c3d9fdef@github.com>
Message-ID: <oTJZJPYhZYcIvDLeKOdqNLOA54bQtaRs1emjt6P6KVA=.9b5d96b1-45a7-43ad-a603-1f118b88219b@github.com>

On Wed, 14 Dec 2022 08:46:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Making fields final, other clean-ups
>>  - Merge branch 'master' into JDK-8298416-SealedConsole
>>  - tidying up
>>  - sealed Console, impl/if separation
>
> src/java.base/share/classes/java/io/Console.java line 359:
> 
>> 357:      * @return true if the previous console echo status is on
>> 358:      */
>> 359:     static native boolean echo(boolean on) throws IOException;
> 
> I think echo should move to ConsoleImpl too. It might be okay to leave the native method in Console_md.c, then it would be just renaming the JNI function.

Moved the method into ConsoleImpl

-------------

PR: https://git.openjdk.org/jdk/pull/11615

From naoto at openjdk.org  Wed Dec 14 17:35:49 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 14 Dec 2022 17:35:49 GMT
Subject: RFR: 8298416: Console should be declared `sealed` [v3]
In-Reply-To: <jCTqJPXwVy3l0CFP2qBPmN1N5H7oUJH59Rr0P2Ak_W0=.2b84d40d-0ab5-43b8-bfc5-fd4255530393@github.com>
References: <CGOo7D3wTII2bpEbIU4VsWjMeHJsh0hGjOe_eBQYxjY=.948b2f0c-7466-420b-9756-2dcf92363bb7@github.com>
 <ZP48r7aHQab9Eiirn6tmjORBkNybO7GkHdigMA_UXSM=.56fc365a-b12d-4ad0-bb6d-27eaf52edf09@github.com>
 <jCTqJPXwVy3l0CFP2qBPmN1N5H7oUJH59Rr0P2Ak_W0=.2b84d40d-0ab5-43b8-bfc5-fd4255530393@github.com>
Message-ID: <TZl0JH49HTnqONhbBXwEuum4LIiCw22uPXNy-M9Cfew=.664997af-1ae2-443e-bf3d-781c999e490a@github.com>

On Wed, 14 Dec 2022 02:16:41 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Moved echo() to ConsoleImpl, clean-ups
>
> src/java.base/share/classes/java/io/ConsoleImpl.java line 306:
> 
>> 304:                                 if (cbuf == rcb) {
>> 305:                                     cbuf = grow();
>> 306:                                     end = cbuf.length;
> 
> Initially this looked like an unintentionally change of logic to me, but when I see the current mainline code in IntelliJ, it does note that this assignment is then never used and it's right - after assigning `end` here, it never gets used and we ultimately end up with a `return` statement which is independent of this `end` value. So this change looks fine.

In fact, that was suggested by IntelliJ ?

-------------

PR: https://git.openjdk.org/jdk/pull/11615

From pminborg at openjdk.org  Wed Dec 14 21:44:08 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 14 Dec 2022 21:44:08 GMT
Subject: [jdk20] Integrated: JDK-8298277: Replace "session" with "scope" for
 FFM access
In-Reply-To: <Vd9aDANBb28x1Fw9gDp3YPZ2wT37aEeYXwGxn4uHEUU=.0c9c2aa5-3fa4-4da2-9105-8366ce972d56@github.com>
References: <Vd9aDANBb28x1Fw9gDp3YPZ2wT37aEeYXwGxn4uHEUU=.0c9c2aa5-3fa4-4da2-9105-8366ce972d56@github.com>
Message-ID: <cKJU_C9OZLAqASALHbcrdPK5Myr5Vedr5lLZ6sWTxDM=.6fc218e9-dc64-49a9-9201-94a45e5cca19@github.com>

On Wed, 14 Dec 2022 09:30:21 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes changing variable names from `session` to `scope`. The proposed changes are only for the FFM API and not other parts like the Vector API and test classes.

This pull request has now been integrated.

Changeset: ebc47104
Author:    Per Minborg <pminborg at openjdk.org>
Committer: Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/ebc471040e03dc41829d57e1280cabd75b2ad53a
Stats:     131 lines in 19 files changed: 0 ins; 0 del; 131 mod

8298277: Replace "session" with "scope" for FFM access

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk20/pull/29

From jwilhelm at openjdk.org  Wed Dec 14 22:47:06 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 14 Dec 2022 22:47:06 GMT
Subject: RFR: Merge jdk20
Message-ID: <8p3Jcug89v8O_mG-nx7UEAkr5VSsr7GG47LCn3gaF2c=.73ad0d26-f212-4358-b9fd-4a7b47839c3c@github.com>

Forwardport JDK 20 -> JDK 21

-------------

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8298785: gc/TestFullGCCount.java fails with "invalid boolean value: `null' for expression `vm.opt.ExplicitGCInvokesConcurrent'"
 - 8298277: Replace "session" with "scope" for FFM access

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jdk/pull/11683/files
  Stats: 132 lines in 20 files changed: 0 ins; 0 del; 132 mod
  Patch: https://git.openjdk.org/jdk/pull/11683.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11683/head:pull/11683

PR: https://git.openjdk.org/jdk/pull/11683

From naoto at openjdk.org  Wed Dec 14 23:21:44 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 14 Dec 2022 23:21:44 GMT
Subject: RFR: 8298808: Check `script` code on detecting the base locales
Message-ID: <-y3oZIKk1c7lLT9v6xYmNaOWr0aoKChLz5erO0Mx9vs=.02bc4c39-8d21-4aaa-ac95-0f7e28c21a43@github.com>

Fixing `CLDRConverter` build tool to not regard [new locales](https://github.com/unicode-org/cldr/pull/2508/files#diff-94cbefde02914335da884f768063a06a84ad651ee4e56cdb1cb90625d7776731) introduced in CLDR 43 as one of the base locales. Otherwise they would incorrectly go into `java.base` module, then a test case fails.

-------------

Commit messages:
 - 8298808: Check `script` code on detecting the base locales

Changes: https://git.openjdk.org/jdk/pull/11684/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11684&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298808
  Stats: 12 lines in 2 files changed: 9 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11684.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11684/head:pull/11684

PR: https://git.openjdk.org/jdk/pull/11684

From naoto at openjdk.org  Wed Dec 14 23:47:43 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 14 Dec 2022 23:47:43 GMT
Subject: RFR: 8298808: Check `script` code on detecting the base locales
 [v2]
In-Reply-To: <-y3oZIKk1c7lLT9v6xYmNaOWr0aoKChLz5erO0Mx9vs=.02bc4c39-8d21-4aaa-ac95-0f7e28c21a43@github.com>
References: <-y3oZIKk1c7lLT9v6xYmNaOWr0aoKChLz5erO0Mx9vs=.02bc4c39-8d21-4aaa-ac95-0f7e28c21a43@github.com>
Message-ID: <fCe2qY1mZZAih3y9VNmromWJLUrchaw-sm2VT1XqvuY=.dd45a913-3b68-40ab-935a-933e7020a1af@github.com>

> Fixing `CLDRConverter` build tool to not regard [new locales](https://github.com/unicode-org/cldr/pull/2508/files#diff-94cbefde02914335da884f768063a06a84ad651ee4e56cdb1cb90625d7776731) introduced in CLDR 43 as one of the base locales. Otherwise they would incorrectly go into `java.base` module, then a test case fails.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Allow Latin script by default

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11684/files
  - new: https://git.openjdk.org/jdk/pull/11684/files/28b01e21..9191b601

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11684&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11684&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11684.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11684/head:pull/11684

PR: https://git.openjdk.org/jdk/pull/11684

From dnguyen at openjdk.org  Wed Dec 14 23:47:55 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 14 Dec 2022 23:47:55 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop
 10
Message-ID: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>

Open l10n drop
All tests passed

-------------

Commit messages:
 - open l10n drop

Changes: https://git.openjdk.org/jdk20/pull/35/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298133
  Stats: 1177 lines in 110 files changed: 783 ins; 207 del; 187 mod
  Patch: https://git.openjdk.org/jdk20/pull/35.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35

PR: https://git.openjdk.org/jdk20/pull/35

From achung at openjdk.org  Thu Dec 15 00:07:04 2022
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 15 Dec 2022 00:07:04 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <Sfe4uUeYHsI1HUSpkDyn-dbJiiReR3yQCyzrBo1H_7k=.52ee8dbe-28b5-4b59-a4d9-3b2dda6ac0b8@github.com>

On Wed, 14 Dec 2022 23:40:52 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Open l10n drop
> All tests passed

looks good

-------------

Marked as reviewed by achung (Committer).

PR: https://git.openjdk.org/jdk20/pull/35

From duke at openjdk.org  Thu Dec 15 01:01:05 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 15 Dec 2022 01:01:05 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <k7G3LUpn1hYfFwASwRuATz0OVhWJEBaqAFSo-7zK4rI=.c4a1b71d-93a7-4d08-b379-baf63a09ed31@github.com>

On Wed, 14 Dec 2022 23:40:52 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Open l10n drop
> All tests passed

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties line 188:

> 186: main.plugin.module=\u63D2\u4EF6\u6A21\u5757
> 187: 
> 188: main.plugin.category=\u7C7B\u522B 

As Naoto pointed out, it looks like a trailing space was added by accident. This is also done in the ja version but for a different value. And no space was added for any value for the de version. It looks like the translation drop that Damon is receiving contains random changes.

-------------

PR: https://git.openjdk.org/jdk20/pull/35

From duke at openjdk.org  Thu Dec 15 01:07:14 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 15 Dec 2022 01:07:14 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <d95C1dlJ8bWMdxqTxzNFfJ8wIfXUWprXL1Mj8EhLiaM=.2215541c-f86e-4a46-9e49-9a2a1f2f1e63@github.com>

On Wed, 14 Dec 2022 23:40:52 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Open l10n drop
> All tests passed

src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_de.properties line 26:

> 24: #
> 25: 
> 26: jmod.description=JMOD-Dateien erstellen und den Inhalt vorhandener JMOD-Dateien auflisten

`jlink.description` was added to `jmod.properties` in May 2022 (Which was before Alisen's drop for JDK19). Shouldn't this have been translated during the 19 drop in August, as opposed to showing up now?

-------------

PR: https://git.openjdk.org/jdk20/pull/35

From duke at openjdk.org  Thu Dec 15 01:16:13 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 15 Dec 2022 01:16:13 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10
In-Reply-To: <k7G3LUpn1hYfFwASwRuATz0OVhWJEBaqAFSo-7zK4rI=.c4a1b71d-93a7-4d08-b379-baf63a09ed31@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <k7G3LUpn1hYfFwASwRuATz0OVhWJEBaqAFSo-7zK4rI=.c4a1b71d-93a7-4d08-b379-baf63a09ed31@github.com>
Message-ID: <gt3H8LBSGCmyftDD3Oyzx_BXZgZzvQtJq4pDIWFQnQY=.fbc90067-e182-490f-85e4-f302ae7cfd64@github.com>

On Thu, 15 Dec 2022 00:58:06 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties line 188:
> 
>> 186: main.plugin.module=\u63D2\u4EF6\u6A21\u5757
>> 187: 
>> 188: main.plugin.category=\u7C7B\u522B 
> 
> As Naoto pointed out, it looks like a trailing space was added by accident. This is also done in the ja version but for a different value. And no space was added for any value for the de version. It looks like the translation drop that Damon is receiving contains random changes.

Additionally, there were changes made to plugins.properties in October that were not translated in the translation drop

-------------

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Thu Dec 15 02:26:12 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 15 Dec 2022 02:26:12 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10
In-Reply-To: <d95C1dlJ8bWMdxqTxzNFfJ8wIfXUWprXL1Mj8EhLiaM=.2215541c-f86e-4a46-9e49-9a2a1f2f1e63@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <d95C1dlJ8bWMdxqTxzNFfJ8wIfXUWprXL1Mj8EhLiaM=.2215541c-f86e-4a46-9e49-9a2a1f2f1e63@github.com>
Message-ID: <QB_rvT43I38Ksdn8YuHCvzPrTNTua2287iebkdsNakM=.0656bf7b-2eed-4858-ad71-a5ffecdad65b@github.com>

On Thu, 15 Dec 2022 01:04:12 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_de.properties line 26:
> 
>> 24: #
>> 25: 
>> 26: jmod.description=JMOD-Dateien erstellen und den Inhalt vorhandener JMOD-Dateien auflisten
> 
> `jlink.description` was added to `jmod.properties` in May 2022 (Which was before Alisen's drop for JDK19). Shouldn't this have been translated during the 19 drop in August, as opposed to showing up now?

I see the date of [that PR](https://github.com/openjdk/jdk/pull/8772) as well. Looks like it was integrated on May 19.

I'm contacting Kate Gavin to determine why some translations seem to sometimes be delayed. As you mentioned in the other comment, there are a few instances where text was added between the last drop & this drop, but weren't translated.

And as you showed here, this should have been translated in the last drop rather than this one, but showed up here. I need a response from Kate to clarify when these translations are generated.

-------------

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Thu Dec 15 02:45:48 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 15 Dec 2022 02:45:48 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <td2m9lDu24tKE3INK9xXuzPGPPNVoHfQYwzgCBkTF2Y=.3f4f2fd3-276e-4f27-a9fb-6bb7bea1a608@github.com>

> Open l10n drop
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Removed trailing whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/35/files
  - new: https://git.openjdk.org/jdk20/pull/35/files/39511b7a..54d2ec5f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk20/pull/35.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35

PR: https://git.openjdk.org/jdk20/pull/35

From jwilhelm at openjdk.org  Thu Dec 15 06:40:11 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Thu, 15 Dec 2022 06:40:11 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <8p3Jcug89v8O_mG-nx7UEAkr5VSsr7GG47LCn3gaF2c=.73ad0d26-f212-4358-b9fd-4a7b47839c3c@github.com>
References: <8p3Jcug89v8O_mG-nx7UEAkr5VSsr7GG47LCn3gaF2c=.73ad0d26-f212-4358-b9fd-4a7b47839c3c@github.com>
Message-ID: <MpqHYdq2CoIApvCNjwNvNA1lKnmaCU9cj6NJnaa6tnA=.ab62bb74-f8d1-4604-b355-24e9fa68bff4@github.com>

On Wed, 14 Dec 2022 22:39:44 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: 10bc86cc
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/10bc86cc260fac48bf10f67dd56aa73c6954f026
Stats:     132 lines in 20 files changed: 0 ins; 0 del; 132 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/11683

From jpai at openjdk.org  Thu Dec 15 06:48:09 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 15 Dec 2022 06:48:09 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v2]
In-Reply-To: <L0YQ-HpkzstQ-kaNwoO3BxLqgcluDK5Lzt8R9c9ZGSs=.637129c6-047c-4197-8ed2-70d0a203ec90@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <L0YQ-HpkzstQ-kaNwoO3BxLqgcluDK5Lzt8R9c9ZGSs=.637129c6-047c-4197-8ed2-70d0a203ec90@github.com>
Message-ID: <WXmNZhZPiiv_uma2xU6mJcF-DwkY3P267rnKZt2gOMg=.927cd9e8-94a4-459d-9ddc-efb4d7c15c2a@github.com>

On Mon, 12 Dec 2022 20:53:27 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> This is an approach to adding a flag to jlink that will allow --compress to take the same types of arguments as jmod, thus bringing the two into alignment. This likely requires a CSR and a discussion on whether we should deprecate or simply remove the original numeric compression arguments.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Swapping deprecations in properties

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/DefaultCompressPlugin.java line 27:

> 25: package jdk.tools.jlink.internal.plugins;
> 26: 
> 27: import java.text.NumberFormat;

I suspect this is an unused import?

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/DefaultCompressPlugin.java line 111:

> 109:                             zip = new ZipPlugin(resFilter, zipLevel);
> 110:                             break;
> 111:                         } catch (NumberFormatException ignored) {}

Hello Ian, previously before this change (and even now for non `zip-` values) we throw an `IllegalArgumentException` if the value for compression level is incorrect. Should we do the same for wrong values of `zip-` and throw `IllegalArgumentException` when we catch a `NumberFormatException`?

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ZipPlugin.java line 49:

> 47: 
> 48:     private static final int DEFAULT_COMPRESSION = 6;
> 49:     private int compressionLevel;

Perhaps we could mark this as `final`?

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From jpai at openjdk.org  Thu Dec 15 07:00:08 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 15 Dec 2022 07:00:08 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v2]
In-Reply-To: <L0YQ-HpkzstQ-kaNwoO3BxLqgcluDK5Lzt8R9c9ZGSs=.637129c6-047c-4197-8ed2-70d0a203ec90@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <L0YQ-HpkzstQ-kaNwoO3BxLqgcluDK5Lzt8R9c9ZGSs=.637129c6-047c-4197-8ed2-70d0a203ec90@github.com>
Message-ID: <nMGAVNtVpo4j1Q-1YwFzVEJSoqkji4c7AvFsce4Bx50=.243b2540-1bc8-4c67-a845-cbfdc6148f10@github.com>

On Mon, 12 Dec 2022 20:53:27 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> This is an approach to adding a flag to jlink that will allow --compress to take the same types of arguments as jmod, thus bringing the two into alignment. This likely requires a CSR and a discussion on whether we should deprecate or simply remove the original numeric compression arguments.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Swapping deprecations in properties

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties line 73:

> 71: 
> 72: compress.usage=\
> 73: \  --compress <0|1|2|zip-[0-9]>[:filter=<pattern-list>]\n\

This is a bit odd - when I run the `jlink`  command against latest mainline, I don't see the `[:filter=<pattern-list>]` being displayed in the help output nor do I see the message which states `An optional <pattern-list> ....`. This is what the `jlink --help` looks like against current mainline:
(first check the version)

jlink --version
21-internal

(check help output)

jlink --help
Usage: jlink <options> --module-path <modulepath> --add-modules <module>[,<module>...]
Possible options include:
      --add-modules <mod>[,<mod>...]    Root modules to resolve in addition to the
                                        initial modules. <mod> can also be ALL-MODULE-PATH.
      --bind-services                   Link in service provider modules and
                                        their dependences
  -c, --compress=<0|1|2>                Enable compression of resources:
                                          Level 0: No compression
                                          Level 1: Constant string sharing
                                          Level 2: ZIP


So it appears that this is not where the `-c --compress` option's help text is being picked up from?

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From jpai at openjdk.org  Thu Dec 15 07:00:10 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 15 Dec 2022 07:00:10 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v2]
In-Reply-To: <nMGAVNtVpo4j1Q-1YwFzVEJSoqkji4c7AvFsce4Bx50=.243b2540-1bc8-4c67-a845-cbfdc6148f10@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <L0YQ-HpkzstQ-kaNwoO3BxLqgcluDK5Lzt8R9c9ZGSs=.637129c6-047c-4197-8ed2-70d0a203ec90@github.com>
 <nMGAVNtVpo4j1Q-1YwFzVEJSoqkji4c7AvFsce4Bx50=.243b2540-1bc8-4c67-a845-cbfdc6148f10@github.com>
Message-ID: <aw1A0PJrkoRyDyN0yTdni_NET8az4U07uvwZvAxDttM=.9fa1a156-e231-4613-b226-c72549b7cf8f@github.com>

On Thu, 15 Dec 2022 06:56:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Swapping deprecations in properties
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties line 73:
> 
>> 71: 
>> 72: compress.usage=\
>> 73: \  --compress <0|1|2|zip-[0-9]>[:filter=<pattern-list>]\n\
> 
> This is a bit odd - when I run the `jlink`  command against latest mainline, I don't see the `[:filter=<pattern-list>]` being displayed in the help output nor do I see the message which states `An optional <pattern-list> ....`. This is what the `jlink --help` looks like against current mainline:
> (first check the version)
> 
> jlink --version
> 21-internal
> 
> (check help output)
> 
> jlink --help
> Usage: jlink <options> --module-path <modulepath> --add-modules <module>[,<module>...]
> Possible options include:
>       --add-modules <mod>[,<mod>...]    Root modules to resolve in addition to the
>                                         initial modules. <mod> can also be ALL-MODULE-PATH.
>       --bind-services                   Link in service provider modules and
>                                         their dependences
>   -c, --compress=<0|1|2>                Enable compression of resources:
>                                           Level 0: No compression
>                                           Level 1: Constant string sharing
>                                           Level 2: ZIP
> 
> 
> So it appears that this is not where the `-c --compress` option's help text is being picked up from?

Irrespective of this issue, I believe the `compress.argument` and `compress.description` property values in this file would need an update too.

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From jpai at openjdk.org  Thu Dec 15 07:07:10 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 15 Dec 2022 07:07:10 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v2]
In-Reply-To: <L0YQ-HpkzstQ-kaNwoO3BxLqgcluDK5Lzt8R9c9ZGSs=.637129c6-047c-4197-8ed2-70d0a203ec90@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <L0YQ-HpkzstQ-kaNwoO3BxLqgcluDK5Lzt8R9c9ZGSs=.637129c6-047c-4197-8ed2-70d0a203ec90@github.com>
Message-ID: <z4Lh3mo4wSeVY8LS-NSPsEdCKnBGNmzBkIRKtpecQl8=.4ff4a5d7-b50f-42a7-9e40-6bd71d37da79@github.com>

On Mon, 12 Dec 2022 20:53:27 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> This is an approach to adding a flag to jlink that will allow --compress to take the same types of arguments as jmod, thus bringing the two into alignment. This likely requires a CSR and a discussion on whether we should deprecate or simply remove the original numeric compression arguments.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Swapping deprecations in properties

test/jdk/tools/jlink/plugins/CompressorPluginTest.java line 153:

> 151:         Properties optionsZip0 = new Properties();
> 152:         DefaultCompressPlugin compressPluginZip0 = new DefaultCompressPlugin();
> 153:         options0.setProperty(compressPluginZip0.getName(), "zip-0");

I suspect this supposed to be `optionsZip0.setProperty(....)` instead of `options0.setProperty(....)`?

test/jdk/tools/jlink/plugins/CompressorPluginTest.java line 203:

> 201:             if (e.getMessage().contains("Invalid compression level")) {
> 202:                 return;
> 203:             }

Should we print the stacktrace if the message is not the one we expect, to help debug any failures? Or perhaps rethrow the exception to cause the test to fail?

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From jpai at openjdk.org  Thu Dec 15 07:13:06 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 15 Dec 2022 07:13:06 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v2]
In-Reply-To: <L0YQ-HpkzstQ-kaNwoO3BxLqgcluDK5Lzt8R9c9ZGSs=.637129c6-047c-4197-8ed2-70d0a203ec90@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <L0YQ-HpkzstQ-kaNwoO3BxLqgcluDK5Lzt8R9c9ZGSs=.637129c6-047c-4197-8ed2-70d0a203ec90@github.com>
Message-ID: <aks_esII-v62jHoLXBTPbrnf5k67bR-mfLRKbNiws6Q=.79b86b9b-5a11-4337-afe5-fee40221e465@github.com>

On Mon, 12 Dec 2022 20:53:27 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> This is an approach to adding a flag to jlink that will allow --compress to take the same types of arguments as jmod, thus bringing the two into alignment. This likely requires a CSR and a discussion on whether we should deprecate or simply remove the original numeric compression arguments.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Swapping deprecations in properties

Unrelated to the changes in this PR, the `--compress` option allows the value `1` to be specified, which implies "Constant string sharing" and enables the `jdk.tools.jlink.internal.plugins.StringSharingPlugin` which as per its documentation, states:
> A Plugin that stores the image classes constant pool UTF_8 entries into the Image StringsTable.

Would there ever be a case where it would be beneficial to have this `StringSharingPlugin` enabled and also set a zip compression?

The `DefaultCompressPlugin`, `ZipPlugin` and the `CompressorPluginTest` would need an update for the copyright years.

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From jpai at openjdk.org  Thu Dec 15 07:26:05 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 15 Dec 2022 07:26:05 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v2]
In-Reply-To: <L0YQ-HpkzstQ-kaNwoO3BxLqgcluDK5Lzt8R9c9ZGSs=.637129c6-047c-4197-8ed2-70d0a203ec90@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <L0YQ-HpkzstQ-kaNwoO3BxLqgcluDK5Lzt8R9c9ZGSs=.637129c6-047c-4197-8ed2-70d0a203ec90@github.com>
Message-ID: <jNkqEmwR3QhjvxJCmjMotsZHwIfcdsKce-gDsRdzWgY=.122a68b8-6069-43d2-a3f6-c2ac1a50cf39@github.com>

On Mon, 12 Dec 2022 20:53:27 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> This is an approach to adding a flag to jlink that will allow --compress to take the same types of arguments as jmod, thus bringing the two into alignment. This likely requires a CSR and a discussion on whether we should deprecate or simply remove the original numeric compression arguments.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Swapping deprecations in properties

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 227:

> 225:         boolean suggestProviders = false;
> 226: 
> 227:         int compressLevel;

Does this get used anywhere?

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From jpai at openjdk.org  Thu Dec 15 07:35:08 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 15 Dec 2022 07:35:08 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v2]
In-Reply-To: <z4Lh3mo4wSeVY8LS-NSPsEdCKnBGNmzBkIRKtpecQl8=.4ff4a5d7-b50f-42a7-9e40-6bd71d37da79@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <L0YQ-HpkzstQ-kaNwoO3BxLqgcluDK5Lzt8R9c9ZGSs=.637129c6-047c-4197-8ed2-70d0a203ec90@github.com>
 <z4Lh3mo4wSeVY8LS-NSPsEdCKnBGNmzBkIRKtpecQl8=.4ff4a5d7-b50f-42a7-9e40-6bd71d37da79@github.com>
Message-ID: <90W6AVU6RNPg3e3UgscPlDJGT2rUaVkduOmuoI8pOJU=.c35ea283-c399-4fda-9e60-3a1b679791ec@github.com>

On Thu, 15 Dec 2022 07:01:05 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Swapping deprecations in properties
>
> test/jdk/tools/jlink/plugins/CompressorPluginTest.java line 153:
> 
>> 151:         Properties optionsZip0 = new Properties();
>> 152:         DefaultCompressPlugin compressPluginZip0 = new DefaultCompressPlugin();
>> 153:         options0.setProperty(compressPluginZip0.getName(), "zip-0");
> 
> I suspect this supposed to be `optionsZip0.setProperty(....)` instead of `options0.setProperty(....)`?

I think, there's also a typo in the next line:

checkCompress(classes, compressPlugin,

should have been:

checkCompress(classes, compressPluginZip0,

I haven't yet looked at the existing test code in `checkCompress` method, but it might need a closer look as to why this test passed. I would have expected it to fail due to the typos.

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From pminborg at openjdk.org  Thu Dec 15 09:56:37 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 15 Dec 2022 09:56:37 GMT
Subject: RFR: 8298639: Perform I/O operations in bulk for RandomAccessFile
 [v3]
In-Reply-To: <CSr3MHVxoI_YzG4NXS5apLiU3VTDavZh7URxs52x9wc=.c508ecdd-dae5-4ce6-9573-7786301bcd4b@github.com>
References: <CSr3MHVxoI_YzG4NXS5apLiU3VTDavZh7URxs52x9wc=.c508ecdd-dae5-4ce6-9573-7786301bcd4b@github.com>
Message-ID: <4_ts6ima0CarPvtJtnLTNfzPXnF62jbufUxizjKfSJ8=.10edeea8-7be8-4a0a-a658-8d95a8234a3c@github.com>

> This PR suggests improving performance for read and write operations for the longer primitives in `RandomAccessFile`.
> 
> These improvements would also propagate to other JDK classes relying on these improved `RandomAccessFile` operations.

Per Minborg has updated the pull request incrementally with three additional commits since the last revision:

 - Improve benchmarks
 - Add benchmark
 - Use Bits instead of custom code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11644/files
  - new: https://git.openjdk.org/jdk/pull/11644/files/4fab79c9..e4f3841e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11644&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11644&range=01-02

  Stats: 174 lines in 2 files changed: 134 ins; 28 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/11644.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11644/head:pull/11644

PR: https://git.openjdk.org/jdk/pull/11644

From pminborg at openjdk.org  Thu Dec 15 10:11:06 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 15 Dec 2022 10:11:06 GMT
Subject: RFR: 8298639: Perform I/O operations in bulk for RandomAccessFile
 [v3]
In-Reply-To: <4_ts6ima0CarPvtJtnLTNfzPXnF62jbufUxizjKfSJ8=.10edeea8-7be8-4a0a-a658-8d95a8234a3c@github.com>
References: <CSr3MHVxoI_YzG4NXS5apLiU3VTDavZh7URxs52x9wc=.c508ecdd-dae5-4ce6-9573-7786301bcd4b@github.com>
 <4_ts6ima0CarPvtJtnLTNfzPXnF62jbufUxizjKfSJ8=.10edeea8-7be8-4a0a-a658-8d95a8234a3c@github.com>
Message-ID: <d98sGr2dlJxRkTDA5z5RIK5U2XvXToruG-iU7-MkkDI=.b6d72d6c-54fd-49de-9c5b-fc158de211bd@github.com>

On Thu, 15 Dec 2022 09:56:37 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests improving performance for read and write operations for the longer primitives in `RandomAccessFile`.
>> 
>> These improvements would also propagate to other JDK classes relying on these improved `RandomAccessFile` operations.
>
> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Improve benchmarks
>  - Add benchmark
>  - Use Bits instead of custom code

Before (baseline):


Benchmark                             (kiloBytes)  Mode  Cnt      Score     Error  Units
RandomAccessFileBenchmark.readInt               1  avgt   10    425,047 ?   4,391  us/op
RandomAccessFileBenchmark.readInt               5  avgt   10   2116,130 ?  33,072  us/op
RandomAccessFileBenchmark.readLong              1  avgt   10    425,847 ?   3,115  us/op
RandomAccessFileBenchmark.readLong              5  avgt   10   2118,740 ?  10,773  us/op
RandomAccessFileBenchmark.readShort             1  avgt   10    425,054 ?   6,808  us/op
RandomAccessFileBenchmark.readShort             5  avgt   10   2198,914 ? 105,192  us/op
RandomAccessFileBenchmark.writeInt              1  avgt   10   2259,429 ? 111,989  us/op
RandomAccessFileBenchmark.writeInt              5  avgt   10  10927,965 ? 579,343  us/op
RandomAccessFileBenchmark.writeLong             1  avgt   10   2181,974 ? 136,907  us/op
RandomAccessFileBenchmark.writeLong             5  avgt   10  11319,550 ? 408,315  us/op
RandomAccessFileBenchmark.writeShort            1  avgt   10   2283,893 ? 122,679  us/op
RandomAccessFileBenchmark.writeShort            5  avgt   10  11397,006 ? 543,862  us/op


After:


Benchmark                             (kiloBytes)  Mode  Cnt     Score     Error  Units
RandomAccessFileBenchmark.readInt               1  avgt   10   132,385 ?   2,416  us/op
RandomAccessFileBenchmark.readInt               5  avgt   10   655,828 ?  14,442  us/op
RandomAccessFileBenchmark.readLong              1  avgt   10    66,383 ?   0,763  us/op
RandomAccessFileBenchmark.readLong              5  avgt   10   329,242 ?   9,269  us/op
RandomAccessFileBenchmark.readShort             1  avgt   10   263,399 ?   4,584  us/op
RandomAccessFileBenchmark.readShort             5  avgt   10  1322,607 ?  27,811  us/op
RandomAccessFileBenchmark.writeInt              1  avgt   10   535,133 ?  24,860  us/op
RandomAccessFileBenchmark.writeInt              5  avgt   10  2701,959 ? 115,069  us/op
RandomAccessFileBenchmark.writeLong             1  avgt   10   268,175 ?  13,810  us/op
RandomAccessFileBenchmark.writeLong             5  avgt   10  1313,634 ?  33,461  us/op
RandomAccessFileBenchmark.writeShort            1  avgt   10  1076,690 ?  17,407  us/op
RandomAccessFileBenchmark.writeShort            5  avgt   10  5383,567 ? 250,833  us/op


![image](https://user-images.githubusercontent.com/7457876/207831696-95c93d88-11e1-49be-949f-8fb39537425f.png)

-------------

PR: https://git.openjdk.org/jdk/pull/11644

From mcimadamore at openjdk.org  Thu Dec 15 10:50:00 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 15 Dec 2022 10:50:00 GMT
Subject: [jdk20] RFR: 8298797: Specification of some restricted methods is
 incorrect
Message-ID: <PjrmbYlP97ORHfseTAFprgUV5O00JCJt74t51RLqey8=.692df6ba-6b9f-4962-b7da-16d202e6ac0b@github.com>

This patch fixes some inconsistencies in the javadoc for restricted methods:

* ModuleLayer.Controller::addEnableNativeAccess has a shorted text in its `@throws` clause. This shorted text is now used everywhere.
* One overload of `MemorySegment::ofAddress` is missing the restricted method narrative text

-------------

Commit messages:
 - Fix javadoc for restricted methods

Changes: https://git.openjdk.org/jdk20/pull/40/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=40&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298797
  Stats: 33 lines in 6 files changed: 10 ins; 14 del; 9 mod
  Patch: https://git.openjdk.org/jdk20/pull/40.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/40/head:pull/40

PR: https://git.openjdk.org/jdk20/pull/40

From serb at openjdk.org  Thu Dec 15 10:51:08 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 15 Dec 2022 10:51:08 GMT
Subject: RFR: 8290899: java/lang/String/StringRepeat.java test requests too
 much heap on windows x86
In-Reply-To: <rbTMWm4K6IURZtk_xvrnpwPnsUwBD4XvmQzQrOS86dQ=.6cb3dac8-815b-45ec-a6b0-8731ed18991b@github.com>
References: <rbTMWm4K6IURZtk_xvrnpwPnsUwBD4XvmQzQrOS86dQ=.6cb3dac8-815b-45ec-a6b0-8731ed18991b@github.com>
Message-ID: <si1pIs0_gYAnpuPj_1fC9nnm-gr_QgWvQJDNm1iT1N0=.1ed6a752-239f-440a-a940-1c5195595930@github.com>

On Tue, 13 Dec 2022 00:06:00 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The `java/lang/String/StringRepeat.java` test was updated twice after integration:
> 
> https://bugs.openjdk.org/browse/JDK-8221400 - the xmx4g was replaced by the xmx2g
> https://bugs.openjdk.org/browse/JDK-8265421 - the "os.maxMemory >= 2G" was added
> 
> Unfortunately, this test still may fail on Windows x86 due to: `Could not reserve enough space for xxx object heap.`
> 
> This is a request to exclude it on win x86 since that JDK cannot allocate 2g.

If there are no objections or any other comments I'll integrate the fix.

-------------

PR: https://git.openjdk.org/jdk/pull/11639

From jpai at openjdk.org  Thu Dec 15 10:53:07 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 15 Dec 2022 10:53:07 GMT
Subject: RFR: 8298416: Console should be declared `sealed` [v3]
In-Reply-To: <-rOAEdXfRLE6huOK1AvrDnz43lm_MQ1BmbNGHCiSEiQ=.60dbcdb7-699e-4550-beaa-4071ede43432@github.com>
References: <CGOo7D3wTII2bpEbIU4VsWjMeHJsh0hGjOe_eBQYxjY=.948b2f0c-7466-420b-9756-2dcf92363bb7@github.com>
 <-rOAEdXfRLE6huOK1AvrDnz43lm_MQ1BmbNGHCiSEiQ=.60dbcdb7-699e-4550-beaa-4071ede43432@github.com>
Message-ID: <L89grUvPxqC4_Z9gOBVeNJ_ACXWmTFLINKL35aLaKac=.21c0f414-810a-49cc-bba9-41a758259d1f@github.com>

On Wed, 14 Dec 2022 17:35:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `Console` class now has a couple of internal subclasses within `java.io` package. It should be `sealed` and subclasses be declared in the `permits` clause. The implementation resided in `Console` class is separated into `ConsoleImpl` class.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved echo() to ConsoleImpl, clean-ups

Marked as reviewed by jpai (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11615

From jvernee at openjdk.org  Thu Dec 15 11:22:04 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 15 Dec 2022 11:22:04 GMT
Subject: [jdk20] RFR: 8298797: Specification of some restricted methods is
 incorrect
In-Reply-To: <PjrmbYlP97ORHfseTAFprgUV5O00JCJt74t51RLqey8=.692df6ba-6b9f-4962-b7da-16d202e6ac0b@github.com>
References: <PjrmbYlP97ORHfseTAFprgUV5O00JCJt74t51RLqey8=.692df6ba-6b9f-4962-b7da-16d202e6ac0b@github.com>
Message-ID: <ekgloG_fm8U6pzpih_EJ7iahHR55xkt0eI_TAdlZIKQ=.511d4c47-a720-4f11-851e-8e413a85294f@github.com>

On Thu, 15 Dec 2022 10:43:35 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch fixes some inconsistencies in the javadoc for restricted methods:
> 
> * ModuleLayer.Controller::addEnableNativeAccess has a shorted text in its `@throws` clause. This shorted text is now used everywhere.
> * One overload of `MemorySegment::ofAddress` is missing the restricted method narrative text

Marked as reviewed by jvernee (Reviewer).

-------------

PR: https://git.openjdk.org/jdk20/pull/40

From dnguyen at openjdk.org  Thu Dec 15 12:06:10 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 15 Dec 2022 12:06:10 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <gt3H8LBSGCmyftDD3Oyzx_BXZgZzvQtJq4pDIWFQnQY=.fbc90067-e182-490f-85e4-f302ae7cfd64@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <k7G3LUpn1hYfFwASwRuATz0OVhWJEBaqAFSo-7zK4rI=.c4a1b71d-93a7-4d08-b379-baf63a09ed31@github.com>
 <gt3H8LBSGCmyftDD3Oyzx_BXZgZzvQtJq4pDIWFQnQY=.fbc90067-e182-490f-85e4-f302ae7cfd64@github.com>
Message-ID: <iBTNjKoPxhwIA8LhLguE4u7j67wbLJolkZ4jx-1uz5g=.be6291cd-2fd4-403a-bb37-1f88479f967e@github.com>

On Thu, 15 Dec 2022 01:13:32 GMT, Justin Lu <duke at openjdk.org> wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties line 188:
>> 
>>> 186: main.plugin.module=\u63D2\u4EF6\u6A21\u5757
>>> 187: 
>>> 188: main.plugin.category=\u7C7B\u522B 
>> 
>> As Naoto pointed out, it looks like a trailing space was added by accident. This is also done in the ja version but for a different value. And no space was added for any value for the de version. It looks like the translation drop that Damon is receiving contains random changes.
>
> Additionally, there were changes made to plugins.properties in October that were not translated in the translation drop

In our discussion, Kate mentioned that some languages are double byte, so this extra space may be correct but she hasn't looked in detail yet. I looked through all of the changes and these two instances of trailing whitespaces were the only two. I removed the extra spaces to reduce the changes as it seems useless due to the previous version not having the whitespace.

-------------

PR: https://git.openjdk.org/jdk20/pull/35

From pminborg at openjdk.org  Thu Dec 15 12:28:07 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 15 Dec 2022 12:28:07 GMT
Subject: [jdk20] RFR: 8298797: Specification of some restricted methods is
 incorrect
In-Reply-To: <PjrmbYlP97ORHfseTAFprgUV5O00JCJt74t51RLqey8=.692df6ba-6b9f-4962-b7da-16d202e6ac0b@github.com>
References: <PjrmbYlP97ORHfseTAFprgUV5O00JCJt74t51RLqey8=.692df6ba-6b9f-4962-b7da-16d202e6ac0b@github.com>
Message-ID: <6oWm1oANov11IBMRKQPuFn3IJI3UVNuqTavUYNYGrzg=.76dde409-4944-4144-bb9b-7f3a95486f08@github.com>

On Thu, 15 Dec 2022 10:43:35 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch fixes some inconsistencies in the javadoc for restricted methods:
> 
> * ModuleLayer.Controller::addEnableNativeAccess has a shorted text in its `@throws` clause. This shorted text is now used everywhere.
> * One overload of `MemorySegment::ofAddress` is missing the restricted method narrative text

Marked as reviewed by pminborg (no project role).

-------------

PR: https://git.openjdk.org/jdk20/pull/40

From alanb at openjdk.org  Thu Dec 15 12:28:09 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 15 Dec 2022 12:28:09 GMT
Subject: RFR: 8298416: Console should be declared `sealed` [v3]
In-Reply-To: <-rOAEdXfRLE6huOK1AvrDnz43lm_MQ1BmbNGHCiSEiQ=.60dbcdb7-699e-4550-beaa-4071ede43432@github.com>
References: <CGOo7D3wTII2bpEbIU4VsWjMeHJsh0hGjOe_eBQYxjY=.948b2f0c-7466-420b-9756-2dcf92363bb7@github.com>
 <-rOAEdXfRLE6huOK1AvrDnz43lm_MQ1BmbNGHCiSEiQ=.60dbcdb7-699e-4550-beaa-4071ede43432@github.com>
Message-ID: <c4kQam5LBTsBQ17Gd57XXEcMD2UGn4677cSEsc4nRDA=.b62d481e-dd0b-4ce8-b9db-0d44445414f4@github.com>

On Wed, 14 Dec 2022 17:35:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `Console` class now has a couple of internal subclasses within `java.io` package. It should be `sealed` and subclasses be declared in the `permits` clause. The implementation resided in `Console` class is separated into `ConsoleImpl` class.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved echo() to ConsoleImpl, clean-ups

Good.

src/java.base/share/classes/java/io/Console.java line 111:

> 109:     public PrintWriter writer() {
> 110:         throw new UnsupportedOperationException(
> 111:                 "Console class itself does not provide implementation");

Minor comment is the same "throw new UOE(message)" is repeated in every method. You could add a static method to return it, then it would reduce to "throw newUnsupportedOperationException();".

Also looks like the method descriptions on all these methods starts at position 3. Pre-dates your change but since every method is changed then maybe we should fix that too, up to you.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11615

From luhenry at openjdk.org  Thu Dec 15 13:27:11 2022
From: luhenry at openjdk.org (Ludovic Henry)
Date: Thu, 15 Dec 2022 13:27:11 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v13]
In-Reply-To: <d5iY-dwoEXUM9u1-exI-nkWwd9Hv-1QhVFSACbLtsz0=.2f040010-af30-40a5-8f19-1c5e3f8a01cd@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <pW8HHmh-dQnjrRftd052fBQVulqe_z5KldY76Hp-OmI=.a7a2b6e6-a182-45d2-bd11-16a406126482@github.com>
 <d5iY-dwoEXUM9u1-exI-nkWwd9Hv-1QhVFSACbLtsz0=.2f040010-af30-40a5-8f19-1c5e3f8a01cd@github.com>
Message-ID: <wvu5T2bGen5XIPti0lzD930sfSlqiXeTmAuxoE_xNds=.2203a097-0a97-46fa-a68f-ec7381ab337f@github.com>

On Wed, 16 Nov 2022 18:18:55 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missing & 0xff in StringLatin1::hashCode
>
> I'm getting pulled into other tasks and would request for this to be either accepted as-is, rejected or picked up by someone else to rewrite it to something that can be accepted.
> 
> Obviously I'm biased towards acceptance: While imperfect, it provides improved testing - both functional and performance-wise - and establishes a significantly improved benchmark for more future-proof solutions to beat. There are many ways to iteratively improve upon this solution, some of which would even simplify the implementation. But in the face of upcoming changes that might allow C2 to optimize these kinds of loops without intrinsic support I am not sure spending more time on perfecting the current patch is worth our while.
> 
> Rejecting it might be the reasonable thing to do, too, especially if the C2 loop optimizations @iwanowww points out might be coming around sooner rather than later. Even if that's not coming soon, the PR at hand adds a chunk of complexity for the compiler team to maintain.

@cl4es @iwanowww is that change still good to go forward? What else would you like to see for it to be merged? Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From asotona at openjdk.org  Thu Dec 15 14:16:13 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 15 Dec 2022 14:16:13 GMT
Subject: RFR: [DRAFT] 8294982: Implementation of Classfile API [v5]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <9AFHEyl31qV6P-hNvXUw1eGUhd1mq_COGxYvd3MVIuo=.df0adf38-ea72-4216-ab20-f791457d328a@github.com>

> **This pull request is not intended for immediate integration to JDK mainline.**
> 
> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 99 commits:

 - Merge branch 'master' into JDK-8294982
 - javadoc cleanup
 - removal of AccessController::doPriviledged from ClassHierarchyResolver
 - PackageSnippets moved from jdk/classfile/snippets to jdk/classfile/snippet-files
 - removed executable
 - removed executable
 - removed executable flags and fixed whitespaces
 - removed executable flag from test/micro/org/openjdk/bench/jdk/classfile/Write.java
 - Merge branch 'classfile-api-branch' into classfile-api-initial-branch
   
   # Conflicts:
   #	README.md
   #	make/Docs.gmk
   #	test/jdk/jdk/classfile/CorpusTest.java
   #	test/jdk/jdk/classfile/LvtTest.java
   #	test/jdk/jdk/classfile/StackMapsTest.java
 - Merge branch 'master' into classfile-api-branch
   
   # Conflicts:
   #	README.md
   #	make/Docs.gmk
 - ... and 89 more: https://git.openjdk.org/jdk/compare/dd18d76b...78ba7bdb

-------------

Changes: https://git.openjdk.org/jdk/pull/10982/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=04
  Stats: 53419 lines in 323 files changed: 53418 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Thu Dec 15 14:25:17 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 15 Dec 2022 14:25:17 GMT
Subject: RFR: [DRAFT] 8294982: Implementation of Classfile API [v6]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <LItYPeb1Ui0L7xFExgACKaUJliKyM3EaiPVP2tr75z0=.1130b6ba-b4d1-4019-b62f-f17d1065174c@github.com>

> **This pull request is not intended for immediate integration to JDK mainline.**
> 
> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 100 commits:

 - Merge branch 'master' into JDK-8294982
 - Merge branch 'master' into JDK-8294982
 - javadoc cleanup
 - removal of AccessController::doPriviledged from ClassHierarchyResolver
 - PackageSnippets moved from jdk/classfile/snippets to jdk/classfile/snippet-files
 - removed executable
 - removed executable
 - removed executable flags and fixed whitespaces
 - removed executable flag from test/micro/org/openjdk/bench/jdk/classfile/Write.java
 - Merge branch 'classfile-api-branch' into classfile-api-initial-branch
   
   # Conflicts:
   #	README.md
   #	make/Docs.gmk
   #	test/jdk/jdk/classfile/CorpusTest.java
   #	test/jdk/jdk/classfile/LvtTest.java
   #	test/jdk/jdk/classfile/StackMapsTest.java
 - ... and 90 more: https://git.openjdk.org/jdk/compare/b17c5242...a350f5bd

-------------

Changes: https://git.openjdk.org/jdk/pull/10982/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=05
  Stats: 53419 lines in 323 files changed: 53418 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

PR: https://git.openjdk.org/jdk/pull/10982

From phh at openjdk.org  Thu Dec 15 14:39:07 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Thu, 15 Dec 2022 14:39:07 GMT
Subject: RFR: 8290899: java/lang/String/StringRepeat.java test requests too
 much heap on windows x86
In-Reply-To: <rbTMWm4K6IURZtk_xvrnpwPnsUwBD4XvmQzQrOS86dQ=.6cb3dac8-815b-45ec-a6b0-8731ed18991b@github.com>
References: <rbTMWm4K6IURZtk_xvrnpwPnsUwBD4XvmQzQrOS86dQ=.6cb3dac8-815b-45ec-a6b0-8731ed18991b@github.com>
Message-ID: <y2toD_E09K_h0XBn8ZUP4vM2unfhB_m4ao67OM7Ew1E=.9cd3743a-9b52-4d17-be03-9db53e12fc1c@github.com>

On Tue, 13 Dec 2022 00:06:00 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The `java/lang/String/StringRepeat.java` test was updated twice after integration:
> 
> https://bugs.openjdk.org/browse/JDK-8221400 - the xmx4g was replaced by the xmx2g
> https://bugs.openjdk.org/browse/JDK-8265421 - the "os.maxMemory >= 2G" was added
> 
> Unfortunately, this test still may fail on Windows x86 due to: `Could not reserve enough space for xxx object heap.`
> 
> This is a request to exclude it on win x86 since that JDK cannot allocate 2g.

Lgtm.

This is a (very old) known problem with 32-bit Windows. Address space randomization (libraries allocated at widely dispersed locations within the 4g 32-bit virtual address space) means there's a limit to the size of contiguous virtual address space mappable to the Java heap.

-------------

Marked as reviewed by phh (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11639

From alanb at openjdk.org  Thu Dec 15 15:04:07 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 15 Dec 2022 15:04:07 GMT
Subject: RFR: 8298639: Perform I/O operations in bulk for RandomAccessFile
 [v3]
In-Reply-To: <4_ts6ima0CarPvtJtnLTNfzPXnF62jbufUxizjKfSJ8=.10edeea8-7be8-4a0a-a658-8d95a8234a3c@github.com>
References: <CSr3MHVxoI_YzG4NXS5apLiU3VTDavZh7URxs52x9wc=.c508ecdd-dae5-4ce6-9573-7786301bcd4b@github.com>
 <4_ts6ima0CarPvtJtnLTNfzPXnF62jbufUxizjKfSJ8=.10edeea8-7be8-4a0a-a658-8d95a8234a3c@github.com>
Message-ID: <-c874mcRJH8mbebARm1XDXDXfDL36XuuymsGsC-Zg-g=.06b8c290-1bf0-447c-aa75-849c68f88f0c@github.com>

On Thu, 15 Dec 2022 09:56:37 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests improving performance for read and write operations for the longer primitives in `RandomAccessFile`.
>> 
>> These improvements would also propagate to other JDK classes relying on these improved `RandomAccessFile` operations.
>
> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Improve benchmarks
>  - Add benchmark
>  - Use Bits instead of custom code

src/java.base/share/classes/java/io/RandomAccessFile.java line 60:

> 58:  * {@code IOException} may be thrown if the stream has been closed.
> 59:  *
> 60:  * @implNote This class is not thread safe.

I don't think this should be an implNote. Maybe for a different issue/PR is that the class description probably needs a paragraph to say that a RAF is not thread safe and requires appropriate synchronization when used by concurrent threads. This leads to discussion about a FileChannel obtained from a RAF as FileChannel defines read/write methods that support cases where threads need to access different parts of a file at the same time. There is a lot more to say on this topic and probably best to keep it separate.

-------------

PR: https://git.openjdk.org/jdk/pull/11644

From alanb at openjdk.org  Thu Dec 15 15:09:09 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 15 Dec 2022 15:09:09 GMT
Subject: RFR: 8298639: Perform I/O operations in bulk for RandomAccessFile
 [v3]
In-Reply-To: <4_ts6ima0CarPvtJtnLTNfzPXnF62jbufUxizjKfSJ8=.10edeea8-7be8-4a0a-a658-8d95a8234a3c@github.com>
References: <CSr3MHVxoI_YzG4NXS5apLiU3VTDavZh7URxs52x9wc=.c508ecdd-dae5-4ce6-9573-7786301bcd4b@github.com>
 <4_ts6ima0CarPvtJtnLTNfzPXnF62jbufUxizjKfSJ8=.10edeea8-7be8-4a0a-a658-8d95a8234a3c@github.com>
Message-ID: <UsquZQIZgMeROkwPzSc7wYXv0IbiMPM_KT4lqibLgGQ=.54e85698-d1e2-4116-b10d-96b59518126b@github.com>

On Thu, 15 Dec 2022 09:56:37 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests improving performance for read and write operations for the longer primitives in `RandomAccessFile`.
>> 
>> These improvements would also propagate to other JDK classes relying on these improved `RandomAccessFile` operations.
>
> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Improve benchmarks
>  - Add benchmark
>  - Use Bits instead of custom code

src/java.base/share/classes/java/io/RandomAccessFile.java line 1090:

> 1088:         buffer[0] = (byte)(v >>>  8);
> 1089:         write(buffer, 0, Short.BYTES);
> 1090:         //written += 2;

I suppose the commented out //written += ... can be removed, it seems to be leftover in at least 3 methods (not your doing of course).

-------------

PR: https://git.openjdk.org/jdk/pull/11644

From duke at openjdk.org  Thu Dec 15 15:59:11 2022
From: duke at openjdk.org (Ismael Juma)
Date: Thu, 15 Dec 2022 15:59:11 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v13]
In-Reply-To: <pW8HHmh-dQnjrRftd052fBQVulqe_z5KldY76Hp-OmI=.a7a2b6e6-a182-45d2-bd11-16a406126482@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <pW8HHmh-dQnjrRftd052fBQVulqe_z5KldY76Hp-OmI=.a7a2b6e6-a182-45d2-bd11-16a406126482@github.com>
Message-ID: <Xg9-_61r0KV5EzLlHiRgmr7JmcixExTuE3n0h2_QWTQ=.1031b959-a696-428c-bf0a-2a7f7c65c95a@github.com>

On Fri, 11 Nov 2022 13:00:06 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
>> 
>> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
>> 
>> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
>> 
>> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
>> 
>> With the most recent fixes the x64 intrinsic results on my workstation look like this:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
>> 
>> Baseline:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
>> 
>> I.e. no measurable overhead compared to baseline even for `size == 1`.
>> 
>> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
>> 
>> Benchmark for `Arrays.hashCode`:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
>> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
>> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
>> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
>> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
>> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
>> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
>> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
>> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
>> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
>> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
>> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
>> 
>> Baseline:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
>> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
>> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
>> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
>> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
>> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
>> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
>> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
>> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
>> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
>> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
>> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
>> 
>> 
>> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing & 0xff in StringLatin1::hashCode

Are the C2 loop optimizations happening any time soon? If not, it seems pretty sensible to take this very significant win for a very common path. We can always remove it once the C2 loop optimizations can achieve results that are as good.

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From bpb at openjdk.org  Thu Dec 15 17:12:12 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 15 Dec 2022 17:12:12 GMT
Subject: RFR: 8298639: Perform I/O operations in bulk for RandomAccessFile
 [v3]
In-Reply-To: <-c874mcRJH8mbebARm1XDXDXfDL36XuuymsGsC-Zg-g=.06b8c290-1bf0-447c-aa75-849c68f88f0c@github.com>
References: <CSr3MHVxoI_YzG4NXS5apLiU3VTDavZh7URxs52x9wc=.c508ecdd-dae5-4ce6-9573-7786301bcd4b@github.com>
 <4_ts6ima0CarPvtJtnLTNfzPXnF62jbufUxizjKfSJ8=.10edeea8-7be8-4a0a-a658-8d95a8234a3c@github.com>
 <-c874mcRJH8mbebARm1XDXDXfDL36XuuymsGsC-Zg-g=.06b8c290-1bf0-447c-aa75-849c68f88f0c@github.com>
Message-ID: <PexaKx2ofTHrcpYjzZ-aOI8ZCwuLRqiRBRe3Ref_88E=.9083042b-9ec0-4d96-b9ca-17823d81758f@github.com>

On Thu, 15 Dec 2022 15:01:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Improve benchmarks
>>  - Add benchmark
>>  - Use Bits instead of custom code
>
> src/java.base/share/classes/java/io/RandomAccessFile.java line 60:
> 
>> 58:  * {@code IOException} may be thrown if the stream has been closed.
>> 59:  *
>> 60:  * @implNote This class is not thread safe.
> 
> I don't think this should be an implNote. Maybe for a different issue/PR is that the class description probably needs a paragraph to say that a RAF is not thread safe and requires appropriate synchronization when used by concurrent threads. This leads to discussion about a FileChannel obtained from a RAF as FileChannel defines read/write methods that support cases where threads need to access different parts of a file at the same time. There is a lot more to say on this topic and probably best to keep it separate.

Nit: Also I think it needs hyphenation: `thread-safe`.

-------------

PR: https://git.openjdk.org/jdk/pull/11644

From naoto at openjdk.org  Thu Dec 15 17:12:33 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 Dec 2022 17:12:33 GMT
Subject: RFR: 8298416: Console should be declared `sealed` [v4]
In-Reply-To: <CGOo7D3wTII2bpEbIU4VsWjMeHJsh0hGjOe_eBQYxjY=.948b2f0c-7466-420b-9756-2dcf92363bb7@github.com>
References: <CGOo7D3wTII2bpEbIU4VsWjMeHJsh0hGjOe_eBQYxjY=.948b2f0c-7466-420b-9756-2dcf92363bb7@github.com>
Message-ID: <iU8_RftAyQlQk7luVFHqouX3pwpnGLMq0JijyFXdZzo=.9b737a86-3790-4a7e-b936-966288101a52@github.com>

> `Console` class now has a couple of internal subclasses within `java.io` package. It should be `sealed` and subclasses be declared in the `permits` clause. The implementation resided in `Console` class is separated into `ConsoleImpl` class.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  newUnsupportedOperationException(), cosmetic changes to method descs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11615/files
  - new: https://git.openjdk.org/jdk/pull/11615/files/93945d6f..f2b2335b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11615&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11615&range=02-03

  Stats: 208 lines in 1 file changed: 4 ins; 9 del; 195 mod
  Patch: https://git.openjdk.org/jdk/pull/11615.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11615/head:pull/11615

PR: https://git.openjdk.org/jdk/pull/11615

From naoto at openjdk.org  Thu Dec 15 17:12:34 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 Dec 2022 17:12:34 GMT
Subject: RFR: 8298416: Console should be declared `sealed` [v3]
In-Reply-To: <c4kQam5LBTsBQ17Gd57XXEcMD2UGn4677cSEsc4nRDA=.b62d481e-dd0b-4ce8-b9db-0d44445414f4@github.com>
References: <CGOo7D3wTII2bpEbIU4VsWjMeHJsh0hGjOe_eBQYxjY=.948b2f0c-7466-420b-9756-2dcf92363bb7@github.com>
 <-rOAEdXfRLE6huOK1AvrDnz43lm_MQ1BmbNGHCiSEiQ=.60dbcdb7-699e-4550-beaa-4071ede43432@github.com>
 <c4kQam5LBTsBQ17Gd57XXEcMD2UGn4677cSEsc4nRDA=.b62d481e-dd0b-4ce8-b9db-0d44445414f4@github.com>
Message-ID: <KVKN2bmEKhQ4Prm25PuJ1e9xqcdCRi9Irt1Die4LUwc=.2257cbe2-a7d1-468c-a47d-d0e251ff747d@github.com>

On Thu, 15 Dec 2022 12:24:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Moved echo() to ConsoleImpl, clean-ups
>
> src/java.base/share/classes/java/io/Console.java line 111:
> 
>> 109:     public PrintWriter writer() {
>> 110:         throw new UnsupportedOperationException(
>> 111:                 "Console class itself does not provide implementation");
> 
> Minor comment is the same "throw new UOE(message)" is repeated in every method. You could add a static method to return it, then it would reduce to "throw newUnsupportedOperationException();".
> 
> Also looks like the method descriptions on all these methods starts at position 3. Pre-dates your change but since every method is changed then maybe we should fix that too, up to you.

Thanks, Alan. Addressed both.

-------------

PR: https://git.openjdk.org/jdk/pull/11615

From joehw at openjdk.org  Thu Dec 15 17:13:08 2022
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 15 Dec 2022 17:13:08 GMT
Subject: RFR: 8298808: Check `script` code on detecting the base locales
 [v2]
In-Reply-To: <fCe2qY1mZZAih3y9VNmromWJLUrchaw-sm2VT1XqvuY=.dd45a913-3b68-40ab-935a-933e7020a1af@github.com>
References: <-y3oZIKk1c7lLT9v6xYmNaOWr0aoKChLz5erO0Mx9vs=.02bc4c39-8d21-4aaa-ac95-0f7e28c21a43@github.com>
 <fCe2qY1mZZAih3y9VNmromWJLUrchaw-sm2VT1XqvuY=.dd45a913-3b68-40ab-935a-933e7020a1af@github.com>
Message-ID: <9FYcZP2z3NiwHxfLotUTZincXIrB2EdeM0l3B_pdQjU=.f02aab75-40e2-4b21-a0ce-c89e0b177fce@github.com>

On Wed, 14 Dec 2022 23:47:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing `CLDRConverter` build tool to not regard [new locales](https://github.com/unicode-org/cldr/pull/2508/files#diff-94cbefde02914335da884f768063a06a84ad651ee4e56cdb1cb90625d7776731) introduced in CLDR 43 as one of the base locales. Otherwise they would incorrectly go into `java.base` module, then a test case fails.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allow Latin script by default

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11684

From alanb at openjdk.org  Thu Dec 15 17:48:09 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 15 Dec 2022 17:48:09 GMT
Subject: RFR: 8298416: Console should be declared `sealed` [v4]
In-Reply-To: <iU8_RftAyQlQk7luVFHqouX3pwpnGLMq0JijyFXdZzo=.9b737a86-3790-4a7e-b936-966288101a52@github.com>
References: <CGOo7D3wTII2bpEbIU4VsWjMeHJsh0hGjOe_eBQYxjY=.948b2f0c-7466-420b-9756-2dcf92363bb7@github.com>
 <iU8_RftAyQlQk7luVFHqouX3pwpnGLMq0JijyFXdZzo=.9b737a86-3790-4a7e-b936-966288101a52@github.com>
Message-ID: <QXLTsO1UM84gMqM0Yaf24n6YVpzi6LRwvoNjbAv26o8=.ade317b6-13e3-4c69-a7b9-1a211d8223bd@github.com>

On Thu, 15 Dec 2022 17:12:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `Console` class now has a couple of internal subclasses within `java.io` package. It should be `sealed` and subclasses be declared in the `permits` clause. The implementation resided in `Console` class is separated into `ConsoleImpl` class.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   newUnsupportedOperationException(), cosmetic changes to method descs

src/java.base/share/classes/java/io/Console.java line 95:

> 93:  * @author  Xueming Shen
> 94:  * @since   1.6
> 95:  * @sealedGraph

I'm not sure about sealedGraph because the there is nothing for user code to matching on.

-------------

PR: https://git.openjdk.org/jdk/pull/11615

From naoto at openjdk.org  Thu Dec 15 18:04:34 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 Dec 2022 18:04:34 GMT
Subject: RFR: 8298416: Console should be declared `sealed` [v5]
In-Reply-To: <CGOo7D3wTII2bpEbIU4VsWjMeHJsh0hGjOe_eBQYxjY=.948b2f0c-7466-420b-9756-2dcf92363bb7@github.com>
References: <CGOo7D3wTII2bpEbIU4VsWjMeHJsh0hGjOe_eBQYxjY=.948b2f0c-7466-420b-9756-2dcf92363bb7@github.com>
Message-ID: <Xx4V93YN-XamAjRhc3fyVZHlHN9mpOLm06gcmTIxtow=.8f0b9f9b-3449-4a83-84de-663c8ea5516c@github.com>

> `Console` class now has a couple of internal subclasses within `java.io` package. It should be `sealed` and subclasses be declared in the `permits` clause. The implementation resided in `Console` class is separated into `ConsoleImpl` class.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Removed @sealedGraph tag

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11615/files
  - new: https://git.openjdk.org/jdk/pull/11615/files/f2b2335b..c6d00a41

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11615&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11615&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11615.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11615/head:pull/11615

PR: https://git.openjdk.org/jdk/pull/11615

From alanb at openjdk.org  Thu Dec 15 18:04:34 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 15 Dec 2022 18:04:34 GMT
Subject: RFR: 8298416: Console should be declared `sealed` [v5]
In-Reply-To: <Xx4V93YN-XamAjRhc3fyVZHlHN9mpOLm06gcmTIxtow=.8f0b9f9b-3449-4a83-84de-663c8ea5516c@github.com>
References: <CGOo7D3wTII2bpEbIU4VsWjMeHJsh0hGjOe_eBQYxjY=.948b2f0c-7466-420b-9756-2dcf92363bb7@github.com>
 <Xx4V93YN-XamAjRhc3fyVZHlHN9mpOLm06gcmTIxtow=.8f0b9f9b-3449-4a83-84de-663c8ea5516c@github.com>
Message-ID: <eqwxoAxIcmUdtucX4zbuSdrnWrt0HqTV_Q2DFpNs_M4=.d993acf3-14b8-41c0-8ffb-239b5e6d8ce6@github.com>

On Thu, 15 Dec 2022 17:59:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `Console` class now has a couple of internal subclasses within `java.io` package. It should be `sealed` and subclasses be declared in the `permits` clause. The implementation resided in `Console` class is separated into `ConsoleImpl` class.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed @sealedGraph tag

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11615

From naoto at openjdk.org  Thu Dec 15 18:04:34 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 Dec 2022 18:04:34 GMT
Subject: RFR: 8298416: Console should be declared `sealed` [v4]
In-Reply-To: <QXLTsO1UM84gMqM0Yaf24n6YVpzi6LRwvoNjbAv26o8=.ade317b6-13e3-4c69-a7b9-1a211d8223bd@github.com>
References: <CGOo7D3wTII2bpEbIU4VsWjMeHJsh0hGjOe_eBQYxjY=.948b2f0c-7466-420b-9756-2dcf92363bb7@github.com>
 <iU8_RftAyQlQk7luVFHqouX3pwpnGLMq0JijyFXdZzo=.9b737a86-3790-4a7e-b936-966288101a52@github.com>
 <QXLTsO1UM84gMqM0Yaf24n6YVpzi6LRwvoNjbAv26o8=.ade317b6-13e3-4c69-a7b9-1a211d8223bd@github.com>
Message-ID: <XED389-smq-8W_N9wOBugJmoYrWqpjXIPBr3BVhYcvw=.758a5a87-c36e-4822-8d84-8b69352397f6@github.com>

On Thu, 15 Dec 2022 17:45:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   newUnsupportedOperationException(), cosmetic changes to method descs
>
> src/java.base/share/classes/java/io/Console.java line 95:
> 
>> 93:  * @author  Xueming Shen
>> 94:  * @since   1.6
>> 95:  * @sealedGraph
> 
> I'm not sure about sealedGraph because the there is nothing for user code to matching on.

OK, removed

-------------

PR: https://git.openjdk.org/jdk/pull/11615

From dnguyen at openjdk.org  Thu Dec 15 18:54:09 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 15 Dec 2022 18:54:09 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <QB_rvT43I38Ksdn8YuHCvzPrTNTua2287iebkdsNakM=.0656bf7b-2eed-4858-ad71-a5ffecdad65b@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <d95C1dlJ8bWMdxqTxzNFfJ8wIfXUWprXL1Mj8EhLiaM=.2215541c-f86e-4a46-9e49-9a2a1f2f1e63@github.com>
 <QB_rvT43I38Ksdn8YuHCvzPrTNTua2287iebkdsNakM=.0656bf7b-2eed-4858-ad71-a5ffecdad65b@github.com>
Message-ID: <YYf976GjBqhqZZlsCUy6oz6Tx_KLFXz7iCsU86GAKSM=.5bd572ce-1523-4b69-a17a-1a2b70c896f0@github.com>

On Thu, 15 Dec 2022 02:23:34 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_de.properties line 26:
>> 
>>> 24: #
>>> 25: 
>>> 26: jmod.description=JMOD-Dateien erstellen und den Inhalt vorhandener JMOD-Dateien auflisten
>> 
>> `jlink.description` was added to `jmod.properties` in May 2022 (Which was before Alisen's drop for JDK19). Shouldn't this have been translated during the 19 drop in August, as opposed to showing up now?
>
> I see the date of [that PR](https://github.com/openjdk/jdk/pull/8772) as well. Looks like it was integrated on May 19.
> 
> I'm contacting Kate Gavin to determine why some translations seem to sometimes be delayed. As you mentioned in the other comment, there are a few instances where text was added between the last drop & this drop, but weren't translated.
> 
> And as you showed here, this should have been translated in the last drop rather than this one, but showed up here. I need a response from Kate to clarify when these translations are generated.

I conversed with Kate and the problem seems to come from the extraction process. We went through the source files that were sent for translation as a zip, and some changes would be missing. We confirmed that everything in this zip was translated, so the issue was in the extraction to create the source files to send for translation.  

For example, the plugin.properties missing text didn't show in the source.zip but showed on my forked repo used in the extraction. I re-ran the extraction script but still did not see the new text in the generated zip.

Kate thinks a similar issue occurred in the previous drop and this jmod.properties change wasn't captured in the extraction process. So now it is captured in this drop and translated here. It could be syncing or branch issues, but while working with Kate, I learned to better see what files are pulled from the extraction script. So for future drops, I can better check to make sure changes I expect to be translated will appear.

-------------

PR: https://git.openjdk.org/jdk20/pull/35

From naoto at openjdk.org  Thu Dec 15 18:58:09 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 Dec 2022 18:58:09 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <td2m9lDu24tKE3INK9xXuzPGPPNVoHfQYwzgCBkTF2Y=.3f4f2fd3-276e-4f27-a9fb-6bb7bea1a608@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <td2m9lDu24tKE3INK9xXuzPGPPNVoHfQYwzgCBkTF2Y=.3f4f2fd3-276e-4f27-a9fb-6bb7bea1a608@github.com>
Message-ID: <bxawN0XrRjf_HwocX3SD03ihnIENaEb6eqpuOx5KjwY=.265f097f-de75-474e-b835-ef067cb7afde@github.com>

On Thu, 15 Dec 2022 02:45:48 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed trailing whitespace

Changes requested by naoto (Reviewer).

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_de.properties line 217:

> 215: javac.msg.usage.nonstandard.footer=Diese zus\u00E4tzlichen Optionen k\u00F6nnen jederzeit ohne vorherige Ank\u00FCndigung ge\u00E4ndert werden.
> 216: 
> 217: javac.msg.bug=Im Compiler ({0}) ist eine Ausnahme aufgetreten. Erstellen Sie auf der Java-Seite zum Melden von Bugs (http://bugreport.java.com) einen Bugbericht, nachdem Sie die Bugdatenbank (http://bugs.java.com) auf Duplikate gepr\u00FCft haben. Geben Sie in Ihrem Bericht Ihr Programm, die folgende Diagnose und die Parameter an, die Sie dem Java-Compiler \u00FCbergeben haben. Vielen Dank.

How come `https` turned into `http`? I see these happening all over the places other than this location as well.

src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps_de.properties line 134:

> 132: public.api.replacement.column.header=Vorgeschlagene Ersetzung
> 133: artifact.not.found=nicht gefunden
> 134: jdeps.wiki.url=https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool

This seems to change backward. `openjdk.java.net` has changed to `openjdk.org` Same issues are observed in other locales.

-------------

PR: https://git.openjdk.org/jdk20/pull/35

From naoto at openjdk.org  Thu Dec 15 19:23:15 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 Dec 2022 19:23:15 GMT
Subject: Integrated: 8298416: Console should be declared `sealed`
In-Reply-To: <CGOo7D3wTII2bpEbIU4VsWjMeHJsh0hGjOe_eBQYxjY=.948b2f0c-7466-420b-9756-2dcf92363bb7@github.com>
References: <CGOo7D3wTII2bpEbIU4VsWjMeHJsh0hGjOe_eBQYxjY=.948b2f0c-7466-420b-9756-2dcf92363bb7@github.com>
Message-ID: <p4Ej2Br_ObxOeRxO1VSCl_mGOgpKEivimxuUpvygo8o=.e71cfa2b-71d2-4ae3-bf48-7ddf3baff1d7@github.com>

On Fri, 9 Dec 2022 20:14:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> `Console` class now has a couple of internal subclasses within `java.io` package. It should be `sealed` and subclasses be declared in the `permits` clause. The implementation resided in `Console` class is separated into `ConsoleImpl` class.

This pull request has now been integrated.

Changeset: 0ef35392
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0ef353925e645dd519e17aeb7a83e927271f8b95
Stats:     827 lines in 3 files changed: 373 ins; 249 del; 205 mod

8298416: Console should be declared `sealed`

Reviewed-by: jpai, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/11615

From ethan at mccue.dev  Thu Dec 15 20:30:17 2022
From: ethan at mccue.dev (Ethan McCue)
Date: Thu, 15 Dec 2022 15:30:17 -0500
Subject: JEP-198 - Lets start talking about JSON
Message-ID: <CA+NR86hGVP2F948jFH3qo7fDQsc-W6HP-1YK6LVSCJTL5yQ+mA@mail.gmail.com>

I'm writing this to drive some forward motion and to nerd-snipe those who
know better than I do into putting their thoughts into words.

There are three ways to process JSON[1]
- Streaming (Push or Pull)
- Traversing a Tree (Realized or Lazy)
- Declarative Databind (N ways)

Of these, JEP-198 explicitly ruled out providing "JAXB style type safe data
binding."

No justification is given, but if I had to insert my own: mapping the Json
model to/from the Java/JVM object model is a cursed combo of
- Huge possible design space
- Unpalatably large surface for backwards compatibility
- Serialization! Boo![2]

So for an artifact like the JDK, it probably doesn't make sense to include.
That tracks.
It won't make everyone happy, people like databind APIs, but it tracks.

So for the "read flow" these are the things to figure out.

                | Should Provide? | Intended User(s) |
----------------+-----------------+------------------+
 Streaming Push |                 |                  |
----------------+-----------------+------------------+
 Streaming Pull |                 |                  |
----------------+-----------------+------------------+
 Realized Tree  |                 |                  |
----------------+-----------------+------------------+
 Lazy Tree      |                 |                  |
----------------+-----------------+------------------+

At which point, we should talk about what "meets needs of Java developers
using JSON" implies.

JSON is ubiquitous. Most kinds of software us schmucks write could have a
reason to interact with it.
The full set of "user personas" therefore aren't practical for me to talk
about.[3]

JSON documents, however, are not so varied.

- There are small ones (1-10kb)
- There are medium ones (10-1000kb)
- There are big ones (1000kb-???)

- There are shallow ones
- There are deep ones

So that feels like an easier direction to talk about it from.


This repo[4] has some convenient toy examples of how some of those APIs
look in libraries
in the ecosystem. Specifically the Streaming Pull and Realized Tree models.

        User r = new User();
        while (true) {
            JsonToken token = reader.peek();
            switch (token) {
                case BEGIN_OBJECT:
                    reader.beginObject();
                    break;
                case END_OBJECT:
                    reader.endObject();
                    return r;
                case NAME:
                    String fieldname = reader.nextName();
                    switch (fieldname) {
                        case "id":
                            r.setId(reader.nextString());
                            break;
                        case "index":
                            r.setIndex(reader.nextInt());
                            break;
                        ...
                        case "friends":
                            r.setFriends(new ArrayList<>());
                            Friend f = null;
                            carryOn = true;
                            while (carryOn) {
                                token = reader.peek();
                                switch (token) {
                                    case BEGIN_ARRAY:
                                        reader.beginArray();
                                        break;
                                    case END_ARRAY:
                                        reader.endArray();
                                        carryOn = false;
                                        break;
                                    case BEGIN_OBJECT:
                                        reader.beginObject();
                                        f = new Friend();
                                        break;
                                    case END_OBJECT:
                                        reader.endObject();
                                        r.getFriends().add(f);
                                        break;
                                    case NAME:
                                        String fn = reader.nextName();
                                        switch (fn) {
                                            case "id":

f.setId(reader.nextString());
                                                break;
                                            case "name":

f.setName(reader.nextString());
                                                break;
                                        }
                                        break;
                                }
                            }
                            break;
                    }
            }

I think its not hard to argue that the streaming apis are brutalist. The
above is Gson, but Jackson, moshi, etc
seem at least morally equivalent.

Its hard to write, hard to write *correctly*, and theres is a curious
protensity towards pairing it
with anemic, mutable models.

That being said, it handles big documents and deep documents really well.
It also performs
pretty darn well and is good enough as a "fallback" when the intended user
experience
is through something like databind.

So what could we do meaningfully better with the language we have
today/will have tommorow?

- Sealed interfaces + Pattern matching could give a nicer model for tokens

        sealed interface JsonToken {
            record Field(String name) implements JsonToken {}
            record BeginArray() implements JsonToken {}
            record EndArray() implements JsonToken {}
            record BeginObject() implements JsonToken {}
            record EndObject() implements JsonToken {}
            // ...
        }

        // ...

        User r = new User();
        while (true) {
            JsonToken token = reader.peek();
            switch (token) {
                case BeginObject __:
                    reader.beginObject();
                    break;
                case EndObject __:
                    reader.endObject();
                    return r;
                case Field("id"):
                    r.setId(reader.nextString());
                    break;
                case Field("index"):
                    r.setIndex(reader.nextInt());
                    break;

                // ...

                case Field("friends"):
                    r.setFriends(new ArrayList<>());
                    Friend f = null;
                    carryOn = true;
                    while (carryOn) {
                        token = reader.peek();
                        switch (token) {
                // ...

- Value classes can make it all more efficient

        sealed interface JsonToken {
            value record Field(String name) implements JsonToken {}
            value record BeginArray() implements JsonToken {}
            value record EndArray() implements JsonToken {}
            value record BeginObject() implements JsonToken {}
            value record EndObject() implements JsonToken {}
            // ...
        }

- (Fun One) We can transform a simpler-to-write push parser into a pull
parser with Coroutines

    This is just a toy we could play with while making something in the
JDK. I'm pretty sure
    we could make a parser which feeds into something like

        interface Listener {
            void onObjectStart();
            void onObjectEnd();
            void onArrayStart();
            void onArrayEnd();
            void onField(String name);
            // ...
        }

    and invert a loop like

        while (true) {
            char c = next();
            switch (c) {
                case '{':
                    listener.onObjectStart();
                    // ...
                // ...
            }
        }

    by putting a Coroutine.yield in the callback.

    That might be a meaningful simplification in code structure, I don't
know enough to say.

But, I think there are some hard questions like

- Is the intent[5] to be make backing parser for ecosystem databind apis?
- Is the intent that users who want to handle big/deep documents fall back
to this?
- Are those new language features / conveniences enough to offset the cost
of committing to a new api?
- To whom exactly does a low level api provide value?
- What benefit is standardization in the JDK?

and just generally - who would be the consumer(s) of this?

The other kind of API still on the table is a Tree. There are two ways to
handle this

1. Load it into `Object`. Use a bunch of instanceof checks/casts to confirm
what it actually is.

        Object v;
        User u = new User();

        if ((v = jso.get("id")) != null) {
            u.setId((String) v);
        }
        if ((v = jso.get("index")) != null) {
            u.setIndex(((Long) v).intValue());
        }
        if ((v = jso.get("guid")) != null) {
            u.setGuid((String) v);
        }
        if ((v = jso.get("isActive")) != null) {
            u.setIsActive(((Boolean) v));
        }
        if ((v = jso.get("balance")) != null) {
            u.setBalance((String) v);
        }
        // ...
        if ((v = jso.get("latitude")) != null) {
            u.setLatitude(v instanceof BigDecimal ? ((BigDecimal)
v).doubleValue() : (Double) v);
        }
        if ((v = jso.get("longitude")) != null) {
            u.setLongitude(v instanceof BigDecimal ? ((BigDecimal)
v).doubleValue() : (Double) v);
        }
        if ((v = jso.get("greeting")) != null) {
            u.setGreeting((String) v);
        }
        if ((v = jso.get("favoriteFruit")) != null) {
            u.setFavoriteFruit((String) v);
        }
        if ((v = jso.get("tags")) != null) {
            List<Object> jsonarr = (List<Object>) v;
            u.setTags(new ArrayList<>());
            for (Object vi : jsonarr) {
                u.getTags().add((String) vi);
            }
        }
        if ((v = jso.get("friends")) != null) {
            List<Object> jsonarr = (List<Object>) v;
            u.setFriends(new ArrayList<>());
            for (Object vi : jsonarr) {
                Map<String, Object> jso0 = (Map<String, Object>) vi;
                Friend f = new Friend();
                f.setId((String) jso0.get("id"));
                f.setName((String) jso0.get("name"));
                u.getFriends().add(f);
            }
        }

2. Have an explicit model for Json, and helper methods that do said casts[6]


this.setSiteSetting(readFromJson(jsonObject.getJsonObject("site")));
JsonArray groups = jsonObject.getJsonArray("group");
if(groups != null)
{
int len = groups.size();
for(int i=0; i<len; i++)
{
JsonObject grp = groups.getJsonObject(i);
SNMPSetting grpSetting = readFromJson(grp);
String grpName = grp.getString("dbgroup", null);
if(grpName != null && grpSetting != null)
this.groupSettings.put(grpName, grpSetting);
}
}
JsonArray hosts = jsonObject.getJsonArray("host");
if(hosts != null)
{
int len = hosts.size();
for(int i=0; i<len; i++)
{
JsonObject host = hosts.getJsonObject(i);
SNMPSetting hostSetting = readFromJson(host);
String hostName = host.getString("dbhost", null);
if(hostName != null && hostSetting != null)
this.hostSettings.put(hostName, hostSetting);
}
}

I think what has become easier to represent in the language nowadays is
that explicit model for Json.
Its the 101 lesson of sealed interfaces.[7] It feels nice and clean.

        sealed interface Json {
            final class Null implements Json {}
            final class True implements Json {}
            final class False implements Json {}
            final class Array implements Json {}
            final class Object implements Json {}
            final class String implements Json {}
            final class Number implements Json {}
        }

And the cast-and-check approach is now more viable on account of pattern
matching.

        if (jso.get("id") instanceof String v) {
            u.setId(v);
        }
        if (jso.get("index") instanceof Long v) {
            u.setIndex(v.intValue());
        }
        if (jso.get("guid") instanceof String v) {
            u.setGuid(v);
        }

        // or

        if (jso.get("id") instanceof String id &&
                jso.get("index") instanceof Long index &&
                jso.get("guid") instanceof String guid) {
            return new User(id, index, guid, ...); // look ma, no setters!
        }


And on the horizon, again, is value types.

But there are problems with this approach beyond the performance
implications of loading into
a tree.

For one, all the code samples above have different behaviors around null
keys and missing keys
that are not obvious from first glance.

This won't accept any null or missing fields

        if (jso.get("id") instanceof String id &&
                jso.get("index") instanceof Long index &&
                jso.get("guid") instanceof String guid) {
            return new User(id, index, guid, ...);
        }

This will accept individual null or missing fields, but also will silently
ignore
fields with incorrect types

        if (jso.get("id") instanceof String v) {
            u.setId(v);
        }
        if (jso.get("index") instanceof Long v) {
            u.setIndex(v.intValue());
        }
        if (jso.get("guid") instanceof String v) {
            u.setGuid(v);
        }

And, compared to databind where there is information about the expected
structure of the document
and its the job of the framework to assert that, I posit that the errors
that would be encountered
when writing code against this would be more like

    "something wrong with user"

than

    "problem at users[5].name, expected string or null. got 5"

Which feels unideal.


One approach I find promising is something close to what Elm does with its
decoders[8]. Not just combining assertion
and binding like what pattern matching with records allows, but including a
scheme for bubbling/nesting errors.

    static String string(Json json) throws JsonDecodingException {
        if (!(json instanceof Json.String jsonString)) {
            throw JsonDecodingException.of(
                    "expected a string",
                    json
            );
        } else {
            return jsonString.value();
        }
    }

    static <T> T field(Json json, String fieldName, Decoder<? extends T>
valueDecoder) throws JsonDecodingException {
        var jsonObject = object(json);
        var value = jsonObject.get(fieldName);
        if (value == null) {
            throw JsonDecodingException.atField(
                    fieldName,
                    JsonDecodingException.of(
                            "no value for field",
                            json
                    )
            );
        }
        else {
            try {
                return valueDecoder.decode(value);
            } catch (JsonDecodingException e) {
                throw JsonDecodingException.atField(
                        fieldName,
                        e
                );
            }  catch (Exception e) {
                throw JsonDecodingException.atField(fieldName,
JsonDecodingException.of(e, value));
            }
        }
    }

Which I think has some benefits over the ways I've seen of working with
trees.



- It is declarative enough that folks who prefer databind might be happy
enough.

        static User fromJson(Json json) {
            return new User(
                Decoder.field(json, "id", Decoder::string),
                Decoder.field(json, "index", Decoder::long_),
                Decoder.field(json, "guid", Decoder::string),
            );
        }

        / ...

        List<User> users = Decoders.array(json, User::fromJson);

- Handling null and optional fields could be less easily conflated

    Decoder.field(json, "id", Decoder::string);

    Decoder.nullableField(json, "id", Decoder::string);

    Decoder.optionalField(json, "id", Decoder::string);

    Decoder.optionalNullableField(json, "id", Decoder::string);


- It composes well with user defined classes

    record Guid(String value) {
        Guid {
            // some assertions on the structure of value
        }
    }

    Decoder.string(json, "guid", guid -> new Guid(Decoder.string(guid)));

    // or even

    record Guid(String value) {
        Guid {
            // some assertions on the structure of value
        }

        static Guid fromJson(Json json) {
            return new Guid(Decoder.string(guid));
        }
    }

    Decoder.string(json, "guid", Guid::fromJson);


- When something goes wrong, the API can handle the fiddlyness of capturing
information for feedback.

    In the code I've sketched out its just what field/index things went
wrong at. Potentially
    capturing metadata like row/col numbers of the source would be sensible
too.

    Its just not reasonable to expect devs to do extra work to get that and
its really nice to give it.

There are also some downsides like

-  I do not know how compatible it would be with lazy trees.

     Lazy trees being the only way that a tree api could handle big or deep
documents.
     The general concept as applied in libraries like json-tree[9] is to
navigate without
     doing any work, and that clashes with wanting to instanceof check the
info at the
     current path.

- It *almost* gives enough information to be a general schema approach

    If one field fails, that in the model throws an exception immediately.
If an API should
    return "errors": [...], that is inconvenient to construct.

- None of the existing popular libraries are doing this

     The only mechanics that are strictly required to give this sort of API
is lambdas. Those have
     been out for a decade. Yes sealed interfaces make the data model
prettier but in concept you
     can build the same thing on top of anything.

     I could argue that this is because of "cultural momentum" of databind
or some other reason,
     but the fact remains that it isn't a proven out approach.

     Writing Json libraries is a todo list[10]. There are a lot of bad
ideas and this might be one of the,

- Performance impact of so many instanceof checks

    I've gotten a 4.2% slowdown compared to the "regular" tree code without
the repeated casts.

    But that was with a parser that is 5x slower than Jacksons. (using the
same benchmark project as for the snippets).
    I think there could be reason to believe that the JIT does well enough
with repeated instanceof
    checks to consider it.


My current thinking is that - despite not solving for large or deep
documents - starting with a really "dumb" realized tree api
might be the right place to start for the read side of a potential
incubator module.

But regardless - this feels like a good time to start more concrete
conversations. I fell I should cap this email since I've reached the point
of decoherence and haven't even mentioned the write side of things




[1]: http://www.cowtowncoder.com/blog/archives/2009/01/entry_131.html
[2]: https://security.snyk.io/vuln/maven?search=jackson-databind
[3]: I only know like 8 people
[4]:
https://github.com/fabienrenaud/java-json-benchmark/blob/master/src/main/java/com/github/fabienrenaud/jjb/stream/UsersStreamDeserializer.java
[5]: When I say "intent", I do so knowing full well no one has been
actively thinking of this for an entire Game of Thrones
[6]:
https://github.com/yahoo/mysql_perf_analyzer/blob/master/myperf/src/main/java/com/yahoo/dba/perf/myperf/common/SNMPSettings.java
[7]: https://www.infoq.com/articles/data-oriented-programming-java/
[8]: https://package.elm-lang.org/packages/elm/json/latest/Json-Decode
[9]: https://github.com/jbee/json-tree
[10]: https://stackoverflow.com/a/14442630/2948173
[11]: In 30 days JEP-198 it will be recognizably PI days old for the 2nd
time in its history.
[12]: To me, the fact that is still an open JEP is more a social
convenience than anything. I could just as easily writing this exact same
email about TOML.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221215/67be6730/attachment-0001.htm>

From dnguyen at openjdk.org  Thu Dec 15 20:43:42 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 15 Dec 2022 20:43:42 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>

> Open l10n drop
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Fix https and changed URL back

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/35/files
  - new: https://git.openjdk.org/jdk20/pull/35/files/54d2ec5f..09140a05

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=01-02

  Stats: 15 lines in 15 files changed: 0 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk20/pull/35.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Thu Dec 15 20:55:08 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 15 Dec 2022 20:55:08 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <bxawN0XrRjf_HwocX3SD03ihnIENaEb6eqpuOx5KjwY=.265f097f-de75-474e-b835-ef067cb7afde@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <td2m9lDu24tKE3INK9xXuzPGPPNVoHfQYwzgCBkTF2Y=.3f4f2fd3-276e-4f27-a9fb-6bb7bea1a608@github.com>
 <bxawN0XrRjf_HwocX3SD03ihnIENaEb6eqpuOx5KjwY=.265f097f-de75-474e-b835-ef067cb7afde@github.com>
Message-ID: <Wq-WW8kfFkrS08vlPmgmD_ApiBVdboI6hEoARHr72zk=.7d3ca55c-db6e-4734-8724-75cb5d0a2f82@github.com>

On Thu, 15 Dec 2022 18:52:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed trailing whitespace
>
> src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps_de.properties line 134:
> 
>> 132: public.api.replacement.column.header=Vorgeschlagene Ersetzung
>> 133: artifact.not.found=nicht gefunden
>> 134: jdeps.wiki.url=https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool
> 
> This seems to change backward. `openjdk.java.net` has changed to `openjdk.org` Same issues are observed in other locales.

This and the https->http differences seem to also be a part of the extraction issue. The resource generation files show "http" and "java.net", but I see differently on my local repo that I used for the extraction.

I will run a new extraction job on a fresh repo/branch to see if this issue is reproducible and narrow down the source of the extraction issue.

As discussed with Naoto, these are small edits, and they have been addressed in the latest PR.

-------------

PR: https://git.openjdk.org/jdk20/pull/35

From naoto at openjdk.org  Thu Dec 15 21:16:07 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 Dec 2022 21:16:07 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
Message-ID: <pE7z2olK_Ec3qJO1w1KbXo55BIsYVK7Cu1_MPUMUmkg=.48f8c2f4-0b68-47ba-a46f-d8cb8d17d481@github.com>

On Thu, 15 Dec 2022 20:43:42 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix https and changed URL back

Thanks for the update, Damon. Looks good for this drop.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/35

From jonathan.gibbons at oracle.com  Thu Dec 15 21:47:59 2022
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 15 Dec 2022 13:47:59 -0800
Subject: Boilerplate to add a new module
In-Reply-To: <CA+NR86gQB+33FtsMbPzfMg80csrzbf3vMZMnRXPKP0=6E7iaiA@mail.gmail.com>
References: <CA+NR86gQB+33FtsMbPzfMg80csrzbf3vMZMnRXPKP0=6E7iaiA@mail.gmail.com>
Message-ID: <9f3c4efe-d646-9578-49aa-65014df699ea@oracle.com>

No changes or updates are required for jtreg

-- Jon

On 12/13/22 7:36 PM, Ethan McCue wrote:
>
> (jtreg I assume has some extra setup? Anything else?)

From reinier at zwitserloot.com  Thu Dec 15 22:03:36 2022
From: reinier at zwitserloot.com (Reinier Zwitserloot)
Date: Thu, 15 Dec 2022 23:03:36 +0100
Subject: JEP-198 - Lets start talking about JSON
In-Reply-To: <CA+NR86hGVP2F948jFH3qo7fDQsc-W6HP-1YK6LVSCJTL5yQ+mA@mail.gmail.com>
References: <CA+NR86hGVP2F948jFH3qo7fDQsc-W6HP-1YK6LVSCJTL5yQ+mA@mail.gmail.com>
Message-ID: <CAK6PxWPA9hVqsczSrPFr6cdWgedhfamVJL0OE8fqZd7uA6j9qA@mail.gmail.com>

A recent Advent-of-Code puzzle also made me double check the support of
JSON in the java core libs and it is indeed a curious situation that the
java core libs don?t cater to it particularly well.

However, I?m not seeing an easy way forward to try to close this hole in
the core library offerings.

If you need to stream huge swaths of JSON, generally there?s a clear unit
size that you can just databind. Something like:

String jsonStr = """ { "version": 5, "data": [
  -- 1 million relatively small records in this list --
  ] } """;


The usual swath of JSON parsers tend to support this (giving you a stream
of java instances created by databinding those small records one by one),
or if not, the best move forward is presumably to file a pull request with
those projects; the java.util.log experiment shows that trying to
?core-librarize? needs that the community at large already fulfills with
third party deps isn?t a good move, especially if the core library variant
tries to oversimplify to avoid the trap of being too opinionated (which
core libs shouldn?t be). In other words, the need for ?stream this JSON for
me? style APIs is even more exotic that Ethan is suggesting.

I see a fundamental problem here:


   - The 95%+ use case for working with JSON for your average java coder is
   best done with data binding.
   - core libs doesn?t want to provide it, partly because it?s got a large
   design space, partly because the field?s already covered by GSON and
   Jackson-json; java.util.log proves this doesn?t work. At least, I gather
   that?s what Ethan thinks and I agree with this assessment.
   - A language that claims to be ?batteries included? that doesn?t ship
   with a JSON parser in this era is dubious, to say the least.


I?m not sure how to square this circle. Hence it feels like core-libs needs
to hold some more fundamental debates first:


   - Maybe it?s time to state in a more or less official decree that
   well-established, large design space jobs will remain the purview of
   dependencies no matter how popular it has, unless being part of the
   core-libs adds something more fundamental the third party deps cannot bring
   to the table (such as language integration), or the community standardizes
   on a single library (JSR310?s story, more or less). JSON parsing would
   qualify as ?well-established? (GSON and Jackson) and ?large design space?
   as Ethan pointed out.
   - Given that 99% of java projects, even really simple ones, start with
   maven/gradle and a list of deps, is that really a problem?


I?m honestly not sure what the right answer is. On one hand, the npm
ecosystem seems to be doing very well even though their ?batteries
included? situation is an utter shambles. Then again, the notion that your
average nodejs project includes 10x+ more dependencies than other languages
is likely a significant part of the security clown fiesta going on over
there as far as 3rd party deps is concerned, so by no means should java
just blindly emulate their solutions.

I don?t like the idea of shipping a non-data-binding JSON API in the core
libs. The root issue with JSON is that you just can?t tell how to interpret
any given JSON token, because that?s not how JSON is used in practice. What
does 5 mean? Could be that I?m to take that as an int, or as a double, or
perhaps even as a j.t.Instant (epoch-millis), and defaulting behaviour
(similar to j.u.Map?s .getOrDefault is *very* convenient to parse most JSON
out there in the real world - omitting k/v pairs whose value is still on
default is very common). That?s what makes those databind libraries so
enticing: Instead of trying to pattern match my way into this behaviour:


   - If the element isn?t there at all or null, give me a list-of-longs
   with a single 0 in it.
   - If the element is a number, make me a list-of-longs with 1 value in
   it, that is that number, as long.
   - If the element is a string, parse it into a long, then get me a list
   with this one long value (because IEEE double rules mean sometimes you have
   to put these things in string form or they get mangled by
javascript-eval style
   parsers).


And yet the above is quite common, and can easily be done by a databinder,
which sees you want a List<Long> for a field whose default value is
List.of(1L), and, armed with that knowledge, can transit the JSON into java
in that way.

You don?t *need* databinding to cater to this idea: You could for example
have a jsonNode.asLong(123) method that would parse a string if need be,
even. But this has nothing to do with pattern matching either.

 --Reinier Zwitserloot


On 15 Dec 2022 at 21:30:17, Ethan McCue <ethan at mccue.dev> wrote:

> I'm writing this to drive some forward motion and to nerd-snipe those who
> know better than I do into putting their thoughts into words.
>
> There are three ways to process JSON[1]
> - Streaming (Push or Pull)
> - Traversing a Tree (Realized or Lazy)
> - Declarative Databind (N ways)
>
> Of these, JEP-198 explicitly ruled out providing "JAXB style type safe
> data binding."
>
> No justification is given, but if I had to insert my own: mapping the Json
> model to/from the Java/JVM object model is a cursed combo of
> - Huge possible design space
> - Unpalatably large surface for backwards compatibility
> - Serialization! Boo![2]
>
> So for an artifact like the JDK, it probably doesn't make sense to
> include. That tracks.
> It won't make everyone happy, people like databind APIs, but it tracks.
>
> So for the "read flow" these are the things to figure out.
>
>                 | Should Provide? | Intended User(s) |
> ----------------+-----------------+------------------+
>  Streaming Push |                 |                  |
> ----------------+-----------------+------------------+
>  Streaming Pull |                 |                  |
> ----------------+-----------------+------------------+
>  Realized Tree  |                 |                  |
> ----------------+-----------------+------------------+
>  Lazy Tree      |                 |                  |
> ----------------+-----------------+------------------+
>
> At which point, we should talk about what "meets needs of Java developers
> using JSON" implies.
>
> JSON is ubiquitous. Most kinds of software us schmucks write could have a
> reason to interact with it.
> The full set of "user personas" therefore aren't practical for me to talk
> about.[3]
>
> JSON documents, however, are not so varied.
>
> - There are small ones (1-10kb)
> - There are medium ones (10-1000kb)
> - There are big ones (1000kb-???)
>
> - There are shallow ones
> - There are deep ones
>
> So that feels like an easier direction to talk about it from.
>
>
> This repo[4] has some convenient toy examples of how some of those APIs
> look in libraries
> in the ecosystem. Specifically the Streaming Pull and Realized Tree models.
>
>         User r = new User();
>         while (true) {
>             JsonToken token = reader.peek();
>             switch (token) {
>                 case BEGIN_OBJECT:
>                     reader.beginObject();
>                     break;
>                 case END_OBJECT:
>                     reader.endObject();
>                     return r;
>                 case NAME:
>                     String fieldname = reader.nextName();
>                     switch (fieldname) {
>                         case "id":
>                             r.setId(reader.nextString());
>                             break;
>                         case "index":
>                             r.setIndex(reader.nextInt());
>                             break;
>                         ...
>                         case "friends":
>                             r.setFriends(new ArrayList<>());
>                             Friend f = null;
>                             carryOn = true;
>                             while (carryOn) {
>                                 token = reader.peek();
>                                 switch (token) {
>                                     case BEGIN_ARRAY:
>                                         reader.beginArray();
>                                         break;
>                                     case END_ARRAY:
>                                         reader.endArray();
>                                         carryOn = false;
>                                         break;
>                                     case BEGIN_OBJECT:
>                                         reader.beginObject();
>                                         f = new Friend();
>                                         break;
>                                     case END_OBJECT:
>                                         reader.endObject();
>                                         r.getFriends().add(f);
>                                         break;
>                                     case NAME:
>                                         String fn = reader.nextName();
>                                         switch (fn) {
>                                             case "id":
>
> f.setId(reader.nextString());
>                                                 break;
>                                             case "name":
>
> f.setName(reader.nextString());
>                                                 break;
>                                         }
>                                         break;
>                                 }
>                             }
>                             break;
>                     }
>             }
>
> I think its not hard to argue that the streaming apis are brutalist. The
> above is Gson, but Jackson, moshi, etc
> seem at least morally equivalent.
>
> Its hard to write, hard to write *correctly*, and theres is a curious
> protensity towards pairing it
> with anemic, mutable models.
>
> That being said, it handles big documents and deep documents really well.
> It also performs
> pretty darn well and is good enough as a "fallback" when the intended user
> experience
> is through something like databind.
>
> So what could we do meaningfully better with the language we have
> today/will have tommorow?
>
> - Sealed interfaces + Pattern matching could give a nicer model for tokens
>
>         sealed interface JsonToken {
>             record Field(String name) implements JsonToken {}
>             record BeginArray() implements JsonToken {}
>             record EndArray() implements JsonToken {}
>             record BeginObject() implements JsonToken {}
>             record EndObject() implements JsonToken {}
>             // ...
>         }
>
>         // ...
>
>         User r = new User();
>         while (true) {
>             JsonToken token = reader.peek();
>             switch (token) {
>                 case BeginObject __:
>                     reader.beginObject();
>                     break;
>                 case EndObject __:
>                     reader.endObject();
>                     return r;
>                 case Field("id"):
>                     r.setId(reader.nextString());
>                     break;
>                 case Field("index"):
>                     r.setIndex(reader.nextInt());
>                     break;
>
>                 // ...
>
>                 case Field("friends"):
>                     r.setFriends(new ArrayList<>());
>                     Friend f = null;
>                     carryOn = true;
>                     while (carryOn) {
>                         token = reader.peek();
>                         switch (token) {
>                 // ...
>
> - Value classes can make it all more efficient
>
>         sealed interface JsonToken {
>             value record Field(String name) implements JsonToken {}
>             value record BeginArray() implements JsonToken {}
>             value record EndArray() implements JsonToken {}
>             value record BeginObject() implements JsonToken {}
>             value record EndObject() implements JsonToken {}
>             // ...
>         }
>
> - (Fun One) We can transform a simpler-to-write push parser into a pull
> parser with Coroutines
>
>     This is just a toy we could play with while making something in the
> JDK. I'm pretty sure
>     we could make a parser which feeds into something like
>
>         interface Listener {
>             void onObjectStart();
>             void onObjectEnd();
>             void onArrayStart();
>             void onArrayEnd();
>             void onField(String name);
>             // ...
>         }
>
>     and invert a loop like
>
>         while (true) {
>             char c = next();
>             switch (c) {
>                 case '{':
>                     listener.onObjectStart();
>                     // ...
>                 // ...
>             }
>         }
>
>     by putting a Coroutine.yield in the callback.
>
>     That might be a meaningful simplification in code structure, I don't
> know enough to say.
>
> But, I think there are some hard questions like
>
> - Is the intent[5] to be make backing parser for ecosystem databind apis?
> - Is the intent that users who want to handle big/deep documents fall back
> to this?
> - Are those new language features / conveniences enough to offset the cost
> of committing to a new api?
> - To whom exactly does a low level api provide value?
> - What benefit is standardization in the JDK?
>
> and just generally - who would be the consumer(s) of this?
>
> The other kind of API still on the table is a Tree. There are two ways to
> handle this
>
> 1. Load it into `Object`. Use a bunch of instanceof checks/casts to
> confirm what it actually is.
>
>         Object v;
>         User u = new User();
>
>         if ((v = jso.get("id")) != null) {
>             u.setId((String) v);
>         }
>         if ((v = jso.get("index")) != null) {
>             u.setIndex(((Long) v).intValue());
>         }
>         if ((v = jso.get("guid")) != null) {
>             u.setGuid((String) v);
>         }
>         if ((v = jso.get("isActive")) != null) {
>             u.setIsActive(((Boolean) v));
>         }
>         if ((v = jso.get("balance")) != null) {
>             u.setBalance((String) v);
>         }
>         // ...
>         if ((v = jso.get("latitude")) != null) {
>             u.setLatitude(v instanceof BigDecimal ? ((BigDecimal)
> v).doubleValue() : (Double) v);
>         }
>         if ((v = jso.get("longitude")) != null) {
>             u.setLongitude(v instanceof BigDecimal ? ((BigDecimal)
> v).doubleValue() : (Double) v);
>         }
>         if ((v = jso.get("greeting")) != null) {
>             u.setGreeting((String) v);
>         }
>         if ((v = jso.get("favoriteFruit")) != null) {
>             u.setFavoriteFruit((String) v);
>         }
>         if ((v = jso.get("tags")) != null) {
>             List<Object> jsonarr = (List<Object>) v;
>             u.setTags(new ArrayList<>());
>             for (Object vi : jsonarr) {
>                 u.getTags().add((String) vi);
>             }
>         }
>         if ((v = jso.get("friends")) != null) {
>             List<Object> jsonarr = (List<Object>) v;
>             u.setFriends(new ArrayList<>());
>             for (Object vi : jsonarr) {
>                 Map<String, Object> jso0 = (Map<String, Object>) vi;
>                 Friend f = new Friend();
>                 f.setId((String) jso0.get("id"));
>                 f.setName((String) jso0.get("name"));
>                 u.getFriends().add(f);
>             }
>         }
>
> 2. Have an explicit model for Json, and helper methods that do said
> casts[6]
>
>
> this.setSiteSetting(readFromJson(jsonObject.getJsonObject("site")));
> JsonArray groups = jsonObject.getJsonArray("group");
> if(groups != null)
> {
> int len = groups.size();
> for(int i=0; i<len; i++)
> {
> JsonObject grp = groups.getJsonObject(i);
> SNMPSetting grpSetting = readFromJson(grp);
> String grpName = grp.getString("dbgroup", null);
> if(grpName != null && grpSetting != null)
> this.groupSettings.put(grpName, grpSetting);
> }
> }
> JsonArray hosts = jsonObject.getJsonArray("host");
> if(hosts != null)
> {
> int len = hosts.size();
> for(int i=0; i<len; i++)
> {
> JsonObject host = hosts.getJsonObject(i);
> SNMPSetting hostSetting = readFromJson(host);
> String hostName = host.getString("dbhost", null);
> if(hostName != null && hostSetting != null)
> this.hostSettings.put(hostName, hostSetting);
> }
> }
>
> I think what has become easier to represent in the language nowadays is
> that explicit model for Json.
> Its the 101 lesson of sealed interfaces.[7] It feels nice and clean.
>
>         sealed interface Json {
>             final class Null implements Json {}
>             final class True implements Json {}
>             final class False implements Json {}
>             final class Array implements Json {}
>             final class Object implements Json {}
>             final class String implements Json {}
>             final class Number implements Json {}
>         }
>
> And the cast-and-check approach is now more viable on account of pattern
> matching.
>
>         if (jso.get("id") instanceof String v) {
>             u.setId(v);
>         }
>         if (jso.get("index") instanceof Long v) {
>             u.setIndex(v.intValue());
>         }
>         if (jso.get("guid") instanceof String v) {
>             u.setGuid(v);
>         }
>
>         // or
>
>         if (jso.get("id") instanceof String id &&
>                 jso.get("index") instanceof Long index &&
>                 jso.get("guid") instanceof String guid) {
>             return new User(id, index, guid, ...); // look ma, no setters!
>         }
>
>
> And on the horizon, again, is value types.
>
> But there are problems with this approach beyond the performance
> implications of loading into
> a tree.
>
> For one, all the code samples above have different behaviors around null
> keys and missing keys
> that are not obvious from first glance.
>
> This won't accept any null or missing fields
>
>         if (jso.get("id") instanceof String id &&
>                 jso.get("index") instanceof Long index &&
>                 jso.get("guid") instanceof String guid) {
>             return new User(id, index, guid, ...);
>         }
>
> This will accept individual null or missing fields, but also will silently
> ignore
> fields with incorrect types
>
>         if (jso.get("id") instanceof String v) {
>             u.setId(v);
>         }
>         if (jso.get("index") instanceof Long v) {
>             u.setIndex(v.intValue());
>         }
>         if (jso.get("guid") instanceof String v) {
>             u.setGuid(v);
>         }
>
> And, compared to databind where there is information about the expected
> structure of the document
> and its the job of the framework to assert that, I posit that the errors
> that would be encountered
> when writing code against this would be more like
>
>     "something wrong with user"
>
> than
>
>     "problem at users[5].name, expected string or null. got 5"
>
> Which feels unideal.
>
>
> One approach I find promising is something close to what Elm does with its
> decoders[8]. Not just combining assertion
> and binding like what pattern matching with records allows, but including
> a scheme for bubbling/nesting errors.
>
>     static String string(Json json) throws JsonDecodingException {
>         if (!(json instanceof Json.String jsonString)) {
>             throw JsonDecodingException.of(
>                     "expected a string",
>                     json
>             );
>         } else {
>             return jsonString.value();
>         }
>     }
>
>     static <T> T field(Json json, String fieldName, Decoder<? extends T>
> valueDecoder) throws JsonDecodingException {
>         var jsonObject = object(json);
>         var value = jsonObject.get(fieldName);
>         if (value == null) {
>             throw JsonDecodingException.atField(
>                     fieldName,
>                     JsonDecodingException.of(
>                             "no value for field",
>                             json
>                     )
>             );
>         }
>         else {
>             try {
>                 return valueDecoder.decode(value);
>             } catch (JsonDecodingException e) {
>                 throw JsonDecodingException.atField(
>                         fieldName,
>                         e
>                 );
>             }  catch (Exception e) {
>                 throw JsonDecodingException.atField(fieldName,
> JsonDecodingException.of(e, value));
>             }
>         }
>     }
>
> Which I think has some benefits over the ways I've seen of working with
> trees.
>
>
>
> - It is declarative enough that folks who prefer databind might be happy
> enough.
>
>         static User fromJson(Json json) {
>             return new User(
>                 Decoder.field(json, "id", Decoder::string),
>                 Decoder.field(json, "index", Decoder::long_),
>                 Decoder.field(json, "guid", Decoder::string),
>             );
>         }
>
>         / ...
>
>         List<User> users = Decoders.array(json, User::fromJson);
>
> - Handling null and optional fields could be less easily conflated
>
>     Decoder.field(json, "id", Decoder::string);
>
>     Decoder.nullableField(json, "id", Decoder::string);
>
>     Decoder.optionalField(json, "id", Decoder::string);
>
>     Decoder.optionalNullableField(json, "id", Decoder::string);
>
>
> - It composes well with user defined classes
>
>     record Guid(String value) {
>         Guid {
>             // some assertions on the structure of value
>         }
>     }
>
>     Decoder.string(json, "guid", guid -> new Guid(Decoder.string(guid)));
>
>     // or even
>
>     record Guid(String value) {
>         Guid {
>             // some assertions on the structure of value
>         }
>
>         static Guid fromJson(Json json) {
>             return new Guid(Decoder.string(guid));
>         }
>     }
>
>     Decoder.string(json, "guid", Guid::fromJson);
>
>
> - When something goes wrong, the API can handle the fiddlyness of
> capturing information for feedback.
>
>     In the code I've sketched out its just what field/index things went
> wrong at. Potentially
>     capturing metadata like row/col numbers of the source would be
> sensible too.
>
>     Its just not reasonable to expect devs to do extra work to get that
> and its really nice to give it.
>
> There are also some downsides like
>
> -  I do not know how compatible it would be with lazy trees.
>
>      Lazy trees being the only way that a tree api could handle big or
> deep documents.
>      The general concept as applied in libraries like json-tree[9] is to
> navigate without
>      doing any work, and that clashes with wanting to instanceof check the
> info at the
>      current path.
>
> - It *almost* gives enough information to be a general schema approach
>
>     If one field fails, that in the model throws an exception immediately.
> If an API should
>     return "errors": [...], that is inconvenient to construct.
>
> - None of the existing popular libraries are doing this
>
>      The only mechanics that are strictly required to give this sort of
> API is lambdas. Those have
>      been out for a decade. Yes sealed interfaces make the data model
> prettier but in concept you
>      can build the same thing on top of anything.
>
>      I could argue that this is because of "cultural momentum" of databind
> or some other reason,
>      but the fact remains that it isn't a proven out approach.
>
>      Writing Json libraries is a todo list[10]. There are a lot of bad
> ideas and this might be one of the,
>
> - Performance impact of so many instanceof checks
>
>     I've gotten a 4.2% slowdown compared to the "regular" tree code
> without the repeated casts.
>
>     But that was with a parser that is 5x slower than Jacksons. (using the
> same benchmark project as for the snippets).
>     I think there could be reason to believe that the JIT does well enough
> with repeated instanceof
>     checks to consider it.
>
>
> My current thinking is that - despite not solving for large or deep
> documents - starting with a really "dumb" realized tree api
> might be the right place to start for the read side of a potential
> incubator module.
>
> But regardless - this feels like a good time to start more concrete
> conversations. I fell I should cap this email since I've reached the point
> of decoherence and haven't even mentioned the write side of things
>
>
>
>
> [1]: http://www.cowtowncoder.com/blog/archives/2009/01/entry_131.html
> [2]: https://security.snyk.io/vuln/maven?search=jackson-databind
> [3]: I only know like 8 people
> [4]:
> https://github.com/fabienrenaud/java-json-benchmark/blob/master/src/main/java/com/github/fabienrenaud/jjb/stream/UsersStreamDeserializer.java
> [5]: When I say "intent", I do so knowing full well no one has been
> actively thinking of this for an entire Game of Thrones
> [6]:
> https://github.com/yahoo/mysql_perf_analyzer/blob/master/myperf/src/main/java/com/yahoo/dba/perf/myperf/common/SNMPSettings.java
> [7]: https://www.infoq.com/articles/data-oriented-programming-java/
> [8]: https://package.elm-lang.org/packages/elm/json/latest/Json-Decode
> [9]: https://github.com/jbee/json-tree
> [10]: https://stackoverflow.com/a/14442630/2948173
> [11]: In 30 days JEP-198 it will be recognizably PI days old for the 2nd
> time in its history.
> [12]: To me, the fact that is still an open JEP is more a social
> convenience than anything. I could just as easily writing this exact same
> email about TOML.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221215/7c59bff4/attachment-0001.htm>

From dnguyen at openjdk.org  Thu Dec 15 23:01:35 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 15 Dec 2022 23:01:35 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>

> Open l10n drop
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Revert double quote as well

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/35/files
  - new: https://git.openjdk.org/jdk20/pull/35/files/09140a05..57c42206

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=02-03

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk20/pull/35.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35

PR: https://git.openjdk.org/jdk20/pull/35

From naoto at openjdk.org  Thu Dec 15 23:12:06 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 Dec 2022 23:12:06 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
Message-ID: <orIjM2vHBgrTyKBL5fjG9TX1ZI8AuJ48PGF2nqlSip0=.7f9e9cb5-0cfa-4985-8bff-aa5ead6f1c6d@github.com>

On Thu, 15 Dec 2022 23:01:35 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert double quote as well

Marked as reviewed by naoto (Reviewer).

src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/resources/jdeprscan_de.properties line 26:

> 24: #
> 25: 
> 26: main.usage=Verwendung: jdeprscan [Optionen] '{dir|jar|class}' ...\n\nOptionen:\n        --class-path PATH\n        --for-removal\n        --full-version\n  -? -h --help\n  -l    --list\n        --release {0}\n  -v    --verbose\n        --version

Good catch!

-------------

PR: https://git.openjdk.org/jdk20/pull/35

From almatvee at openjdk.org  Thu Dec 15 23:17:12 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 15 Dec 2022 23:17:12 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
Message-ID: <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>

On Thu, 15 Dec 2022 20:43:42 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix https and changed URL back

src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties line 82:

> 80: 
> 81: error.foreign-app-image=Fehler: .jpackage.xml-Datei fehlt in app-image-Verzeichnis ({0})
> 82: error.invalid-app-image=Fehler: app-image-Verzeichnis ({0}) wurde von einer anderen jpackage-Version generiert, oder .jpackage.xml ist nicht wohlgeformt

error.invalid-app-image looks like old translation and missing "{1}". Also, why () is used instead of ""?

src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_ja.properties line 82:

> 80: 
> 81: error.foreign-app-image=\u30A8\u30E9\u30FC: app-image\u30C7\u30A3\u30EC\u30AF\u30C8\u30EA({0})\u306B.jpackage.xml\u30D5\u30A1\u30A4\u30EB\u304C\u3042\u308A\u307E\u305B\u3093
> 82: error.invalid-app-image=\u30A8\u30E9\u30FC: app-image\u30C7\u30A3\u30EC\u30AF\u30C8\u30EA({0})\u306F\u5225\u306Ejpackage\u30D0\u30FC\u30B8\u30E7\u30F3\u307E\u305F\u306F\u4E0D\u6B63\u306A.jpackage.xml\u3067\u751F\u6210\u3055\u308C\u307E\u3057\u305F

Same as "de" translation.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_zh_CN.properties line 82:

> 80: 
> 81: error.foreign-app-image=\u9519\u8BEF\uFF1Aapp-image \u76EE\u5F55 ({0}) \u4E2D\u7F3A\u5C11 .jpackage.xml \u6587\u4EF6
> 82: error.invalid-app-image=\u9519\u8BEF\uFF1A\u53E6\u4E00\u4E2A jpackage \u7248\u672C\u6216\u683C\u5F0F\u9519\u8BEF\u7684 .jpackage.xml \u751F\u6210\u4E86 app-image \u76EE\u5F55 ({0})

Same as "de" translation.

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_de.wxl line 2:

> 1: <?xml version = '1.0' encoding = 'utf-8'?>
> 2: <WixLocalization Culture="de" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="1252">

Why "de-de" was changed to "de"?

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_ja.wxl line 2:

> 1: <?xml version = '1.0' encoding = 'utf-8'?>
> 2: <WixLocalization Culture="ja" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="932">

Why "ja-jp" to "ja"?

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties line 37:

> 35: resource.post-app-image-script=Auszuf\u00FChrendes Skript nach dem Auff\u00FCllen des Anwendungsimages
> 36: resource.post-msi-script=Auszuf\u00FChrendes Skript nach dem Erstellen der MSI-Datei f\u00FCr das EXE-Installationsprogramm
> 37: resource.wxl-file-name=MsiInstallerStrings_en.wxl

Why this was changed?

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties line 37:

> 35: resource.post-app-image-script=\u30A2\u30D7\u30EA\u30B1\u30FC\u30B7\u30E7\u30F3\u30FB\u30A4\u30E1\u30FC\u30B8\u3092\u79FB\u5165\u3057\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8
> 36: resource.post-msi-script=exe\u30A4\u30F3\u30B9\u30C8\u30FC\u30E9\u306Emsi\u30D5\u30A1\u30A4\u30EB\u304C\u4F5C\u6210\u3055\u308C\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8
> 37: resource.wxl-file-name=MsiInstallerStrings_en.wxl

Why this was changed?

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_zh_CN.properties line 37:

> 35: resource.post-app-image-script=\u8981\u5728\u586B\u5145\u5E94\u7528\u7A0B\u5E8F\u6620\u50CF\u4E4B\u540E\u8FD0\u884C\u7684\u811A\u672C
> 36: resource.post-msi-script=\u5728\u4E3A exe \u5B89\u88C5\u7A0B\u5E8F\u521B\u5EFA msi \u6587\u4EF6\u4E4B\u540E\u8981\u8FD0\u884C\u7684\u811A\u672C
> 37: resource.wxl-file-name=MsiInstallerStrings_en.wxl

Same as above.

-------------

PR: https://git.openjdk.org/jdk20/pull/35

From almatvee at openjdk.org  Thu Dec 15 23:17:15 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 15 Dec 2022 23:17:15 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
Message-ID: <yAXqJCyxsT6KgDaEqjCnsudaB4zIy8gvPnrQkUkNPCw=.d87796f7-1c29-41b4-9b16-86920924ebed@github.com>

On Thu, 15 Dec 2022 23:01:35 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert double quote as well

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_ja.wxl line 15:

> 13:   <String Id="ShortcutPromptDlgStartMenuShortcutControlLabel">????????????????????</String>
> 14:   <String Id="InstallDirNotEmptyDlg_Title">[ProductName]??????</String>
> 15:   <String Id="ContextMenuCommandLabel">Open with [ProductName]</String>

Why it was removed in all translations, except English?

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties line 51:

> 49: error.msi-product-version-minor-out-of-range=Nebenversion muss im Bereich [0, 255] liegen
> 50: error.version-swap=Versionsinformationen f\u00FCr {0} konnten nicht aktualisiert werden
> 51: error.icon-swap=Failed to update icon for {0}

Why this was removed?

-------------

PR: https://git.openjdk.org/jdk20/pull/35

From lichtenberger.johannes at gmail.com  Thu Dec 15 23:18:21 2022
From: lichtenberger.johannes at gmail.com (Johannes Lichtenberger)
Date: Fri, 16 Dec 2022 00:18:21 +0100
Subject: JEP-198 - Lets start talking about JSON
In-Reply-To: <CAK6PxWPA9hVqsczSrPFr6cdWgedhfamVJL0OE8fqZd7uA6j9qA@mail.gmail.com>
References: <CA+NR86hGVP2F948jFH3qo7fDQsc-W6HP-1YK6LVSCJTL5yQ+mA@mail.gmail.com>
 <CAK6PxWPA9hVqsczSrPFr6cdWgedhfamVJL0OE8fqZd7uA6j9qA@mail.gmail.com>
Message-ID: <CAGXNUvbsRiVYEZPVy9RG7gYJm+wy0wPL3Y=6_6qqPJ6ya9SMoQ@mail.gmail.com>

I'll have to read the whole thing, but are pure JSON parsers really the
go-to for most people? I'm a big advocate of providing also something
similar to XPath/XQuery and that's IMHO JSONiq (90% XQuery). I might be
biased, of course, as I'm working on Brackit[1] in my spare time (which is
also a query compiler and intended to be used with proven optimizations by
document stores / JSON stores), but also can be used as an in-memory query
engine.

kind regards
Johannes

[1] https://github.com/sirixdb/brackit

Am Do., 15. Dez. 2022 um 23:03 Uhr schrieb Reinier Zwitserloot <
reinier at zwitserloot.com>:

> A recent Advent-of-Code puzzle also made me double check the support of
> JSON in the java core libs and it is indeed a curious situation that the
> java core libs don?t cater to it particularly well.
>
> However, I?m not seeing an easy way forward to try to close this hole in
> the core library offerings.
>
> If you need to stream huge swaths of JSON, generally there?s a clear unit
> size that you can just databind. Something like:
>
> String jsonStr = """ { "version": 5, "data": [
>   -- 1 million relatively small records in this list --
>   ] } """;
>
>
> The usual swath of JSON parsers tend to support this (giving you a stream
> of java instances created by databinding those small records one by one),
> or if not, the best move forward is presumably to file a pull request with
> those projects; the java.util.log experiment shows that trying to
> ?core-librarize? needs that the community at large already fulfills with
> third party deps isn?t a good move, especially if the core library variant
> tries to oversimplify to avoid the trap of being too opinionated (which
> core libs shouldn?t be). In other words, the need for ?stream this JSON for
> me? style APIs is even more exotic that Ethan is suggesting.
>
> I see a fundamental problem here:
>
>
>    - The 95%+ use case for working with JSON for your average java coder
>    is best done with data binding.
>    - core libs doesn?t want to provide it, partly because it?s got a
>    large design space, partly because the field?s already covered by GSON and
>    Jackson-json; java.util.log proves this doesn?t work. At least, I gather
>    that?s what Ethan thinks and I agree with this assessment.
>    - A language that claims to be ?batteries included? that doesn?t ship
>    with a JSON parser in this era is dubious, to say the least.
>
>
> I?m not sure how to square this circle. Hence it feels like core-libs
> needs to hold some more fundamental debates first:
>
>
>    - Maybe it?s time to state in a more or less official decree that
>    well-established, large design space jobs will remain the purview of
>    dependencies no matter how popular it has, unless being part of the
>    core-libs adds something more fundamental the third party deps cannot bring
>    to the table (such as language integration), or the community standardizes
>    on a single library (JSR310?s story, more or less). JSON parsing would
>    qualify as ?well-established? (GSON and Jackson) and ?large design space?
>    as Ethan pointed out.
>    - Given that 99% of java projects, even really simple ones, start with
>    maven/gradle and a list of deps, is that really a problem?
>
>
> I?m honestly not sure what the right answer is. On one hand, the npm
> ecosystem seems to be doing very well even though their ?batteries
> included? situation is an utter shambles. Then again, the notion that your
> average nodejs project includes 10x+ more dependencies than other languages
> is likely a significant part of the security clown fiesta going on over
> there as far as 3rd party deps is concerned, so by no means should java
> just blindly emulate their solutions.
>
> I don?t like the idea of shipping a non-data-binding JSON API in the core
> libs. The root issue with JSON is that you just can?t tell how to interpret
> any given JSON token, because that?s not how JSON is used in practice. What
> does 5 mean? Could be that I?m to take that as an int, or as a double, or
> perhaps even as a j.t.Instant (epoch-millis), and defaulting behaviour
> (similar to j.u.Map?s .getOrDefault is *very* convenient to parse most
> JSON out there in the real world - omitting k/v pairs whose value is still
> on default is very common). That?s what makes those databind libraries so
> enticing: Instead of trying to pattern match my way into this behaviour:
>
>
>    - If the element isn?t there at all or null, give me a list-of-longs
>    with a single 0 in it.
>    - If the element is a number, make me a list-of-longs with 1 value in
>    it, that is that number, as long.
>    - If the element is a string, parse it into a long, then get me a list
>    with this one long value (because IEEE double rules mean sometimes you have
>    to put these things in string form or they get mangled by javascript-
>    eval style parsers).
>
>
> And yet the above is quite common, and can easily be done by a databinder,
> which sees you want a List<Long> for a field whose default value is
> List.of(1L), and, armed with that knowledge, can transit the JSON into
> java in that way.
>
> You don?t *need* databinding to cater to this idea: You could for example
> have a jsonNode.asLong(123) method that would parse a string if need be,
> even. But this has nothing to do with pattern matching either.
>
>  --Reinier Zwitserloot
>
>
> On 15 Dec 2022 at 21:30:17, Ethan McCue <ethan at mccue.dev> wrote:
>
>> I'm writing this to drive some forward motion and to nerd-snipe those who
>> know better than I do into putting their thoughts into words.
>>
>> There are three ways to process JSON[1]
>> - Streaming (Push or Pull)
>> - Traversing a Tree (Realized or Lazy)
>> - Declarative Databind (N ways)
>>
>> Of these, JEP-198 explicitly ruled out providing "JAXB style type safe
>> data binding."
>>
>> No justification is given, but if I had to insert my own: mapping the
>> Json model to/from the Java/JVM object model is a cursed combo of
>> - Huge possible design space
>> - Unpalatably large surface for backwards compatibility
>> - Serialization! Boo![2]
>>
>> So for an artifact like the JDK, it probably doesn't make sense to
>> include. That tracks.
>> It won't make everyone happy, people like databind APIs, but it tracks.
>>
>> So for the "read flow" these are the things to figure out.
>>
>>                 | Should Provide? | Intended User(s) |
>> ----------------+-----------------+------------------+
>>  Streaming Push |                 |                  |
>> ----------------+-----------------+------------------+
>>  Streaming Pull |                 |                  |
>> ----------------+-----------------+------------------+
>>  Realized Tree  |                 |                  |
>> ----------------+-----------------+------------------+
>>  Lazy Tree      |                 |                  |
>> ----------------+-----------------+------------------+
>>
>> At which point, we should talk about what "meets needs of Java developers
>> using JSON" implies.
>>
>> JSON is ubiquitous. Most kinds of software us schmucks write could have a
>> reason to interact with it.
>> The full set of "user personas" therefore aren't practical for me to talk
>> about.[3]
>>
>> JSON documents, however, are not so varied.
>>
>> - There are small ones (1-10kb)
>> - There are medium ones (10-1000kb)
>> - There are big ones (1000kb-???)
>>
>> - There are shallow ones
>> - There are deep ones
>>
>> So that feels like an easier direction to talk about it from.
>>
>>
>> This repo[4] has some convenient toy examples of how some of those APIs
>> look in libraries
>> in the ecosystem. Specifically the Streaming Pull and Realized Tree
>> models.
>>
>>         User r = new User();
>>         while (true) {
>>             JsonToken token = reader.peek();
>>             switch (token) {
>>                 case BEGIN_OBJECT:
>>                     reader.beginObject();
>>                     break;
>>                 case END_OBJECT:
>>                     reader.endObject();
>>                     return r;
>>                 case NAME:
>>                     String fieldname = reader.nextName();
>>                     switch (fieldname) {
>>                         case "id":
>>                             r.setId(reader.nextString());
>>                             break;
>>                         case "index":
>>                             r.setIndex(reader.nextInt());
>>                             break;
>>                         ...
>>                         case "friends":
>>                             r.setFriends(new ArrayList<>());
>>                             Friend f = null;
>>                             carryOn = true;
>>                             while (carryOn) {
>>                                 token = reader.peek();
>>                                 switch (token) {
>>                                     case BEGIN_ARRAY:
>>                                         reader.beginArray();
>>                                         break;
>>                                     case END_ARRAY:
>>                                         reader.endArray();
>>                                         carryOn = false;
>>                                         break;
>>                                     case BEGIN_OBJECT:
>>                                         reader.beginObject();
>>                                         f = new Friend();
>>                                         break;
>>                                     case END_OBJECT:
>>                                         reader.endObject();
>>                                         r.getFriends().add(f);
>>                                         break;
>>                                     case NAME:
>>                                         String fn = reader.nextName();
>>                                         switch (fn) {
>>                                             case "id":
>>
>> f.setId(reader.nextString());
>>                                                 break;
>>                                             case "name":
>>
>> f.setName(reader.nextString());
>>                                                 break;
>>                                         }
>>                                         break;
>>                                 }
>>                             }
>>                             break;
>>                     }
>>             }
>>
>> I think its not hard to argue that the streaming apis are brutalist. The
>> above is Gson, but Jackson, moshi, etc
>> seem at least morally equivalent.
>>
>> Its hard to write, hard to write *correctly*, and theres is a curious
>> protensity towards pairing it
>> with anemic, mutable models.
>>
>> That being said, it handles big documents and deep documents really well.
>> It also performs
>> pretty darn well and is good enough as a "fallback" when the intended
>> user experience
>> is through something like databind.
>>
>> So what could we do meaningfully better with the language we have
>> today/will have tommorow?
>>
>> - Sealed interfaces + Pattern matching could give a nicer model for tokens
>>
>>         sealed interface JsonToken {
>>             record Field(String name) implements JsonToken {}
>>             record BeginArray() implements JsonToken {}
>>             record EndArray() implements JsonToken {}
>>             record BeginObject() implements JsonToken {}
>>             record EndObject() implements JsonToken {}
>>             // ...
>>         }
>>
>>         // ...
>>
>>         User r = new User();
>>         while (true) {
>>             JsonToken token = reader.peek();
>>             switch (token) {
>>                 case BeginObject __:
>>                     reader.beginObject();
>>                     break;
>>                 case EndObject __:
>>                     reader.endObject();
>>                     return r;
>>                 case Field("id"):
>>                     r.setId(reader.nextString());
>>                     break;
>>                 case Field("index"):
>>                     r.setIndex(reader.nextInt());
>>                     break;
>>
>>                 // ...
>>
>>                 case Field("friends"):
>>                     r.setFriends(new ArrayList<>());
>>                     Friend f = null;
>>                     carryOn = true;
>>                     while (carryOn) {
>>                         token = reader.peek();
>>                         switch (token) {
>>                 // ...
>>
>> - Value classes can make it all more efficient
>>
>>         sealed interface JsonToken {
>>             value record Field(String name) implements JsonToken {}
>>             value record BeginArray() implements JsonToken {}
>>             value record EndArray() implements JsonToken {}
>>             value record BeginObject() implements JsonToken {}
>>             value record EndObject() implements JsonToken {}
>>             // ...
>>         }
>>
>> - (Fun One) We can transform a simpler-to-write push parser into a pull
>> parser with Coroutines
>>
>>     This is just a toy we could play with while making something in the
>> JDK. I'm pretty sure
>>     we could make a parser which feeds into something like
>>
>>         interface Listener {
>>             void onObjectStart();
>>             void onObjectEnd();
>>             void onArrayStart();
>>             void onArrayEnd();
>>             void onField(String name);
>>             // ...
>>         }
>>
>>     and invert a loop like
>>
>>         while (true) {
>>             char c = next();
>>             switch (c) {
>>                 case '{':
>>                     listener.onObjectStart();
>>                     // ...
>>                 // ...
>>             }
>>         }
>>
>>     by putting a Coroutine.yield in the callback.
>>
>>     That might be a meaningful simplification in code structure, I don't
>> know enough to say.
>>
>> But, I think there are some hard questions like
>>
>> - Is the intent[5] to be make backing parser for ecosystem databind apis?
>> - Is the intent that users who want to handle big/deep documents fall
>> back to this?
>> - Are those new language features / conveniences enough to offset the
>> cost of committing to a new api?
>> - To whom exactly does a low level api provide value?
>> - What benefit is standardization in the JDK?
>>
>> and just generally - who would be the consumer(s) of this?
>>
>> The other kind of API still on the table is a Tree. There are two ways to
>> handle this
>>
>> 1. Load it into `Object`. Use a bunch of instanceof checks/casts to
>> confirm what it actually is.
>>
>>         Object v;
>>         User u = new User();
>>
>>         if ((v = jso.get("id")) != null) {
>>             u.setId((String) v);
>>         }
>>         if ((v = jso.get("index")) != null) {
>>             u.setIndex(((Long) v).intValue());
>>         }
>>         if ((v = jso.get("guid")) != null) {
>>             u.setGuid((String) v);
>>         }
>>         if ((v = jso.get("isActive")) != null) {
>>             u.setIsActive(((Boolean) v));
>>         }
>>         if ((v = jso.get("balance")) != null) {
>>             u.setBalance((String) v);
>>         }
>>         // ...
>>         if ((v = jso.get("latitude")) != null) {
>>             u.setLatitude(v instanceof BigDecimal ? ((BigDecimal)
>> v).doubleValue() : (Double) v);
>>         }
>>         if ((v = jso.get("longitude")) != null) {
>>             u.setLongitude(v instanceof BigDecimal ? ((BigDecimal)
>> v).doubleValue() : (Double) v);
>>         }
>>         if ((v = jso.get("greeting")) != null) {
>>             u.setGreeting((String) v);
>>         }
>>         if ((v = jso.get("favoriteFruit")) != null) {
>>             u.setFavoriteFruit((String) v);
>>         }
>>         if ((v = jso.get("tags")) != null) {
>>             List<Object> jsonarr = (List<Object>) v;
>>             u.setTags(new ArrayList<>());
>>             for (Object vi : jsonarr) {
>>                 u.getTags().add((String) vi);
>>             }
>>         }
>>         if ((v = jso.get("friends")) != null) {
>>             List<Object> jsonarr = (List<Object>) v;
>>             u.setFriends(new ArrayList<>());
>>             for (Object vi : jsonarr) {
>>                 Map<String, Object> jso0 = (Map<String, Object>) vi;
>>                 Friend f = new Friend();
>>                 f.setId((String) jso0.get("id"));
>>                 f.setName((String) jso0.get("name"));
>>                 u.getFriends().add(f);
>>             }
>>         }
>>
>> 2. Have an explicit model for Json, and helper methods that do said
>> casts[6]
>>
>>
>> this.setSiteSetting(readFromJson(jsonObject.getJsonObject("site")));
>> JsonArray groups = jsonObject.getJsonArray("group");
>> if(groups != null)
>> {
>> int len = groups.size();
>> for(int i=0; i<len; i++)
>> {
>> JsonObject grp = groups.getJsonObject(i);
>> SNMPSetting grpSetting = readFromJson(grp);
>> String grpName = grp.getString("dbgroup", null);
>> if(grpName != null && grpSetting != null)
>> this.groupSettings.put(grpName, grpSetting);
>> }
>> }
>> JsonArray hosts = jsonObject.getJsonArray("host");
>> if(hosts != null)
>> {
>> int len = hosts.size();
>> for(int i=0; i<len; i++)
>> {
>> JsonObject host = hosts.getJsonObject(i);
>> SNMPSetting hostSetting = readFromJson(host);
>> String hostName = host.getString("dbhost", null);
>> if(hostName != null && hostSetting != null)
>> this.hostSettings.put(hostName, hostSetting);
>> }
>> }
>>
>> I think what has become easier to represent in the language nowadays is
>> that explicit model for Json.
>> Its the 101 lesson of sealed interfaces.[7] It feels nice and clean.
>>
>>         sealed interface Json {
>>             final class Null implements Json {}
>>             final class True implements Json {}
>>             final class False implements Json {}
>>             final class Array implements Json {}
>>             final class Object implements Json {}
>>             final class String implements Json {}
>>             final class Number implements Json {}
>>         }
>>
>> And the cast-and-check approach is now more viable on account of pattern
>> matching.
>>
>>         if (jso.get("id") instanceof String v) {
>>             u.setId(v);
>>         }
>>         if (jso.get("index") instanceof Long v) {
>>             u.setIndex(v.intValue());
>>         }
>>         if (jso.get("guid") instanceof String v) {
>>             u.setGuid(v);
>>         }
>>
>>         // or
>>
>>         if (jso.get("id") instanceof String id &&
>>                 jso.get("index") instanceof Long index &&
>>                 jso.get("guid") instanceof String guid) {
>>             return new User(id, index, guid, ...); // look ma, no setters!
>>         }
>>
>>
>> And on the horizon, again, is value types.
>>
>> But there are problems with this approach beyond the performance
>> implications of loading into
>> a tree.
>>
>> For one, all the code samples above have different behaviors around null
>> keys and missing keys
>> that are not obvious from first glance.
>>
>> This won't accept any null or missing fields
>>
>>         if (jso.get("id") instanceof String id &&
>>                 jso.get("index") instanceof Long index &&
>>                 jso.get("guid") instanceof String guid) {
>>             return new User(id, index, guid, ...);
>>         }
>>
>> This will accept individual null or missing fields, but also will
>> silently ignore
>> fields with incorrect types
>>
>>         if (jso.get("id") instanceof String v) {
>>             u.setId(v);
>>         }
>>         if (jso.get("index") instanceof Long v) {
>>             u.setIndex(v.intValue());
>>         }
>>         if (jso.get("guid") instanceof String v) {
>>             u.setGuid(v);
>>         }
>>
>> And, compared to databind where there is information about the expected
>> structure of the document
>> and its the job of the framework to assert that, I posit that the errors
>> that would be encountered
>> when writing code against this would be more like
>>
>>     "something wrong with user"
>>
>> than
>>
>>     "problem at users[5].name, expected string or null. got 5"
>>
>> Which feels unideal.
>>
>>
>> One approach I find promising is something close to what Elm does with
>> its decoders[8]. Not just combining assertion
>> and binding like what pattern matching with records allows, but including
>> a scheme for bubbling/nesting errors.
>>
>>     static String string(Json json) throws JsonDecodingException {
>>         if (!(json instanceof Json.String jsonString)) {
>>             throw JsonDecodingException.of(
>>                     "expected a string",
>>                     json
>>             );
>>         } else {
>>             return jsonString.value();
>>         }
>>     }
>>
>>     static <T> T field(Json json, String fieldName, Decoder<? extends T>
>> valueDecoder) throws JsonDecodingException {
>>         var jsonObject = object(json);
>>         var value = jsonObject.get(fieldName);
>>         if (value == null) {
>>             throw JsonDecodingException.atField(
>>                     fieldName,
>>                     JsonDecodingException.of(
>>                             "no value for field",
>>                             json
>>                     )
>>             );
>>         }
>>         else {
>>             try {
>>                 return valueDecoder.decode(value);
>>             } catch (JsonDecodingException e) {
>>                 throw JsonDecodingException.atField(
>>                         fieldName,
>>                         e
>>                 );
>>             }  catch (Exception e) {
>>                 throw JsonDecodingException.atField(fieldName,
>> JsonDecodingException.of(e, value));
>>             }
>>         }
>>     }
>>
>> Which I think has some benefits over the ways I've seen of working with
>> trees.
>>
>>
>>
>> - It is declarative enough that folks who prefer databind might be happy
>> enough.
>>
>>         static User fromJson(Json json) {
>>             return new User(
>>                 Decoder.field(json, "id", Decoder::string),
>>                 Decoder.field(json, "index", Decoder::long_),
>>                 Decoder.field(json, "guid", Decoder::string),
>>             );
>>         }
>>
>>         / ...
>>
>>         List<User> users = Decoders.array(json, User::fromJson);
>>
>> - Handling null and optional fields could be less easily conflated
>>
>>     Decoder.field(json, "id", Decoder::string);
>>
>>     Decoder.nullableField(json, "id", Decoder::string);
>>
>>     Decoder.optionalField(json, "id", Decoder::string);
>>
>>     Decoder.optionalNullableField(json, "id", Decoder::string);
>>
>>
>> - It composes well with user defined classes
>>
>>     record Guid(String value) {
>>         Guid {
>>             // some assertions on the structure of value
>>         }
>>     }
>>
>>     Decoder.string(json, "guid", guid -> new Guid(Decoder.string(guid)));
>>
>>     // or even
>>
>>     record Guid(String value) {
>>         Guid {
>>             // some assertions on the structure of value
>>         }
>>
>>         static Guid fromJson(Json json) {
>>             return new Guid(Decoder.string(guid));
>>         }
>>     }
>>
>>     Decoder.string(json, "guid", Guid::fromJson);
>>
>>
>> - When something goes wrong, the API can handle the fiddlyness of
>> capturing information for feedback.
>>
>>     In the code I've sketched out its just what field/index things went
>> wrong at. Potentially
>>     capturing metadata like row/col numbers of the source would be
>> sensible too.
>>
>>     Its just not reasonable to expect devs to do extra work to get that
>> and its really nice to give it.
>>
>> There are also some downsides like
>>
>> -  I do not know how compatible it would be with lazy trees.
>>
>>      Lazy trees being the only way that a tree api could handle big or
>> deep documents.
>>      The general concept as applied in libraries like json-tree[9] is to
>> navigate without
>>      doing any work, and that clashes with wanting to instanceof check
>> the info at the
>>      current path.
>>
>> - It *almost* gives enough information to be a general schema approach
>>
>>     If one field fails, that in the model throws an exception
>> immediately. If an API should
>>     return "errors": [...], that is inconvenient to construct.
>>
>> - None of the existing popular libraries are doing this
>>
>>      The only mechanics that are strictly required to give this sort of
>> API is lambdas. Those have
>>      been out for a decade. Yes sealed interfaces make the data model
>> prettier but in concept you
>>      can build the same thing on top of anything.
>>
>>      I could argue that this is because of "cultural momentum" of
>> databind or some other reason,
>>      but the fact remains that it isn't a proven out approach.
>>
>>      Writing Json libraries is a todo list[10]. There are a lot of bad
>> ideas and this might be one of the,
>>
>> - Performance impact of so many instanceof checks
>>
>>     I've gotten a 4.2% slowdown compared to the "regular" tree code
>> without the repeated casts.
>>
>>     But that was with a parser that is 5x slower than Jacksons. (using
>> the same benchmark project as for the snippets).
>>     I think there could be reason to believe that the JIT does well
>> enough with repeated instanceof
>>     checks to consider it.
>>
>>
>> My current thinking is that - despite not solving for large or deep
>> documents - starting with a really "dumb" realized tree api
>> might be the right place to start for the read side of a potential
>> incubator module.
>>
>> But regardless - this feels like a good time to start more concrete
>> conversations. I fell I should cap this email since I've reached the point
>> of decoherence and haven't even mentioned the write side of things
>>
>>
>>
>>
>> [1]: http://www.cowtowncoder.com/blog/archives/2009/01/entry_131.html
>> [2]: https://security.snyk.io/vuln/maven?search=jackson-databind
>> [3]: I only know like 8 people
>> [4]:
>> https://github.com/fabienrenaud/java-json-benchmark/blob/master/src/main/java/com/github/fabienrenaud/jjb/stream/UsersStreamDeserializer.java
>> [5]: When I say "intent", I do so knowing full well no one has been
>> actively thinking of this for an entire Game of Thrones
>> [6]:
>> https://github.com/yahoo/mysql_perf_analyzer/blob/master/myperf/src/main/java/com/yahoo/dba/perf/myperf/common/SNMPSettings.java
>> [7]: https://www.infoq.com/articles/data-oriented-programming-java/
>> [8]: https://package.elm-lang.org/packages/elm/json/latest/Json-Decode
>> [9]: https://github.com/jbee/json-tree
>> [10]: https://stackoverflow.com/a/14442630/2948173
>> [11]: In 30 days JEP-198 it will be recognizably PI days old for the 2nd
>> time in its history.
>> [12]: To me, the fact that is still an open JEP is more a social
>> convenience than anything. I could just as easily writing this exact same
>> email about TOML.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221216/ba48583c/attachment-0001.htm>

From ethan at mccue.dev  Thu Dec 15 23:26:43 2022
From: ethan at mccue.dev (Ethan McCue)
Date: Thu, 15 Dec 2022 18:26:43 -0500
Subject: JEP-198 - Lets start talking about JSON
In-Reply-To: <CAGXNUvbsRiVYEZPVy9RG7gYJm+wy0wPL3Y=6_6qqPJ6ya9SMoQ@mail.gmail.com>
References: <CA+NR86hGVP2F948jFH3qo7fDQsc-W6HP-1YK6LVSCJTL5yQ+mA@mail.gmail.com>
 <CAK6PxWPA9hVqsczSrPFr6cdWgedhfamVJL0OE8fqZd7uA6j9qA@mail.gmail.com>
 <CAGXNUvbsRiVYEZPVy9RG7gYJm+wy0wPL3Y=6_6qqPJ6ya9SMoQ@mail.gmail.com>
Message-ID: <CA+NR86ixwVNMsJPkK8LUMavPy7Wxaa=EGCrJvxaqqf7r8sG3eg@mail.gmail.com>

> The 95%+ use case for working with JSON for your average java coder is
best done with data binding.

To be brave yet controversial: I'm not sure this is neccesarily true.

I will elaborate and respond to the other points after a hot cocoa, but the
last point is part of why I think that tree-crawling needs _something_
better as an API to fit the bill.

With my sketch that set of requirements would be represented as

    record Thing(
        List<Long> xs
    ) {
        static Thing fromJson(Json json)
            var defaultList = List.of(0L);
            return new Thing(Decoder.optionalNullableField(
                json
                "xs",
                Decoder.oneOf(
                    Decoder.array(Decoder.oneOf(
                        x -> Long.parseLong(Decoder.string(x)),
                        Decoder::long
                    ))
                    Decoder.null_(defaultList),
                    x -> List.of(Decoder.long_(x))
                ),
                defaultList
            ));
        )
    }

Which isn't amazing at first glance, but also

   {}
   {"xs": null}
   {"xs": 5}
   {"xs": [5]}   {"xs": ["5"]}
   {"xs": [1, "2", "3"]}

these are some wildly varied structures. You could make a solid argument
that something which silently treats these all the same is
a bad API for all the reasons you would consider it a good one.

On Thu, Dec 15, 2022 at 6:18 PM Johannes Lichtenberger <
lichtenberger.johannes at gmail.com> wrote:

> I'll have to read the whole thing, but are pure JSON parsers really the
> go-to for most people? I'm a big advocate of providing also something
> similar to XPath/XQuery and that's IMHO JSONiq (90% XQuery). I might be
> biased, of course, as I'm working on Brackit[1] in my spare time (which is
> also a query compiler and intended to be used with proven optimizations by
> document stores / JSON stores), but also can be used as an in-memory query
> engine.
>
> kind regards
> Johannes
>
> [1] https://github.com/sirixdb/brackit
>
> Am Do., 15. Dez. 2022 um 23:03 Uhr schrieb Reinier Zwitserloot <
> reinier at zwitserloot.com>:
>
>> A recent Advent-of-Code puzzle also made me double check the support of
>> JSON in the java core libs and it is indeed a curious situation that the
>> java core libs don?t cater to it particularly well.
>>
>> However, I?m not seeing an easy way forward to try to close this hole in
>> the core library offerings.
>>
>> If you need to stream huge swaths of JSON, generally there?s a clear unit
>> size that you can just databind. Something like:
>>
>> String jsonStr = """ { "version": 5, "data": [
>>   -- 1 million relatively small records in this list --
>>   ] } """;
>>
>>
>> The usual swath of JSON parsers tend to support this (giving you a stream
>> of java instances created by databinding those small records one by one),
>> or if not, the best move forward is presumably to file a pull request with
>> those projects; the java.util.log experiment shows that trying to
>> ?core-librarize? needs that the community at large already fulfills with
>> third party deps isn?t a good move, especially if the core library variant
>> tries to oversimplify to avoid the trap of being too opinionated (which
>> core libs shouldn?t be). In other words, the need for ?stream this JSON for
>> me? style APIs is even more exotic that Ethan is suggesting.
>>
>> I see a fundamental problem here:
>>
>>
>>    - The 95%+ use case for working with JSON for your average java coder
>>    is best done with data binding.
>>    - core libs doesn?t want to provide it, partly because it?s got a
>>    large design space, partly because the field?s already covered by GSON and
>>    Jackson-json; java.util.log proves this doesn?t work. At least, I gather
>>    that?s what Ethan thinks and I agree with this assessment.
>>    - A language that claims to be ?batteries included? that doesn?t ship
>>    with a JSON parser in this era is dubious, to say the least.
>>
>>
>> I?m not sure how to square this circle. Hence it feels like core-libs
>> needs to hold some more fundamental debates first:
>>
>>
>>    - Maybe it?s time to state in a more or less official decree that
>>    well-established, large design space jobs will remain the purview of
>>    dependencies no matter how popular it has, unless being part of the
>>    core-libs adds something more fundamental the third party deps cannot bring
>>    to the table (such as language integration), or the community standardizes
>>    on a single library (JSR310?s story, more or less). JSON parsing would
>>    qualify as ?well-established? (GSON and Jackson) and ?large design space?
>>    as Ethan pointed out.
>>    - Given that 99% of java projects, even really simple ones, start
>>    with maven/gradle and a list of deps, is that really a problem?
>>
>>
>> I?m honestly not sure what the right answer is. On one hand, the npm
>> ecosystem seems to be doing very well even though their ?batteries
>> included? situation is an utter shambles. Then again, the notion that your
>> average nodejs project includes 10x+ more dependencies than other languages
>> is likely a significant part of the security clown fiesta going on over
>> there as far as 3rd party deps is concerned, so by no means should java
>> just blindly emulate their solutions.
>>
>> I don?t like the idea of shipping a non-data-binding JSON API in the core
>> libs. The root issue with JSON is that you just can?t tell how to interpret
>> any given JSON token, because that?s not how JSON is used in practice. What
>> does 5 mean? Could be that I?m to take that as an int, or as a double,
>> or perhaps even as a j.t.Instant (epoch-millis), and defaulting
>> behaviour (similar to j.u.Map?s .getOrDefault is *very* convenient to
>> parse most JSON out there in the real world - omitting k/v pairs whose
>> value is still on default is very common). That?s what makes those databind
>> libraries so enticing: Instead of trying to pattern match my way into this
>> behaviour:
>>
>>
>>    - If the element isn?t there at all or null, give me a list-of-longs
>>    with a single 0 in it.
>>    - If the element is a number, make me a list-of-longs with 1 value in
>>    it, that is that number, as long.
>>    - If the element is a string, parse it into a long, then get me a
>>    list with this one long value (because IEEE double rules mean sometimes you
>>    have to put these things in string form or they get mangled by javascript-
>>    eval style parsers).
>>
>>
>> And yet the above is quite common, and can easily be done by a
>> databinder, which sees you want a List<Long> for a field whose default
>> value is List.of(1L), and, armed with that knowledge, can transit the
>> JSON into java in that way.
>>
>> You don?t *need* databinding to cater to this idea: You could for
>> example have a jsonNode.asLong(123) method that would parse a string if
>> need be, even. But this has nothing to do with pattern matching either.
>>
>>  --Reinier Zwitserloot
>>
>>
>> On 15 Dec 2022 at 21:30:17, Ethan McCue <ethan at mccue.dev> wrote:
>>
>>> I'm writing this to drive some forward motion and to nerd-snipe those
>>> who know better than I do into putting their thoughts into words.
>>>
>>> There are three ways to process JSON[1]
>>> - Streaming (Push or Pull)
>>> - Traversing a Tree (Realized or Lazy)
>>> - Declarative Databind (N ways)
>>>
>>> Of these, JEP-198 explicitly ruled out providing "JAXB style type safe
>>> data binding."
>>>
>>> No justification is given, but if I had to insert my own: mapping the
>>> Json model to/from the Java/JVM object model is a cursed combo of
>>> - Huge possible design space
>>> - Unpalatably large surface for backwards compatibility
>>> - Serialization! Boo![2]
>>>
>>> So for an artifact like the JDK, it probably doesn't make sense to
>>> include. That tracks.
>>> It won't make everyone happy, people like databind APIs, but it tracks.
>>>
>>> So for the "read flow" these are the things to figure out.
>>>
>>>                 | Should Provide? | Intended User(s) |
>>> ----------------+-----------------+------------------+
>>>  Streaming Push |                 |                  |
>>> ----------------+-----------------+------------------+
>>>  Streaming Pull |                 |                  |
>>> ----------------+-----------------+------------------+
>>>  Realized Tree  |                 |                  |
>>> ----------------+-----------------+------------------+
>>>  Lazy Tree      |                 |                  |
>>> ----------------+-----------------+------------------+
>>>
>>> At which point, we should talk about what "meets needs of Java
>>> developers using JSON" implies.
>>>
>>> JSON is ubiquitous. Most kinds of software us schmucks write could have
>>> a reason to interact with it.
>>> The full set of "user personas" therefore aren't practical for me to
>>> talk about.[3]
>>>
>>> JSON documents, however, are not so varied.
>>>
>>> - There are small ones (1-10kb)
>>> - There are medium ones (10-1000kb)
>>> - There are big ones (1000kb-???)
>>>
>>> - There are shallow ones
>>> - There are deep ones
>>>
>>> So that feels like an easier direction to talk about it from.
>>>
>>>
>>> This repo[4] has some convenient toy examples of how some of those APIs
>>> look in libraries
>>> in the ecosystem. Specifically the Streaming Pull and Realized Tree
>>> models.
>>>
>>>         User r = new User();
>>>         while (true) {
>>>             JsonToken token = reader.peek();
>>>             switch (token) {
>>>                 case BEGIN_OBJECT:
>>>                     reader.beginObject();
>>>                     break;
>>>                 case END_OBJECT:
>>>                     reader.endObject();
>>>                     return r;
>>>                 case NAME:
>>>                     String fieldname = reader.nextName();
>>>                     switch (fieldname) {
>>>                         case "id":
>>>                             r.setId(reader.nextString());
>>>                             break;
>>>                         case "index":
>>>                             r.setIndex(reader.nextInt());
>>>                             break;
>>>                         ...
>>>                         case "friends":
>>>                             r.setFriends(new ArrayList<>());
>>>                             Friend f = null;
>>>                             carryOn = true;
>>>                             while (carryOn) {
>>>                                 token = reader.peek();
>>>                                 switch (token) {
>>>                                     case BEGIN_ARRAY:
>>>                                         reader.beginArray();
>>>                                         break;
>>>                                     case END_ARRAY:
>>>                                         reader.endArray();
>>>                                         carryOn = false;
>>>                                         break;
>>>                                     case BEGIN_OBJECT:
>>>                                         reader.beginObject();
>>>                                         f = new Friend();
>>>                                         break;
>>>                                     case END_OBJECT:
>>>                                         reader.endObject();
>>>                                         r.getFriends().add(f);
>>>                                         break;
>>>                                     case NAME:
>>>                                         String fn = reader.nextName();
>>>                                         switch (fn) {
>>>                                             case "id":
>>>
>>> f.setId(reader.nextString());
>>>                                                 break;
>>>                                             case "name":
>>>
>>> f.setName(reader.nextString());
>>>                                                 break;
>>>                                         }
>>>                                         break;
>>>                                 }
>>>                             }
>>>                             break;
>>>                     }
>>>             }
>>>
>>> I think its not hard to argue that the streaming apis are brutalist. The
>>> above is Gson, but Jackson, moshi, etc
>>> seem at least morally equivalent.
>>>
>>> Its hard to write, hard to write *correctly*, and theres is a curious
>>> protensity towards pairing it
>>> with anemic, mutable models.
>>>
>>> That being said, it handles big documents and deep documents really
>>> well. It also performs
>>> pretty darn well and is good enough as a "fallback" when the intended
>>> user experience
>>> is through something like databind.
>>>
>>> So what could we do meaningfully better with the language we have
>>> today/will have tommorow?
>>>
>>> - Sealed interfaces + Pattern matching could give a nicer model for
>>> tokens
>>>
>>>         sealed interface JsonToken {
>>>             record Field(String name) implements JsonToken {}
>>>             record BeginArray() implements JsonToken {}
>>>             record EndArray() implements JsonToken {}
>>>             record BeginObject() implements JsonToken {}
>>>             record EndObject() implements JsonToken {}
>>>             // ...
>>>         }
>>>
>>>         // ...
>>>
>>>         User r = new User();
>>>         while (true) {
>>>             JsonToken token = reader.peek();
>>>             switch (token) {
>>>                 case BeginObject __:
>>>                     reader.beginObject();
>>>                     break;
>>>                 case EndObject __:
>>>                     reader.endObject();
>>>                     return r;
>>>                 case Field("id"):
>>>                     r.setId(reader.nextString());
>>>                     break;
>>>                 case Field("index"):
>>>                     r.setIndex(reader.nextInt());
>>>                     break;
>>>
>>>                 // ...
>>>
>>>                 case Field("friends"):
>>>                     r.setFriends(new ArrayList<>());
>>>                     Friend f = null;
>>>                     carryOn = true;
>>>                     while (carryOn) {
>>>                         token = reader.peek();
>>>                         switch (token) {
>>>                 // ...
>>>
>>> - Value classes can make it all more efficient
>>>
>>>         sealed interface JsonToken {
>>>             value record Field(String name) implements JsonToken {}
>>>             value record BeginArray() implements JsonToken {}
>>>             value record EndArray() implements JsonToken {}
>>>             value record BeginObject() implements JsonToken {}
>>>             value record EndObject() implements JsonToken {}
>>>             // ...
>>>         }
>>>
>>> - (Fun One) We can transform a simpler-to-write push parser into a pull
>>> parser with Coroutines
>>>
>>>     This is just a toy we could play with while making something in the
>>> JDK. I'm pretty sure
>>>     we could make a parser which feeds into something like
>>>
>>>         interface Listener {
>>>             void onObjectStart();
>>>             void onObjectEnd();
>>>             void onArrayStart();
>>>             void onArrayEnd();
>>>             void onField(String name);
>>>             // ...
>>>         }
>>>
>>>     and invert a loop like
>>>
>>>         while (true) {
>>>             char c = next();
>>>             switch (c) {
>>>                 case '{':
>>>                     listener.onObjectStart();
>>>                     // ...
>>>                 // ...
>>>             }
>>>         }
>>>
>>>     by putting a Coroutine.yield in the callback.
>>>
>>>     That might be a meaningful simplification in code structure, I don't
>>> know enough to say.
>>>
>>> But, I think there are some hard questions like
>>>
>>> - Is the intent[5] to be make backing parser for ecosystem databind apis?
>>> - Is the intent that users who want to handle big/deep documents fall
>>> back to this?
>>> - Are those new language features / conveniences enough to offset the
>>> cost of committing to a new api?
>>> - To whom exactly does a low level api provide value?
>>> - What benefit is standardization in the JDK?
>>>
>>> and just generally - who would be the consumer(s) of this?
>>>
>>> The other kind of API still on the table is a Tree. There are two ways
>>> to handle this
>>>
>>> 1. Load it into `Object`. Use a bunch of instanceof checks/casts to
>>> confirm what it actually is.
>>>
>>>         Object v;
>>>         User u = new User();
>>>
>>>         if ((v = jso.get("id")) != null) {
>>>             u.setId((String) v);
>>>         }
>>>         if ((v = jso.get("index")) != null) {
>>>             u.setIndex(((Long) v).intValue());
>>>         }
>>>         if ((v = jso.get("guid")) != null) {
>>>             u.setGuid((String) v);
>>>         }
>>>         if ((v = jso.get("isActive")) != null) {
>>>             u.setIsActive(((Boolean) v));
>>>         }
>>>         if ((v = jso.get("balance")) != null) {
>>>             u.setBalance((String) v);
>>>         }
>>>         // ...
>>>         if ((v = jso.get("latitude")) != null) {
>>>             u.setLatitude(v instanceof BigDecimal ? ((BigDecimal)
>>> v).doubleValue() : (Double) v);
>>>         }
>>>         if ((v = jso.get("longitude")) != null) {
>>>             u.setLongitude(v instanceof BigDecimal ? ((BigDecimal)
>>> v).doubleValue() : (Double) v);
>>>         }
>>>         if ((v = jso.get("greeting")) != null) {
>>>             u.setGreeting((String) v);
>>>         }
>>>         if ((v = jso.get("favoriteFruit")) != null) {
>>>             u.setFavoriteFruit((String) v);
>>>         }
>>>         if ((v = jso.get("tags")) != null) {
>>>             List<Object> jsonarr = (List<Object>) v;
>>>             u.setTags(new ArrayList<>());
>>>             for (Object vi : jsonarr) {
>>>                 u.getTags().add((String) vi);
>>>             }
>>>         }
>>>         if ((v = jso.get("friends")) != null) {
>>>             List<Object> jsonarr = (List<Object>) v;
>>>             u.setFriends(new ArrayList<>());
>>>             for (Object vi : jsonarr) {
>>>                 Map<String, Object> jso0 = (Map<String, Object>) vi;
>>>                 Friend f = new Friend();
>>>                 f.setId((String) jso0.get("id"));
>>>                 f.setName((String) jso0.get("name"));
>>>                 u.getFriends().add(f);
>>>             }
>>>         }
>>>
>>> 2. Have an explicit model for Json, and helper methods that do said
>>> casts[6]
>>>
>>>
>>> this.setSiteSetting(readFromJson(jsonObject.getJsonObject("site")));
>>> JsonArray groups = jsonObject.getJsonArray("group");
>>> if(groups != null)
>>> {
>>> int len = groups.size();
>>> for(int i=0; i<len; i++)
>>> {
>>> JsonObject grp = groups.getJsonObject(i);
>>> SNMPSetting grpSetting = readFromJson(grp);
>>> String grpName = grp.getString("dbgroup", null);
>>> if(grpName != null && grpSetting != null)
>>> this.groupSettings.put(grpName, grpSetting);
>>> }
>>> }
>>> JsonArray hosts = jsonObject.getJsonArray("host");
>>> if(hosts != null)
>>> {
>>> int len = hosts.size();
>>> for(int i=0; i<len; i++)
>>> {
>>> JsonObject host = hosts.getJsonObject(i);
>>> SNMPSetting hostSetting = readFromJson(host);
>>> String hostName = host.getString("dbhost", null);
>>> if(hostName != null && hostSetting != null)
>>> this.hostSettings.put(hostName, hostSetting);
>>> }
>>> }
>>>
>>> I think what has become easier to represent in the language nowadays is
>>> that explicit model for Json.
>>> Its the 101 lesson of sealed interfaces.[7] It feels nice and clean.
>>>
>>>         sealed interface Json {
>>>             final class Null implements Json {}
>>>             final class True implements Json {}
>>>             final class False implements Json {}
>>>             final class Array implements Json {}
>>>             final class Object implements Json {}
>>>             final class String implements Json {}
>>>             final class Number implements Json {}
>>>         }
>>>
>>> And the cast-and-check approach is now more viable on account of pattern
>>> matching.
>>>
>>>         if (jso.get("id") instanceof String v) {
>>>             u.setId(v);
>>>         }
>>>         if (jso.get("index") instanceof Long v) {
>>>             u.setIndex(v.intValue());
>>>         }
>>>         if (jso.get("guid") instanceof String v) {
>>>             u.setGuid(v);
>>>         }
>>>
>>>         // or
>>>
>>>         if (jso.get("id") instanceof String id &&
>>>                 jso.get("index") instanceof Long index &&
>>>                 jso.get("guid") instanceof String guid) {
>>>             return new User(id, index, guid, ...); // look ma, no
>>> setters!
>>>         }
>>>
>>>
>>> And on the horizon, again, is value types.
>>>
>>> But there are problems with this approach beyond the performance
>>> implications of loading into
>>> a tree.
>>>
>>> For one, all the code samples above have different behaviors around null
>>> keys and missing keys
>>> that are not obvious from first glance.
>>>
>>> This won't accept any null or missing fields
>>>
>>>         if (jso.get("id") instanceof String id &&
>>>                 jso.get("index") instanceof Long index &&
>>>                 jso.get("guid") instanceof String guid) {
>>>             return new User(id, index, guid, ...);
>>>         }
>>>
>>> This will accept individual null or missing fields, but also will
>>> silently ignore
>>> fields with incorrect types
>>>
>>>         if (jso.get("id") instanceof String v) {
>>>             u.setId(v);
>>>         }
>>>         if (jso.get("index") instanceof Long v) {
>>>             u.setIndex(v.intValue());
>>>         }
>>>         if (jso.get("guid") instanceof String v) {
>>>             u.setGuid(v);
>>>         }
>>>
>>> And, compared to databind where there is information about the expected
>>> structure of the document
>>> and its the job of the framework to assert that, I posit that the errors
>>> that would be encountered
>>> when writing code against this would be more like
>>>
>>>     "something wrong with user"
>>>
>>> than
>>>
>>>     "problem at users[5].name, expected string or null. got 5"
>>>
>>> Which feels unideal.
>>>
>>>
>>> One approach I find promising is something close to what Elm does with
>>> its decoders[8]. Not just combining assertion
>>> and binding like what pattern matching with records allows, but
>>> including a scheme for bubbling/nesting errors.
>>>
>>>     static String string(Json json) throws JsonDecodingException {
>>>         if (!(json instanceof Json.String jsonString)) {
>>>             throw JsonDecodingException.of(
>>>                     "expected a string",
>>>                     json
>>>             );
>>>         } else {
>>>             return jsonString.value();
>>>         }
>>>     }
>>>
>>>     static <T> T field(Json json, String fieldName, Decoder<? extends T>
>>> valueDecoder) throws JsonDecodingException {
>>>         var jsonObject = object(json);
>>>         var value = jsonObject.get(fieldName);
>>>         if (value == null) {
>>>             throw JsonDecodingException.atField(
>>>                     fieldName,
>>>                     JsonDecodingException.of(
>>>                             "no value for field",
>>>                             json
>>>                     )
>>>             );
>>>         }
>>>         else {
>>>             try {
>>>                 return valueDecoder.decode(value);
>>>             } catch (JsonDecodingException e) {
>>>                 throw JsonDecodingException.atField(
>>>                         fieldName,
>>>                         e
>>>                 );
>>>             }  catch (Exception e) {
>>>                 throw JsonDecodingException.atField(fieldName,
>>> JsonDecodingException.of(e, value));
>>>             }
>>>         }
>>>     }
>>>
>>> Which I think has some benefits over the ways I've seen of working with
>>> trees.
>>>
>>>
>>>
>>> - It is declarative enough that folks who prefer databind might be happy
>>> enough.
>>>
>>>         static User fromJson(Json json) {
>>>             return new User(
>>>                 Decoder.field(json, "id", Decoder::string),
>>>                 Decoder.field(json, "index", Decoder::long_),
>>>                 Decoder.field(json, "guid", Decoder::string),
>>>             );
>>>         }
>>>
>>>         / ...
>>>
>>>         List<User> users = Decoders.array(json, User::fromJson);
>>>
>>> - Handling null and optional fields could be less easily conflated
>>>
>>>     Decoder.field(json, "id", Decoder::string);
>>>
>>>     Decoder.nullableField(json, "id", Decoder::string);
>>>
>>>     Decoder.optionalField(json, "id", Decoder::string);
>>>
>>>     Decoder.optionalNullableField(json, "id", Decoder::string);
>>>
>>>
>>> - It composes well with user defined classes
>>>
>>>     record Guid(String value) {
>>>         Guid {
>>>             // some assertions on the structure of value
>>>         }
>>>     }
>>>
>>>     Decoder.string(json, "guid", guid -> new Guid(Decoder.string(guid)));
>>>
>>>     // or even
>>>
>>>     record Guid(String value) {
>>>         Guid {
>>>             // some assertions on the structure of value
>>>         }
>>>
>>>         static Guid fromJson(Json json) {
>>>             return new Guid(Decoder.string(guid));
>>>         }
>>>     }
>>>
>>>     Decoder.string(json, "guid", Guid::fromJson);
>>>
>>>
>>> - When something goes wrong, the API can handle the fiddlyness of
>>> capturing information for feedback.
>>>
>>>     In the code I've sketched out its just what field/index things went
>>> wrong at. Potentially
>>>     capturing metadata like row/col numbers of the source would be
>>> sensible too.
>>>
>>>     Its just not reasonable to expect devs to do extra work to get that
>>> and its really nice to give it.
>>>
>>> There are also some downsides like
>>>
>>> -  I do not know how compatible it would be with lazy trees.
>>>
>>>      Lazy trees being the only way that a tree api could handle big or
>>> deep documents.
>>>      The general concept as applied in libraries like json-tree[9] is to
>>> navigate without
>>>      doing any work, and that clashes with wanting to instanceof check
>>> the info at the
>>>      current path.
>>>
>>> - It *almost* gives enough information to be a general schema approach
>>>
>>>     If one field fails, that in the model throws an exception
>>> immediately. If an API should
>>>     return "errors": [...], that is inconvenient to construct.
>>>
>>> - None of the existing popular libraries are doing this
>>>
>>>      The only mechanics that are strictly required to give this sort of
>>> API is lambdas. Those have
>>>      been out for a decade. Yes sealed interfaces make the data model
>>> prettier but in concept you
>>>      can build the same thing on top of anything.
>>>
>>>      I could argue that this is because of "cultural momentum" of
>>> databind or some other reason,
>>>      but the fact remains that it isn't a proven out approach.
>>>
>>>      Writing Json libraries is a todo list[10]. There are a lot of bad
>>> ideas and this might be one of the,
>>>
>>> - Performance impact of so many instanceof checks
>>>
>>>     I've gotten a 4.2% slowdown compared to the "regular" tree code
>>> without the repeated casts.
>>>
>>>     But that was with a parser that is 5x slower than Jacksons. (using
>>> the same benchmark project as for the snippets).
>>>     I think there could be reason to believe that the JIT does well
>>> enough with repeated instanceof
>>>     checks to consider it.
>>>
>>>
>>> My current thinking is that - despite not solving for large or deep
>>> documents - starting with a really "dumb" realized tree api
>>> might be the right place to start for the read side of a potential
>>> incubator module.
>>>
>>> But regardless - this feels like a good time to start more concrete
>>> conversations. I fell I should cap this email since I've reached the point
>>> of decoherence and haven't even mentioned the write side of things
>>>
>>>
>>>
>>>
>>> [1]: http://www.cowtowncoder.com/blog/archives/2009/01/entry_131.html
>>> [2]: https://security.snyk.io/vuln/maven?search=jackson-databind
>>> [3]: I only know like 8 people
>>> [4]:
>>> https://github.com/fabienrenaud/java-json-benchmark/blob/master/src/main/java/com/github/fabienrenaud/jjb/stream/UsersStreamDeserializer.java
>>> [5]: When I say "intent", I do so knowing full well no one has been
>>> actively thinking of this for an entire Game of Thrones
>>> [6]:
>>> https://github.com/yahoo/mysql_perf_analyzer/blob/master/myperf/src/main/java/com/yahoo/dba/perf/myperf/common/SNMPSettings.java
>>> [7]: https://www.infoq.com/articles/data-oriented-programming-java/
>>> [8]: https://package.elm-lang.org/packages/elm/json/latest/Json-Decode
>>> [9]: https://github.com/jbee/json-tree
>>> [10]: https://stackoverflow.com/a/14442630/2948173
>>> [11]: In 30 days JEP-198 it will be recognizably PI days old for the 2nd
>>> time in its history.
>>> [12]: To me, the fact that is still an open JEP is more a social
>>> convenience than anything. I could just as easily writing this exact same
>>> email about TOML.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221215/27aa276a/attachment-0001.htm>

From weijun at openjdk.org  Thu Dec 15 23:34:10 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 15 Dec 2022 23:34:10 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
Message-ID: <apmyl72NuiCfwAbiJ757W8j59iQar67gH1cIVV757n8=.eeda79d2-99d1-4380-ae15-6d69e8446743@github.com>

On Thu, 15 Dec 2022 23:01:35 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert double quote as well

src/java.base/share/classes/sun/security/tools/keytool/Resources_zh_CN.java line 75:

> 73:                 "\u5DF2\u751F\u6210 {0} \u4F4D{1}\u5BC6\u94A5"}, //-genseckey
> 74:         {"key.algorithm.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u7B97\u6CD5\u88AB\u89C6\u4E3A\u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"},
> 75:         {"key.size.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"},

The exact same "is considered a security risk" is sometimes translated into "?????????" and sometimes "??????". Either is OK for me but please be consistent. This is also shown in 5 other places in the same file.

-------------

PR: https://git.openjdk.org/jdk20/pull/35

From ethan at mccue.dev  Thu Dec 15 23:34:08 2022
From: ethan at mccue.dev (Ethan McCue)
Date: Thu, 15 Dec 2022 18:34:08 -0500
Subject: JEP-198 - Lets start talking about JSON
In-Reply-To: <CA+NR86ixwVNMsJPkK8LUMavPy7Wxaa=EGCrJvxaqqf7r8sG3eg@mail.gmail.com>
References: <CA+NR86hGVP2F948jFH3qo7fDQsc-W6HP-1YK6LVSCJTL5yQ+mA@mail.gmail.com>
 <CAK6PxWPA9hVqsczSrPFr6cdWgedhfamVJL0OE8fqZd7uA6j9qA@mail.gmail.com>
 <CAGXNUvbsRiVYEZPVy9RG7gYJm+wy0wPL3Y=6_6qqPJ6ya9SMoQ@mail.gmail.com>
 <CA+NR86ixwVNMsJPkK8LUMavPy7Wxaa=EGCrJvxaqqf7r8sG3eg@mail.gmail.com>
Message-ID: <CA+NR86gtkdF6D2mCu+jzgwopsrO5kjiBereRZUBScM4bctZwrg@mail.gmail.com>

> are pure JSON parsers really the go-to for most people?

Depends on what you mean by JSON parsers and it depends on what you mean by
people.

To the best of my knowledge, both python and Javascript do not include
streaming, databinding, or path navigation capabilities in their json
parsers.


On Thu, Dec 15, 2022 at 6:26 PM Ethan McCue <ethan at mccue.dev> wrote:

> > The 95%+ use case for working with JSON for your average java coder is
> best done with data binding.
>
> To be brave yet controversial: I'm not sure this is neccesarily true.
>
> I will elaborate and respond to the other points after a hot cocoa, but
> the last point is part of why I think that tree-crawling needs _something_
> better as an API to fit the bill.
>
> With my sketch that set of requirements would be represented as
>
>     record Thing(
>         List<Long> xs
>     ) {
>         static Thing fromJson(Json json)
>             var defaultList = List.of(0L);
>             return new Thing(Decoder.optionalNullableField(
>                 json
>                 "xs",
>                 Decoder.oneOf(
>                     Decoder.array(Decoder.oneOf(
>                         x -> Long.parseLong(Decoder.string(x)),
>                         Decoder::long
>                     ))
>                     Decoder.null_(defaultList),
>                     x -> List.of(Decoder.long_(x))
>                 ),
>                 defaultList
>             ));
>         )
>     }
>
> Which isn't amazing at first glance, but also
>
>    {}
>    {"xs": null}
>    {"xs": 5}
>    {"xs": [5]}   {"xs": ["5"]}
>    {"xs": [1, "2", "3"]}
>
> these are some wildly varied structures. You could make a solid argument
> that something which silently treats these all the same is
> a bad API for all the reasons you would consider it a good one.
>
> On Thu, Dec 15, 2022 at 6:18 PM Johannes Lichtenberger <
> lichtenberger.johannes at gmail.com> wrote:
>
>> I'll have to read the whole thing, but are pure JSON parsers really the
>> go-to for most people? I'm a big advocate of providing also something
>> similar to XPath/XQuery and that's IMHO JSONiq (90% XQuery). I might be
>> biased, of course, as I'm working on Brackit[1] in my spare time (which is
>> also a query compiler and intended to be used with proven optimizations by
>> document stores / JSON stores), but also can be used as an in-memory query
>> engine.
>>
>> kind regards
>> Johannes
>>
>> [1] https://github.com/sirixdb/brackit
>>
>> Am Do., 15. Dez. 2022 um 23:03 Uhr schrieb Reinier Zwitserloot <
>> reinier at zwitserloot.com>:
>>
>>> A recent Advent-of-Code puzzle also made me double check the support of
>>> JSON in the java core libs and it is indeed a curious situation that the
>>> java core libs don?t cater to it particularly well.
>>>
>>> However, I?m not seeing an easy way forward to try to close this hole in
>>> the core library offerings.
>>>
>>> If you need to stream huge swaths of JSON, generally there?s a clear
>>> unit size that you can just databind. Something like:
>>>
>>> String jsonStr = """ { "version": 5, "data": [
>>>   -- 1 million relatively small records in this list --
>>>   ] } """;
>>>
>>>
>>> The usual swath of JSON parsers tend to support this (giving you a
>>> stream of java instances created by databinding those small records one by
>>> one), or if not, the best move forward is presumably to file a pull request
>>> with those projects; the java.util.log experiment shows that trying to
>>> ?core-librarize? needs that the community at large already fulfills with
>>> third party deps isn?t a good move, especially if the core library variant
>>> tries to oversimplify to avoid the trap of being too opinionated (which
>>> core libs shouldn?t be). In other words, the need for ?stream this JSON for
>>> me? style APIs is even more exotic that Ethan is suggesting.
>>>
>>> I see a fundamental problem here:
>>>
>>>
>>>    - The 95%+ use case for working with JSON for your average java
>>>    coder is best done with data binding.
>>>    - core libs doesn?t want to provide it, partly because it?s got a
>>>    large design space, partly because the field?s already covered by GSON and
>>>    Jackson-json; java.util.log proves this doesn?t work. At least, I gather
>>>    that?s what Ethan thinks and I agree with this assessment.
>>>    - A language that claims to be ?batteries included? that doesn?t
>>>    ship with a JSON parser in this era is dubious, to say the least.
>>>
>>>
>>> I?m not sure how to square this circle. Hence it feels like core-libs
>>> needs to hold some more fundamental debates first:
>>>
>>>
>>>    - Maybe it?s time to state in a more or less official decree that
>>>    well-established, large design space jobs will remain the purview of
>>>    dependencies no matter how popular it has, unless being part of the
>>>    core-libs adds something more fundamental the third party deps cannot bring
>>>    to the table (such as language integration), or the community standardizes
>>>    on a single library (JSR310?s story, more or less). JSON parsing would
>>>    qualify as ?well-established? (GSON and Jackson) and ?large design space?
>>>    as Ethan pointed out.
>>>    - Given that 99% of java projects, even really simple ones, start
>>>    with maven/gradle and a list of deps, is that really a problem?
>>>
>>>
>>> I?m honestly not sure what the right answer is. On one hand, the npm
>>> ecosystem seems to be doing very well even though their ?batteries
>>> included? situation is an utter shambles. Then again, the notion that your
>>> average nodejs project includes 10x+ more dependencies than other languages
>>> is likely a significant part of the security clown fiesta going on over
>>> there as far as 3rd party deps is concerned, so by no means should java
>>> just blindly emulate their solutions.
>>>
>>> I don?t like the idea of shipping a non-data-binding JSON API in the
>>> core libs. The root issue with JSON is that you just can?t tell how to
>>> interpret any given JSON token, because that?s not how JSON is used in
>>> practice. What does 5 mean? Could be that I?m to take that as an int,
>>> or as a double, or perhaps even as a j.t.Instant (epoch-millis), and
>>> defaulting behaviour (similar to j.u.Map?s .getOrDefault is *very*
>>> convenient to parse most JSON out there in the real world - omitting k/v
>>> pairs whose value is still on default is very common). That?s what makes
>>> those databind libraries so enticing: Instead of trying to pattern match my
>>> way into this behaviour:
>>>
>>>
>>>    - If the element isn?t there at all or null, give me a list-of-longs
>>>    with a single 0 in it.
>>>    - If the element is a number, make me a list-of-longs with 1 value
>>>    in it, that is that number, as long.
>>>    - If the element is a string, parse it into a long, then get me a
>>>    list with this one long value (because IEEE double rules mean sometimes you
>>>    have to put these things in string form or they get mangled by javascript-
>>>    eval style parsers).
>>>
>>>
>>> And yet the above is quite common, and can easily be done by a
>>> databinder, which sees you want a List<Long> for a field whose default
>>> value is List.of(1L), and, armed with that knowledge, can transit the
>>> JSON into java in that way.
>>>
>>> You don?t *need* databinding to cater to this idea: You could for
>>> example have a jsonNode.asLong(123) method that would parse a string if
>>> need be, even. But this has nothing to do with pattern matching either.
>>>
>>>  --Reinier Zwitserloot
>>>
>>>
>>> On 15 Dec 2022 at 21:30:17, Ethan McCue <ethan at mccue.dev> wrote:
>>>
>>>> I'm writing this to drive some forward motion and to nerd-snipe those
>>>> who know better than I do into putting their thoughts into words.
>>>>
>>>> There are three ways to process JSON[1]
>>>> - Streaming (Push or Pull)
>>>> - Traversing a Tree (Realized or Lazy)
>>>> - Declarative Databind (N ways)
>>>>
>>>> Of these, JEP-198 explicitly ruled out providing "JAXB style type safe
>>>> data binding."
>>>>
>>>> No justification is given, but if I had to insert my own: mapping the
>>>> Json model to/from the Java/JVM object model is a cursed combo of
>>>> - Huge possible design space
>>>> - Unpalatably large surface for backwards compatibility
>>>> - Serialization! Boo![2]
>>>>
>>>> So for an artifact like the JDK, it probably doesn't make sense to
>>>> include. That tracks.
>>>> It won't make everyone happy, people like databind APIs, but it tracks.
>>>>
>>>> So for the "read flow" these are the things to figure out.
>>>>
>>>>                 | Should Provide? | Intended User(s) |
>>>> ----------------+-----------------+------------------+
>>>>  Streaming Push |                 |                  |
>>>> ----------------+-----------------+------------------+
>>>>  Streaming Pull |                 |                  |
>>>> ----------------+-----------------+------------------+
>>>>  Realized Tree  |                 |                  |
>>>> ----------------+-----------------+------------------+
>>>>  Lazy Tree      |                 |                  |
>>>> ----------------+-----------------+------------------+
>>>>
>>>> At which point, we should talk about what "meets needs of Java
>>>> developers using JSON" implies.
>>>>
>>>> JSON is ubiquitous. Most kinds of software us schmucks write could have
>>>> a reason to interact with it.
>>>> The full set of "user personas" therefore aren't practical for me to
>>>> talk about.[3]
>>>>
>>>> JSON documents, however, are not so varied.
>>>>
>>>> - There are small ones (1-10kb)
>>>> - There are medium ones (10-1000kb)
>>>> - There are big ones (1000kb-???)
>>>>
>>>> - There are shallow ones
>>>> - There are deep ones
>>>>
>>>> So that feels like an easier direction to talk about it from.
>>>>
>>>>
>>>> This repo[4] has some convenient toy examples of how some of those APIs
>>>> look in libraries
>>>> in the ecosystem. Specifically the Streaming Pull and Realized Tree
>>>> models.
>>>>
>>>>         User r = new User();
>>>>         while (true) {
>>>>             JsonToken token = reader.peek();
>>>>             switch (token) {
>>>>                 case BEGIN_OBJECT:
>>>>                     reader.beginObject();
>>>>                     break;
>>>>                 case END_OBJECT:
>>>>                     reader.endObject();
>>>>                     return r;
>>>>                 case NAME:
>>>>                     String fieldname = reader.nextName();
>>>>                     switch (fieldname) {
>>>>                         case "id":
>>>>                             r.setId(reader.nextString());
>>>>                             break;
>>>>                         case "index":
>>>>                             r.setIndex(reader.nextInt());
>>>>                             break;
>>>>                         ...
>>>>                         case "friends":
>>>>                             r.setFriends(new ArrayList<>());
>>>>                             Friend f = null;
>>>>                             carryOn = true;
>>>>                             while (carryOn) {
>>>>                                 token = reader.peek();
>>>>                                 switch (token) {
>>>>                                     case BEGIN_ARRAY:
>>>>                                         reader.beginArray();
>>>>                                         break;
>>>>                                     case END_ARRAY:
>>>>                                         reader.endArray();
>>>>                                         carryOn = false;
>>>>                                         break;
>>>>                                     case BEGIN_OBJECT:
>>>>                                         reader.beginObject();
>>>>                                         f = new Friend();
>>>>                                         break;
>>>>                                     case END_OBJECT:
>>>>                                         reader.endObject();
>>>>                                         r.getFriends().add(f);
>>>>                                         break;
>>>>                                     case NAME:
>>>>                                         String fn = reader.nextName();
>>>>                                         switch (fn) {
>>>>                                             case "id":
>>>>
>>>> f.setId(reader.nextString());
>>>>                                                 break;
>>>>                                             case "name":
>>>>
>>>> f.setName(reader.nextString());
>>>>                                                 break;
>>>>                                         }
>>>>                                         break;
>>>>                                 }
>>>>                             }
>>>>                             break;
>>>>                     }
>>>>             }
>>>>
>>>> I think its not hard to argue that the streaming apis are brutalist.
>>>> The above is Gson, but Jackson, moshi, etc
>>>> seem at least morally equivalent.
>>>>
>>>> Its hard to write, hard to write *correctly*, and theres is a curious
>>>> protensity towards pairing it
>>>> with anemic, mutable models.
>>>>
>>>> That being said, it handles big documents and deep documents really
>>>> well. It also performs
>>>> pretty darn well and is good enough as a "fallback" when the intended
>>>> user experience
>>>> is through something like databind.
>>>>
>>>> So what could we do meaningfully better with the language we have
>>>> today/will have tommorow?
>>>>
>>>> - Sealed interfaces + Pattern matching could give a nicer model for
>>>> tokens
>>>>
>>>>         sealed interface JsonToken {
>>>>             record Field(String name) implements JsonToken {}
>>>>             record BeginArray() implements JsonToken {}
>>>>             record EndArray() implements JsonToken {}
>>>>             record BeginObject() implements JsonToken {}
>>>>             record EndObject() implements JsonToken {}
>>>>             // ...
>>>>         }
>>>>
>>>>         // ...
>>>>
>>>>         User r = new User();
>>>>         while (true) {
>>>>             JsonToken token = reader.peek();
>>>>             switch (token) {
>>>>                 case BeginObject __:
>>>>                     reader.beginObject();
>>>>                     break;
>>>>                 case EndObject __:
>>>>                     reader.endObject();
>>>>                     return r;
>>>>                 case Field("id"):
>>>>                     r.setId(reader.nextString());
>>>>                     break;
>>>>                 case Field("index"):
>>>>                     r.setIndex(reader.nextInt());
>>>>                     break;
>>>>
>>>>                 // ...
>>>>
>>>>                 case Field("friends"):
>>>>                     r.setFriends(new ArrayList<>());
>>>>                     Friend f = null;
>>>>                     carryOn = true;
>>>>                     while (carryOn) {
>>>>                         token = reader.peek();
>>>>                         switch (token) {
>>>>                 // ...
>>>>
>>>> - Value classes can make it all more efficient
>>>>
>>>>         sealed interface JsonToken {
>>>>             value record Field(String name) implements JsonToken {}
>>>>             value record BeginArray() implements JsonToken {}
>>>>             value record EndArray() implements JsonToken {}
>>>>             value record BeginObject() implements JsonToken {}
>>>>             value record EndObject() implements JsonToken {}
>>>>             // ...
>>>>         }
>>>>
>>>> - (Fun One) We can transform a simpler-to-write push parser into a pull
>>>> parser with Coroutines
>>>>
>>>>     This is just a toy we could play with while making something in the
>>>> JDK. I'm pretty sure
>>>>     we could make a parser which feeds into something like
>>>>
>>>>         interface Listener {
>>>>             void onObjectStart();
>>>>             void onObjectEnd();
>>>>             void onArrayStart();
>>>>             void onArrayEnd();
>>>>             void onField(String name);
>>>>             // ...
>>>>         }
>>>>
>>>>     and invert a loop like
>>>>
>>>>         while (true) {
>>>>             char c = next();
>>>>             switch (c) {
>>>>                 case '{':
>>>>                     listener.onObjectStart();
>>>>                     // ...
>>>>                 // ...
>>>>             }
>>>>         }
>>>>
>>>>     by putting a Coroutine.yield in the callback.
>>>>
>>>>     That might be a meaningful simplification in code structure, I
>>>> don't know enough to say.
>>>>
>>>> But, I think there are some hard questions like
>>>>
>>>> - Is the intent[5] to be make backing parser for ecosystem databind
>>>> apis?
>>>> - Is the intent that users who want to handle big/deep documents fall
>>>> back to this?
>>>> - Are those new language features / conveniences enough to offset the
>>>> cost of committing to a new api?
>>>> - To whom exactly does a low level api provide value?
>>>> - What benefit is standardization in the JDK?
>>>>
>>>> and just generally - who would be the consumer(s) of this?
>>>>
>>>> The other kind of API still on the table is a Tree. There are two ways
>>>> to handle this
>>>>
>>>> 1. Load it into `Object`. Use a bunch of instanceof checks/casts to
>>>> confirm what it actually is.
>>>>
>>>>         Object v;
>>>>         User u = new User();
>>>>
>>>>         if ((v = jso.get("id")) != null) {
>>>>             u.setId((String) v);
>>>>         }
>>>>         if ((v = jso.get("index")) != null) {
>>>>             u.setIndex(((Long) v).intValue());
>>>>         }
>>>>         if ((v = jso.get("guid")) != null) {
>>>>             u.setGuid((String) v);
>>>>         }
>>>>         if ((v = jso.get("isActive")) != null) {
>>>>             u.setIsActive(((Boolean) v));
>>>>         }
>>>>         if ((v = jso.get("balance")) != null) {
>>>>             u.setBalance((String) v);
>>>>         }
>>>>         // ...
>>>>         if ((v = jso.get("latitude")) != null) {
>>>>             u.setLatitude(v instanceof BigDecimal ? ((BigDecimal)
>>>> v).doubleValue() : (Double) v);
>>>>         }
>>>>         if ((v = jso.get("longitude")) != null) {
>>>>             u.setLongitude(v instanceof BigDecimal ? ((BigDecimal)
>>>> v).doubleValue() : (Double) v);
>>>>         }
>>>>         if ((v = jso.get("greeting")) != null) {
>>>>             u.setGreeting((String) v);
>>>>         }
>>>>         if ((v = jso.get("favoriteFruit")) != null) {
>>>>             u.setFavoriteFruit((String) v);
>>>>         }
>>>>         if ((v = jso.get("tags")) != null) {
>>>>             List<Object> jsonarr = (List<Object>) v;
>>>>             u.setTags(new ArrayList<>());
>>>>             for (Object vi : jsonarr) {
>>>>                 u.getTags().add((String) vi);
>>>>             }
>>>>         }
>>>>         if ((v = jso.get("friends")) != null) {
>>>>             List<Object> jsonarr = (List<Object>) v;
>>>>             u.setFriends(new ArrayList<>());
>>>>             for (Object vi : jsonarr) {
>>>>                 Map<String, Object> jso0 = (Map<String, Object>) vi;
>>>>                 Friend f = new Friend();
>>>>                 f.setId((String) jso0.get("id"));
>>>>                 f.setName((String) jso0.get("name"));
>>>>                 u.getFriends().add(f);
>>>>             }
>>>>         }
>>>>
>>>> 2. Have an explicit model for Json, and helper methods that do said
>>>> casts[6]
>>>>
>>>>
>>>> this.setSiteSetting(readFromJson(jsonObject.getJsonObject("site")));
>>>> JsonArray groups = jsonObject.getJsonArray("group");
>>>> if(groups != null)
>>>> {
>>>> int len = groups.size();
>>>> for(int i=0; i<len; i++)
>>>> {
>>>> JsonObject grp = groups.getJsonObject(i);
>>>> SNMPSetting grpSetting = readFromJson(grp);
>>>> String grpName = grp.getString("dbgroup", null);
>>>> if(grpName != null && grpSetting != null)
>>>> this.groupSettings.put(grpName, grpSetting);
>>>> }
>>>> }
>>>> JsonArray hosts = jsonObject.getJsonArray("host");
>>>> if(hosts != null)
>>>> {
>>>> int len = hosts.size();
>>>> for(int i=0; i<len; i++)
>>>> {
>>>> JsonObject host = hosts.getJsonObject(i);
>>>> SNMPSetting hostSetting = readFromJson(host);
>>>> String hostName = host.getString("dbhost", null);
>>>> if(hostName != null && hostSetting != null)
>>>> this.hostSettings.put(hostName, hostSetting);
>>>> }
>>>> }
>>>>
>>>> I think what has become easier to represent in the language nowadays is
>>>> that explicit model for Json.
>>>> Its the 101 lesson of sealed interfaces.[7] It feels nice and clean.
>>>>
>>>>         sealed interface Json {
>>>>             final class Null implements Json {}
>>>>             final class True implements Json {}
>>>>             final class False implements Json {}
>>>>             final class Array implements Json {}
>>>>             final class Object implements Json {}
>>>>             final class String implements Json {}
>>>>             final class Number implements Json {}
>>>>         }
>>>>
>>>> And the cast-and-check approach is now more viable on account of
>>>> pattern matching.
>>>>
>>>>         if (jso.get("id") instanceof String v) {
>>>>             u.setId(v);
>>>>         }
>>>>         if (jso.get("index") instanceof Long v) {
>>>>             u.setIndex(v.intValue());
>>>>         }
>>>>         if (jso.get("guid") instanceof String v) {
>>>>             u.setGuid(v);
>>>>         }
>>>>
>>>>         // or
>>>>
>>>>         if (jso.get("id") instanceof String id &&
>>>>                 jso.get("index") instanceof Long index &&
>>>>                 jso.get("guid") instanceof String guid) {
>>>>             return new User(id, index, guid, ...); // look ma, no
>>>> setters!
>>>>         }
>>>>
>>>>
>>>> And on the horizon, again, is value types.
>>>>
>>>> But there are problems with this approach beyond the performance
>>>> implications of loading into
>>>> a tree.
>>>>
>>>> For one, all the code samples above have different behaviors around
>>>> null keys and missing keys
>>>> that are not obvious from first glance.
>>>>
>>>> This won't accept any null or missing fields
>>>>
>>>>         if (jso.get("id") instanceof String id &&
>>>>                 jso.get("index") instanceof Long index &&
>>>>                 jso.get("guid") instanceof String guid) {
>>>>             return new User(id, index, guid, ...);
>>>>         }
>>>>
>>>> This will accept individual null or missing fields, but also will
>>>> silently ignore
>>>> fields with incorrect types
>>>>
>>>>         if (jso.get("id") instanceof String v) {
>>>>             u.setId(v);
>>>>         }
>>>>         if (jso.get("index") instanceof Long v) {
>>>>             u.setIndex(v.intValue());
>>>>         }
>>>>         if (jso.get("guid") instanceof String v) {
>>>>             u.setGuid(v);
>>>>         }
>>>>
>>>> And, compared to databind where there is information about the expected
>>>> structure of the document
>>>> and its the job of the framework to assert that, I posit that the
>>>> errors that would be encountered
>>>> when writing code against this would be more like
>>>>
>>>>     "something wrong with user"
>>>>
>>>> than
>>>>
>>>>     "problem at users[5].name, expected string or null. got 5"
>>>>
>>>> Which feels unideal.
>>>>
>>>>
>>>> One approach I find promising is something close to what Elm does with
>>>> its decoders[8]. Not just combining assertion
>>>> and binding like what pattern matching with records allows, but
>>>> including a scheme for bubbling/nesting errors.
>>>>
>>>>     static String string(Json json) throws JsonDecodingException {
>>>>         if (!(json instanceof Json.String jsonString)) {
>>>>             throw JsonDecodingException.of(
>>>>                     "expected a string",
>>>>                     json
>>>>             );
>>>>         } else {
>>>>             return jsonString.value();
>>>>         }
>>>>     }
>>>>
>>>>     static <T> T field(Json json, String fieldName, Decoder<? extends
>>>> T> valueDecoder) throws JsonDecodingException {
>>>>         var jsonObject = object(json);
>>>>         var value = jsonObject.get(fieldName);
>>>>         if (value == null) {
>>>>             throw JsonDecodingException.atField(
>>>>                     fieldName,
>>>>                     JsonDecodingException.of(
>>>>                             "no value for field",
>>>>                             json
>>>>                     )
>>>>             );
>>>>         }
>>>>         else {
>>>>             try {
>>>>                 return valueDecoder.decode(value);
>>>>             } catch (JsonDecodingException e) {
>>>>                 throw JsonDecodingException.atField(
>>>>                         fieldName,
>>>>                         e
>>>>                 );
>>>>             }  catch (Exception e) {
>>>>                 throw JsonDecodingException.atField(fieldName,
>>>> JsonDecodingException.of(e, value));
>>>>             }
>>>>         }
>>>>     }
>>>>
>>>> Which I think has some benefits over the ways I've seen of working with
>>>> trees.
>>>>
>>>>
>>>>
>>>> - It is declarative enough that folks who prefer databind might be
>>>> happy enough.
>>>>
>>>>         static User fromJson(Json json) {
>>>>             return new User(
>>>>                 Decoder.field(json, "id", Decoder::string),
>>>>                 Decoder.field(json, "index", Decoder::long_),
>>>>                 Decoder.field(json, "guid", Decoder::string),
>>>>             );
>>>>         }
>>>>
>>>>         / ...
>>>>
>>>>         List<User> users = Decoders.array(json, User::fromJson);
>>>>
>>>> - Handling null and optional fields could be less easily conflated
>>>>
>>>>     Decoder.field(json, "id", Decoder::string);
>>>>
>>>>     Decoder.nullableField(json, "id", Decoder::string);
>>>>
>>>>     Decoder.optionalField(json, "id", Decoder::string);
>>>>
>>>>     Decoder.optionalNullableField(json, "id", Decoder::string);
>>>>
>>>>
>>>> - It composes well with user defined classes
>>>>
>>>>     record Guid(String value) {
>>>>         Guid {
>>>>             // some assertions on the structure of value
>>>>         }
>>>>     }
>>>>
>>>>     Decoder.string(json, "guid", guid -> new
>>>> Guid(Decoder.string(guid)));
>>>>
>>>>     // or even
>>>>
>>>>     record Guid(String value) {
>>>>         Guid {
>>>>             // some assertions on the structure of value
>>>>         }
>>>>
>>>>         static Guid fromJson(Json json) {
>>>>             return new Guid(Decoder.string(guid));
>>>>         }
>>>>     }
>>>>
>>>>     Decoder.string(json, "guid", Guid::fromJson);
>>>>
>>>>
>>>> - When something goes wrong, the API can handle the fiddlyness of
>>>> capturing information for feedback.
>>>>
>>>>     In the code I've sketched out its just what field/index things went
>>>> wrong at. Potentially
>>>>     capturing metadata like row/col numbers of the source would be
>>>> sensible too.
>>>>
>>>>     Its just not reasonable to expect devs to do extra work to get that
>>>> and its really nice to give it.
>>>>
>>>> There are also some downsides like
>>>>
>>>> -  I do not know how compatible it would be with lazy trees.
>>>>
>>>>      Lazy trees being the only way that a tree api could handle big or
>>>> deep documents.
>>>>      The general concept as applied in libraries like json-tree[9] is
>>>> to navigate without
>>>>      doing any work, and that clashes with wanting to instanceof check
>>>> the info at the
>>>>      current path.
>>>>
>>>> - It *almost* gives enough information to be a general schema approach
>>>>
>>>>     If one field fails, that in the model throws an exception
>>>> immediately. If an API should
>>>>     return "errors": [...], that is inconvenient to construct.
>>>>
>>>> - None of the existing popular libraries are doing this
>>>>
>>>>      The only mechanics that are strictly required to give this sort of
>>>> API is lambdas. Those have
>>>>      been out for a decade. Yes sealed interfaces make the data model
>>>> prettier but in concept you
>>>>      can build the same thing on top of anything.
>>>>
>>>>      I could argue that this is because of "cultural momentum" of
>>>> databind or some other reason,
>>>>      but the fact remains that it isn't a proven out approach.
>>>>
>>>>      Writing Json libraries is a todo list[10]. There are a lot of bad
>>>> ideas and this might be one of the,
>>>>
>>>> - Performance impact of so many instanceof checks
>>>>
>>>>     I've gotten a 4.2% slowdown compared to the "regular" tree code
>>>> without the repeated casts.
>>>>
>>>>     But that was with a parser that is 5x slower than Jacksons. (using
>>>> the same benchmark project as for the snippets).
>>>>     I think there could be reason to believe that the JIT does well
>>>> enough with repeated instanceof
>>>>     checks to consider it.
>>>>
>>>>
>>>> My current thinking is that - despite not solving for large or deep
>>>> documents - starting with a really "dumb" realized tree api
>>>> might be the right place to start for the read side of a potential
>>>> incubator module.
>>>>
>>>> But regardless - this feels like a good time to start more concrete
>>>> conversations. I fell I should cap this email since I've reached the point
>>>> of decoherence and haven't even mentioned the write side of things
>>>>
>>>>
>>>>
>>>>
>>>> [1]: http://www.cowtowncoder.com/blog/archives/2009/01/entry_131.html
>>>> [2]: https://security.snyk.io/vuln/maven?search=jackson-databind
>>>> [3]: I only know like 8 people
>>>> [4]:
>>>> https://github.com/fabienrenaud/java-json-benchmark/blob/master/src/main/java/com/github/fabienrenaud/jjb/stream/UsersStreamDeserializer.java
>>>> [5]: When I say "intent", I do so knowing full well no one has been
>>>> actively thinking of this for an entire Game of Thrones
>>>> [6]:
>>>> https://github.com/yahoo/mysql_perf_analyzer/blob/master/myperf/src/main/java/com/yahoo/dba/perf/myperf/common/SNMPSettings.java
>>>> [7]: https://www.infoq.com/articles/data-oriented-programming-java/
>>>> [8]: https://package.elm-lang.org/packages/elm/json/latest/Json-Decode
>>>> [9]: https://github.com/jbee/json-tree
>>>> [10]: https://stackoverflow.com/a/14442630/2948173
>>>> [11]: In 30 days JEP-198 it will be recognizably PI days old for the
>>>> 2nd time in its history.
>>>> [12]: To me, the fact that is still an open JEP is more a social
>>>> convenience than anything. I could just as easily writing this exact same
>>>> email about TOML.
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221215/5909c830/attachment-0001.htm>

From dnguyen at openjdk.org  Fri Dec 16 00:20:09 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 00:20:09 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
 <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
Message-ID: <NwruB7W8obX6XLW0oYPNwk_hsyRRDQfnjcSQ2IcG0BM=.0bda120a-ca70-470f-9ed9-bdb3f43e958a@github.com>

On Thu, 15 Dec 2022 22:57:31 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix https and changed URL back
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties line 82:
> 
>> 80: 
>> 81: error.foreign-app-image=Fehler: .jpackage.xml-Datei fehlt in app-image-Verzeichnis ({0})
>> 82: error.invalid-app-image=Fehler: app-image-Verzeichnis ({0}) wurde von einer anderen jpackage-Version generiert, oder .jpackage.xml ist nicht wohlgeformt
> 
> error.invalid-app-image looks like old translation and missing "{1}". Also, why () is used instead of ""?

I'm not sure for the decisions of change in punctuation and for the missing {1} as I didn't do the translation myself. Would this be better to be reverted?

> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_de.wxl line 2:
> 
>> 1: <?xml version = '1.0' encoding = 'utf-8'?>
>> 2: <WixLocalization Culture="de" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="1252">
> 
> Why "de-de" was changed to "de"?

Also not sure why this was changed in the translation. I'm reverting all instances of these language codes.

-------------

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 00:28:14 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 00:28:14 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
 <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
Message-ID: <OBPofdj-HAyS2LOEYb9Di6foNnPm0PQYQoQ1AsyGD6o=.daf96361-fae0-488c-b400-6edea72cf6f9@github.com>

On Thu, 15 Dec 2022 23:13:22 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix https and changed URL back
>
> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties line 37:
> 
>> 35: resource.post-app-image-script=\u30A2\u30D7\u30EA\u30B1\u30FC\u30B7\u30E7\u30F3\u30FB\u30A4\u30E1\u30FC\u30B8\u3092\u79FB\u5165\u3057\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8
>> 36: resource.post-msi-script=exe\u30A4\u30F3\u30B9\u30C8\u30FC\u30E9\u306Emsi\u30D5\u30A1\u30A4\u30EB\u304C\u4F5C\u6210\u3055\u308C\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8
>> 37: resource.wxl-file-name=MsiInstallerStrings_en.wxl
> 
> Why this was changed?

Also not sure as it is what I received from the latest translation drop. If this is incorrect, I can manually correct this here and for the other locales for this file.

-------------

PR: https://git.openjdk.org/jdk20/pull/35

From serb at openjdk.org  Fri Dec 16 00:47:09 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 16 Dec 2022 00:47:09 GMT
Subject: Integrated: 8290899: java/lang/String/StringRepeat.java test requests
 too much heap on windows x86
In-Reply-To: <rbTMWm4K6IURZtk_xvrnpwPnsUwBD4XvmQzQrOS86dQ=.6cb3dac8-815b-45ec-a6b0-8731ed18991b@github.com>
References: <rbTMWm4K6IURZtk_xvrnpwPnsUwBD4XvmQzQrOS86dQ=.6cb3dac8-815b-45ec-a6b0-8731ed18991b@github.com>
Message-ID: <KAKjRXzEpBm0gXjRNqfnyEckHc1hXY0vYyRtIN9-GR8=.a3a776a8-dd0a-46cf-94c9-94042cec29eb@github.com>

On Tue, 13 Dec 2022 00:06:00 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The `java/lang/String/StringRepeat.java` test was updated twice after integration:
> 
> https://bugs.openjdk.org/browse/JDK-8221400 - the xmx4g was replaced by the xmx2g
> https://bugs.openjdk.org/browse/JDK-8265421 - the "os.maxMemory >= 2G" was added
> 
> Unfortunately, this test still may fail on Windows x86 due to: `Could not reserve enough space for xxx object heap.`
> 
> This is a request to exclude it on win x86 since that JDK cannot allocate 2g.

This pull request has now been integrated.

Changeset: 2bb727c4
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2bb727c4eaf8a948f17f6416a1e6fbaeade4d7ce
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8290899: java/lang/String/StringRepeat.java test requests too much heap on windows x86

Reviewed-by: jpai, phh

-------------

PR: https://git.openjdk.org/jdk/pull/11639

From almatvee at openjdk.org  Fri Dec 16 00:55:07 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 16 Dec 2022 00:55:07 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <NwruB7W8obX6XLW0oYPNwk_hsyRRDQfnjcSQ2IcG0BM=.0bda120a-ca70-470f-9ed9-bdb3f43e958a@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
 <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
 <NwruB7W8obX6XLW0oYPNwk_hsyRRDQfnjcSQ2IcG0BM=.0bda120a-ca70-470f-9ed9-bdb3f43e958a@github.com>
Message-ID: <Bdj4sr53WcCg6vWDmTIfcvVoCxGjbLiCL4Hc-Ydgrvk=.ca1b89df-5ec8-447e-9f0e-7d5f3eb8fa92@github.com>

On Fri, 16 Dec 2022 00:15:51 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties line 82:
>> 
>>> 80: 
>>> 81: error.foreign-app-image=Fehler: .jpackage.xml-Datei fehlt in app-image-Verzeichnis ({0})
>>> 82: error.invalid-app-image=Fehler: app-image-Verzeichnis ({0}) wurde von einer anderen jpackage-Version generiert, oder .jpackage.xml ist nicht wohlgeformt
>> 
>> error.invalid-app-image looks like old translation and missing "{1}". Also, why () is used instead of ""?
>
> I'm not sure for the decisions of change in punctuation and for the missing {1} as I didn't do the translation myself. Would this be better to be reverted?

Looks like translation is done on files before JDK-8293462 was integrated (before Sep 26). See [commit](https://github.com/openjdk/jdk20/commit/1e222bccd3807c1be0d1d824e0ff9745751d8375#diff-8bfeb61c827c2bc073c65cbf4137dbf8f7baa5f4f88e5d59785e985d9510577c) when I changed these two strings. For now it is better to revert them to original English version or figure out why translation is old.

-------------

PR: https://git.openjdk.org/jdk20/pull/35

From almatvee at openjdk.org  Fri Dec 16 00:59:08 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 16 Dec 2022 00:59:08 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <OBPofdj-HAyS2LOEYb9Di6foNnPm0PQYQoQ1AsyGD6o=.daf96361-fae0-488c-b400-6edea72cf6f9@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
 <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
 <OBPofdj-HAyS2LOEYb9Di6foNnPm0PQYQoQ1AsyGD6o=.daf96361-fae0-488c-b400-6edea72cf6f9@github.com>
Message-ID: <ybG8PSIdt0XyYOo4JF4ozp2yRpZDnPQUpDxoDeFTiCo=.fbe7a6d5-9bc3-4097-bd02-164f015bcaf6@github.com>

On Fri, 16 Dec 2022 00:24:26 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties line 37:
>> 
>>> 35: resource.post-app-image-script=\u30A2\u30D7\u30EA\u30B1\u30FC\u30B7\u30E7\u30F3\u30FB\u30A4\u30E1\u30FC\u30B8\u3092\u79FB\u5165\u3057\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8
>>> 36: resource.post-msi-script=exe\u30A4\u30F3\u30B9\u30C8\u30FC\u30E9\u306Emsi\u30D5\u30A1\u30A4\u30EB\u304C\u4F5C\u6210\u3055\u308C\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8
>>> 37: resource.wxl-file-name=MsiInstallerStrings_en.wxl
>> 
>> Why this was changed?
>
> Also not sure as it is what I received from the latest translation drop. If this is incorrect, I can manually correct this here and for the other locales for this file.

Yes it needs to be correct. It was changed to _ja, etc with [commit](https://github.com/openjdk/jdk20/commit/543163a03b5f1af7a7e7af317a26eb8c5aa81c38#diff-afb8ea68d8b3e9be4bba1c417c82d2162eea9333a3157f05ef57c026af94eb3b). Which was done on Aug 10, 2022, so it seems message drop is based on old code.

-------------

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 01:05:08 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 01:05:08 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <Bdj4sr53WcCg6vWDmTIfcvVoCxGjbLiCL4Hc-Ydgrvk=.ca1b89df-5ec8-447e-9f0e-7d5f3eb8fa92@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
 <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
 <NwruB7W8obX6XLW0oYPNwk_hsyRRDQfnjcSQ2IcG0BM=.0bda120a-ca70-470f-9ed9-bdb3f43e958a@github.com>
 <Bdj4sr53WcCg6vWDmTIfcvVoCxGjbLiCL4Hc-Ydgrvk=.ca1b89df-5ec8-447e-9f0e-7d5f3eb8fa92@github.com>
Message-ID: <iqZK2YXVbWKWqoQkJhlwxX1sNPCdcJkRKjgWh51KiWg=.9bb3af83-561d-4711-8ec9-585adf10f676@github.com>

On Fri, 16 Dec 2022 00:51:55 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> I'm not sure for the decisions of change in punctuation and for the missing {1} as I didn't do the translation myself. Would this be better to be reverted?
>
> Looks like translation is done on files before JDK-8293462 was integrated (before Sep 26). See [commit](https://github.com/openjdk/jdk20/commit/1e222bccd3807c1be0d1d824e0ff9745751d8375#diff-8bfeb61c827c2bc073c65cbf4137dbf8f7baa5f4f88e5d59785e985d9510577c) when I changed these two strings. For now it is better to revert them to original English version or figure out why translation is old.

I'll revert it, investigate the cause for the extraction issue in this drop, and try to have it translated by the next drop then.

>> Also not sure as it is what I received from the latest translation drop. If this is incorrect, I can manually correct this here and for the other locales for this file.
>
> Yes it needs to be correct. It was changed to _ja, etc with [commit](https://github.com/openjdk/jdk20/commit/543163a03b5f1af7a7e7af317a26eb8c5aa81c38#diff-afb8ea68d8b3e9be4bba1c417c82d2162eea9333a3157f05ef57c026af94eb3b). Which was done on Aug 10, 2022, so it seems message drop is based on old code.

This drop had some issues with the extraction which will be resolved. Some of the changes are correct while some seem to be old. It seems these jpackage files were are older? I can revert these changes for jpackage then.

-------------

PR: https://git.openjdk.org/jdk20/pull/35

From joehw at openjdk.org  Fri Dec 16 01:25:18 2022
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 16 Dec 2022 01:25:18 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
Message-ID: <ienEQpq9KGQ0-B04HBvRrPpNQDISigGzx4lTtzjuDVY=.7bcc0fd3-51c9-4e51-9684-266a98e521ec@github.com>

On Thu, 15 Dec 2022 23:01:35 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert double quote as well

The changes in the java.xml area look good to me.

-------------

Marked as reviewed by joehw (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 03:38:54 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 03:38:54 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>

> Open l10n drop
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Revert old translation. Fix lang codes

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/35/files
  - new: https://git.openjdk.org/jdk20/pull/35/files/57c42206..29880af9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=03-04

  Stats: 18 lines in 9 files changed: 6 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk20/pull/35.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 03:38:56 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 03:38:56 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <iqZK2YXVbWKWqoQkJhlwxX1sNPCdcJkRKjgWh51KiWg=.9bb3af83-561d-4711-8ec9-585adf10f676@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
 <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
 <NwruB7W8obX6XLW0oYPNwk_hsyRRDQfnjcSQ2IcG0BM=.0bda120a-ca70-470f-9ed9-bdb3f43e958a@github.com>
 <Bdj4sr53WcCg6vWDmTIfcvVoCxGjbLiCL4Hc-Ydgrvk=.ca1b89df-5ec8-447e-9f0e-7d5f3eb8fa92@github.com>
 <iqZK2YXVbWKWqoQkJhlwxX1sNPCdcJkRKjgWh51KiWg=.9bb3af83-561d-4711-8ec9-585adf10f676@github.com>
Message-ID: <_Dir5hjsOpTXHLKfV6SM_6kUJfNcHSkgHjrRAHbGUfw=.db9fe398-4a22-4aab-90ef-72d67f5c708e@github.com>

On Fri, 16 Dec 2022 01:02:03 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Looks like translation is done on files before JDK-8293462 was integrated (before Sep 26). See [commit](https://github.com/openjdk/jdk20/commit/1e222bccd3807c1be0d1d824e0ff9745751d8375#diff-8bfeb61c827c2bc073c65cbf4137dbf8f7baa5f4f88e5d59785e985d9510577c) when I changed these two strings. For now it is better to revert them to original English version or figure out why translation is old.
>
> I'll revert it, investigate the cause for the extraction issue in this drop, and try to have it translated by the next drop then.

The translated text here has been reverted to its original English. The same has been done for its locales.

-------------

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 03:38:58 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 03:38:58 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <NwruB7W8obX6XLW0oYPNwk_hsyRRDQfnjcSQ2IcG0BM=.0bda120a-ca70-470f-9ed9-bdb3f43e958a@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
 <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
 <NwruB7W8obX6XLW0oYPNwk_hsyRRDQfnjcSQ2IcG0BM=.0bda120a-ca70-470f-9ed9-bdb3f43e958a@github.com>
Message-ID: <AkPK7pgS3BMYAhNKSN0Xz0Jr0ey_vcQHGP8UmdXy1II=.9691952b-cf52-4724-8c48-3496dfa671c8@github.com>

On Fri, 16 Dec 2022 00:17:15 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_de.wxl line 2:
>> 
>>> 1: <?xml version = '1.0' encoding = 'utf-8'?>
>>> 2: <WixLocalization Culture="de" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="1252">
>> 
>> Why "de-de" was changed to "de"?
>
> Also not sure why this was changed in the translation. I'm reverting all instances of these language codes.

This has been reverted as it was a regression for all locales of MsiInstallerStrings.wxl

-------------

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 03:39:01 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 03:39:01 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <yAXqJCyxsT6KgDaEqjCnsudaB4zIy8gvPnrQkUkNPCw=.d87796f7-1c29-41b4-9b16-86920924ebed@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
 <yAXqJCyxsT6KgDaEqjCnsudaB4zIy8gvPnrQkUkNPCw=.d87796f7-1c29-41b4-9b16-86920924ebed@github.com>
Message-ID: <bbvTT7_7dNA1j9sUSiPADGEnuneemJPFgiiIAI8SsxU=.7e1290eb-107a-458e-a4ee-2cab3b9e7fbf@github.com>

On Thu, 15 Dec 2022 23:12:58 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed trailing whitespace
>
> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties line 51:
> 
>> 49: error.msi-product-version-build-out-of-range=Build-Teil der Version muss im Bereich [0, 65535] liegen
>> 50: error.msi-product-version-minor-out-of-range=Nebenversion muss im Bereich [0, 255] liegen
>> 51: error.version-swap=Versionsinformationen f\u00FCr {0} konnten nicht aktualisiert werden
> 
> Why this was removed?

This line was added back to all locales as it was a regression from the translation process.

-------------

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 03:45:07 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 03:45:07 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <apmyl72NuiCfwAbiJ757W8j59iQar67gH1cIVV757n8=.eeda79d2-99d1-4380-ae15-6d69e8446743@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
 <apmyl72NuiCfwAbiJ757W8j59iQar67gH1cIVV757n8=.eeda79d2-99d1-4380-ae15-6d69e8446743@github.com>
Message-ID: <ZcKFnXSYxP1CuvlfZvENNb3orDWrb4a1Jy8Zkh0KFqI=.ce653817-d7bf-4c64-b505-72a8a06ce590@github.com>

On Thu, 15 Dec 2022 23:30:52 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert double quote as well
>
> src/java.base/share/classes/sun/security/tools/keytool/Resources_zh_CN.java line 75:
> 
>> 73:                 "\u5DF2\u751F\u6210 {0} \u4F4D{1}\u5BC6\u94A5"}, //-genseckey
>> 74:         {"key.algorithm.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u7B97\u6CD5\u88AB\u89C6\u4E3A\u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"},
>> 75:         {"key.size.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"},
> 
> The exact same "is considered a security risk" is sometimes translated into "?????????" and sometimes "??????". Either is OK for me but please be consistent. This is also shown in 5 other places in the same file.

I didn't do the translation myself so I'm not sure the best approach to resolve this. I can manually replace these translations with one or the other. However, it's determine which parts of the code translate to ?????????" or "??????". I converted the unicode you highlighted above to characters, and I see where each one is located. If I just replace all instances of "??????" and insert "?????????" in unicode in its place, will it be OK?

-------------

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 03:58:08 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 03:58:08 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
Message-ID: <uCw2LCc01qL0w9UYrWT7tMoQOhNIB_VaKm4kGc_Z9Vw=.e52a56bf-c4dc-454c-b2a2-e8796c284d66@github.com>

On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert old translation. Fix lang codes

@dfuch Could I get a review from you as well? I believe this translation covers some of the files for your team.

-------------

PR: https://git.openjdk.org/jdk20/pull/35

From cjplummer at openjdk.org  Fri Dec 16 04:12:17 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 16 Dec 2022 04:12:17 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
Message-ID: <XK9d6e9V7rnGtOvMP2mHVDwxsaO_cQCWhnehjTarZ_w=.01c61275-fd0e-4532-8a17-a13c16734bb8@github.com>

On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert old translation. Fix lang codes

`src/jdk.jdi/share/classes/com/sun/tools` changes look good.

-------------

Marked as reviewed by cjplummer (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/35

From almatvee at openjdk.org  Fri Dec 16 05:17:11 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 16 Dec 2022 05:17:11 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
Message-ID: <J3GyIIuioqw6EvIvhMXFm2MByz1cylrmF-jSJcyg3RM=.cd6f3f83-a261-4fa1-ab46-c7d017709595@github.com>

On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert old translation. Fix lang codes

jpackage changes looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/35

From pminborg at openjdk.org  Fri Dec 16 08:16:50 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 16 Dec 2022 08:16:50 GMT
Subject: RFR: 8298639: Perform I/O operations in bulk for RandomAccessFile
 [v4]
In-Reply-To: <CSr3MHVxoI_YzG4NXS5apLiU3VTDavZh7URxs52x9wc=.c508ecdd-dae5-4ce6-9573-7786301bcd4b@github.com>
References: <CSr3MHVxoI_YzG4NXS5apLiU3VTDavZh7URxs52x9wc=.c508ecdd-dae5-4ce6-9573-7786301bcd4b@github.com>
Message-ID: <idKcZBIsCwzjZ-_Xs2f-YM381qp9soHkCWEapTLflWw=.bf6532be-cbce-44d6-aa9a-6bd8bb095ebe@github.com>

> This PR suggests improving performance for read and write operations for the longer primitives in `RandomAccessFile`.
> 
> These improvements would also propagate to other JDK classes relying on these improved `RandomAccessFile` operations.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove api note and redundant comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11644/files
  - new: https://git.openjdk.org/jdk/pull/11644/files/e4f3841e..1bbbcee4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11644&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11644&range=02-03

  Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11644.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11644/head:pull/11644

PR: https://git.openjdk.org/jdk/pull/11644

From pminborg at openjdk.org  Fri Dec 16 09:06:10 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 16 Dec 2022 09:06:10 GMT
Subject: RFR: 8298639: Perform I/O operations in bulk for RandomAccessFile
 [v5]
In-Reply-To: <CSr3MHVxoI_YzG4NXS5apLiU3VTDavZh7URxs52x9wc=.c508ecdd-dae5-4ce6-9573-7786301bcd4b@github.com>
References: <CSr3MHVxoI_YzG4NXS5apLiU3VTDavZh7URxs52x9wc=.c508ecdd-dae5-4ce6-9573-7786301bcd4b@github.com>
Message-ID: <P2C9iRmQU_JKyoPf2JoI-HzK2hPDnv7Ul58IMXUsiho=.42cefa04-3794-4ba7-af86-dcbb7785f4ac@github.com>

> This PR suggests improving performance for read and write operations for the longer primitives in `RandomAccessFile`.
> 
> These improvements would also propagate to other JDK classes relying on these improved `RandomAccessFile` operations.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove redundant import

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11644/files
  - new: https://git.openjdk.org/jdk/pull/11644/files/1bbbcee4..befe033b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11644&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11644&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11644.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11644/head:pull/11644

PR: https://git.openjdk.org/jdk/pull/11644

From dfuchs at openjdk.org  Fri Dec 16 09:22:29 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 16 Dec 2022 09:22:29 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
Message-ID: <MC7rYWqlI84Gv7KqwscR0nXPVEKfDfNjIheXZsUkQZM=.65548e00-c87b-49da-bf02-d03f6365dbcf@github.com>

On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert old translation. Fix lang codes

src/java.base/share/classes/sun/launcher/resources/launcher_de.properties line 34:

> 32: # Translators please note do not translate the options themselves
> 33: java.launcher.opt.footer = \    -cp <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n    -classpath <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n    --class-path <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, JAR-Archiven\n                  und ZIP-Archiven, in denen nach Klassendateien gesucht wird.\n    -p <Modulpfad>\n    --module-path <Modulpfad>...\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n                  ein Verzeichnis mit Modulen ist.\n    --upgrade-module-path <Modulpfad>...\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n                  ein Verzeichnis mit Modulen ist, die upgradef\u00E4hige\n                  Module im Laufzeitimage ersetzen\n    --add-modules <Modulname>[,<Modulname>...]\n                  Root-Module, die zus\u00E4tzlich zum anf\u00E4n
 glichen Modul aufgel\u00F6st werden sollen.\n                  <Modulname> kann auch wie folgt lauten: ALL-DEFAULT, ALL-SYSTEM,\n                  ALL-MODULE-PATH.\n    --enable-native-access <Modulname>[,<Modulname>...]\n                  Module, die eingeschr\u00E4nkte native Vorg\u00E4nge ausf\u00FChren d\u00FCrfen.\n                  <Modulname> kann auch ALL-UNNAMED lauten.\n    --list-modules\n                  Listet beobachtbare Module auf und beendet den Vorgang\n    -d <Modulname>\n    --describe-module <Modulname>\n                  Beschreibt ein Modul und beendet den Vorgang\n    --dry-run     Erstellt eine VM und l\u00E4dt die Hauptklasse, f\u00FChrt aber nicht die Hauptmethode aus.\n                  Die Option "--dry-run" kann n\u00FCtzlich sein, um die\n                  Befehlszeilenoptionen, wie die Modulsystemkonfiguration, zu validieren.\n    --validate-modules\n                  Validiert alle Module und beendet den Vorgang\n                  Die Option "--vali
 date-modules" kann n\u00FCtzlich sein, um\n                  Konflikte und andere Fehler mit Modulen auf dem Modulpfad zu ermitteln.\n    -D<Name>=<Wert>\n                  Legt eine Systemeigenschaft fest\n    -verbose:[class|module|gc|jni]\n                  Aktiviert die Verbose-Ausgabe f\u00FCr das angegebene Subsystem\n    -version      Gibt die Produktversion an den Fehlerstream aus und beendet den Vorgang\n    --version      Gibt die Produktversion an den Outputstream aus und beendet den Vorgang\n    -showversion  Gibt die Produktversion an den Fehlerstream aus und setzt den Vorgang fort\n    --show-version\n                  Gibt die Produktversion an den Outputstream aus und setzt den Vorgang fort\n    --show-module-resolution\n                  Zeigt die Modulaufl\u00F6sungsausgabe beim Start an\n    -? -h -help\n                  Gibt diese Hilfemeldung an den Fehlerstream aus\n    --help        Gibt diese Hilfemeldung an den Outputstream aus\n    -X            Gibt Hilfe
  zu zus\u00E4tzlichen Optionen an den Fehlerstream aus\n    --help-extra  Gibt Hilfe zu zus\u00E4tzlichen Optionen an den Outputstream aus\n    -ea[:<packagename>...|:<classname>]\n    -enableassertions[:<packagename>...|:<classname>]\n                  Aktiviert Assertions mit angegebener Granularit\u00E4t\n    -da[:<packagename>...|:<classname>]\n    -disableassertions[:<packagename>...|:<classname>]\n                  Deaktiviert Assertions mit angegebener Granularit\u00E4t\n    -esa | -enablesystemassertions\n                  Aktiviert System-Assertions\n    -dsa | -disablesystemassertions\n                  Deaktiviert System-Assertions\n    -agentlib:<libname>[=<options>]\n                  L\u00E4dt die native Agent Library <libname>. Beispiel: -agentlib:jdwp\n                  siehe auch -agentlib:jdwp=help\n    -agentpath:<pathname>[=<options>]\n                  L\u00E4dt die native Agent Library mit dem vollst\u00E4ndigen Pfadnamen\n    -javaagent:<jarpath>[=<options>]\n
                   \
> 34: L\u00E4dt den Java-Programmiersprachen-Agent, siehe java.lang.instrument\n    -splash:<imagepath>\n                  Zeigt den Startbildschirm mit einem angegebenen Bild an\n                  Skalierte HiDPI-Bilder werden automatisch unterst\u00FCtzt und verwendet,\n                  falls verf\u00FCgbar. Der nicht skalierte Bilddateiname (Beispiel: image.ext)\n                  muss immer als Argument an die Option "-splash" \u00FCbergeben werden.\n                  Das am besten geeignete angegebene skalierte Bild wird\n                  automatisch ausgew\u00E4hlt.\n                  Weitere Informationen finden Sie in der Dokumentation zur SplashScreen-API\n    @argument files\n                  Eine oder mehrere Argumentdateien mit Optionen\n    -disable- at files\n                  Verhindert die weitere Erweiterung von Argumentdateien\n    --enable-preview\n                  L\u00E4sst zu, das Klassen von Vorschaufeatures dieses Release abh\u00E4ngig sind\nUm ein Argument f
 \u00FCr eine lange Option anzugeben, k\u00F6nnen Sie --<Name>=<Wert> oder\n--<Name> <Wert> verwenden.\n

This change seems wrong, unless I'm mistaken the option name is `--disable- at files`, not `-disable- at files`

-------------

PR: https://git.openjdk.org/jdk20/pull/35

From dfuchs at openjdk.org  Fri Dec 16 09:48:59 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 16 Dec 2022 09:48:59 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <MC7rYWqlI84Gv7KqwscR0nXPVEKfDfNjIheXZsUkQZM=.65548e00-c87b-49da-bf02-d03f6365dbcf@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
 <MC7rYWqlI84Gv7KqwscR0nXPVEKfDfNjIheXZsUkQZM=.65548e00-c87b-49da-bf02-d03f6365dbcf@github.com>
Message-ID: <_0KsmHnCRIMKjENGMD87WqQJUloO0LDLaQyHBkwGiw0=.b44b40b1-10b0-4be4-99cf-0d18750a6c19@github.com>

On Fri, 16 Dec 2022 09:20:07 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert old translation. Fix lang codes
>
> src/java.base/share/classes/sun/launcher/resources/launcher_de.properties line 34:
> 
>> 32: # Translators please note do not translate the options themselves
>> 33: java.launcher.opt.footer = \    -cp <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n    -classpath <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n    --class-path <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, JAR-Archiven\n                  und ZIP-Archiven, in denen nach Klassendateien gesucht wird.\n    -p <Modulpfad>\n    --module-path <Modulpfad>...\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n                  ein Verzeichnis mit Modulen ist.\n    --upgrade-module-path <Modulpfad>...\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n                  ein Verzeichnis mit Modulen ist, die upgradef\u00E4hige\n                  Module im Laufzeitimage ersetzen\n    --add-modules <Modulname>[,<Modulname>...]\n                  Root-Module, die zus\u00E4tzlich zum anf\u00E4
 nglichen Modul aufgel\u00F6st werden sollen.\n                  <Modulname> kann auch wie folgt lauten: ALL-DEFAULT, ALL-SYSTEM,\n                  ALL-MODULE-PATH.\n    --enable-native-access <Modulname>[,<Modulname>...]\n                  Module, die eingeschr\u00E4nkte native Vorg\u00E4nge ausf\u00FChren d\u00FCrfen.\n                  <Modulname> kann auch ALL-UNNAMED lauten.\n    --list-modules\n                  Listet beobachtbare Module auf und beendet den Vorgang\n    -d <Modulname>\n    --describe-module <Modulname>\n                  Beschreibt ein Modul und beendet den Vorgang\n    --dry-run     Erstellt eine VM und l\u00E4dt die Hauptklasse, f\u00FChrt aber nicht die Hauptmethode aus.\n                  Die Option "--dry-run" kann n\u00FCtzlich sein, um die\n                  Befehlszeilenoptionen, wie die Modulsystemkonfiguration, zu validieren.\n    --validate-modules\n                  Validiert alle Module und beendet den Vorgang\n                  Die Option "--val
 idate-modules" kann n\u00FCtzlich sein, um\n                  Konflikte und andere Fehler mit Modulen auf dem Modulpfad zu ermitteln.\n    -D<Name>=<Wert>\n                  Legt eine Systemeigenschaft fest\n    -verbose:[class|module|gc|jni]\n                  Aktiviert die Verbose-Ausgabe f\u00FCr das angegebene Subsystem\n    -version      Gibt die Produktversion an den Fehlerstream aus und beendet den Vorgang\n    --version      Gibt die Produktversion an den Outputstream aus und beendet den Vorgang\n    -showversion  Gibt die Produktversion an den Fehlerstream aus und setzt den Vorgang fort\n    --show-version\n                  Gibt die Produktversion an den Outputstream aus und setzt den Vorgang fort\n    --show-module-resolution\n                  Zeigt die Modulaufl\u00F6sungsausgabe beim Start an\n    -? -h -help\n                  Gibt diese Hilfemeldung an den Fehlerstream aus\n    --help        Gibt diese Hilfemeldung an den Outputstream aus\n    -X            Gibt Hilf
 e zu zus\u00E4tzlichen Optionen an den Fehlerstream aus\n    --help-extra  Gibt Hilfe zu zus\u00E4tzlichen Optionen an den Outputstream aus\n    -ea[:<packagename>...|:<classname>]\n    -enableassertions[:<packagename>...|:<classname>]\n                  Aktiviert Assertions mit angegebener Granularit\u00E4t\n    -da[:<packagename>...|:<classname>]\n    -disableassertions[:<packagename>...|:<classname>]\n                  Deaktiviert Assertions mit angegebener Granularit\u00E4t\n    -esa | -enablesystemassertions\n                  Aktiviert System-Assertions\n    -dsa | -disablesystemassertions\n                  Deaktiviert System-Assertions\n    -agentlib:<libname>[=<options>]\n                  L\u00E4dt die native Agent Library <libname>. Beispiel: -agentlib:jdwp\n                  siehe auch -agentlib:jdwp=help\n    -agentpath:<pathname>[=<options>]\n                  L\u00E4dt die native Agent Library mit dem vollst\u00E4ndigen Pfadnamen\n    -javaagent:<jarpath>[=<options>]\
 n                  \
>> 34: L\u00E4dt den Java-Programmiersprachen-Agent, siehe java.lang.instrument\n    -splash:<imagepath>\n                  Zeigt den Startbildschirm mit einem angegebenen Bild an\n                  Skalierte HiDPI-Bilder werden automatisch unterst\u00FCtzt und verwendet,\n                  falls verf\u00FCgbar. Der nicht skalierte Bilddateiname (Beispiel: image.ext)\n                  muss immer als Argument an die Option "-splash" \u00FCbergeben werden.\n                  Das am besten geeignete angegebene skalierte Bild wird\n                  automatisch ausgew\u00E4hlt.\n                  Weitere Informationen finden Sie in der Dokumentation zur SplashScreen-API\n    @argument files\n                  Eine oder mehrere Argumentdateien mit Optionen\n    -disable- at files\n                  Verhindert die weitere Erweiterung von Argumentdateien\n    --enable-preview\n                  L\u00E4sst zu, das Klassen von Vorschaufeatures dieses Release abh\u00E4ngig sind\nUm ein Argument 
 f\u00FCr eine lange Option anzugeben, k\u00F6nnen Sie --<Name>=<Wert> oder\n--<Name> <Wert> verwenden.\n
> 
> This change seems wrong, unless I'm mistaken the option name is still  `--disable- at files`, not `-disable- at files`

I'm unfortunately not familiar with any of these resources files,  and can't neither comment on any of the translated languages. I still had a look and spotted the glitch above - which seems to be an error introduced in the translation.
Find-in-files revealed that the source is still using --disable- at files. See:

https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/args.c#L131

https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L1377

https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/launcher/resources/launcher.properties#L121

-------------

PR: https://git.openjdk.org/jdk20/pull/35

From dsamersoff at openjdk.org  Fri Dec 16 10:01:07 2022
From: dsamersoff at openjdk.org (Dmitry Samersoff)
Date: Fri, 16 Dec 2022 10:01:07 GMT
Subject: RFR: 8298638: Cleanup of unix java_md.c for better re-exec
 handling
In-Reply-To: <TaHshA4rGKbmy2y4ULvvf8BEDiQCY3l3n-1FwXOxt98=.0c878574-49d3-4811-a5e3-8935fceb9d7b@github.com>
References: <UqitH23_LetW3nTGVU_7m5SxPsrpMojdrdYOOnWeZFI=.bc783eec-1c8d-4b80-9ef4-d92cb4131825@github.com>
 <7Qhy0FBtbbTEjb3vLLam6pPLIeIug4LH8taW0GJ8nIs=.fa0c55f3-944e-4923-91ae-850bbcecc307@github.com>
 <TaHshA4rGKbmy2y4ULvvf8BEDiQCY3l3n-1FwXOxt98=.0c878574-49d3-4811-a5e3-8935fceb9d7b@github.com>
Message-ID: <nhQv1BWq75iav8yuvB0qAjFyfyzDu1ZvoaMkhMZ8ors=.6c0c994c-9a76-4c2d-87f7-3ca350f34bcd@github.com>

On Wed, 14 Dec 2022 09:51:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/unix/native/libjli/java_md.c line 177:
>> 
>>> 175:     char clientPattern[] = "lib/client";
>>> 176:     char serverPattern[] = "lib/server";
>>> 177:     char minimalPattern[] = "lib/minimal";
>> 
>> I don't see any point in adding this when the MinimalVM is not really relevant to current JDK.
>
> Yeah, the minimal VM build probably needs wider discussion. There are bug reports when it breaks so some people are still building it. The context here seems to be that LD_LIBRARY_PATH set to a location that includes "lib/minimal" so somewhat unusual setup. It seems like it's a separate issue for discussion.

>From launcher perspective, lib/minimal is just another "suspicious" keyword in LD_LIBRARY_PATH. Launcher is not affected by any other problems related to  minimal VM. 

I think that launcher should support all VM variants consistently, as long as we can build a minimal VM from the current JDK sources.

-------------

PR: https://git.openjdk.org/jdk/pull/11645

From alanb at openjdk.org  Fri Dec 16 10:13:04 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 Dec 2022 10:13:04 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <uCw2LCc01qL0w9UYrWT7tMoQOhNIB_VaKm4kGc_Z9Vw=.e52a56bf-c4dc-454c-b2a2-e8796c284d66@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
 <uCw2LCc01qL0w9UYrWT7tMoQOhNIB_VaKm4kGc_Z9Vw=.e52a56bf-c4dc-454c-b2a2-e8796c284d66@github.com>
Message-ID: <s7AGBhlHie3pq-e0NT_2pQ3hWQ15Oyt1dR_t2D9YM3g=.01648378-0fb2-4f51-a9bf-1f5066e40158@github.com>

On Fri, 16 Dec 2022 03:55:29 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert old translation. Fix lang codes
>
> @dfuch Could I get a review from you as well? I believe this translation covers some of the files for your team.

@DamonGuy There seems to be several glitches in this refresh. It's also surprising that the translations appear to be done on several out of date files. On the positive front, it's good to see this update has caught the attention of Naoto, Weijun, and others. Once the identified issues have been fixed then it would be good to try to get a review from someone that is native in each of the languages.

-------------

PR: https://git.openjdk.org/jdk20/pull/35

From mcimadamore at openjdk.org  Fri Dec 16 10:52:50 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 16 Dec 2022 10:52:50 GMT
Subject: [jdk20] Integrated: 8298797: Specification of some restricted methods
 is incorrect
In-Reply-To: <PjrmbYlP97ORHfseTAFprgUV5O00JCJt74t51RLqey8=.692df6ba-6b9f-4962-b7da-16d202e6ac0b@github.com>
References: <PjrmbYlP97ORHfseTAFprgUV5O00JCJt74t51RLqey8=.692df6ba-6b9f-4962-b7da-16d202e6ac0b@github.com>
Message-ID: <p-cqSXqXmWneknh7EQyjCpHx2qqNegEfVrLOqt3BLd0=.fcd6044b-e64c-4458-a96b-a9451e98e3d4@github.com>

On Thu, 15 Dec 2022 10:43:35 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch fixes some inconsistencies in the javadoc for restricted methods:
> 
> * ModuleLayer.Controller::addEnableNativeAccess has a shorted text in its `@throws` clause. This shorted text is now used everywhere.
> * One overload of `MemorySegment::ofAddress` is missing the restricted method narrative text

This pull request has now been integrated.

Changeset: f771c56e
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/f771c56e16a39724712ca0d8c2dd55b9ce260f4d
Stats:     33 lines in 6 files changed: 10 ins; 14 del; 9 mod

8298797: Specification of some restricted methods is incorrect

Reviewed-by: jvernee, pminborg

-------------

PR: https://git.openjdk.org/jdk20/pull/40

From alanb at openjdk.org  Fri Dec 16 11:49:54 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 Dec 2022 11:49:54 GMT
Subject: RFR: 8298639: Perform I/O operations in bulk for RandomAccessFile
 [v5]
In-Reply-To: <P2C9iRmQU_JKyoPf2JoI-HzK2hPDnv7Ul58IMXUsiho=.42cefa04-3794-4ba7-af86-dcbb7785f4ac@github.com>
References: <CSr3MHVxoI_YzG4NXS5apLiU3VTDavZh7URxs52x9wc=.c508ecdd-dae5-4ce6-9573-7786301bcd4b@github.com>
 <P2C9iRmQU_JKyoPf2JoI-HzK2hPDnv7Ul58IMXUsiho=.42cefa04-3794-4ba7-af86-dcbb7785f4ac@github.com>
Message-ID: <r17vPXVNODpj-UU4UJcnHBpOKfOw60x2PQmeDPJJtdI=.437d82e4-8385-4b99-87af-1c0ed1f06fa2@github.com>

On Fri, 16 Dec 2022 09:06:10 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests improving performance for read and write operations for the longer primitives in `RandomAccessFile`.
>> 
>> These improvements would also propagate to other JDK classes relying on these improved `RandomAccessFile` operations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant import

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11644

From ssahoo at openjdk.org  Fri Dec 16 12:38:05 2022
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Fri, 16 Dec 2022 12:38:05 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v5]
In-Reply-To: <uw2kQJPBcg5iPyVZGL-BiSMkIK7S2htYcOyOTSi_1-w=.2b19fdf9-5978-4ded-b2e9-3d228c586fd6@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <uw2kQJPBcg5iPyVZGL-BiSMkIK7S2htYcOyOTSi_1-w=.2b19fdf9-5978-4ded-b2e9-3d228c586fd6@github.com>
Message-ID: <uDwwI-PKA1x-jZ1noAhf3jmID9VyD2fBeBGYfs__wpg=.05c55abe-673f-4aac-86d3-35c9c51ad3cf@github.com>

On Mon, 5 Dec 2022 19:52:18 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task converts 5 manual tests to automated tests.
>> 
>> sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java 
>> sun/security/provider/PolicyParser/ExtDirsChange.java 
>> sun/security/provider/PolicyParser/ExtDirs.java 
>> java/security/Policy/Root/Root.javajava/security/Policy/Root/Root.java 
>> javax/crypto/CryptoPermissions/InconsistentEntries.java
>
> Bill Huang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8295087
>  - Added an extra line to the end of the policy file.
>  - AssertThrows an exception in InconsistentEntries test.
>  - Refactored to use testng framework for test enviroment setup.
>  - Converted security manual tests to automated tests.

test/jdk/javax/crypto/CryptoPermissions/InconsistentEntries.java line 52:

> 50:     private static final String JDK_HOME = System.getProperty("test.jdk");
> 51:     private static final String TEST_SRC = System.getProperty("test.src");
> 52:     private static final Path POLICY_DIR = Paths.get(JDK_HOME, "conf", "security",

This doesn't looks like a safe Test to be automated. Can it create conflict with any other existing Test requiring "testlimited" with  default_local.policy? This need to be verified. Also changing anything inside an installed JDK probably not a good choice. It's just a thought from my side and it could be different for others.

test/jdk/sun/security/provider/PolicyParser/ExtDirs.java line 37:

> 35:  * @summary standard extensions path is hard-coded in default
> 36:  *      system policy file
> 37:  * @run main/othervm/policy=ExtDirs.policy/secure=default ExtDirs

May be "/secure=default" is optional here.

-------------

PR: https://git.openjdk.org/jdk/pull/10637

From jwilhelm at openjdk.org  Fri Dec 16 13:33:14 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Fri, 16 Dec 2022 13:33:14 GMT
Subject: RFR: Merge jdk20
Message-ID: <YSHTcwXEKi0AYIOzrJy89CKa6GDNBwOXsUj0qcvrtz0=.249e0882-9bd1-49da-abcd-19e0a3d9ef5b@github.com>

Forwardport JDK 20 -> JDK 21

-------------

Commit messages:
 - Merge
 - 8298797: Specification of some restricted methods is incorrect
 - 8287699: jdk/jfr/api/consumer/TestRecordingFileWrite.java fails with exception: java.lang.Exception: Found event that should not be there.
 - 8297979: ZGC: Ensure consistent MemoryUsage from MemoryMXBean.getHeapMemoryUsage()
 - 8298083: The "CheckBox/RadioButton[Enabled/Disabled].textForeground" stoped working
 - 8298888: ProblemList gc/g1/TestVerifyGCType.java on linux and macosx
 - 7093322: (fs spec) Files.newBufferedWriter should be clear when coding errors are detected
 - 8298050: Add links to graph output for javadoc
 - 8298376: ZGC: thaws stackChunk with stale oops
 - 8298727: Trees.getPath may crash for unnamed package
 - ... and 1 more: https://git.openjdk.org/jdk/compare/ac2fcf3f...f069db65

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=11710&range=00.0
 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=11710&range=00.1

Changes: https://git.openjdk.org/jdk/pull/11710/files
  Stats: 250 lines in 15 files changed: 180 ins; 52 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/11710.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11710/head:pull/11710

PR: https://git.openjdk.org/jdk/pull/11710

From naoto at openjdk.org  Fri Dec 16 13:46:02 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 16 Dec 2022 13:46:02 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
Message-ID: <FkE6xWy1f_931bWkjLEGooZJgRw31mF1UNMMMjICFUQ=.90de6a4a-57c3-41c4-8c9c-2c582f4696c0@github.com>

On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert old translation. Fix lang codes

There is another translation drop scheduled in January, so our plan is to figure out why the source extraction in this drop mistakenly used old files till then, then address it in the January l10n drop.

-------------

PR: https://git.openjdk.org/jdk20/pull/35

From jwilhelm at openjdk.org  Fri Dec 16 15:52:00 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Fri, 16 Dec 2022 15:52:00 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <YSHTcwXEKi0AYIOzrJy89CKa6GDNBwOXsUj0qcvrtz0=.249e0882-9bd1-49da-abcd-19e0a3d9ef5b@github.com>
References: <YSHTcwXEKi0AYIOzrJy89CKa6GDNBwOXsUj0qcvrtz0=.249e0882-9bd1-49da-abcd-19e0a3d9ef5b@github.com>
Message-ID: <z_G2NJpaW0cmxQZFzSX6rOdwLniXiNqi1pJnO1i3px0=.5f7eff5b-3931-4541-b0b1-717d7e2eecd6@github.com>

On Fri, 16 Dec 2022 13:25:55 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: 3696711e
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3696711efa566fb776d6923da86e17b0e1e22964
Stats:     250 lines in 15 files changed: 180 ins; 52 del; 18 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/11710

From ihse at openjdk.org  Fri Dec 16 15:59:50 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 16 Dec 2022 15:59:50 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v8]
In-Reply-To: <xy2Eago_3UXJFsvRNfJ4y3GLbfnvdSBEL8MEMLZLr44=.6fb62abf-a53b-4531-bcc6-42aaf74d030d@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <xy2Eago_3UXJFsvRNfJ4y3GLbfnvdSBEL8MEMLZLr44=.6fb62abf-a53b-4531-bcc6-42aaf74d030d@github.com>
Message-ID: <TVgOLxtNqz5oaLxuiXMaMr3Dm47UENz1vUPqye7PKfs=.185d208c-83dc-41cb-8d9c-58e0b0bccb52@github.com>

On Mon, 12 Dec 2022 10:42:22 GMT, Justin King <jcking at openjdk.org> wrote:

>> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify logic for including __ubsan_default_options
>   
>   Signed-off-by: Justin King <jcking at google.com>

Sorry for the late review.

"Magic" solutions like this is always a bit scary. But we have some precedence in terms of the "autoheaders" for assembly files, so I guess this is not worse.

However, I do think the included source files should be treated like the autoheaders, and reside in data rather than in `src`. The latter is intended for buildtools, even though they are a bit scattered at the moment (there is a long-standing JBS bug about fixing that), and these are not really intended to be compiled into a product by itself, rather as something "injected" into all builds. I'd recommend `make/data/ubsan`, and perhaps skip the leading `__`.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From ihse at openjdk.org  Fri Dec 16 16:04:51 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 16 Dec 2022 16:04:51 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v8]
In-Reply-To: <J-iYcVYMBl2Ub-HohIii7v7yPPG7w9Dp1i40SpAD8TY=.1cd821c5-9318-4b62-920b-3ece28047704@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <-1gzjFB0pjbXBXsKVQv4z0-ZSO7ZhOgPHHn4A-ix7tw=.64b4fb3d-5d8e-4450-9428-ca086cc5d3aa@github.com>
 <J-iYcVYMBl2Ub-HohIii7v7yPPG7w9Dp1i40SpAD8TY=.1cd821c5-9318-4b62-920b-3ece28047704@github.com>
Message-ID: <m2OU-QHP_jeLe4l2sNmrJG5rJdqnuio_GJxoyOfKk9E=.6161a9b3-20ae-4950-a071-14df2189b004@github.com>

On Fri, 9 Dec 2022 20:38:26 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> make/autoconf/jdk-options.m4 line 450:
>> 
>>> 448: ###############################################################################
>>> 449: #
>>> 450: # UndefinedBehaviorSanitizer
>> 
>> I think this logic fits better in `flags.m4`, otherwise this looks ok to me.
>
> Ah now I understand that this compiles runtime checks into the product. In that case it does actually fit well into jdk-options.m4, so you can leave it there.

Well, this function actually does two things -- first it checks if ubsan support should be enabled, and that code really belong here. But then if it i enabled, it adds additional compiler options, including globally silencing some warnings, and that should really reside in flags-cflags.m4. 

But, I see we have this pattern for other optional tooling support like ASan and GCov, so I guess this is fine for now.

I'm really looking forward to a better way of handling flags so we wouldn't have to do it like this.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From ihse at openjdk.org  Fri Dec 16 16:12:50 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 16 Dec 2022 16:12:50 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v8]
In-Reply-To: <xy2Eago_3UXJFsvRNfJ4y3GLbfnvdSBEL8MEMLZLr44=.6fb62abf-a53b-4531-bcc6-42aaf74d030d@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <xy2Eago_3UXJFsvRNfJ4y3GLbfnvdSBEL8MEMLZLr44=.6fb62abf-a53b-4531-bcc6-42aaf74d030d@github.com>
Message-ID: <b7fEttZ902Ss_f8_XN84mn7rxgnk3BiSc2-hbegYi00=.daec5059-5f55-4d8a-9f19-a711a579611d@github.com>

On Mon, 12 Dec 2022 10:42:22 GMT, Justin King <jcking at openjdk.org> wrote:

>> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify logic for including __ubsan_default_options
>   
>   Signed-off-by: Justin King <jcking at google.com>

I much also check: is this really needed for *all* executables we make? I would have guessed that it would suffice with the "launchers", i.e. like `java`, `javac`, `jar` etc. These are all compiled from a single source file, `src/java.base/share/native/launcher/main.c`, with different defines depending on what Java classes it should actually launch, and with different output names.

Doing things this way will also affect non-launcher executables, like `jabswitch`, `msiwrapper` and all executable test binaries. 

That might be correct, but I could not be certain of that from trying to read the backlog of discussion in this bug.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From weijun at openjdk.org  Fri Dec 16 15:05:55 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 16 Dec 2022 15:05:55 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <ZcKFnXSYxP1CuvlfZvENNb3orDWrb4a1Jy8Zkh0KFqI=.ce653817-d7bf-4c64-b505-72a8a06ce590@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
 <apmyl72NuiCfwAbiJ757W8j59iQar67gH1cIVV757n8=.eeda79d2-99d1-4380-ae15-6d69e8446743@github.com>
 <ZcKFnXSYxP1CuvlfZvENNb3orDWrb4a1Jy8Zkh0KFqI=.ce653817-d7bf-4c64-b505-72a8a06ce590@github.com>
Message-ID: <2YOQE1QvnJ2ntEgk3PVI_IXfwyPyZN50WAiiEf0Nub0=.ba16fa2f-799d-42b5-a0b1-4e65d99fecb7@github.com>

On Fri, 16 Dec 2022 03:41:09 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/tools/keytool/Resources_zh_CN.java line 75:
>> 
>>> 73:                 "\u5DF2\u751F\u6210 {0} \u4F4D{1}\u5BC6\u94A5"}, //-genseckey
>>> 74:         {"key.algorithm.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u7B97\u6CD5\u88AB\u89C6\u4E3A\u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"},
>>> 75:         {"key.size.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"},
>> 
>> The exact same "is considered a security risk" is sometimes translated into "?????????" and sometimes "??????". Either is OK for me but please be consistent. This is also shown in 5 other places in the same file.
>
> I didn't do the translation myself so I'm not sure the best approach to resolve this. I can manually replace these translations with one or the other. However, it's determine which parts of the code translate to ?????????" or "??????". I converted the unicode you highlighted above to characters, and I see where each one is located. If I just replace all instances of "??????" and insert "?????????" in unicode in its place, will it be OK?

Yes, you can replace all "??????" (that is not after ""???") to "?????????".

There are also similar usages in `src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java`.

-------------

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 16:53:59 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 16:53:59 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
Message-ID: <eKoHNhbn6nSejGumOAm87rtEJh5ZyQVEaFblB2t7jOA=.3366bc22-6709-479c-a23a-d41f1aa49b33@github.com>

On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert old translation. Fix lang codes

Right, Naoto's comment is correct. This time, the source extraction used some older files. To resolve this for this drop, I went through the files and reverted any changes that would be deemed as regressions or outdated files. Any other updates missed in this drop will be handled in the close upcoming drop in January.

-------------

PR: https://git.openjdk.org/jdk20/pull/35

From bpb at openjdk.org  Fri Dec 16 16:59:50 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 16 Dec 2022 16:59:50 GMT
Subject: RFR: 8298639: Perform I/O operations in bulk for RandomAccessFile
 [v5]
In-Reply-To: <P2C9iRmQU_JKyoPf2JoI-HzK2hPDnv7Ul58IMXUsiho=.42cefa04-3794-4ba7-af86-dcbb7785f4ac@github.com>
References: <CSr3MHVxoI_YzG4NXS5apLiU3VTDavZh7URxs52x9wc=.c508ecdd-dae5-4ce6-9573-7786301bcd4b@github.com>
 <P2C9iRmQU_JKyoPf2JoI-HzK2hPDnv7Ul58IMXUsiho=.42cefa04-3794-4ba7-af86-dcbb7785f4ac@github.com>
Message-ID: <MZ6k0blAI1fDyp4ew8WyQrko783ijcmSyBQ3m1sJbBg=.7a1d6ec6-1293-42ef-a4b6-592ea86763bf@github.com>

On Fri, 16 Dec 2022 09:06:10 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests improving performance for read and write operations for the longer primitives in `RandomAccessFile`.
>> 
>> These improvements would also propagate to other JDK classes relying on these improved `RandomAccessFile` operations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant import

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11644

From dnguyen at openjdk.org  Fri Dec 16 17:02:42 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 17:02:42 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v6]
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <scvd5xE_Bjf0z8Q_DD1Ri4KSI64RhpsxuqIxdiTIbmw=.b58bccb0-64b3-4239-8f38-7a4c1804b14d@github.com>

> Open l10n drop
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Fix missing dash

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/35/files
  - new: https://git.openjdk.org/jdk20/pull/35/files/29880af9..62a19a83

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=04-05

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk20/pull/35.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 17:02:44 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 17:02:44 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <_0KsmHnCRIMKjENGMD87WqQJUloO0LDLaQyHBkwGiw0=.b44b40b1-10b0-4be4-99cf-0d18750a6c19@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
 <MC7rYWqlI84Gv7KqwscR0nXPVEKfDfNjIheXZsUkQZM=.65548e00-c87b-49da-bf02-d03f6365dbcf@github.com>
 <_0KsmHnCRIMKjENGMD87WqQJUloO0LDLaQyHBkwGiw0=.b44b40b1-10b0-4be4-99cf-0d18750a6c19@github.com>
Message-ID: <uipT8s-ZFfoJgsIH3b7vP8Pgu15BiK3gx4EmIZ09pyQ=.c1ead06a-8b31-41d3-8601-52c4ed8d854e@github.com>

On Fri, 16 Dec 2022 09:46:14 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.base/share/classes/sun/launcher/resources/launcher_de.properties line 34:
>> 
>>> 32: # Translators please note do not translate the options themselves
>>> 33: java.launcher.opt.footer = \    -cp <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n    -classpath <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n    --class-path <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, JAR-Archiven\n                  und ZIP-Archiven, in denen nach Klassendateien gesucht wird.\n    -p <Modulpfad>\n    --module-path <Modulpfad>...\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n                  ein Verzeichnis mit Modulen ist.\n    --upgrade-module-path <Modulpfad>...\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n                  ein Verzeichnis mit Modulen ist, die upgradef\u00E4hige\n                  Module im Laufzeitimage ersetzen\n    --add-modules <Modulname>[,<Modulname>...]\n                  Root-Module, die zus\u00E4tzlich zum anf\u00E
 4nglichen Modul aufgel\u00F6st werden sollen.\n                  <Modulname> kann auch wie folgt lauten: ALL-DEFAULT, ALL-SYSTEM,\n                  ALL-MODULE-PATH.\n    --enable-native-access <Modulname>[,<Modulname>...]\n                  Module, die eingeschr\u00E4nkte native Vorg\u00E4nge ausf\u00FChren d\u00FCrfen.\n                  <Modulname> kann auch ALL-UNNAMED lauten.\n    --list-modules\n                  Listet beobachtbare Module auf und beendet den Vorgang\n    -d <Modulname>\n    --describe-module <Modulname>\n                  Beschreibt ein Modul und beendet den Vorgang\n    --dry-run     Erstellt eine VM und l\u00E4dt die Hauptklasse, f\u00FChrt aber nicht die Hauptmethode aus.\n                  Die Option "--dry-run" kann n\u00FCtzlich sein, um die\n                  Befehlszeilenoptionen, wie die Modulsystemkonfiguration, zu validieren.\n    --validate-modules\n                  Validiert alle Module und beendet den Vorgang\n                  Die Option "--va
 lidate-modules" kann n\u00FCtzlich sein, um\n                  Konflikte und andere Fehler mit Modulen auf dem Modulpfad zu ermitteln.\n    -D<Name>=<Wert>\n                  Legt eine Systemeigenschaft fest\n    -verbose:[class|module|gc|jni]\n                  Aktiviert die Verbose-Ausgabe f\u00FCr das angegebene Subsystem\n    -version      Gibt die Produktversion an den Fehlerstream aus und beendet den Vorgang\n    --version      Gibt die Produktversion an den Outputstream aus und beendet den Vorgang\n    -showversion  Gibt die Produktversion an den Fehlerstream aus und setzt den Vorgang fort\n    --show-version\n                  Gibt die Produktversion an den Outputstream aus und setzt den Vorgang fort\n    --show-module-resolution\n                  Zeigt die Modulaufl\u00F6sungsausgabe beim Start an\n    -? -h -help\n                  Gibt diese Hilfemeldung an den Fehlerstream aus\n    --help        Gibt diese Hilfemeldung an den Outputstream aus\n    -X            Gibt Hil
 fe zu zus\u00E4tzlichen Optionen an den Fehlerstream aus\n    --help-extra  Gibt Hilfe zu zus\u00E4tzlichen Optionen an den Outputstream aus\n    -ea[:<packagename>...|:<classname>]\n    -enableassertions[:<packagename>...|:<classname>]\n                  Aktiviert Assertions mit angegebener Granularit\u00E4t\n    -da[:<packagename>...|:<classname>]\n    -disableassertions[:<packagename>...|:<classname>]\n                  Deaktiviert Assertions mit angegebener Granularit\u00E4t\n    -esa | -enablesystemassertions\n                  Aktiviert System-Assertions\n    -dsa | -disablesystemassertions\n                  Deaktiviert System-Assertions\n    -agentlib:<libname>[=<options>]\n                  L\u00E4dt die native Agent Library <libname>. Beispiel: -agentlib:jdwp\n                  siehe auch -agentlib:jdwp=help\n    -agentpath:<pathname>[=<options>]\n                  L\u00E4dt die native Agent Library mit dem vollst\u00E4ndigen Pfadnamen\n    -javaagent:<jarpath>[=<options>]
 \n                  \
>>> 34: L\u00E4dt den Java-Programmiersprachen-Agent, siehe java.lang.instrument\n    -splash:<imagepath>\n                  Zeigt den Startbildschirm mit einem angegebenen Bild an\n                  Skalierte HiDPI-Bilder werden automatisch unterst\u00FCtzt und verwendet,\n                  falls verf\u00FCgbar. Der nicht skalierte Bilddateiname (Beispiel: image.ext)\n                  muss immer als Argument an die Option "-splash" \u00FCbergeben werden.\n                  Das am besten geeignete angegebene skalierte Bild wird\n                  automatisch ausgew\u00E4hlt.\n                  Weitere Informationen finden Sie in der Dokumentation zur SplashScreen-API\n    @argument files\n                  Eine oder mehrere Argumentdateien mit Optionen\n    -disable- at files\n                  Verhindert die weitere Erweiterung von Argumentdateien\n    --enable-preview\n                  L\u00E4sst zu, das Klassen von Vorschaufeatures dieses Release abh\u00E4ngig sind\nUm ein Argument
  f\u00FCr eine lange Option anzugeben, k\u00F6nnen Sie --<Name>=<Wert> oder\n--<Name> <Wert> verwenden.\n
>> 
>> This change seems wrong, unless I'm mistaken the option name is still  `--disable- at files`, not `-disable- at files`
>
> I'm unfortunately not familiar with any of these resources files,  and can't neither comment on any of the translated languages. I still had a look and spotted the glitch above - which seems to be an error introduced in the translation.
> Find-in-files revealed that the source is still using --disable- at files. See:
> 
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/args.c#L131
> 
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L1377
> 
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/launcher/resources/launcher.properties#L121

Thanks for taking a look. I fixed this removed dash from the translation in the latest PR.

-------------

PR: https://git.openjdk.org/jdk20/pull/35

From naoto at openjdk.org  Fri Dec 16 17:19:57 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 16 Dec 2022 17:19:57 GMT
Subject: Integrated: 8298808: Check `script` code on detecting the base locales
In-Reply-To: <-y3oZIKk1c7lLT9v6xYmNaOWr0aoKChLz5erO0Mx9vs=.02bc4c39-8d21-4aaa-ac95-0f7e28c21a43@github.com>
References: <-y3oZIKk1c7lLT9v6xYmNaOWr0aoKChLz5erO0Mx9vs=.02bc4c39-8d21-4aaa-ac95-0f7e28c21a43@github.com>
Message-ID: <OGwpeGkz8uVvzxeMc9GnFezFPoqUIcPKbHA48AImGGk=.8bf8e294-c167-4f09-847c-91a3a71491ee@github.com>

On Wed, 14 Dec 2022 23:08:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing `CLDRConverter` build tool to not regard [new locales](https://github.com/unicode-org/cldr/pull/2508/files#diff-94cbefde02914335da884f768063a06a84ad651ee4e56cdb1cb90625d7776731) introduced in CLDR 43 as one of the base locales. Otherwise they would incorrectly go into `java.base` module, then a test case fails.

This pull request has now been integrated.

Changeset: 0eeaeb8e
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0eeaeb8e7ba40be5e93eb87c7e3dc94230062746
Stats:     13 lines in 2 files changed: 10 ins; 1 del; 2 mod

8298808: Check `script` code on detecting the base locales

Reviewed-by: joehw

-------------

PR: https://git.openjdk.org/jdk/pull/11684

From prr at openjdk.org  Fri Dec 16 17:28:56 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 16 Dec 2022 17:28:56 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v6]
In-Reply-To: <scvd5xE_Bjf0z8Q_DD1Ri4KSI64RhpsxuqIxdiTIbmw=.b58bccb0-64b3-4239-8f38-7a4c1804b14d@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <scvd5xE_Bjf0z8Q_DD1Ri4KSI64RhpsxuqIxdiTIbmw=.b58bccb0-64b3-4239-8f38-7a4c1804b14d@github.com>
Message-ID: <FmlUsetmec4ajWf41qIKWiV_d6svun82djbObUKfyao=.bb2b49e5-3426-4d2d-9f8c-1167d867889d@github.com>

On Fri, 16 Dec 2022 17:02:42 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix missing dash

src/demo/share/jfc/SwingSet2/resources/swingset_zh_CN.properties line 430:

> 428: ProgressBarDemo.accessible_text_area_name=\u52A0\u8F7D\u7684\u6587\u672C\u6B63\u5728\u9010\u6E10\u589E\u591A
> 429: 
> 430: ProgressBarDemo.accessible_text_area_description=\u8FD9\u4E2A JTextArea \u7531\u6765\u81EA\u7F13\u51B2\u533A\u7684\u6587\u672C\u9010\u4E2A\u5B57\u7B26\u5730\u586B\u5145, \u540C\u65F6\u7A97\u53E3\u5E95\u90E8\u7684\u8FDB\u5EA6\u680F\u5C06\u663E\u793A\u52A0\u8F7D\u7684\u8FDB\u5EA6

I was asked to review SwingSet2 changes but this isn't code.
But apparently I am not the right person to review this since I cannot understand the changes (not a DE, CN, or JA language expert) nor the reason for them. If this is a change to a unicode comma (as implied in an off-review message), I have no idea why .. it seems to be just asking for trouble.

-------------

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 17:42:17 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 17:42:17 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v7]
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <joe6G_LIkLeUlpKw1IqhH00g23fEFnyi4ItJUUbQDxk=.89bfe214-866a-4e27-98eb-ba925b45dd05@github.com>

> Open l10n drop
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Revert swingset. Consistency in CN

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/35/files
  - new: https://git.openjdk.org/jdk20/pull/35/files/62a19a83..fe18e4ea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=05-06

  Stats: 7 lines in 4 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk20/pull/35.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 17:45:05 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 17:45:05 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <2YOQE1QvnJ2ntEgk3PVI_IXfwyPyZN50WAiiEf0Nub0=.ba16fa2f-799d-42b5-a0b1-4e65d99fecb7@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
 <apmyl72NuiCfwAbiJ757W8j59iQar67gH1cIVV757n8=.eeda79d2-99d1-4380-ae15-6d69e8446743@github.com>
 <ZcKFnXSYxP1CuvlfZvENNb3orDWrb4a1Jy8Zkh0KFqI=.ce653817-d7bf-4c64-b505-72a8a06ce590@github.com>
 <2YOQE1QvnJ2ntEgk3PVI_IXfwyPyZN50WAiiEf0Nub0=.ba16fa2f-799d-42b5-a0b1-4e65d99fecb7@github.com>
Message-ID: <ImfItIZ3kWNbX8DHMnA4-zo1_fkH8J_A6-1ZiRzRNR8=.fed31abb-ab70-440f-90ad-902588875929@github.com>

On Fri, 16 Dec 2022 15:02:42 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I didn't do the translation myself so I'm not sure the best approach to resolve this. I can manually replace these translations with one or the other. However, it's determine which parts of the code translate to ?????????" or "??????". I converted the unicode you highlighted above to characters, and I see where each one is located. If I just replace all instances of "??????" and insert "?????????" in unicode in its place, will it be OK?
>
> Yes, you can replace all "??????" (that is not after ""???") to "?????????".
> 
> There are also similar usages in `src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java`.

Hi @wangweij , I believe I fixed the occurrences of "??????" and replaced them with "?????????". This translation drop does not update `src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java`. So, this may be a separate request. If that file is selected for extraction in the next drop in January, then it could also be fixed then. 

Could you re-review the current changes for this drop?

-------------

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 17:51:19 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 17:51:19 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v8]
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <HHXCd5IsWRZEjWoBRIxu95AEttEQXvgPx-uzGBjHn8I=.34a5040a-1cf9-4ac2-b664-b710cab2e7cf@github.com>

> Open l10n drop
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Swingset newline

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/35/files
  - new: https://git.openjdk.org/jdk20/pull/35/files/fe18e4ea..f058a1de

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=06-07

  Stats: 3 lines in 3 files changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk20/pull/35.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 17:51:20 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 17:51:20 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <FmlUsetmec4ajWf41qIKWiV_d6svun82djbObUKfyao=.bb2b49e5-3426-4d2d-9f8c-1167d867889d@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <scvd5xE_Bjf0z8Q_DD1Ri4KSI64RhpsxuqIxdiTIbmw=.b58bccb0-64b3-4239-8f38-7a4c1804b14d@github.com>
 <FmlUsetmec4ajWf41qIKWiV_d6svun82djbObUKfyao=.bb2b49e5-3426-4d2d-9f8c-1167d867889d@github.com>
Message-ID: <Z2W3BZQLpjHfGyASnkwSyvXnU9U0eou4iovSpNWPrX8=.896c41fd-df2d-4cac-be80-7cb28c32959c@github.com>

On Fri, 16 Dec 2022 17:26:18 GMT, Phil Race <prr at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert old translation. Fix lang codes
>
> src/demo/share/jfc/SwingSet2/resources/swingset_zh_CN.properties line 430:
> 
>> 428: ProgressBarDemo.accessible_text_area_name=\u52A0\u8F7D\u7684\u6587\u672C\u6B63\u5728\u9010\u6E10\u589E\u591A
>> 429: 
>> 430: ProgressBarDemo.accessible_text_area_description=\u8FD9\u4E2A JTextArea \u7531\u6765\u81EA\u7F13\u51B2\u533A\u7684\u6587\u672C\u9010\u4E2A\u5B57\u7B26\u5730\u586B\u5145\uFF0C\u540C\u65F6\u7A97\u53E3\u5E95\u90E8\u7684\u8FDB\u5EA6\u680F\u5C06\u663E\u793A\u52A0\u8F7D\u7684\u8FDB\u5EA6
> 
> I was asked to review SwingSet2 changes but this isn't code.
> But apparently I am not the right person to review this since I cannot understand the changes (not a DE, CN, or JA language expert) nor the reason for them. If this is a change to a unicode comma (as implied in an off-review message), I have no idea why .. it seems to be just asking for trouble.

Thanks. I removed the changes to swingset's translation to avoid causing any issues.

-------------

PR: https://git.openjdk.org/jdk20/pull/35

From weijun at openjdk.org  Fri Dec 16 18:02:55 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 16 Dec 2022 18:02:55 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <ImfItIZ3kWNbX8DHMnA4-zo1_fkH8J_A6-1ZiRzRNR8=.fed31abb-ab70-440f-90ad-902588875929@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
 <apmyl72NuiCfwAbiJ757W8j59iQar67gH1cIVV757n8=.eeda79d2-99d1-4380-ae15-6d69e8446743@github.com>
 <ZcKFnXSYxP1CuvlfZvENNb3orDWrb4a1Jy8Zkh0KFqI=.ce653817-d7bf-4c64-b505-72a8a06ce590@github.com>
 <2YOQE1QvnJ2ntEgk3PVI_IXfwyPyZN50WAiiEf0Nub0=.ba16fa2f-799d-42b5-a0b1-4e65d99fecb7@github.com>
 <ImfItIZ3kWNbX8DHMnA4-zo1_fkH8J_A6-1ZiRzRNR8=.fed31abb-ab70-440f-90ad-902588875929@github.com>
Message-ID: <szezmXXF_0qzSfcp7mcIRk885jnyJf63o7prZfi2VJ8=.e6528252-60de-45c9-9bbd-0157164d890f@github.com>

On Fri, 16 Dec 2022 17:41:42 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Yes, you can replace all "??????" (that is not after ""???") to "?????????".
>> 
>> There are also similar usages in `src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java`.
>
> Hi @wangweij , I believe I fixed the occurrences of "??????" and replaced them with "?????????". This translation drop does not update `src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java`. So, this may be a separate request. If that file is selected for extraction in the next drop in January, then it could also be fixed then. 
> 
> Could you re-review the current changes for this drop?

The updated file looks fine to me. Thanks.

-------------

PR: https://git.openjdk.org/jdk20/pull/35

From asotona at openjdk.org  Fri Dec 16 18:22:24 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 16 Dec 2022 18:22:24 GMT
Subject: RFR: [DRAFT] 8294982: Implementation of Classfile API [v7]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <cCJkKGiF9YEs_DrnEKfGMl-mVqkFFg17Frvz8mg0dfg=.74f27f83-f539-41e4-9691-46c9535aa442@github.com>

> **This pull request is not intended for immediate integration to JDK mainline.**
> 
> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - removal of Preview.java and TransPatterns.java patch
   and enabled preview for java.base
 - jdk.compiler ClassWriter patch to avoid writing PREVIEW_MINOR_VERSION to classes participating in preview

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/a350f5bd..c42dc3e4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=05-06

  Stats: 31 lines in 3 files changed: 7 ins; 23 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Fri Dec 16 18:40:52 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 16 Dec 2022 18:40:52 GMT
Subject: RFR: [DRAFT] 8294982: Implementation of Classfile API [v7]
In-Reply-To: <A9kiGx0-AfBCC6IrmmwUGIxOY0EbGKu6wHCpDXQNiQE=.4b6ee2f8-affa-4f46-8713-bb1d0a125fbf@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <l5TiO65JvoxaXsg8kYAs1ugfRWjNVd_6HstdFTb2nfg=.05b28b60-3c60-4d83-a3e9-cbba6b4567d0@github.com>
 <8KVAMrO7qchZ5Cyzq-QbL4bRfKklcSjXVBzsJP-l1x0=.83786c3d-be15-4376-9cff-f2e6f0df9917@github.com>
 <1D0PTNGSVOGfVS0JBTUNc05udOIxs0UToG_8_Ubb4EU=.f3d5b9af-a5b3-47af-96e0-42df82444edc@github.com>
 <5OGC5Uv2U2YuWEueIlag1J1-sIisWbuwQnJdEGwFrRE=.098668c9-1e3a-4e79-9a3a-30d55fe7e440@github.com>
 <A9kiGx0-AfBCC6IrmmwUGIxOY0EbGKu6wHCpDXQNiQE=.4b6ee2f8-affa-4f46-8713-bb1d0a125fbf@github.com>
Message-ID: <nSj902Vgc3j2YZy9NRPI3Rei1t60OJHRRR_zHtf8ezo=.7df6d558-9e1c-47e0-92a9-4afcda625a7c@github.com>

On Mon, 7 Nov 2022 16:28:19 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> So this will be removed later on in one of the follow up "chicken" PRs?
>
> It will be removed in this PR later, this specific workaround is not intended to fall into JDK.
> The CompileInterimLangtools patch represents a way how to make the whole Classfile API and following "chickens" compilable in the current JDK.

Affected modules participate in preview and have enabled preview instead of CompileInterimLangtools.gmk patch

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From dcubed at openjdk.org  Fri Dec 16 21:14:32 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 16 Dec 2022 21:14:32 GMT
Subject: [jdk20] RFR: 8298976: ProblemList
 java/util/concurrent/ExecutorService/CloseTest.java on macosx-aarch64
Message-ID: <enzUeANxJZeER53A6OReLFDyR1NRE_xExRAkwrKR1XM=.9d9cec1c-8bb4-4270-a127-3e074a89e06f@github.com>

A batch a trivial fixes to ProblemList tests:
[JDK-8298976](https://bugs.openjdk.org/browse/JDK-8298976) ProblemList java/util/concurrent/ExecutorService/CloseTest.java on macosx-aarch64
[JDK-8298977](https://bugs.openjdk.org/browse/JDK-8298977) ProblemList vmTestbase/nsk/stress/strace/strace002.java on 2 platforms
[JDK-8298978](https://bugs.openjdk.org/browse/JDK-8298978) ProblemList vmTestbase/nsk/stress/strace/strace003.java on 2 platforms

-------------

Commit messages:
 - 8298978: ProblemList vmTestbase/nsk/stress/strace/strace003.java on 2 platforms
 - 8298977: ProblemList vmTestbase/nsk/stress/strace/strace002.java on 2 platforms
 - 8298976: ProblemList java/util/concurrent/ExecutorService/CloseTest.java on macosx-aarch64

Changes: https://git.openjdk.org/jdk20/pull/50/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=50&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298976
  Stats: 3 lines in 2 files changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk20/pull/50.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/50/head:pull/50

PR: https://git.openjdk.org/jdk20/pull/50

From dnguyen at openjdk.org  Fri Dec 16 21:18:58 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 21:18:58 GMT
Subject: [jdk20] Integrated: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <3RA_5D04t20xCtp1jJI-KMZt7Ev8f7bJv2zlanOnE-E=.d82daa27-fd0d-4eca-88cd-61ace8ba0d4a@github.com>

On Wed, 14 Dec 2022 23:40:52 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Open l10n drop
> All tests passed

This pull request has now been integrated.

Changeset: c997b5bf
Author:    Damon Nguyen <dnguyen at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/c997b5bffd0ebbd6d68332572639c8cea05ccdb1
Stats:     1128 lines in 99 files changed: 783 ins; 198 del; 147 mod

8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10

Reviewed-by: achung, naoto, joehw, cjplummer, almatvee

-------------

PR: https://git.openjdk.org/jdk20/pull/35

From kbarrett at openjdk.org  Fri Dec 16 21:21:50 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 16 Dec 2022 21:21:50 GMT
Subject: [jdk20] RFR: 8298976: ProblemList
 java/util/concurrent/ExecutorService/CloseTest.java on macosx-aarch64
In-Reply-To: <enzUeANxJZeER53A6OReLFDyR1NRE_xExRAkwrKR1XM=.9d9cec1c-8bb4-4270-a127-3e074a89e06f@github.com>
References: <enzUeANxJZeER53A6OReLFDyR1NRE_xExRAkwrKR1XM=.9d9cec1c-8bb4-4270-a127-3e074a89e06f@github.com>
Message-ID: <n3NSWmD1w7fXVtGMIz8gD5pP2qeM9GJf2ylhRjNCsxo=.8277c895-585f-4fcd-899a-f76ef84be017@github.com>

On Fri, 16 Dec 2022 21:02:21 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A batch a trivial fixes to ProblemList tests:
> [JDK-8298976](https://bugs.openjdk.org/browse/JDK-8298976) ProblemList java/util/concurrent/ExecutorService/CloseTest.java on macosx-aarch64
> [JDK-8298977](https://bugs.openjdk.org/browse/JDK-8298977) ProblemList vmTestbase/nsk/stress/strace/strace002.java on 2 platforms
> [JDK-8298978](https://bugs.openjdk.org/browse/JDK-8298978) ProblemList vmTestbase/nsk/stress/strace/strace003.java on 2 platforms

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/50

From iris at openjdk.org  Fri Dec 16 21:21:51 2022
From: iris at openjdk.org (Iris Clark)
Date: Fri, 16 Dec 2022 21:21:51 GMT
Subject: [jdk20] RFR: 8298976: ProblemList
 java/util/concurrent/ExecutorService/CloseTest.java on macosx-aarch64
In-Reply-To: <enzUeANxJZeER53A6OReLFDyR1NRE_xExRAkwrKR1XM=.9d9cec1c-8bb4-4270-a127-3e074a89e06f@github.com>
References: <enzUeANxJZeER53A6OReLFDyR1NRE_xExRAkwrKR1XM=.9d9cec1c-8bb4-4270-a127-3e074a89e06f@github.com>
Message-ID: <g6Cxym8KdHKdW3_FjxGwmjp_dSWhG4RFi8olWWpSXTc=.ece2d4c8-77b3-4b99-b9b2-fa4e4dbb4abc@github.com>

On Fri, 16 Dec 2022 21:02:21 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A batch a trivial fixes to ProblemList tests:
> [JDK-8298976](https://bugs.openjdk.org/browse/JDK-8298976) ProblemList java/util/concurrent/ExecutorService/CloseTest.java on macosx-aarch64
> [JDK-8298977](https://bugs.openjdk.org/browse/JDK-8298977) ProblemList vmTestbase/nsk/stress/strace/strace002.java on 2 platforms
> [JDK-8298978](https://bugs.openjdk.org/browse/JDK-8298978) ProblemList vmTestbase/nsk/stress/strace/strace003.java on 2 platforms

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.org/jdk20/pull/50

From dcubed at openjdk.org  Fri Dec 16 21:21:52 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 16 Dec 2022 21:21:52 GMT
Subject: [jdk20] RFR: 8298976: ProblemList
 java/util/concurrent/ExecutorService/CloseTest.java on macosx-aarch64
In-Reply-To: <n3NSWmD1w7fXVtGMIz8gD5pP2qeM9GJf2ylhRjNCsxo=.8277c895-585f-4fcd-899a-f76ef84be017@github.com>
References: <enzUeANxJZeER53A6OReLFDyR1NRE_xExRAkwrKR1XM=.9d9cec1c-8bb4-4270-a127-3e074a89e06f@github.com>
 <n3NSWmD1w7fXVtGMIz8gD5pP2qeM9GJf2ylhRjNCsxo=.8277c895-585f-4fcd-899a-f76ef84be017@github.com>
Message-ID: <PCpC3gUPzB6l9vhPkWige4seH9-uw297WA4q9OD8SQQ=.52b750b2-2f11-4012-9f27-25a6c39b6d22@github.com>

On Fri, 16 Dec 2022 21:13:56 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> A batch a trivial fixes to ProblemList tests:
>> [JDK-8298976](https://bugs.openjdk.org/browse/JDK-8298976) ProblemList java/util/concurrent/ExecutorService/CloseTest.java on macosx-aarch64
>> [JDK-8298977](https://bugs.openjdk.org/browse/JDK-8298977) ProblemList vmTestbase/nsk/stress/strace/strace002.java on 2 platforms
>> [JDK-8298978](https://bugs.openjdk.org/browse/JDK-8298978) ProblemList vmTestbase/nsk/stress/strace/strace003.java on 2 platforms
>
> Looks good.

@kimbarrett - Thanks for the fast review!

-------------

PR: https://git.openjdk.org/jdk20/pull/50

From dcubed at openjdk.org  Fri Dec 16 21:21:53 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 16 Dec 2022 21:21:53 GMT
Subject: [jdk20] Integrated: 8298976: ProblemList
 java/util/concurrent/ExecutorService/CloseTest.java on macosx-aarch64
In-Reply-To: <enzUeANxJZeER53A6OReLFDyR1NRE_xExRAkwrKR1XM=.9d9cec1c-8bb4-4270-a127-3e074a89e06f@github.com>
References: <enzUeANxJZeER53A6OReLFDyR1NRE_xExRAkwrKR1XM=.9d9cec1c-8bb4-4270-a127-3e074a89e06f@github.com>
Message-ID: <XkB8N7CZmoJ5K3SPJQU2F8ur_wALKLotUDIvpOTVr60=.217e1c38-3232-4f51-822a-1c16f8724042@github.com>

On Fri, 16 Dec 2022 21:02:21 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A batch a trivial fixes to ProblemList tests:
> [JDK-8298976](https://bugs.openjdk.org/browse/JDK-8298976) ProblemList java/util/concurrent/ExecutorService/CloseTest.java on macosx-aarch64
> [JDK-8298977](https://bugs.openjdk.org/browse/JDK-8298977) ProblemList vmTestbase/nsk/stress/strace/strace002.java on 2 platforms
> [JDK-8298978](https://bugs.openjdk.org/browse/JDK-8298978) ProblemList vmTestbase/nsk/stress/strace/strace003.java on 2 platforms

This pull request has now been integrated.

Changeset: 0ecad28d
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/0ecad28daa64ae1a0e6194e207ae57486b06e484
Stats:     3 lines in 2 files changed: 3 ins; 0 del; 0 mod

8298976: ProblemList java/util/concurrent/ExecutorService/CloseTest.java on macosx-aarch64
8298977: ProblemList vmTestbase/nsk/stress/strace/strace002.java on 2 platforms
8298978: ProblemList vmTestbase/nsk/stress/strace/strace003.java on 2 platforms

Reviewed-by: kbarrett, iris

-------------

PR: https://git.openjdk.org/jdk20/pull/50

From dcubed at openjdk.org  Fri Dec 16 21:21:53 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 16 Dec 2022 21:21:53 GMT
Subject: [jdk20] RFR: 8298976: ProblemList
 java/util/concurrent/ExecutorService/CloseTest.java on macosx-aarch64
In-Reply-To: <g6Cxym8KdHKdW3_FjxGwmjp_dSWhG4RFi8olWWpSXTc=.ece2d4c8-77b3-4b99-b9b2-fa4e4dbb4abc@github.com>
References: <enzUeANxJZeER53A6OReLFDyR1NRE_xExRAkwrKR1XM=.9d9cec1c-8bb4-4270-a127-3e074a89e06f@github.com>
 <g6Cxym8KdHKdW3_FjxGwmjp_dSWhG4RFi8olWWpSXTc=.ece2d4c8-77b3-4b99-b9b2-fa4e4dbb4abc@github.com>
Message-ID: <LofM7MjABoYeFWb923LL1k1e188oDlm9zaLqSidzPRk=.b0cc9c7f-5615-47ab-a794-7fc1e503f34d@github.com>

On Fri, 16 Dec 2022 21:16:38 GMT, Iris Clark <iris at openjdk.org> wrote:

>> A batch a trivial fixes to ProblemList tests:
>> [JDK-8298976](https://bugs.openjdk.org/browse/JDK-8298976) ProblemList java/util/concurrent/ExecutorService/CloseTest.java on macosx-aarch64
>> [JDK-8298977](https://bugs.openjdk.org/browse/JDK-8298977) ProblemList vmTestbase/nsk/stress/strace/strace002.java on 2 platforms
>> [JDK-8298978](https://bugs.openjdk.org/browse/JDK-8298978) ProblemList vmTestbase/nsk/stress/strace/strace003.java on 2 platforms
>
> Marked as reviewed by iris (Reviewer).

@irisclark - Thanks for the review! You may not be listed on the integration
depending on how the bots are running.

-------------

PR: https://git.openjdk.org/jdk20/pull/50

From sviswanathan at openjdk.org  Fri Dec 16 21:43:56 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 16 Dec 2022 21:43:56 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v13]
In-Reply-To: <pW8HHmh-dQnjrRftd052fBQVulqe_z5KldY76Hp-OmI=.a7a2b6e6-a182-45d2-bd11-16a406126482@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <pW8HHmh-dQnjrRftd052fBQVulqe_z5KldY76Hp-OmI=.a7a2b6e6-a182-45d2-bd11-16a406126482@github.com>
Message-ID: <35kCBSJh0N-kNpJyUDG7jr7p0aejbNDnVbZw6XdxZlM=.f0c1314e-707d-407f-b7bf-ea016d6800f1@github.com>

On Fri, 11 Nov 2022 13:00:06 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
>> 
>> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
>> 
>> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
>> 
>> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
>> 
>> With the most recent fixes the x64 intrinsic results on my workstation look like this:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
>> 
>> Baseline:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
>> 
>> I.e. no measurable overhead compared to baseline even for `size == 1`.
>> 
>> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
>> 
>> Benchmark for `Arrays.hashCode`:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
>> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
>> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
>> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
>> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
>> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
>> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
>> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
>> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
>> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
>> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
>> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
>> 
>> Baseline:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
>> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
>> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
>> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
>> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
>> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
>> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
>> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
>> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
>> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
>> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
>> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
>> 
>> 
>> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing & 0xff in StringLatin1::hashCode

src/java.base/share/classes/java/lang/StringUTF16.java line 418:

> 416:             return 0;
> 417:         } else {
> 418:             return ArraysSupport.vectorizedHashCode(value, ArraysSupport.UTF16);

Special case for 1 missing here.

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From ethan at mccue.dev  Fri Dec 16 23:23:46 2022
From: ethan at mccue.dev (Ethan McCue)
Date: Fri, 16 Dec 2022 18:23:46 -0500
Subject: JEP-198 - Lets start talking about JSON
In-Reply-To: <CA+NR86gtkdF6D2mCu+jzgwopsrO5kjiBereRZUBScM4bctZwrg@mail.gmail.com>
References: <CA+NR86hGVP2F948jFH3qo7fDQsc-W6HP-1YK6LVSCJTL5yQ+mA@mail.gmail.com>
 <CAK6PxWPA9hVqsczSrPFr6cdWgedhfamVJL0OE8fqZd7uA6j9qA@mail.gmail.com>
 <CAGXNUvbsRiVYEZPVy9RG7gYJm+wy0wPL3Y=6_6qqPJ6ya9SMoQ@mail.gmail.com>
 <CA+NR86ixwVNMsJPkK8LUMavPy7Wxaa=EGCrJvxaqqf7r8sG3eg@mail.gmail.com>
 <CA+NR86gtkdF6D2mCu+jzgwopsrO5kjiBereRZUBScM4bctZwrg@mail.gmail.com>
Message-ID: <CA+NR86i-m0-wq+Vdx8EXK1QLP-8eqamevCq5okz7t=j4LZswNA@mail.gmail.com>

Sidenote about "Project Galahad" - I know Graal uses json for a few things
including a reflection-config.json. Food for thought.

> the java.util.log experiment shows that trying to ?core-librarize? needs
that the community at large already fulfills with third party deps isn?t a
good move,

I, personally, do not have much historical context for java.util.log. What
feels distinct about providing a JSON api is that
logging is an implicitly global thing. If a JSON api doesn't fill all
ecosystem niches, multiple can be used alongside
each other.

> The root issue with JSON is that you just can?t tell how to interpret any
given JSON token

The point where this could be an issue is numbers. Once something is
identified as a number we can

1. Parse it immediately. Using a long and falling back to a BigInteger. For
decimals its harder to know
whether to use a double or BigDecimal internally. In the library I've been
copy pasting from to build
a prototype that last one is an explicit option and it defaults to doubles
for the whole parse.
2. Store the string and parse it upon request. We can still model it as a
Json.Number, but the
work of interpreting is deferred.

But in general, making a tree of json values doesn't particularly affect
our ability to interpret it
in a certain way. That interpretation is just positional. That's just as
true as when making assertions
in the form of class structure and field types as it is when making
assertions in the form of code.[2]

    record Thing(Instant a) {}

    // vs.

    Decoder.field(json, "a", a -> Instant.ofEpochSecond(Decoder.long_(a)))

If anything, using a named type as a lookup key for a deserialization
function is the less obvious
way to do this.

> I?m not sure how to square this circle
> I don?t like the idea of shipping a non-data-binding JSON API in the core
libs.

I think the way to cube this rhombus is to find ways to like the idea of a
non-data-binding JSON API. ?\_(?)_/?

My personal journey with that is reaching its terminus here I think.

Look on the bright side though - there are legit upsides to explicit tree
plucking!

Yeah, the friction per field is slightly higher, but the relative
friction of custom types, or multiple construction methods for a particular
type, or maintaining compatibility with
legacy representations, or even just handling a top level list of things -
its much lower.

And all that complexity - that an instant is made by looking for a long or
that it is parsed from a string in a
particular format - it lives in Java code you can see, touch, feel and
taste.

I know "nobody does this"[2] but it's not that bad, actually.

[1]: I do apologize for the code sketches consistently being "what I think
an interaction with a tree api should look like."
That is what I have been thinking about for a while so it's hard to resist.
[2]: https://youtu.be/dOgfWXw9VrI?t=1225

On Thu, Dec 15, 2022 at 6:34 PM Ethan McCue <ethan at mccue.dev> wrote:

> > are pure JSON parsers really the go-to for most people?
>
> Depends on what you mean by JSON parsers and it depends on what you mean
> by people.
>
> To the best of my knowledge, both python and Javascript do not include
> streaming, databinding, or path navigation capabilities in their json
> parsers.
>
>
> On Thu, Dec 15, 2022 at 6:26 PM Ethan McCue <ethan at mccue.dev> wrote:
>
>> > The 95%+ use case for working with JSON for your average java coder is
>> best done with data binding.
>>
>> To be brave yet controversial: I'm not sure this is neccesarily true.
>>
>> I will elaborate and respond to the other points after a hot cocoa, but
>> the last point is part of why I think that tree-crawling needs _something_
>> better as an API to fit the bill.
>>
>> With my sketch that set of requirements would be represented as
>>
>>     record Thing(
>>         List<Long> xs
>>     ) {
>>         static Thing fromJson(Json json)
>>             var defaultList = List.of(0L);
>>             return new Thing(Decoder.optionalNullableField(
>>                 json
>>                 "xs",
>>                 Decoder.oneOf(
>>                     Decoder.array(Decoder.oneOf(
>>                         x -> Long.parseLong(Decoder.string(x)),
>>                         Decoder::long
>>                     ))
>>                     Decoder.null_(defaultList),
>>                     x -> List.of(Decoder.long_(x))
>>                 ),
>>                 defaultList
>>             ));
>>         )
>>     }
>>
>> Which isn't amazing at first glance, but also
>>
>>    {}
>>    {"xs": null}
>>    {"xs": 5}
>>    {"xs": [5]}   {"xs": ["5"]}
>>    {"xs": [1, "2", "3"]}
>>
>> these are some wildly varied structures. You could make a solid argument
>> that something which silently treats these all the same is
>> a bad API for all the reasons you would consider it a good one.
>>
>> On Thu, Dec 15, 2022 at 6:18 PM Johannes Lichtenberger <
>> lichtenberger.johannes at gmail.com> wrote:
>>
>>> I'll have to read the whole thing, but are pure JSON parsers really the
>>> go-to for most people? I'm a big advocate of providing also something
>>> similar to XPath/XQuery and that's IMHO JSONiq (90% XQuery). I might be
>>> biased, of course, as I'm working on Brackit[1] in my spare time (which is
>>> also a query compiler and intended to be used with proven optimizations by
>>> document stores / JSON stores), but also can be used as an in-memory query
>>> engine.
>>>
>>> kind regards
>>> Johannes
>>>
>>> [1] https://github.com/sirixdb/brackit
>>>
>>> Am Do., 15. Dez. 2022 um 23:03 Uhr schrieb Reinier Zwitserloot <
>>> reinier at zwitserloot.com>:
>>>
>>>> A recent Advent-of-Code puzzle also made me double check the support of
>>>> JSON in the java core libs and it is indeed a curious situation that the
>>>> java core libs don?t cater to it particularly well.
>>>>
>>>> However, I?m not seeing an easy way forward to try to close this hole
>>>> in the core library offerings.
>>>>
>>>> If you need to stream huge swaths of JSON, generally there?s a clear
>>>> unit size that you can just databind. Something like:
>>>>
>>>> String jsonStr = """ { "version": 5, "data": [
>>>>   -- 1 million relatively small records in this list --
>>>>   ] } """;
>>>>
>>>>
>>>> The usual swath of JSON parsers tend to support this (giving you a
>>>> stream of java instances created by databinding those small records one by
>>>> one), or if not, the best move forward is presumably to file a pull request
>>>> with those projects; the java.util.log experiment shows that trying to
>>>> ?core-librarize? needs that the community at large already fulfills with
>>>> third party deps isn?t a good move, especially if the core library variant
>>>> tries to oversimplify to avoid the trap of being too opinionated (which
>>>> core libs shouldn?t be). In other words, the need for ?stream this JSON for
>>>> me? style APIs is even more exotic that Ethan is suggesting.
>>>>
>>>> I see a fundamental problem here:
>>>>
>>>>
>>>>    - The 95%+ use case for working with JSON for your average java
>>>>    coder is best done with data binding.
>>>>    - core libs doesn?t want to provide it, partly because it?s got a
>>>>    large design space, partly because the field?s already covered by GSON and
>>>>    Jackson-json; java.util.log proves this doesn?t work. At least, I gather
>>>>    that?s what Ethan thinks and I agree with this assessment.
>>>>    - A language that claims to be ?batteries included? that doesn?t
>>>>    ship with a JSON parser in this era is dubious, to say the least.
>>>>
>>>>
>>>> I?m not sure how to square this circle. Hence it feels like core-libs
>>>> needs to hold some more fundamental debates first:
>>>>
>>>>
>>>>    - Maybe it?s time to state in a more or less official decree that
>>>>    well-established, large design space jobs will remain the purview of
>>>>    dependencies no matter how popular it has, unless being part of the
>>>>    core-libs adds something more fundamental the third party deps cannot bring
>>>>    to the table (such as language integration), or the community standardizes
>>>>    on a single library (JSR310?s story, more or less). JSON parsing would
>>>>    qualify as ?well-established? (GSON and Jackson) and ?large design space?
>>>>    as Ethan pointed out.
>>>>    - Given that 99% of java projects, even really simple ones, start
>>>>    with maven/gradle and a list of deps, is that really a problem?
>>>>
>>>>
>>>> I?m honestly not sure what the right answer is. On one hand, the npm
>>>> ecosystem seems to be doing very well even though their ?batteries
>>>> included? situation is an utter shambles. Then again, the notion that your
>>>> average nodejs project includes 10x+ more dependencies than other languages
>>>> is likely a significant part of the security clown fiesta going on over
>>>> there as far as 3rd party deps is concerned, so by no means should java
>>>> just blindly emulate their solutions.
>>>>
>>>> I don?t like the idea of shipping a non-data-binding JSON API in the
>>>> core libs. The root issue with JSON is that you just can?t tell how to
>>>> interpret any given JSON token, because that?s not how JSON is used in
>>>> practice. What does 5 mean? Could be that I?m to take that as an int,
>>>> or as a double, or perhaps even as a j.t.Instant (epoch-millis), and
>>>> defaulting behaviour (similar to j.u.Map?s .getOrDefault is *very*
>>>> convenient to parse most JSON out there in the real world - omitting k/v
>>>> pairs whose value is still on default is very common). That?s what makes
>>>> those databind libraries so enticing: Instead of trying to pattern match my
>>>> way into this behaviour:
>>>>
>>>>
>>>>    - If the element isn?t there at all or null, give me a
>>>>    list-of-longs with a single 0 in it.
>>>>    - If the element is a number, make me a list-of-longs with 1 value
>>>>    in it, that is that number, as long.
>>>>    - If the element is a string, parse it into a long, then get me a
>>>>    list with this one long value (because IEEE double rules mean sometimes you
>>>>    have to put these things in string form or they get mangled by javascript-
>>>>    eval style parsers).
>>>>
>>>>
>>>> And yet the above is quite common, and can easily be done by a
>>>> databinder, which sees you want a List<Long> for a field whose default
>>>> value is List.of(1L), and, armed with that knowledge, can transit the
>>>> JSON into java in that way.
>>>>
>>>> You don?t *need* databinding to cater to this idea: You could for
>>>> example have a jsonNode.asLong(123) method that would parse a string
>>>> if need be, even. But this has nothing to do with pattern matching either.
>>>>
>>>>  --Reinier Zwitserloot
>>>>
>>>>
>>>> On 15 Dec 2022 at 21:30:17, Ethan McCue <ethan at mccue.dev> wrote:
>>>>
>>>>> I'm writing this to drive some forward motion and to nerd-snipe those
>>>>> who know better than I do into putting their thoughts into words.
>>>>>
>>>>> There are three ways to process JSON[1]
>>>>> - Streaming (Push or Pull)
>>>>> - Traversing a Tree (Realized or Lazy)
>>>>> - Declarative Databind (N ways)
>>>>>
>>>>> Of these, JEP-198 explicitly ruled out providing "JAXB style type safe
>>>>> data binding."
>>>>>
>>>>> No justification is given, but if I had to insert my own: mapping the
>>>>> Json model to/from the Java/JVM object model is a cursed combo of
>>>>> - Huge possible design space
>>>>> - Unpalatably large surface for backwards compatibility
>>>>> - Serialization! Boo![2]
>>>>>
>>>>> So for an artifact like the JDK, it probably doesn't make sense to
>>>>> include. That tracks.
>>>>> It won't make everyone happy, people like databind APIs, but it tracks.
>>>>>
>>>>> So for the "read flow" these are the things to figure out.
>>>>>
>>>>>                 | Should Provide? | Intended User(s) |
>>>>> ----------------+-----------------+------------------+
>>>>>  Streaming Push |                 |                  |
>>>>> ----------------+-----------------+------------------+
>>>>>  Streaming Pull |                 |                  |
>>>>> ----------------+-----------------+------------------+
>>>>>  Realized Tree  |                 |                  |
>>>>> ----------------+-----------------+------------------+
>>>>>  Lazy Tree      |                 |                  |
>>>>> ----------------+-----------------+------------------+
>>>>>
>>>>> At which point, we should talk about what "meets needs of Java
>>>>> developers using JSON" implies.
>>>>>
>>>>> JSON is ubiquitous. Most kinds of software us schmucks write could
>>>>> have a reason to interact with it.
>>>>> The full set of "user personas" therefore aren't practical for me to
>>>>> talk about.[3]
>>>>>
>>>>> JSON documents, however, are not so varied.
>>>>>
>>>>> - There are small ones (1-10kb)
>>>>> - There are medium ones (10-1000kb)
>>>>> - There are big ones (1000kb-???)
>>>>>
>>>>> - There are shallow ones
>>>>> - There are deep ones
>>>>>
>>>>> So that feels like an easier direction to talk about it from.
>>>>>
>>>>>
>>>>> This repo[4] has some convenient toy examples of how some of those
>>>>> APIs look in libraries
>>>>> in the ecosystem. Specifically the Streaming Pull and Realized Tree
>>>>> models.
>>>>>
>>>>>         User r = new User();
>>>>>         while (true) {
>>>>>             JsonToken token = reader.peek();
>>>>>             switch (token) {
>>>>>                 case BEGIN_OBJECT:
>>>>>                     reader.beginObject();
>>>>>                     break;
>>>>>                 case END_OBJECT:
>>>>>                     reader.endObject();
>>>>>                     return r;
>>>>>                 case NAME:
>>>>>                     String fieldname = reader.nextName();
>>>>>                     switch (fieldname) {
>>>>>                         case "id":
>>>>>                             r.setId(reader.nextString());
>>>>>                             break;
>>>>>                         case "index":
>>>>>                             r.setIndex(reader.nextInt());
>>>>>                             break;
>>>>>                         ...
>>>>>                         case "friends":
>>>>>                             r.setFriends(new ArrayList<>());
>>>>>                             Friend f = null;
>>>>>                             carryOn = true;
>>>>>                             while (carryOn) {
>>>>>                                 token = reader.peek();
>>>>>                                 switch (token) {
>>>>>                                     case BEGIN_ARRAY:
>>>>>                                         reader.beginArray();
>>>>>                                         break;
>>>>>                                     case END_ARRAY:
>>>>>                                         reader.endArray();
>>>>>                                         carryOn = false;
>>>>>                                         break;
>>>>>                                     case BEGIN_OBJECT:
>>>>>                                         reader.beginObject();
>>>>>                                         f = new Friend();
>>>>>                                         break;
>>>>>                                     case END_OBJECT:
>>>>>                                         reader.endObject();
>>>>>                                         r.getFriends().add(f);
>>>>>                                         break;
>>>>>                                     case NAME:
>>>>>                                         String fn = reader.nextName();
>>>>>                                         switch (fn) {
>>>>>                                             case "id":
>>>>>
>>>>> f.setId(reader.nextString());
>>>>>                                                 break;
>>>>>                                             case "name":
>>>>>
>>>>> f.setName(reader.nextString());
>>>>>                                                 break;
>>>>>                                         }
>>>>>                                         break;
>>>>>                                 }
>>>>>                             }
>>>>>                             break;
>>>>>                     }
>>>>>             }
>>>>>
>>>>> I think its not hard to argue that the streaming apis are brutalist.
>>>>> The above is Gson, but Jackson, moshi, etc
>>>>> seem at least morally equivalent.
>>>>>
>>>>> Its hard to write, hard to write *correctly*, and theres is a curious
>>>>> protensity towards pairing it
>>>>> with anemic, mutable models.
>>>>>
>>>>> That being said, it handles big documents and deep documents really
>>>>> well. It also performs
>>>>> pretty darn well and is good enough as a "fallback" when the intended
>>>>> user experience
>>>>> is through something like databind.
>>>>>
>>>>> So what could we do meaningfully better with the language we have
>>>>> today/will have tommorow?
>>>>>
>>>>> - Sealed interfaces + Pattern matching could give a nicer model for
>>>>> tokens
>>>>>
>>>>>         sealed interface JsonToken {
>>>>>             record Field(String name) implements JsonToken {}
>>>>>             record BeginArray() implements JsonToken {}
>>>>>             record EndArray() implements JsonToken {}
>>>>>             record BeginObject() implements JsonToken {}
>>>>>             record EndObject() implements JsonToken {}
>>>>>             // ...
>>>>>         }
>>>>>
>>>>>         // ...
>>>>>
>>>>>         User r = new User();
>>>>>         while (true) {
>>>>>             JsonToken token = reader.peek();
>>>>>             switch (token) {
>>>>>                 case BeginObject __:
>>>>>                     reader.beginObject();
>>>>>                     break;
>>>>>                 case EndObject __:
>>>>>                     reader.endObject();
>>>>>                     return r;
>>>>>                 case Field("id"):
>>>>>                     r.setId(reader.nextString());
>>>>>                     break;
>>>>>                 case Field("index"):
>>>>>                     r.setIndex(reader.nextInt());
>>>>>                     break;
>>>>>
>>>>>                 // ...
>>>>>
>>>>>                 case Field("friends"):
>>>>>                     r.setFriends(new ArrayList<>());
>>>>>                     Friend f = null;
>>>>>                     carryOn = true;
>>>>>                     while (carryOn) {
>>>>>                         token = reader.peek();
>>>>>                         switch (token) {
>>>>>                 // ...
>>>>>
>>>>> - Value classes can make it all more efficient
>>>>>
>>>>>         sealed interface JsonToken {
>>>>>             value record Field(String name) implements JsonToken {}
>>>>>             value record BeginArray() implements JsonToken {}
>>>>>             value record EndArray() implements JsonToken {}
>>>>>             value record BeginObject() implements JsonToken {}
>>>>>             value record EndObject() implements JsonToken {}
>>>>>             // ...
>>>>>         }
>>>>>
>>>>> - (Fun One) We can transform a simpler-to-write push parser into a
>>>>> pull parser with Coroutines
>>>>>
>>>>>     This is just a toy we could play with while making something in
>>>>> the JDK. I'm pretty sure
>>>>>     we could make a parser which feeds into something like
>>>>>
>>>>>         interface Listener {
>>>>>             void onObjectStart();
>>>>>             void onObjectEnd();
>>>>>             void onArrayStart();
>>>>>             void onArrayEnd();
>>>>>             void onField(String name);
>>>>>             // ...
>>>>>         }
>>>>>
>>>>>     and invert a loop like
>>>>>
>>>>>         while (true) {
>>>>>             char c = next();
>>>>>             switch (c) {
>>>>>                 case '{':
>>>>>                     listener.onObjectStart();
>>>>>                     // ...
>>>>>                 // ...
>>>>>             }
>>>>>         }
>>>>>
>>>>>     by putting a Coroutine.yield in the callback.
>>>>>
>>>>>     That might be a meaningful simplification in code structure, I
>>>>> don't know enough to say.
>>>>>
>>>>> But, I think there are some hard questions like
>>>>>
>>>>> - Is the intent[5] to be make backing parser for ecosystem databind
>>>>> apis?
>>>>> - Is the intent that users who want to handle big/deep documents fall
>>>>> back to this?
>>>>> - Are those new language features / conveniences enough to offset the
>>>>> cost of committing to a new api?
>>>>> - To whom exactly does a low level api provide value?
>>>>> - What benefit is standardization in the JDK?
>>>>>
>>>>> and just generally - who would be the consumer(s) of this?
>>>>>
>>>>> The other kind of API still on the table is a Tree. There are two ways
>>>>> to handle this
>>>>>
>>>>> 1. Load it into `Object`. Use a bunch of instanceof checks/casts to
>>>>> confirm what it actually is.
>>>>>
>>>>>         Object v;
>>>>>         User u = new User();
>>>>>
>>>>>         if ((v = jso.get("id")) != null) {
>>>>>             u.setId((String) v);
>>>>>         }
>>>>>         if ((v = jso.get("index")) != null) {
>>>>>             u.setIndex(((Long) v).intValue());
>>>>>         }
>>>>>         if ((v = jso.get("guid")) != null) {
>>>>>             u.setGuid((String) v);
>>>>>         }
>>>>>         if ((v = jso.get("isActive")) != null) {
>>>>>             u.setIsActive(((Boolean) v));
>>>>>         }
>>>>>         if ((v = jso.get("balance")) != null) {
>>>>>             u.setBalance((String) v);
>>>>>         }
>>>>>         // ...
>>>>>         if ((v = jso.get("latitude")) != null) {
>>>>>             u.setLatitude(v instanceof BigDecimal ? ((BigDecimal)
>>>>> v).doubleValue() : (Double) v);
>>>>>         }
>>>>>         if ((v = jso.get("longitude")) != null) {
>>>>>             u.setLongitude(v instanceof BigDecimal ? ((BigDecimal)
>>>>> v).doubleValue() : (Double) v);
>>>>>         }
>>>>>         if ((v = jso.get("greeting")) != null) {
>>>>>             u.setGreeting((String) v);
>>>>>         }
>>>>>         if ((v = jso.get("favoriteFruit")) != null) {
>>>>>             u.setFavoriteFruit((String) v);
>>>>>         }
>>>>>         if ((v = jso.get("tags")) != null) {
>>>>>             List<Object> jsonarr = (List<Object>) v;
>>>>>             u.setTags(new ArrayList<>());
>>>>>             for (Object vi : jsonarr) {
>>>>>                 u.getTags().add((String) vi);
>>>>>             }
>>>>>         }
>>>>>         if ((v = jso.get("friends")) != null) {
>>>>>             List<Object> jsonarr = (List<Object>) v;
>>>>>             u.setFriends(new ArrayList<>());
>>>>>             for (Object vi : jsonarr) {
>>>>>                 Map<String, Object> jso0 = (Map<String, Object>) vi;
>>>>>                 Friend f = new Friend();
>>>>>                 f.setId((String) jso0.get("id"));
>>>>>                 f.setName((String) jso0.get("name"));
>>>>>                 u.getFriends().add(f);
>>>>>             }
>>>>>         }
>>>>>
>>>>> 2. Have an explicit model for Json, and helper methods that do said
>>>>> casts[6]
>>>>>
>>>>>
>>>>> this.setSiteSetting(readFromJson(jsonObject.getJsonObject("site")));
>>>>> JsonArray groups = jsonObject.getJsonArray("group");
>>>>> if(groups != null)
>>>>> {
>>>>> int len = groups.size();
>>>>> for(int i=0; i<len; i++)
>>>>> {
>>>>> JsonObject grp = groups.getJsonObject(i);
>>>>> SNMPSetting grpSetting = readFromJson(grp);
>>>>> String grpName = grp.getString("dbgroup", null);
>>>>> if(grpName != null && grpSetting != null)
>>>>> this.groupSettings.put(grpName, grpSetting);
>>>>> }
>>>>> }
>>>>> JsonArray hosts = jsonObject.getJsonArray("host");
>>>>> if(hosts != null)
>>>>> {
>>>>> int len = hosts.size();
>>>>> for(int i=0; i<len; i++)
>>>>> {
>>>>> JsonObject host = hosts.getJsonObject(i);
>>>>> SNMPSetting hostSetting = readFromJson(host);
>>>>> String hostName = host.getString("dbhost", null);
>>>>> if(hostName != null && hostSetting != null)
>>>>> this.hostSettings.put(hostName, hostSetting);
>>>>> }
>>>>> }
>>>>>
>>>>> I think what has become easier to represent in the language nowadays
>>>>> is that explicit model for Json.
>>>>> Its the 101 lesson of sealed interfaces.[7] It feels nice and clean.
>>>>>
>>>>>         sealed interface Json {
>>>>>             final class Null implements Json {}
>>>>>             final class True implements Json {}
>>>>>             final class False implements Json {}
>>>>>             final class Array implements Json {}
>>>>>             final class Object implements Json {}
>>>>>             final class String implements Json {}
>>>>>             final class Number implements Json {}
>>>>>         }
>>>>>
>>>>> And the cast-and-check approach is now more viable on account of
>>>>> pattern matching.
>>>>>
>>>>>         if (jso.get("id") instanceof String v) {
>>>>>             u.setId(v);
>>>>>         }
>>>>>         if (jso.get("index") instanceof Long v) {
>>>>>             u.setIndex(v.intValue());
>>>>>         }
>>>>>         if (jso.get("guid") instanceof String v) {
>>>>>             u.setGuid(v);
>>>>>         }
>>>>>
>>>>>         // or
>>>>>
>>>>>         if (jso.get("id") instanceof String id &&
>>>>>                 jso.get("index") instanceof Long index &&
>>>>>                 jso.get("guid") instanceof String guid) {
>>>>>             return new User(id, index, guid, ...); // look ma, no
>>>>> setters!
>>>>>         }
>>>>>
>>>>>
>>>>> And on the horizon, again, is value types.
>>>>>
>>>>> But there are problems with this approach beyond the performance
>>>>> implications of loading into
>>>>> a tree.
>>>>>
>>>>> For one, all the code samples above have different behaviors around
>>>>> null keys and missing keys
>>>>> that are not obvious from first glance.
>>>>>
>>>>> This won't accept any null or missing fields
>>>>>
>>>>>         if (jso.get("id") instanceof String id &&
>>>>>                 jso.get("index") instanceof Long index &&
>>>>>                 jso.get("guid") instanceof String guid) {
>>>>>             return new User(id, index, guid, ...);
>>>>>         }
>>>>>
>>>>> This will accept individual null or missing fields, but also will
>>>>> silently ignore
>>>>> fields with incorrect types
>>>>>
>>>>>         if (jso.get("id") instanceof String v) {
>>>>>             u.setId(v);
>>>>>         }
>>>>>         if (jso.get("index") instanceof Long v) {
>>>>>             u.setIndex(v.intValue());
>>>>>         }
>>>>>         if (jso.get("guid") instanceof String v) {
>>>>>             u.setGuid(v);
>>>>>         }
>>>>>
>>>>> And, compared to databind where there is information about the
>>>>> expected structure of the document
>>>>> and its the job of the framework to assert that, I posit that the
>>>>> errors that would be encountered
>>>>> when writing code against this would be more like
>>>>>
>>>>>     "something wrong with user"
>>>>>
>>>>> than
>>>>>
>>>>>     "problem at users[5].name, expected string or null. got 5"
>>>>>
>>>>> Which feels unideal.
>>>>>
>>>>>
>>>>> One approach I find promising is something close to what Elm does with
>>>>> its decoders[8]. Not just combining assertion
>>>>> and binding like what pattern matching with records allows, but
>>>>> including a scheme for bubbling/nesting errors.
>>>>>
>>>>>     static String string(Json json) throws JsonDecodingException {
>>>>>         if (!(json instanceof Json.String jsonString)) {
>>>>>             throw JsonDecodingException.of(
>>>>>                     "expected a string",
>>>>>                     json
>>>>>             );
>>>>>         } else {
>>>>>             return jsonString.value();
>>>>>         }
>>>>>     }
>>>>>
>>>>>     static <T> T field(Json json, String fieldName, Decoder<? extends
>>>>> T> valueDecoder) throws JsonDecodingException {
>>>>>         var jsonObject = object(json);
>>>>>         var value = jsonObject.get(fieldName);
>>>>>         if (value == null) {
>>>>>             throw JsonDecodingException.atField(
>>>>>                     fieldName,
>>>>>                     JsonDecodingException.of(
>>>>>                             "no value for field",
>>>>>                             json
>>>>>                     )
>>>>>             );
>>>>>         }
>>>>>         else {
>>>>>             try {
>>>>>                 return valueDecoder.decode(value);
>>>>>             } catch (JsonDecodingException e) {
>>>>>                 throw JsonDecodingException.atField(
>>>>>                         fieldName,
>>>>>                         e
>>>>>                 );
>>>>>             }  catch (Exception e) {
>>>>>                 throw JsonDecodingException.atField(fieldName,
>>>>> JsonDecodingException.of(e, value));
>>>>>             }
>>>>>         }
>>>>>     }
>>>>>
>>>>> Which I think has some benefits over the ways I've seen of working
>>>>> with trees.
>>>>>
>>>>>
>>>>>
>>>>> - It is declarative enough that folks who prefer databind might be
>>>>> happy enough.
>>>>>
>>>>>         static User fromJson(Json json) {
>>>>>             return new User(
>>>>>                 Decoder.field(json, "id", Decoder::string),
>>>>>                 Decoder.field(json, "index", Decoder::long_),
>>>>>                 Decoder.field(json, "guid", Decoder::string),
>>>>>             );
>>>>>         }
>>>>>
>>>>>         / ...
>>>>>
>>>>>         List<User> users = Decoders.array(json, User::fromJson);
>>>>>
>>>>> - Handling null and optional fields could be less easily conflated
>>>>>
>>>>>     Decoder.field(json, "id", Decoder::string);
>>>>>
>>>>>     Decoder.nullableField(json, "id", Decoder::string);
>>>>>
>>>>>     Decoder.optionalField(json, "id", Decoder::string);
>>>>>
>>>>>     Decoder.optionalNullableField(json, "id", Decoder::string);
>>>>>
>>>>>
>>>>> - It composes well with user defined classes
>>>>>
>>>>>     record Guid(String value) {
>>>>>         Guid {
>>>>>             // some assertions on the structure of value
>>>>>         }
>>>>>     }
>>>>>
>>>>>     Decoder.string(json, "guid", guid -> new
>>>>> Guid(Decoder.string(guid)));
>>>>>
>>>>>     // or even
>>>>>
>>>>>     record Guid(String value) {
>>>>>         Guid {
>>>>>             // some assertions on the structure of value
>>>>>         }
>>>>>
>>>>>         static Guid fromJson(Json json) {
>>>>>             return new Guid(Decoder.string(guid));
>>>>>         }
>>>>>     }
>>>>>
>>>>>     Decoder.string(json, "guid", Guid::fromJson);
>>>>>
>>>>>
>>>>> - When something goes wrong, the API can handle the fiddlyness of
>>>>> capturing information for feedback.
>>>>>
>>>>>     In the code I've sketched out its just what field/index things
>>>>> went wrong at. Potentially
>>>>>     capturing metadata like row/col numbers of the source would be
>>>>> sensible too.
>>>>>
>>>>>     Its just not reasonable to expect devs to do extra work to get
>>>>> that and its really nice to give it.
>>>>>
>>>>> There are also some downsides like
>>>>>
>>>>> -  I do not know how compatible it would be with lazy trees.
>>>>>
>>>>>      Lazy trees being the only way that a tree api could handle big or
>>>>> deep documents.
>>>>>      The general concept as applied in libraries like json-tree[9] is
>>>>> to navigate without
>>>>>      doing any work, and that clashes with wanting to instanceof check
>>>>> the info at the
>>>>>      current path.
>>>>>
>>>>> - It *almost* gives enough information to be a general schema approach
>>>>>
>>>>>     If one field fails, that in the model throws an exception
>>>>> immediately. If an API should
>>>>>     return "errors": [...], that is inconvenient to construct.
>>>>>
>>>>> - None of the existing popular libraries are doing this
>>>>>
>>>>>      The only mechanics that are strictly required to give this sort
>>>>> of API is lambdas. Those have
>>>>>      been out for a decade. Yes sealed interfaces make the data model
>>>>> prettier but in concept you
>>>>>      can build the same thing on top of anything.
>>>>>
>>>>>      I could argue that this is because of "cultural momentum" of
>>>>> databind or some other reason,
>>>>>      but the fact remains that it isn't a proven out approach.
>>>>>
>>>>>      Writing Json libraries is a todo list[10]. There are a lot of bad
>>>>> ideas and this might be one of the,
>>>>>
>>>>> - Performance impact of so many instanceof checks
>>>>>
>>>>>     I've gotten a 4.2% slowdown compared to the "regular" tree code
>>>>> without the repeated casts.
>>>>>
>>>>>     But that was with a parser that is 5x slower than Jacksons. (using
>>>>> the same benchmark project as for the snippets).
>>>>>     I think there could be reason to believe that the JIT does well
>>>>> enough with repeated instanceof
>>>>>     checks to consider it.
>>>>>
>>>>>
>>>>> My current thinking is that - despite not solving for large or deep
>>>>> documents - starting with a really "dumb" realized tree api
>>>>> might be the right place to start for the read side of a potential
>>>>> incubator module.
>>>>>
>>>>> But regardless - this feels like a good time to start more concrete
>>>>> conversations. I fell I should cap this email since I've reached the point
>>>>> of decoherence and haven't even mentioned the write side of things
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> [1]: http://www.cowtowncoder.com/blog/archives/2009/01/entry_131.html
>>>>> [2]: https://security.snyk.io/vuln/maven?search=jackson-databind
>>>>> [3]: I only know like 8 people
>>>>> [4]:
>>>>> https://github.com/fabienrenaud/java-json-benchmark/blob/master/src/main/java/com/github/fabienrenaud/jjb/stream/UsersStreamDeserializer.java
>>>>> [5]: When I say "intent", I do so knowing full well no one has been
>>>>> actively thinking of this for an entire Game of Thrones
>>>>> [6]:
>>>>> https://github.com/yahoo/mysql_perf_analyzer/blob/master/myperf/src/main/java/com/yahoo/dba/perf/myperf/common/SNMPSettings.java
>>>>> [7]: https://www.infoq.com/articles/data-oriented-programming-java/
>>>>> [8]: https://package.elm-lang.org/packages/elm/json/latest/Json-Decode
>>>>> [9]: https://github.com/jbee/json-tree
>>>>> [10]: https://stackoverflow.com/a/14442630/2948173
>>>>> [11]: In 30 days JEP-198 it will be recognizably PI days old for the
>>>>> 2nd time in its history.
>>>>> [12]: To me, the fact that is still an open JEP is more a social
>>>>> convenience than anything. I could just as easily writing this exact same
>>>>> email about TOML.
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221216/5c12b8d7/attachment-0001.htm>

From sviswanathan at openjdk.org  Fri Dec 16 23:29:55 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 16 Dec 2022 23:29:55 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v13]
In-Reply-To: <pW8HHmh-dQnjrRftd052fBQVulqe_z5KldY76Hp-OmI=.a7a2b6e6-a182-45d2-bd11-16a406126482@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <pW8HHmh-dQnjrRftd052fBQVulqe_z5KldY76Hp-OmI=.a7a2b6e6-a182-45d2-bd11-16a406126482@github.com>
Message-ID: <_2HYrbXOe6zVuLXHywoy_AjCcGMYR266BcwKUZEA5fs=.1e6f7640-7580-4ff3-ace6-f18f27efbb23@github.com>

On Fri, 11 Nov 2022 13:00:06 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
>> 
>> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
>> 
>> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
>> 
>> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
>> 
>> With the most recent fixes the x64 intrinsic results on my workstation look like this:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
>> 
>> Baseline:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
>> 
>> I.e. no measurable overhead compared to baseline even for `size == 1`.
>> 
>> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
>> 
>> Benchmark for `Arrays.hashCode`:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
>> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
>> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
>> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
>> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
>> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
>> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
>> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
>> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
>> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
>> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
>> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
>> 
>> Baseline:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
>> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
>> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
>> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
>> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
>> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
>> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
>> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
>> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
>> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
>> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
>> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
>> 
>> 
>> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing & 0xff in StringLatin1::hashCode

src/hotspot/cpu/x86/stubRoutines_x86.cpp line 230:

> 228: #endif // _LP64
> 229: 
> 230: jint StubRoutines::x86::_arrays_hashcode_powers_of_31[] =

This should be declared only for LP64.

src/hotspot/cpu/x86/vm_version_x86.cpp line 1671:

> 1669:   }
> 1670:   if (UseAVX >= 2) {
> 1671:     FLAG_SET_ERGO_IF_DEFAULT(UseVectorizedHashCodeIntrinsic, true);

This could be just FLAG_SET_DEFAULT instead of FLAG_SET_ERGO_IF_DEFAULT.

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From sviswanathan at openjdk.org  Fri Dec 16 23:29:57 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 16 Dec 2022 23:29:57 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v13]
In-Reply-To: <qxFxCcOGasCUw3NBap82yIuqJi-D3p1JY7MSDjejtEU=.5ac1a504-d754-4d2b-95d3-68384834f721@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <pW8HHmh-dQnjrRftd052fBQVulqe_z5KldY76Hp-OmI=.a7a2b6e6-a182-45d2-bd11-16a406126482@github.com>
 <IEqn-D6Umb4bhYeCvw6d-riT_R7Y6aag-wdMKDHfxSM=.22808600-b52d-49ea-9a39-9f5b27fe2f24@github.com>
 <qxFxCcOGasCUw3NBap82yIuqJi-D3p1JY7MSDjejtEU=.5ac1a504-d754-4d2b-95d3-68384834f721@github.com>
Message-ID: <NxYrMWFSWyOSFsg_bt1A0Umhr-JWFMVsJMDQk7sYYb4=.d49e8812-1203-4847-9229-4cf337e49f00@github.com>

On Sun, 13 Nov 2022 20:57:44 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/hotspot/cpu/x86/x86_64.ad line 12073:
>> 
>>> 12071:                          legRegD tmp_vec13, rRegI tmp1, rRegI tmp2, rRegI tmp3, rFlagsReg cr)
>>> 12072: %{
>>> 12073:   predicate(UseAVX >= 2 && ((VectorizedHashCodeNode*)n)->mode() == VectorizedHashCodeNode::LATIN1);
>> 
>> If you represent `VectorizedHashCodeNode::mode()` as an input, it would allow to abstract over supported modes and come up with a single AD instruction. Take a look at `VectorMaskCmp` for an example (not a perfect one though since it has both _predicate member and constant input which is redundant).
>
> Thanks for the pointer, I'll check it out!

I agree with Vladimir, adding mode as another input will help. Please take a look at the RoundDoubleModeNode.

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From jcking at openjdk.org  Sat Dec 17 06:33:43 2022
From: jcking at openjdk.org (Justin King)
Date: Sat, 17 Dec 2022 06:33:43 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v9]
In-Reply-To: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
Message-ID: <kVhZQIQkiZOL00Ax_4s_Xe1uf9uDFIji6cV5IL-L8yQ=.5c70386d-bc4a-4ff6-8145-4f48d212f52e@github.com>

> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Update approach based on feedback from @magicus
  
  Signed-off-by: Justin King <jcking at google.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11604/files
  - new: https://git.openjdk.org/jdk/pull/11604/files/f4f8c093..f5dc2e69

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11604&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11604&range=07-08

  Stats: 148 lines in 6 files changed: 109 ins; 34 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/11604.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11604/head:pull/11604

PR: https://git.openjdk.org/jdk/pull/11604

From jcking at openjdk.org  Sat Dec 17 06:39:48 2022
From: jcking at openjdk.org (Justin King)
Date: Sat, 17 Dec 2022 06:39:48 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v10]
In-Reply-To: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
Message-ID: <sXqsKus-IeF9_9SWAYfuPYp6eqhcIipyX0ddU5lKahQ=.af523391-7b13-41da-abc0-1de5b0a596b9@github.com>

> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Delete unintended addition of files from previous commit
  
  Signed-off-by: Justin King <jcking at google.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11604/files
  - new: https://git.openjdk.org/jdk/pull/11604/files/f5dc2e69..fd4b9631

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11604&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11604&range=08-09

  Stats: 85 lines in 2 files changed: 0 ins; 85 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11604.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11604/head:pull/11604

PR: https://git.openjdk.org/jdk/pull/11604

From jcking at openjdk.org  Sat Dec 17 06:39:49 2022
From: jcking at openjdk.org (Justin King)
Date: Sat, 17 Dec 2022 06:39:49 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v8]
In-Reply-To: <TVgOLxtNqz5oaLxuiXMaMr3Dm47UENz1vUPqye7PKfs=.185d208c-83dc-41cb-8d9c-58e0b0bccb52@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <xy2Eago_3UXJFsvRNfJ4y3GLbfnvdSBEL8MEMLZLr44=.6fb62abf-a53b-4531-bcc6-42aaf74d030d@github.com>
 <TVgOLxtNqz5oaLxuiXMaMr3Dm47UENz1vUPqye7PKfs=.185d208c-83dc-41cb-8d9c-58e0b0bccb52@github.com>
Message-ID: <WXkK2T8fUskI10MEXVdHoNso-A_2BqOZ0t3QPSI1dp0=.9d011c99-d969-4cd9-957e-1c6927d37b22@github.com>

On Fri, 16 Dec 2022 15:56:44 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> However, I do think the included source files should be treated like the autoheaders, and reside in data rather than in `src`. The latter is intended for buildtools, even though they are a bit scattered at the moment (there is a long-standing JBS bug about fixing that), and these are not really intended to be compiled into a product by itself, rather as something "injected" into all builds. I'd recommend `make/data/ubsan`, and perhaps skip the leading `__`.

Moved to the directory suggested.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From jcking at openjdk.org  Sat Dec 17 06:39:51 2022
From: jcking at openjdk.org (Justin King)
Date: Sat, 17 Dec 2022 06:39:51 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v9]
In-Reply-To: <kVhZQIQkiZOL00Ax_4s_Xe1uf9uDFIji6cV5IL-L8yQ=.5c70386d-bc4a-4ff6-8145-4f48d212f52e@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <kVhZQIQkiZOL00Ax_4s_Xe1uf9uDFIji6cV5IL-L8yQ=.5c70386d-bc4a-4ff6-8145-4f48d212f52e@github.com>
Message-ID: <HylEbeSb6maHL61t8YGJ3-pxH2p6Izg-ZKd1vHXu1GU=.af96aef6-3946-43ee-81cd-c89cf2fc2be5@github.com>

On Sat, 17 Dec 2022 06:33:43 GMT, Justin King <jcking at openjdk.org> wrote:

>> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update approach based on feedback from @magicus
>   
>   Signed-off-by: Justin King <jcking at google.com>

> I much also check: is this really needed for _all_ executables we make? I would have guessed that it would suffice with the "launchers", i.e. like `java`, `javac`, `jar` etc. These are all compiled from a single source file, `src/java.base/share/native/launcher/main.c`, with different defines depending on what Java classes it should actually launch, and with different output names.
> 
> Doing things this way will also affect non-launcher executables, like `jabswitch`, `msiwrapper` and all executable test binaries.
> 
> That might be correct, but I could not be certain of that from trying to read the backlog of discussion in this bug.

For UBSan, the inclusion in every executable is intentional. For upcoming LSan/ASan stuff, it will be just for launchers. The reason is that UBSan is relaxed by default and won't terminate upon undefined behavior. LSan/ASan are strict by default, and for LSan to work we need to disable some things only when the JVM is being used. So for this commit all executables is correct. For ASan/LSan as you suggest only launchers will have them in that case.

-------------

PR: https://git.openjdk.org/jdk/pull/11604

From alanb at openjdk.org  Sat Dec 17 08:07:49 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 17 Dec 2022 08:07:49 GMT
Subject: [jdk20] RFR: 8298976: ProblemList
 java/util/concurrent/ExecutorService/CloseTest.java on macosx-aarch64
In-Reply-To: <enzUeANxJZeER53A6OReLFDyR1NRE_xExRAkwrKR1XM=.9d9cec1c-8bb4-4270-a127-3e074a89e06f@github.com>
References: <enzUeANxJZeER53A6OReLFDyR1NRE_xExRAkwrKR1XM=.9d9cec1c-8bb4-4270-a127-3e074a89e06f@github.com>
Message-ID: <jYzaPW95Ek_CJ7_0Dz7QkzsSMxx1QOIAFn89LFnnCQk=.92a071df-4749-4788-8da2-9a40df88294c@github.com>

On Fri, 16 Dec 2022 21:02:21 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A batch a trivial fixes to ProblemList tests:
> [JDK-8298976](https://bugs.openjdk.org/browse/JDK-8298976) ProblemList java/util/concurrent/ExecutorService/CloseTest.java on macosx-aarch64
> [JDK-8298977](https://bugs.openjdk.org/browse/JDK-8298977) ProblemList vmTestbase/nsk/stress/strace/strace002.java on 2 platforms
> [JDK-8298978](https://bugs.openjdk.org/browse/JDK-8298978) ProblemList vmTestbase/nsk/stress/strace/strace003.java on 2 platforms

Instead of excluding java/util/concurrent/ExecutorService/CloseTest.java, we can just comment out the line in the test's DataProvider that produces a ForkJoinPool. That will allow the t test to exercise the other implementations until ForkJoinPool shutdown issue is fixed.

-------------

PR: https://git.openjdk.org/jdk20/pull/50

From dcubed at openjdk.org  Sat Dec 17 13:53:49 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Sat, 17 Dec 2022 13:53:49 GMT
Subject: [jdk20] RFR: 8298976: ProblemList
 java/util/concurrent/ExecutorService/CloseTest.java on macosx-aarch64
In-Reply-To: <jYzaPW95Ek_CJ7_0Dz7QkzsSMxx1QOIAFn89LFnnCQk=.92a071df-4749-4788-8da2-9a40df88294c@github.com>
References: <enzUeANxJZeER53A6OReLFDyR1NRE_xExRAkwrKR1XM=.9d9cec1c-8bb4-4270-a127-3e074a89e06f@github.com>
 <jYzaPW95Ek_CJ7_0Dz7QkzsSMxx1QOIAFn89LFnnCQk=.92a071df-4749-4788-8da2-9a40df88294c@github.com>
Message-ID: <93A0WGOAL6fxd_sdWdN_-DBq8V50UdmbA69cBS_avdM=.b2447e4f-f224-48fa-bd66-66d147298fc5@github.com>

On Sat, 17 Dec 2022 08:05:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> A batch a trivial fixes to ProblemList tests:
>> [JDK-8298976](https://bugs.openjdk.org/browse/JDK-8298976) ProblemList java/util/concurrent/ExecutorService/CloseTest.java on macosx-aarch64
>> [JDK-8298977](https://bugs.openjdk.org/browse/JDK-8298977) ProblemList vmTestbase/nsk/stress/strace/strace002.java on 2 platforms
>> [JDK-8298978](https://bugs.openjdk.org/browse/JDK-8298978) ProblemList vmTestbase/nsk/stress/strace/strace003.java on 2 platforms
>
> Instead of excluding java/util/concurrent/ExecutorService/CloseTest.java, we can just comment out the line in the test's DataProvider that produces a ForkJoinPool. That will allow the t test to exercise the other implementations until ForkJoinPool shutdown issue is fixed.

@AlanBateman - It's only ProblemListed on one platform...

-------------

PR: https://git.openjdk.org/jdk20/pull/50

From dcubed at openjdk.org  Sat Dec 17 16:16:35 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Sat, 17 Dec 2022 16:16:35 GMT
Subject: [jdk20] Integrated: 8298987: ProblemList
 jdk/internal/vm/Continuation/Fuzz.java#default with ZGC on X64
Message-ID: <u595Bk9cJtsW25vULHfa7XXI8yebINc35vTPWo6Pc_s=.4f8877ac-5a27-4d70-9ef6-5a5b26ee2523@github.com>

A batch of trivial fixes to ProblemList tests:
[JDK-8298987](https://bugs.openjdk.org/browse/JDK-8298987) ProblemList jdk/internal/vm/Continuation/Fuzz.java#default with ZGC on X64
[JDK-8298989](https://bugs.openjdk.org/browse/JDK-8298989) ProblemList vmTestbase/nsk/jvmti/InterruptThread/intrpthrd003/TestDescription.java on macosx-x64
[JDK-8298990](https://bugs.openjdk.org/browse/JDK-8298990) ProblemList java/lang/Thread/virtual/stress/Skynet.java subtests with ZGC

-------------

Commit messages:
 - 8298990: ProblemList java/lang/Thread/virtual/stress/Skynet.java subtests with ZGC
 - 8298989: ProblemList vmTestbase/nsk/jvmti/InterruptThread/intrpthrd003/TestDescription.java on macosx-x64
 - 8298987: ProblemList jdk/internal/vm/Continuation/Fuzz.java#default with ZGC on X64

Changes: https://git.openjdk.org/jdk20/pull/51/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=51&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298987
  Stats: 5 lines in 2 files changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk20/pull/51.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/51/head:pull/51

PR: https://git.openjdk.org/jdk20/pull/51

From dcubed at openjdk.org  Sat Dec 17 16:16:37 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Sat, 17 Dec 2022 16:16:37 GMT
Subject: [jdk20] Integrated: 8298987: ProblemList
 jdk/internal/vm/Continuation/Fuzz.java#default with ZGC on X64
In-Reply-To: <ie9GHM460hdvXGPbdnh_vShvOUN2x0ptc6HxC8OJeak=.c7dfa1e2-c9fb-46d1-99a9-925bc0a10fd4@github.com>
References: <u595Bk9cJtsW25vULHfa7XXI8yebINc35vTPWo6Pc_s=.4f8877ac-5a27-4d70-9ef6-5a5b26ee2523@github.com>
 <ie9GHM460hdvXGPbdnh_vShvOUN2x0ptc6HxC8OJeak=.c7dfa1e2-c9fb-46d1-99a9-925bc0a10fd4@github.com>
Message-ID: <nWv4i3tMACcGJ2FQxl1BX3ErEnOSqKIk9EnOTTPV4kM=.45d48705-1f8e-4270-a37a-c1e7ed8389cf@github.com>

On Sat, 17 Dec 2022 16:05:24 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> A batch of trivial fixes to ProblemList tests:
>> [JDK-8298987](https://bugs.openjdk.org/browse/JDK-8298987) ProblemList jdk/internal/vm/Continuation/Fuzz.java#default with ZGC on X64
>> [JDK-8298989](https://bugs.openjdk.org/browse/JDK-8298989) ProblemList vmTestbase/nsk/jvmti/InterruptThread/intrpthrd003/TestDescription.java on macosx-x64
>> [JDK-8298990](https://bugs.openjdk.org/browse/JDK-8298990) ProblemList java/lang/Thread/virtual/stress/Skynet.java subtests with ZGC
>
> Marked as reviewed by azvegint (Reviewer).

@azvegint - Thanks for the lightning fast review! Especially for a Saturday AM!

-------------

PR: https://git.openjdk.org/jdk20/pull/51

From azvegint at openjdk.org  Sat Dec 17 16:16:36 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Sat, 17 Dec 2022 16:16:36 GMT
Subject: [jdk20] Integrated: 8298987: ProblemList
 jdk/internal/vm/Continuation/Fuzz.java#default with ZGC on X64
In-Reply-To: <u595Bk9cJtsW25vULHfa7XXI8yebINc35vTPWo6Pc_s=.4f8877ac-5a27-4d70-9ef6-5a5b26ee2523@github.com>
References: <u595Bk9cJtsW25vULHfa7XXI8yebINc35vTPWo6Pc_s=.4f8877ac-5a27-4d70-9ef6-5a5b26ee2523@github.com>
Message-ID: <ie9GHM460hdvXGPbdnh_vShvOUN2x0ptc6HxC8OJeak=.c7dfa1e2-c9fb-46d1-99a9-925bc0a10fd4@github.com>

On Sat, 17 Dec 2022 16:00:32 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A batch of trivial fixes to ProblemList tests:
> [JDK-8298987](https://bugs.openjdk.org/browse/JDK-8298987) ProblemList jdk/internal/vm/Continuation/Fuzz.java#default with ZGC on X64
> [JDK-8298989](https://bugs.openjdk.org/browse/JDK-8298989) ProblemList vmTestbase/nsk/jvmti/InterruptThread/intrpthrd003/TestDescription.java on macosx-x64
> [JDK-8298990](https://bugs.openjdk.org/browse/JDK-8298990) ProblemList java/lang/Thread/virtual/stress/Skynet.java subtests with ZGC

Marked as reviewed by azvegint (Reviewer).

-------------

PR: https://git.openjdk.org/jdk20/pull/51

From dcubed at openjdk.org  Sat Dec 17 16:16:37 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Sat, 17 Dec 2022 16:16:37 GMT
Subject: [jdk20] Integrated: 8298987: ProblemList
 jdk/internal/vm/Continuation/Fuzz.java#default with ZGC on X64
In-Reply-To: <u595Bk9cJtsW25vULHfa7XXI8yebINc35vTPWo6Pc_s=.4f8877ac-5a27-4d70-9ef6-5a5b26ee2523@github.com>
References: <u595Bk9cJtsW25vULHfa7XXI8yebINc35vTPWo6Pc_s=.4f8877ac-5a27-4d70-9ef6-5a5b26ee2523@github.com>
Message-ID: <TLVtonHxh1SKMoK8GB93JESyBR5ITV3DMc8jx18RM1A=.312fa9cc-1253-4f34-9cf2-c12206e66598@github.com>

On Sat, 17 Dec 2022 16:00:32 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A batch of trivial fixes to ProblemList tests:
> [JDK-8298987](https://bugs.openjdk.org/browse/JDK-8298987) ProblemList jdk/internal/vm/Continuation/Fuzz.java#default with ZGC on X64
> [JDK-8298989](https://bugs.openjdk.org/browse/JDK-8298989) ProblemList vmTestbase/nsk/jvmti/InterruptThread/intrpthrd003/TestDescription.java on macosx-x64
> [JDK-8298990](https://bugs.openjdk.org/browse/JDK-8298990) ProblemList java/lang/Thread/virtual/stress/Skynet.java subtests with ZGC

This pull request has now been integrated.

Changeset: 34105556
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/34105556d16774439195076f22f37f275d0d8873
Stats:     5 lines in 2 files changed: 5 ins; 0 del; 0 mod

8298987: ProblemList jdk/internal/vm/Continuation/Fuzz.java#default with ZGC on X64
8298989: ProblemList vmTestbase/nsk/jvmti/InterruptThread/intrpthrd003/TestDescription.java on macosx-x64
8298990: ProblemList java/lang/Thread/virtual/stress/Skynet.java subtests with ZGC

Reviewed-by: azvegint

-------------

PR: https://git.openjdk.org/jdk20/pull/51

From duke at openjdk.org  Sat Dec 17 18:21:51 2022
From: duke at openjdk.org (Chris Hennick)
Date: Sat, 17 Dec 2022 18:21:51 GMT
Subject: RFR: 8284493: Improve computeNextExponential tail performance and
 accuracy [v16]
In-Reply-To: <Lq6DFTk0jdokOkfvKqWoBhtpYgEGpNfKOw5epx46h-4=.e660db98-33ab-4261-b3f2-a0ff22171539@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
 <GKQOg02og11alcCgOGPGZ2wn41zf6g5RylUm74Glr_k=.e5ad1226-a6ee-412f-8508-08946ef11eae@github.com>
 <wbFmoH5Ezcp66xSmyKmfG2kyYL2RIJTxGcLY06MalUc=.257566db-d246-4211-8422-2638768d5943@github.com>
 <Lq6DFTk0jdokOkfvKqWoBhtpYgEGpNfKOw5epx46h-4=.e660db98-33ab-4261-b3f2-a0ff22171539@github.com>
Message-ID: <5h1dP3QyVEZRXiwtUf7ejhERWbU1Qo1GE5DCyyDwXeA=.293d5cea-4442-47af-a45a-3a92eceb37ce@github.com>

On Wed, 7 Dec 2022 20:25:53 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> It's probably just a statistical fluke involving a very large return value, but to know for sure I'd need a way to gather statistics about the return values and how they correlate with running-time outliers.
>
>> It's probably just a statistical fluke involving a very large return value, but to know for sure I'd need a way to gather statistics about the return values and how they correlate with running-time outliers.
> 
> Yeah, it's likely that p100 data are outliers. I think average and p50 data make more sense. 
> I am not a reviewer and lack domain-specific knowledge in the algorithm. I check your code and it seems reasonable. We need reviewers to look into it.

@navyxliu p50 isn't meaningful, because this change doesn't make a difference in the ~98% of cases where only the lookup table is used. It only affects the tails.

-------------

PR: https://git.openjdk.org/jdk/pull/8131

From pminborg at openjdk.org  Sun Dec 18 20:28:57 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Sun, 18 Dec 2022 20:28:57 GMT
Subject: Integrated: 8298639: Perform I/O operations in bulk for
 RandomAccessFile
In-Reply-To: <CSr3MHVxoI_YzG4NXS5apLiU3VTDavZh7URxs52x9wc=.c508ecdd-dae5-4ce6-9573-7786301bcd4b@github.com>
References: <CSr3MHVxoI_YzG4NXS5apLiU3VTDavZh7URxs52x9wc=.c508ecdd-dae5-4ce6-9573-7786301bcd4b@github.com>
Message-ID: <Tn2tcuro_RMNPOXc_SNwuj4ICxqGfdmAAzWcnkaLqx0=.bf6d7b23-a4d9-491a-9af0-d2a54deb415a@github.com>

On Tue, 13 Dec 2022 09:11:10 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests improving performance for read and write operations for the longer primitives in `RandomAccessFile`.
> 
> These improvements would also propagate to other JDK classes relying on these improved `RandomAccessFile` operations.

This pull request has now been integrated.

Changeset: 7938f8c3
Author:    Per Minborg <pminborg at openjdk.org>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7938f8c32a1c0ecdd3bcc8cd1a2652df248a2213
Stats:     196 lines in 3 files changed: 139 ins; 37 del; 20 mod

8298639: Perform I/O operations in bulk for RandomAccessFile

Co-authored-by: Sergey Tsypanov <stsypanov at openjdk.org>
Reviewed-by: alanb, bpb

-------------

PR: https://git.openjdk.org/jdk/pull/11644

From alanb at openjdk.org  Mon Dec 19 07:52:18 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 19 Dec 2022 07:52:18 GMT
Subject: RFR: 8298875: A module requiring "java.base" with flags ACC_SYNTHETIC
 should be rejected
Message-ID: <hFS1P8AQtGocnj-mPM7ShSKel9iLl7xxMwIjlmwCXqA=.f7b7da46-1df4-4706-9ee8-47ba200fac9d@github.com>

A small oversight with ModuleDescriptor.read when checking the requires table of a Module attribute. The requires entry for java.base should not have ACC_SYNTHETIC set.

A new test is added. Some of the existing tests used `@Test(expectedExceptions=...)`. I've changed some of these to use assertThrows to narrow it down to method that is expected to throw.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/11714/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11714&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298875
  Stats: 75 lines in 2 files changed: 34 ins; 17 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/11714.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11714/head:pull/11714

PR: https://git.openjdk.org/jdk/pull/11714

From alanb at openjdk.org  Mon Dec 19 15:57:00 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 19 Dec 2022 15:57:00 GMT
Subject: [jdk20] RFR: 8298894: java/lang/Thread/virtual/stress/Skynet.java
 timed out and threw OutOfMemoryError
Message-ID: <gu0fiGe-HC99vWTiwvLrwwQU15k49l4DzRKvBDggBoI=.8bdabfb1-18de-4554-b1bf-53d8d6687c5e@github.com>

This test started timing out recently on macosx-x64 when testing debug builds with ZGC. The test needs more heap so that it doesn't fail with OOME.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk20/pull/54/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=54&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298894
  Stats: 4 lines in 2 files changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk20/pull/54.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/54/head:pull/54

PR: https://git.openjdk.org/jdk20/pull/54

From eosterlund at openjdk.org  Mon Dec 19 16:21:55 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 19 Dec 2022 16:21:55 GMT
Subject: [jdk20] RFR: 8298894: java/lang/Thread/virtual/stress/Skynet.java
 timed out and threw OutOfMemoryError
In-Reply-To: <gu0fiGe-HC99vWTiwvLrwwQU15k49l4DzRKvBDggBoI=.8bdabfb1-18de-4554-b1bf-53d8d6687c5e@github.com>
References: <gu0fiGe-HC99vWTiwvLrwwQU15k49l4DzRKvBDggBoI=.8bdabfb1-18de-4554-b1bf-53d8d6687c5e@github.com>
Message-ID: <GnTV1WPf3LzH4hzD9k_d_L6NL5GdlyV2TZtEs44uFy8=.e848830b-3c73-4b2d-9e23-6c87ce0deae8@github.com>

On Mon, 19 Dec 2022 14:24:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This test started timing out recently on macosx-x64 when testing debug builds with ZGC. The test needs more heap so that it doesn't fail with OOME.

Looks good.

-------------

Marked as reviewed by eosterlund (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/54

From hannesw at openjdk.org  Mon Dec 19 16:35:32 2022
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 19 Dec 2022 16:35:32 GMT
Subject: [jdk20] RFR: JDK-8277074: Qualified exported types show up in JavaDoc
Message-ID: <6mDlss6DZr5nYR9EgFeDBkVZ4ky3IGvePyNNRy49prM=.eff849fc-b9e9-4d04-8217-4bdda3c14cd1@github.com>

This `noreg-doc` PR has been moved over from the mainline repository, the original PR is openjdk/jdk#11163. 

The purpose is to hide internal classes in generated documentation by adding doc comments containing a @hidden tag. I verified the fix by making sure the internal vector and event classes no longer show up in the generated documentation tree.

-------------

Commit messages:
 - JDK-8277074: Qualified exported types show up in JavaDoc

Changes: https://git.openjdk.org/jdk20/pull/56/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=56&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8277074
  Stats: 14 lines in 2 files changed: 14 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk20/pull/56.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/56/head:pull/56

PR: https://git.openjdk.org/jdk20/pull/56

From asotona at openjdk.org  Mon Dec 19 16:48:51 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 19 Dec 2022 16:48:51 GMT
Subject: RFR: [DRAFT] 8294982: Implementation of Classfile API [v7]
In-Reply-To: <cCJkKGiF9YEs_DrnEKfGMl-mVqkFFg17Frvz8mg0dfg=.74f27f83-f539-41e4-9691-46c9535aa442@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <cCJkKGiF9YEs_DrnEKfGMl-mVqkFFg17Frvz8mg0dfg=.74f27f83-f539-41e4-9691-46c9535aa442@github.com>
Message-ID: <AyQlva9D7F6CKLKlFt20BpsE_9qooItruqdxFvMNIMY=.db1a1e45-61ca-4956-9f30-b81628f12c49@github.com>

On Fri, 16 Dec 2022 18:22:24 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> **This pull request is not intended for immediate integration to JDK mainline.**
>> 
>> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
>> 
>> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
>> 
>> Classfile API development is tracked at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
>> 
>> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
>> 
>> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/classfile/package-summary.html) is also available.
>> 
>> Please take you time to review this non-trivial JDK addition.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - removal of Preview.java and TransPatterns.java patch
>    and enabled preview for java.base
>  - jdk.compiler ClassWriter patch to avoid writing PREVIEW_MINOR_VERSION to classes participating in preview

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java line 1641:

> 1639:         if (preview.isEnabled() && preview.usesPreview(c.sourcefile)
> 1640:                 // do not write PREVIEW_MINOR_VERSION for classes participating in preview
> 1641:                 && !preview.participatesInPreview(syms, c, syms.java_base.unnamedPackage)) {

javac ClassWriter patch to do not write PREVIEW_MINOR_VERSION for classes participating in preview

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From alanb at openjdk.org  Mon Dec 19 18:07:04 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 19 Dec 2022 18:07:04 GMT
Subject: [jdk20] RFR: 8298894: java/lang/Thread/virtual/stress/Skynet.java
 timed out and threw OutOfMemoryError
In-Reply-To: <gu0fiGe-HC99vWTiwvLrwwQU15k49l4DzRKvBDggBoI=.8bdabfb1-18de-4554-b1bf-53d8d6687c5e@github.com>
References: <gu0fiGe-HC99vWTiwvLrwwQU15k49l4DzRKvBDggBoI=.8bdabfb1-18de-4554-b1bf-53d8d6687c5e@github.com>
Message-ID: <Zd8R8jMvwDWCZyVH5laG0QiOOb6INUBgeJtDlrEE2-E=.2af4523a-34a6-4e66-9930-73ef7b6a260e@github.com>

On Mon, 19 Dec 2022 14:24:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This test started timing out recently on macosx-x64 when testing debug builds with ZGC. The test needs more heap so that it doesn't fail with OOME.

Thanks Erik.

-------------

PR: https://git.openjdk.org/jdk20/pull/54

From psandoz at openjdk.org  Mon Dec 19 18:08:50 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 19 Dec 2022 18:08:50 GMT
Subject: [jdk20] RFR: JDK-8277074: Qualified exported types show up in
 JavaDoc
In-Reply-To: <6mDlss6DZr5nYR9EgFeDBkVZ4ky3IGvePyNNRy49prM=.eff849fc-b9e9-4d04-8217-4bdda3c14cd1@github.com>
References: <6mDlss6DZr5nYR9EgFeDBkVZ4ky3IGvePyNNRy49prM=.eff849fc-b9e9-4d04-8217-4bdda3c14cd1@github.com>
Message-ID: <2XGIFQRDGs9sinEkshXPKrbqnUcvMoubo9hu1WRKazs=.4670995a-76fe-4d51-ad4d-029986107d2d@github.com>

On Mon, 19 Dec 2022 16:28:17 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> This `noreg-doc` PR has been moved over from the mainline repository, the original PR is openjdk/jdk#11163. 
> 
> The purpose is to hide internal classes in generated documentation by adding doc comments containing a @hidden tag. I verified the fix by making sure the internal vector and event classes no longer show up in the generated documentation tree.

Marked as reviewed by psandoz (Reviewer).

-------------

PR: https://git.openjdk.org/jdk20/pull/56

From alanb at openjdk.org  Mon Dec 19 18:09:55 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 19 Dec 2022 18:09:55 GMT
Subject: [jdk20] Integrated: 8298894:
 java/lang/Thread/virtual/stress/Skynet.java timed out and threw
 OutOfMemoryError
In-Reply-To: <gu0fiGe-HC99vWTiwvLrwwQU15k49l4DzRKvBDggBoI=.8bdabfb1-18de-4554-b1bf-53d8d6687c5e@github.com>
References: <gu0fiGe-HC99vWTiwvLrwwQU15k49l4DzRKvBDggBoI=.8bdabfb1-18de-4554-b1bf-53d8d6687c5e@github.com>
Message-ID: <yG6vMG7AGpmBRDC9m8HMBtdrfWJN8gFt1nVGdPf5-zI=.88a63bc4-a18e-4566-a5d1-04e71fc5ad75@github.com>

On Mon, 19 Dec 2022 14:24:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This test started timing out recently on macosx-x64 when testing debug builds with ZGC. The test needs more heap so that it doesn't fail with OOME.

This pull request has now been integrated.

Changeset: 2c69c41d
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/2c69c41d48fddcbeb40a374f691b7e5faba3c99a
Stats:     4 lines in 2 files changed: 0 ins; 2 del; 2 mod

8298894: java/lang/Thread/virtual/stress/Skynet.java timed out and threw OutOfMemoryError

Reviewed-by: eosterlund

-------------

PR: https://git.openjdk.org/jdk20/pull/54

From duke at openjdk.org  Mon Dec 19 18:27:07 2022
From: duke at openjdk.org (iaroslavski)
Date: Mon, 19 Dec 2022 18:27:07 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v18]
In-Reply-To: <v1aeO-1p-DSSHsJGRrHYRRFDggX3Q65HAtrHaRd9hEo=.1dd0c76b-ea4f-47f6-8454-dc8ed96fd2cd@github.com>
References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
 <v1aeO-1p-DSSHsJGRrHYRRFDggX3Q65HAtrHaRd9hEo=.1dd0c76b-ea4f-47f6-8454-dc8ed96fd2cd@github.com>
Message-ID: <PnP-YpE-XIBEqWKg3nu4jzOgsOx_AoWvFCtfdU0oHBg=.105cb7b0-70f0-4c67-8157-ffb40e767fe1@github.com>

On Wed, 9 Nov 2022 21:06:50 GMT, iaroslavski <duke at openjdk.org> wrote:

>> Sorting:
>> 
>> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K)
>> - fix tryMergeRuns() to better handle case when the last run is a single element
>> - minor javadoc and comment changes
>> 
>> Testing:
>> - add new data inputs in tests for sorting
>> - add min/max/infinity values to float/double testing
>> - add tests for radix sort
>
> iaroslavski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
>   
>   * Fixed microbenchmarking tests

This PR will be moved to the new one.

-------------

PR: https://git.openjdk.org/jdk/pull/3938

From hannesw at openjdk.org  Mon Dec 19 19:17:00 2022
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 19 Dec 2022 19:17:00 GMT
Subject: [jdk20] Integrated: JDK-8277074: Qualified exported types show up in
 JavaDoc
In-Reply-To: <6mDlss6DZr5nYR9EgFeDBkVZ4ky3IGvePyNNRy49prM=.eff849fc-b9e9-4d04-8217-4bdda3c14cd1@github.com>
References: <6mDlss6DZr5nYR9EgFeDBkVZ4ky3IGvePyNNRy49prM=.eff849fc-b9e9-4d04-8217-4bdda3c14cd1@github.com>
Message-ID: <BxAPhsv_px0krVe78fiSt0iYpONRKE6rcEyHyNe_Dog=.418797e3-d202-488b-9c76-16499848396a@github.com>

On Mon, 19 Dec 2022 16:28:17 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> This `noreg-doc` PR has been moved over from the mainline repository, the original PR is openjdk/jdk#11163. 
> 
> The purpose is to hide internal classes in generated documentation by adding doc comments containing a @hidden tag. I verified the fix by making sure the internal vector and event classes no longer show up in the generated documentation tree.

This pull request has now been integrated.

Changeset: 188aaef3
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/188aaef38594658288e9222ed815d5af4b8d3dad
Stats:     14 lines in 2 files changed: 14 ins; 0 del; 0 mod

8277074: Qualified exported types show up in JavaDoc

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.org/jdk20/pull/56

From rriggs at openjdk.org  Mon Dec 19 20:18:28 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 19 Dec 2022 20:18:28 GMT
Subject: [jdk20] RFR: 4958969: ObjectOutputStream example leads to non-working
 code
Message-ID: <T1B5skiWk5tg__V5hjIagupcwmdmQXRnK4QPzZfPL8I=.86a0005f-8bcc-46c4-abca-031c43ea0e4e@github.com>

Update javadoc examples to use try-with-resources and use javadoc snippet tags.
The examples in ObjectInputStream and ObjectOutputStream get an update with
try-with-resources and use of javadoc snippet tags.
ObjectInputFilter is updated with use of snippet tags instead of html markup.

-------------

Commit messages:
 - 4958969: ObjectOutputStream example leads to non-working code

Changes: https://git.openjdk.org/jdk20/pull/59/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=59&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-4958969
  Stats: 61 lines in 3 files changed: 1 ins; 3 del; 57 mod
  Patch: https://git.openjdk.org/jdk20/pull/59.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/59/head:pull/59

PR: https://git.openjdk.org/jdk20/pull/59

From lancea at openjdk.org  Mon Dec 19 20:25:51 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 19 Dec 2022 20:25:51 GMT
Subject: [jdk20] RFR: 4958969: ObjectOutputStream example leads to
 non-working code
In-Reply-To: <T1B5skiWk5tg__V5hjIagupcwmdmQXRnK4QPzZfPL8I=.86a0005f-8bcc-46c4-abca-031c43ea0e4e@github.com>
References: <T1B5skiWk5tg__V5hjIagupcwmdmQXRnK4QPzZfPL8I=.86a0005f-8bcc-46c4-abca-031c43ea0e4e@github.com>
Message-ID: <WpEds9VHiqG2kYCoLEz15T7qQE91qtE7Z1XgHBDADTI=.af2361e8-0b41-4c36-99eb-d1a52db7dda9@github.com>

On Mon, 19 Dec 2022 20:12:15 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Update javadoc examples to use try-with-resources and use javadoc snippet tags.
> The examples in ObjectInputStream and ObjectOutputStream get an update with
> try-with-resources and use of javadoc snippet tags.
> ObjectInputFilter is updated with use of snippet tags instead of html markup.

Looks good Roger,  one trivial suggestion to consider below

src/java.base/share/classes/java/io/ObjectInputStream.java line 126:

> 124:  *         String label = (String) ois.readObject();
> 125:  *         LocalDateTime date = (LocalDateTime) ois.readObject();
> 126:  *         System.out.println(label + ": " + date);

would it be worth using `System.out.printf` here?

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/59

From rriggs at openjdk.org  Mon Dec 19 20:33:51 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 19 Dec 2022 20:33:51 GMT
Subject: [jdk20] RFR: 4958969: ObjectOutputStream example leads to
 non-working code
In-Reply-To: <WpEds9VHiqG2kYCoLEz15T7qQE91qtE7Z1XgHBDADTI=.af2361e8-0b41-4c36-99eb-d1a52db7dda9@github.com>
References: <T1B5skiWk5tg__V5hjIagupcwmdmQXRnK4QPzZfPL8I=.86a0005f-8bcc-46c4-abca-031c43ea0e4e@github.com>
 <WpEds9VHiqG2kYCoLEz15T7qQE91qtE7Z1XgHBDADTI=.af2361e8-0b41-4c36-99eb-d1a52db7dda9@github.com>
Message-ID: <r4DZC7N5oyafg1NGbr_u82Sx6NK2mQ3YUUBEkgcrOyM=.ee76294c-654d-49c2-b98f-370e35345388@github.com>

On Mon, 19 Dec 2022 20:22:22 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Update javadoc examples to use try-with-resources and use javadoc snippet tags.
>> The examples in ObjectInputStream and ObjectOutputStream get an update with
>> try-with-resources and use of javadoc snippet tags.
>> ObjectInputFilter is updated with use of snippet tags instead of html markup.
>
> src/java.base/share/classes/java/io/ObjectInputStream.java line 126:
> 
>> 124:  *         String label = (String) ois.readObject();
>> 125:  *         LocalDateTime date = (LocalDateTime) ois.readObject();
>> 126:  *         System.out.println(label + ": " + date);
> 
> would it be worth using `System.out.printf` here?

Maybe printing is a distraction; there many preferences for output and the original did not include it.
Simple string concatenation is the most efficient, but the least parameterizable.

-------------

PR: https://git.openjdk.org/jdk20/pull/59

From naoto at openjdk.org  Mon Dec 19 20:37:54 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 19 Dec 2022 20:37:54 GMT
Subject: [jdk20] RFR: 4958969: ObjectOutputStream example leads to
 non-working code
In-Reply-To: <T1B5skiWk5tg__V5hjIagupcwmdmQXRnK4QPzZfPL8I=.86a0005f-8bcc-46c4-abca-031c43ea0e4e@github.com>
References: <T1B5skiWk5tg__V5hjIagupcwmdmQXRnK4QPzZfPL8I=.86a0005f-8bcc-46c4-abca-031c43ea0e4e@github.com>
Message-ID: <M9Gfmowqa8mcSS0J33Szn0JUrXE_jIwzaR-2R9nBYSE=.c01bd038-a4e8-49ad-b94a-3be9a1a19660@github.com>

On Mon, 19 Dec 2022 20:12:15 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Update javadoc examples to use try-with-resources and use javadoc snippet tags.
> The examples in ObjectInputStream and ObjectOutputStream get an update with
> try-with-resources and use of javadoc snippet tags.
> ObjectInputFilter is updated with use of snippet tags instead of html markup.

LGTM, Roger.

src/java.base/share/classes/java/io/ObjectInputStream.java line 125:

> 123:  *          ObjectInputStream ois = new ObjectInputStream(fis)) {
> 124:  *         String label = (String) ois.readObject();
> 125:  *         LocalDateTime date = (LocalDateTime) ois.readObject();

Nit: I'd replace `date` with `dateTime`.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/59

From naoto at openjdk.org  Mon Dec 19 20:46:44 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 19 Dec 2022 20:46:44 GMT
Subject: RFR: 8298971: Move Console implementation into jdk internal package
Message-ID: <HB71j22Ejn5KPT1ahxstZMORHL0SDSoHVsuYIESGgCQ=.681ab0d7-e2af-45e1-b6b7-e978877475a5@github.com>

Moving the built-in implementation of `Console` from `java.io` package into `jdk.internal.io` package. It now implements `JdkConsole` interface and is accessed through `ProxyingConsole`.

-------------

Commit messages:
 - Split Console_md.c
 - 8298971: Move Console implementation into jdk internal package

Changes: https://git.openjdk.org/jdk/pull/11729/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11729&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298971
  Stats: 820 lines in 5 files changed: 425 ins; 392 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11729.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11729/head:pull/11729

PR: https://git.openjdk.org/jdk/pull/11729

From rriggs at openjdk.org  Mon Dec 19 20:50:18 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 19 Dec 2022 20:50:18 GMT
Subject: [jdk20] RFR: 4958969: ObjectOutputStream example leads to
 non-working code [v2]
In-Reply-To: <T1B5skiWk5tg__V5hjIagupcwmdmQXRnK4QPzZfPL8I=.86a0005f-8bcc-46c4-abca-031c43ea0e4e@github.com>
References: <T1B5skiWk5tg__V5hjIagupcwmdmQXRnK4QPzZfPL8I=.86a0005f-8bcc-46c4-abca-031c43ea0e4e@github.com>
Message-ID: <E1Y9ssQGa7Krt4EwhcLnGR3amL5qIVpozOIyPXtUBpQ=.10283580-2344-4b2d-aeb3-a74e8d4fe44a@github.com>

> Update javadoc examples to use try-with-resources and use javadoc snippet tags.
> The examples in ObjectInputStream and ObjectOutputStream get an update with
> try-with-resources and use of javadoc snippet tags.
> ObjectInputFilter is updated with use of snippet tags instead of html markup.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Simplify ObjectInputExample based on review comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/59/files
  - new: https://git.openjdk.org/jdk20/pull/59/files/c27b0e5a..0a5fcbd4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=59&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=59&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk20/pull/59.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/59/head:pull/59

PR: https://git.openjdk.org/jdk20/pull/59

From naoto at openjdk.org  Mon Dec 19 21:02:55 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 19 Dec 2022 21:02:55 GMT
Subject: [jdk20] RFR: 4958969: ObjectOutputStream example leads to
 non-working code [v2]
In-Reply-To: <E1Y9ssQGa7Krt4EwhcLnGR3amL5qIVpozOIyPXtUBpQ=.10283580-2344-4b2d-aeb3-a74e8d4fe44a@github.com>
References: <T1B5skiWk5tg__V5hjIagupcwmdmQXRnK4QPzZfPL8I=.86a0005f-8bcc-46c4-abca-031c43ea0e4e@github.com>
 <E1Y9ssQGa7Krt4EwhcLnGR3amL5qIVpozOIyPXtUBpQ=.10283580-2344-4b2d-aeb3-a74e8d4fe44a@github.com>
Message-ID: <sawUMyDCtYyBar0qQWomKD5WOLRhQT6vObsbOBHY4Xw=.5db565da-518b-4ad7-9590-4666ccd1cf91@github.com>

On Mon, 19 Dec 2022 20:50:18 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Update javadoc examples to use try-with-resources and use javadoc snippet tags.
>> The examples in ObjectInputStream and ObjectOutputStream get an update with
>> try-with-resources and use of javadoc snippet tags.
>> ObjectInputFilter is updated with use of snippet tags instead of html markup.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify ObjectInputExample based on review comments.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk20/pull/59

From hannesw at openjdk.org  Mon Dec 19 21:07:55 2022
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 19 Dec 2022 21:07:55 GMT
Subject: Withdrawn: JDK-8277074: Qualified exported types show up in JavaDoc
In-Reply-To: <xR3kgCjjyFNOCQ2zSYEkv5HjktzCsFsahCsbNGs5Tw4=.ec8b3808-fe12-41b1-986a-64dd67073c3c@github.com>
References: <xR3kgCjjyFNOCQ2zSYEkv5HjktzCsFsahCsbNGs5Tw4=.ec8b3808-fe12-41b1-986a-64dd67073c3c@github.com>
Message-ID: <RMgwkdaVTI_dpdaIUzlSGs7RHzZ8i9px5VbbYssRQiI=.dc748f73-021c-48c4-999d-f72dd3cfbf32@github.com>

On Tue, 15 Nov 2022 12:15:42 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a simple change to hide internal classes in generated documentation by adding doc comments containing a `@hidden` tag. I verified the fix by making sure `grep -r jdk.internal` returns no matches in the generated documentation tree.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11163

From dcubed at openjdk.org  Mon Dec 19 22:28:51 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 19 Dec 2022 22:28:51 GMT
Subject: [jdk20] RFR: 8298699: java/lang/reflect/IllegalArgumentsTest.java
 times out with slowdebug bits
Message-ID: <UTXy4FUBy6LouN3cvN00Of1XqItZUXnOppZRw3ssXso=.18cd53b3-f257-47d5-a737-34270713064a@github.com>

A trivial fix to slightly increase the default timeout so that java/lang/reflect/IllegalArgumentsTest.java
passes with slowdebug bits.

-------------

Commit messages:
 - 8298699: java/lang/reflect/IllegalArgumentsTest.java times out with slowdebug bits

Changes: https://git.openjdk.org/jdk20/pull/60/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=60&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298699
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk20/pull/60.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/60/head:pull/60

PR: https://git.openjdk.org/jdk20/pull/60

From iris at openjdk.org  Mon Dec 19 22:36:48 2022
From: iris at openjdk.org (Iris Clark)
Date: Mon, 19 Dec 2022 22:36:48 GMT
Subject: [jdk20] RFR: 8298699: java/lang/reflect/IllegalArgumentsTest.java
 times out with slowdebug bits
In-Reply-To: <UTXy4FUBy6LouN3cvN00Of1XqItZUXnOppZRw3ssXso=.18cd53b3-f257-47d5-a737-34270713064a@github.com>
References: <UTXy4FUBy6LouN3cvN00Of1XqItZUXnOppZRw3ssXso=.18cd53b3-f257-47d5-a737-34270713064a@github.com>
Message-ID: <BO63OHZO3Z-rHZCuJhUQnhQOw6m6PpQyp7YxVtgx0A0=.59277c6f-54ef-4944-b387-efbc055ecba9@github.com>

On Mon, 19 Dec 2022 22:20:08 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to slightly increase the default timeout so that java/lang/reflect/IllegalArgumentsTest.java
> passes with slowdebug bits.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.org/jdk20/pull/60

From dcubed at openjdk.org  Mon Dec 19 22:46:48 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 19 Dec 2022 22:46:48 GMT
Subject: [jdk20] RFR: 8298699: java/lang/reflect/IllegalArgumentsTest.java
 times out with slowdebug bits
In-Reply-To: <BO63OHZO3Z-rHZCuJhUQnhQOw6m6PpQyp7YxVtgx0A0=.59277c6f-54ef-4944-b387-efbc055ecba9@github.com>
References: <UTXy4FUBy6LouN3cvN00Of1XqItZUXnOppZRw3ssXso=.18cd53b3-f257-47d5-a737-34270713064a@github.com>
 <BO63OHZO3Z-rHZCuJhUQnhQOw6m6PpQyp7YxVtgx0A0=.59277c6f-54ef-4944-b387-efbc055ecba9@github.com>
Message-ID: <uwBhqEQNv3pL79TA9x36Gj97tvIs6S1C-Gs7gV2ALDY=.52b551e4-d5dc-4bb5-a897-04fddc419d0e@github.com>

On Mon, 19 Dec 2022 22:34:00 GMT, Iris Clark <iris at openjdk.org> wrote:

>> A trivial fix to slightly increase the default timeout so that java/lang/reflect/IllegalArgumentsTest.java
>> passes with slowdebug bits.
>
> Marked as reviewed by iris (Reviewer).

@irisclark - Thanks for the fast review. Do you agree that this is a trivial fix?
That would allow me to skip the 24 hour rule...

-------------

PR: https://git.openjdk.org/jdk20/pull/60

From iris.clark at oracle.com  Mon Dec 19 22:59:01 2022
From: iris.clark at oracle.com (Iris Clark)
Date: Mon, 19 Dec 2022 22:59:01 +0000
Subject: [jdk20] RFR: 8298699: java/lang/reflect/IllegalArgumentsTest.java
 times out with slowdebug bits
In-Reply-To: <uwBhqEQNv3pL79TA9x36Gj97tvIs6S1C-Gs7gV2ALDY=.52b551e4-d5dc-4bb5-a897-04fddc419d0e@github.com>
References: <UTXy4FUBy6LouN3cvN00Of1XqItZUXnOppZRw3ssXso=.18cd53b3-f257-47d5-a737-34270713064a@github.com>
 <BO63OHZO3Z-rHZCuJhUQnhQOw6m6PpQyp7YxVtgx0A0=.59277c6f-54ef-4944-b387-efbc055ecba9@github.com>
 <uwBhqEQNv3pL79TA9x36Gj97tvIs6S1C-Gs7gV2ALDY=.52b551e4-d5dc-4bb5-a897-04fddc419d0e@github.com>
Message-ID: <SJ0PR10MB54403C0F079D25B7BEA20BBCFBE59@SJ0PR10MB5440.namprd10.prod.outlook.com>

I agree that this is a trivial fix.

Iris

________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Daniel D.Daugherty <dcubed at openjdk.org>
Sent: Monday, December 19, 2022 2:46 PM
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>; hotspot-runtime-dev at openjdk.org <hotspot-runtime-dev at openjdk.org>
Subject: Re: [jdk20] RFR: 8298699: java/lang/reflect/IllegalArgumentsTest.java times out with slowdebug bits

On Mon, 19 Dec 2022 22:34:00 GMT, Iris Clark <iris at openjdk.org> wrote:

>> A trivial fix to slightly increase the default timeout so that java/lang/reflect/IllegalArgumentsTest.java
>> passes with slowdebug bits.
>
> Marked as reviewed by iris (Reviewer).

@irisclark - Thanks for the fast review. Do you agree that this is a trivial fix?
That would allow me to skip the 24 hour rule...

-------------

PR: https://git.openjdk.org/jdk20/pull/60
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221219/8d63e070/attachment.htm>

From iris at openjdk.org  Mon Dec 19 23:06:49 2022
From: iris at openjdk.org (Iris Clark)
Date: Mon, 19 Dec 2022 23:06:49 GMT
Subject: [jdk20] RFR: 8298699: java/lang/reflect/IllegalArgumentsTest.java
 times out with slowdebug bits
In-Reply-To: <UTXy4FUBy6LouN3cvN00Of1XqItZUXnOppZRw3ssXso=.18cd53b3-f257-47d5-a737-34270713064a@github.com>
References: <UTXy4FUBy6LouN3cvN00Of1XqItZUXnOppZRw3ssXso=.18cd53b3-f257-47d5-a737-34270713064a@github.com>
Message-ID: <VkQDI2q1dWhkQS__1qWEG6ILGc13nNdZHyfOhFIaBPo=.c37d0fd3-2001-4ed0-a58b-549e3b82d493@github.com>

On Mon, 19 Dec 2022 22:20:08 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to slightly increase the default timeout so that java/lang/reflect/IllegalArgumentsTest.java
> passes with slowdebug bits.

Trivial update approved.

-------------

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/60

From dcubed at openjdk.org  Mon Dec 19 23:11:52 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 19 Dec 2022 23:11:52 GMT
Subject: [jdk20] RFR: 8298699: java/lang/reflect/IllegalArgumentsTest.java
 times out with slowdebug bits
In-Reply-To: <VkQDI2q1dWhkQS__1qWEG6ILGc13nNdZHyfOhFIaBPo=.c37d0fd3-2001-4ed0-a58b-549e3b82d493@github.com>
References: <UTXy4FUBy6LouN3cvN00Of1XqItZUXnOppZRw3ssXso=.18cd53b3-f257-47d5-a737-34270713064a@github.com>
 <VkQDI2q1dWhkQS__1qWEG6ILGc13nNdZHyfOhFIaBPo=.c37d0fd3-2001-4ed0-a58b-549e3b82d493@github.com>
Message-ID: <N9gA7fC59WOaQD4JFgG-3YDNupXfaG7Eimza10f-swo=.61cf0378-c8ba-4e8e-84fc-a5ac4e0f2ac7@github.com>

On Mon, 19 Dec 2022 23:03:54 GMT, Iris Clark <iris at openjdk.org> wrote:

>> A trivial fix to slightly increase the default timeout so that java/lang/reflect/IllegalArgumentsTest.java
>> passes with slowdebug bits.
>
> Trivial update approved.

@irisclark - Thanks!

-------------

PR: https://git.openjdk.org/jdk20/pull/60

From dcubed at openjdk.org  Mon Dec 19 23:11:53 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 19 Dec 2022 23:11:53 GMT
Subject: [jdk20] Integrated: 8298699:
 java/lang/reflect/IllegalArgumentsTest.java times out with slowdebug bits
In-Reply-To: <UTXy4FUBy6LouN3cvN00Of1XqItZUXnOppZRw3ssXso=.18cd53b3-f257-47d5-a737-34270713064a@github.com>
References: <UTXy4FUBy6LouN3cvN00Of1XqItZUXnOppZRw3ssXso=.18cd53b3-f257-47d5-a737-34270713064a@github.com>
Message-ID: <YF14-ZUAYBUWFLCnO2isSHEO0hLXVIYev3deC9S4fFM=.81b330ca-eeda-406b-9331-46d79f16779d@github.com>

On Mon, 19 Dec 2022 22:20:08 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to slightly increase the default timeout so that java/lang/reflect/IllegalArgumentsTest.java
> passes with slowdebug bits.

This pull request has now been integrated.

Changeset: f07acfc1
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/f07acfc166e1261f830e63629e76303ec6235377
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8298699: java/lang/reflect/IllegalArgumentsTest.java times out with slowdebug bits

Reviewed-by: iris

-------------

PR: https://git.openjdk.org/jdk20/pull/60

From rriggs at openjdk.org  Mon Dec 19 23:13:53 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 19 Dec 2022 23:13:53 GMT
Subject: [jdk20] Integrated: 4958969: ObjectOutputStream example leads to
 non-working code
In-Reply-To: <T1B5skiWk5tg__V5hjIagupcwmdmQXRnK4QPzZfPL8I=.86a0005f-8bcc-46c4-abca-031c43ea0e4e@github.com>
References: <T1B5skiWk5tg__V5hjIagupcwmdmQXRnK4QPzZfPL8I=.86a0005f-8bcc-46c4-abca-031c43ea0e4e@github.com>
Message-ID: <mScm2OdcuCVHDq_ZSA4J8n8lZ3n0ygASvaoYUjSSNQQ=.563a5653-34a1-4759-9086-c8231414e268@github.com>

On Mon, 19 Dec 2022 20:12:15 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Update javadoc examples to use try-with-resources and use javadoc snippet tags.
> The examples in ObjectInputStream and ObjectOutputStream get an update with
> try-with-resources and use of javadoc snippet tags.
> ObjectInputFilter is updated with use of snippet tags instead of html markup.

This pull request has now been integrated.

Changeset: d0a7679d
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/d0a7679d2e9c86ee2fc6edf2e37c1729c833ae11
Stats:     61 lines in 3 files changed: 1 ins; 3 del; 57 mod

4958969: ObjectOutputStream example leads to non-working code

Reviewed-by: lancea, naoto

-------------

PR: https://git.openjdk.org/jdk20/pull/59

From jwilhelm at openjdk.org  Tue Dec 20 11:13:46 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 20 Dec 2022 11:13:46 GMT
Subject: RFR: Merge jdk20
Message-ID: <m3v45C3WNjtXMERnETYkUxK26uH2AXGrUHf64gA4IQo=.265ed2e3-2da7-4bdc-9fe0-e20d69a6d437@github.com>

Forwardport JDK 20 -> JDK 21

-------------

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8298784: JFR: Test chunk integrity
 - 8298215: gc/g1/TestVerifyGCType.java failed with "Missing expected verification pattern Verifying After GC for: Pause Young (Prepare Mixed): expected true, was false"
 - 4958969: ObjectOutputStream example leads to non-working code
 - 8298699: java/lang/reflect/IllegalArgumentsTest.java times out with slowdebug bits
 - 4512626: Non-editable JTextArea provides no visual indication of keyboard focus
 - 8277074: Qualified exported types show up in JavaDoc
 - 8298894: java/lang/Thread/virtual/stress/Skynet.java timed out and threw OutOfMemoryError
 - 8298987: ProblemList jdk/internal/vm/Continuation/Fuzz.java#default with ZGC on X64
 - 8298905: Test "java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java" fails because the frames of instruction does not display
 - ... and 6 more: https://git.openjdk.org/jdk/compare/36de61c4...d70f5831

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=11739&range=00.0
 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=11739&range=00.1

Changes: https://git.openjdk.org/jdk/pull/11739/files
  Stats: 2286 lines in 125 files changed: 1286 ins; 609 del; 391 mod
  Patch: https://git.openjdk.org/jdk/pull/11739.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11739/head:pull/11739

PR: https://git.openjdk.org/jdk/pull/11739

From jwilhelm at openjdk.org  Tue Dec 20 11:47:31 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 20 Dec 2022 11:47:31 GMT
Subject: RFR: Merge jdk20 [v2]
In-Reply-To: <m3v45C3WNjtXMERnETYkUxK26uH2AXGrUHf64gA4IQo=.265ed2e3-2da7-4bdc-9fe0-e20d69a6d437@github.com>
References: <m3v45C3WNjtXMERnETYkUxK26uH2AXGrUHf64gA4IQo=.265ed2e3-2da7-4bdc-9fe0-e20d69a6d437@github.com>
Message-ID: <FnOGkSoOkKJfJ5JjgZo7uwEF2JILRWkjhHgWx1sprIc=.38ff283a-01ab-401c-9411-f0d8c86702b6@github.com>

> Forwardport JDK 20 -> JDK 21

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits:

 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8298865: Excessive memory allocation in CipherOutputStream AEAD decryption
   
   Reviewed-by: valeriep, ascarpino
 - 8299043: test/jdk/javax/swing/AbstractButton/5049549/bug5049549.java fails with java.lang.NullPointerException
   
   Reviewed-by: serb
 - 8298974: Add ftcolor.c to imported freetype sources
   
   Reviewed-by: serb
 - 8299044: test/jdk/javax/swing/JComboBox/JComboBoxBorderTest.java fails on non mac
   
   Reviewed-by: serb, honkar
 - 8299045: tools/doclint/BadPackageCommentTest.java fails after JDK-8298943
   
   Reviewed-by: vromero
 - 8298943: Missing escapes for single quote marks in compiler.properties
   
   Reviewed-by: jjg
 - 8298701: Cleanup SA entries in ProblemList-zgc.txt.
   
   Reviewed-by: sspitsyn, amenkov
 - 8298470: Short cut java.lang.Object super class loading
   
   Reviewed-by: dholmes, iklam
 - 8299022: Linux ppc64le and s390x build issues after JDK-8160404
   
   Reviewed-by: mdoerr, lucy
 - ... and 97 more: https://git.openjdk.org/jdk/compare/3dd2cfab...d70f5831

-------------

Changes: https://git.openjdk.org/jdk/pull/11739/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11739&range=01
  Stats: 13539 lines in 425 files changed: 8409 ins; 3097 del; 2033 mod
  Patch: https://git.openjdk.org/jdk/pull/11739.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11739/head:pull/11739

PR: https://git.openjdk.org/jdk/pull/11739

From jwilhelm at openjdk.org  Tue Dec 20 11:47:33 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 20 Dec 2022 11:47:33 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <m3v45C3WNjtXMERnETYkUxK26uH2AXGrUHf64gA4IQo=.265ed2e3-2da7-4bdc-9fe0-e20d69a6d437@github.com>
References: <m3v45C3WNjtXMERnETYkUxK26uH2AXGrUHf64gA4IQo=.265ed2e3-2da7-4bdc-9fe0-e20d69a6d437@github.com>
Message-ID: <pk7xFH2bCEPTLw_KlI3RkDUTMMlze8j0j2fNKoqnm5Q=.49972633-6c2a-41af-be30-114c9f119772@github.com>

On Tue, 20 Dec 2022 10:57:44 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: c5a4a7a6
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c5a4a7a679ec76cb08a999a198e5c73e9cd9d2f0
Stats:     2286 lines in 125 files changed: 1286 ins; 609 del; 391 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/11739

From jpai at openjdk.org  Tue Dec 20 14:19:49 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 20 Dec 2022 14:19:49 GMT
Subject: RFR: 8298971: Move Console implementation into jdk internal
 package
In-Reply-To: <HB71j22Ejn5KPT1ahxstZMORHL0SDSoHVsuYIESGgCQ=.681ab0d7-e2af-45e1-b6b7-e978877475a5@github.com>
References: <HB71j22Ejn5KPT1ahxstZMORHL0SDSoHVsuYIESGgCQ=.681ab0d7-e2af-45e1-b6b7-e978877475a5@github.com>
Message-ID: <Bt0wAMLHUSOEq5L8Ko0_Se-N5C_srDtGp5K-sD-oSCM=.ec34eb7b-efd4-403d-a0be-810eeaaa8c00@github.com>

On Mon, 19 Dec 2022 19:23:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Moving the built-in implementation of `Console` from `java.io` package into `jdk.internal.io` package. It now implements `JdkConsole` interface and is accessed through `ProxyingConsole`.

src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 179:

> 177:     private Writer out;
> 178:     private PrintWriter pw;
> 179:     private Formatter formatter;

Hello Naoto, I think some of these can be made `final`.

-------------

PR: https://git.openjdk.org/jdk/pull/11729

From jpai at openjdk.org  Tue Dec 20 14:23:51 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 20 Dec 2022 14:23:51 GMT
Subject: RFR: 8298971: Move Console implementation into jdk internal
 package
In-Reply-To: <HB71j22Ejn5KPT1ahxstZMORHL0SDSoHVsuYIESGgCQ=.681ab0d7-e2af-45e1-b6b7-e978877475a5@github.com>
References: <HB71j22Ejn5KPT1ahxstZMORHL0SDSoHVsuYIESGgCQ=.681ab0d7-e2af-45e1-b6b7-e978877475a5@github.com>
Message-ID: <9G8Pda87X5fIOGyqkNi6tiYNkI3NIPrK9uhB22zmfu8=.f27a9d69-8dce-48e8-9c2a-59533513ac69@github.com>

On Mon, 19 Dec 2022 19:23:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Moving the built-in implementation of `Console` from `java.io` package into `jdk.internal.io` package. It now implements `JdkConsole` interface and is accessed through `ProxyingConsole`.

src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 365:

> 363:     // For convenience
> 364:     public static JdkConsole getJdkConsole(Charset cs) {
> 365:         return INSTANCE != null ? INSTANCE : new JdkConsoleImpl().console(true, cs);

Would this singleton/caching be necessary? Or could we expect that the caller of this method would cache it (like the `java.io.Console` actually does right now)?
In theory, this current implementation in this method can potentially return an incorrect (cached) instance on a second call if the `Charset` that's passed is different from the one that was used by the cached instance that is returned. But, since we know/expect this method to be called only by the `java.io.Console` and with the same `Charset` instance, I think this is OK. I do think that if we remove the caching/singleton logic here, this class could be a bit more simpler.

-------------

PR: https://git.openjdk.org/jdk/pull/11729

From jpai at openjdk.org  Tue Dec 20 14:26:49 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 20 Dec 2022 14:26:49 GMT
Subject: RFR: 8298971: Move Console implementation into jdk internal
 package
In-Reply-To: <HB71j22Ejn5KPT1ahxstZMORHL0SDSoHVsuYIESGgCQ=.681ab0d7-e2af-45e1-b6b7-e978877475a5@github.com>
References: <HB71j22Ejn5KPT1ahxstZMORHL0SDSoHVsuYIESGgCQ=.681ab0d7-e2af-45e1-b6b7-e978877475a5@github.com>
Message-ID: <ht1TrKJvRoq4nkRqZ_6-Gl2CJ9kUbAdO4SSURvm2CF4=.8b0c0940-b380-4d97-a9bf-b1dc923baff0@github.com>

On Mon, 19 Dec 2022 19:23:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Moving the built-in implementation of `Console` from `java.io` package into `jdk.internal.io` package. It now implements `JdkConsole` interface and is accessed through `ProxyingConsole`.

src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 336:

> 334:     public JdkConsole console(boolean isTTY, Charset charset) {
> 335:         if (isTTY) {
> 336:             if (INSTANCE == null) {

This would need a double checked locking, isn't it? Something like:

if (INSTANCE == null) {
   synchronized (JdkConsoleImpl.class) {
      if (INSTANCE != null) {
          return INSTANCE;
      }
      ...// rest of the current code that's in if block


Having said that perhaps the singleton instance isn't needed here and the `java.io.Console` deal with the caching?

-------------

PR: https://git.openjdk.org/jdk/pull/11729

From jpai at openjdk.org  Tue Dec 20 14:39:54 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 20 Dec 2022 14:39:54 GMT
Subject: RFR: 8298971: Move Console implementation into jdk internal
 package
In-Reply-To: <Bt0wAMLHUSOEq5L8Ko0_Se-N5C_srDtGp5K-sD-oSCM=.ec34eb7b-efd4-403d-a0be-810eeaaa8c00@github.com>
References: <HB71j22Ejn5KPT1ahxstZMORHL0SDSoHVsuYIESGgCQ=.681ab0d7-e2af-45e1-b6b7-e978877475a5@github.com>
 <Bt0wAMLHUSOEq5L8Ko0_Se-N5C_srDtGp5K-sD-oSCM=.ec34eb7b-efd4-403d-a0be-810eeaaa8c00@github.com>
Message-ID: <d2UNSmWNsTOApzz0hV___fPn85f9sqGJwXFugSXqU8s=.8971cd08-13a8-446f-89ac-7bcfd85e5287@github.com>

On Tue, 20 Dec 2022 14:17:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Moving the built-in implementation of `Console` from `java.io` package into `jdk.internal.io` package. It now implements `JdkConsole` interface and is accessed through `ProxyingConsole`.
>
> src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 179:
> 
>> 177:     private Writer out;
>> 178:     private PrintWriter pw;
>> 179:     private Formatter formatter;
> 
> Hello Naoto, I think some of these can be made `final`.

Actually, I see that it isn't possible for these to be final because we set these up in the `console(...)` instance method of this class. That's because this `JdkConsoleImpl` implements both the `JdkConsole` interface and the `JdkConsoleProvider` interface.

-------------

PR: https://git.openjdk.org/jdk/pull/11729

From jpai at openjdk.org  Tue Dec 20 14:48:50 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 20 Dec 2022 14:48:50 GMT
Subject: RFR: 8298971: Move Console implementation into jdk internal
 package
In-Reply-To: <d2UNSmWNsTOApzz0hV___fPn85f9sqGJwXFugSXqU8s=.8971cd08-13a8-446f-89ac-7bcfd85e5287@github.com>
References: <HB71j22Ejn5KPT1ahxstZMORHL0SDSoHVsuYIESGgCQ=.681ab0d7-e2af-45e1-b6b7-e978877475a5@github.com>
 <Bt0wAMLHUSOEq5L8Ko0_Se-N5C_srDtGp5K-sD-oSCM=.ec34eb7b-efd4-403d-a0be-810eeaaa8c00@github.com>
 <d2UNSmWNsTOApzz0hV___fPn85f9sqGJwXFugSXqU8s=.8971cd08-13a8-446f-89ac-7bcfd85e5287@github.com>
Message-ID: <yJYKwcbvQdJl7HuDAbuDi0jqSpz7IHyw7Z5mxF_ggBs=.97ca3243-cbf8-4a77-8127-9071912e99d9@github.com>

On Tue, 20 Dec 2022 14:37:10 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 179:
>> 
>>> 177:     private Writer out;
>>> 178:     private PrintWriter pw;
>>> 179:     private Formatter formatter;
>> 
>> Hello Naoto, I think some of these can be made `final`.
>
> Actually, I see that it isn't possible for these to be final because we set these up in the `console(...)` instance method of this class. That's because this `JdkConsoleImpl` implements both the `JdkConsole` interface and the `JdkConsoleProvider` interface.

Do you think we could separate out this class into 2 separate implementations? Just like we do in the `jdk.internal.org.jline.JdkConsoleProviderImpl`? That could perhaps make this implementation similar to that other one and a bit simpler? So something like:


package jdk.internal.io;
public final class JdkConsoleProviderImpl implements JdkConsoleProvider {
	
	private static volatile JdkConsole INSTANCE;

	@Override
    public JdkConsole console(boolean isTTY, Charset charset) {
    	.....
    	// construct and return a (JdkConsoleImpl instance)
    }

    public static synchronized JdkConsole getJdkConsole(Charset cs) {
        return INSTANCE != null ? INSTANCE : new JdkConsoleImpl(cs);
    }

    private static final class JdkConsoleImpl implements JdkConsole {
    	private final Charset charset;
    	private final Object readLock;
	    private final Object writeLock;
	    private final Reader reader;
	    private final Writer out;
	    private final PrintWriter pw;
	    private final Formatter formatter;
	    private char[] rcb;
	    private boolean restoreEcho;
	    private boolean shutdownHookInstalled;


	    private JdkConsoleImpl(Charset cs) {
	    	this.charset = cs;
	    	....
	    }

	    // other methods from JdkConsole

    }


}

-------------

PR: https://git.openjdk.org/jdk/pull/11729

From jpai at openjdk.org  Tue Dec 20 15:21:49 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 20 Dec 2022 15:21:49 GMT
Subject: RFR: 8298875: A module requiring "java.base" with flags
 ACC_SYNTHETIC should be rejected
In-Reply-To: <hFS1P8AQtGocnj-mPM7ShSKel9iLl7xxMwIjlmwCXqA=.f7b7da46-1df4-4706-9ee8-47ba200fac9d@github.com>
References: <hFS1P8AQtGocnj-mPM7ShSKel9iLl7xxMwIjlmwCXqA=.f7b7da46-1df4-4706-9ee8-47ba200fac9d@github.com>
Message-ID: <q4GkLpTInPtQ_p0_cIhM_N8eIjpsjT6_8RTiOLInllM=.cb578867-8301-4e72-98ef-051cbdd75c3a@github.com>

On Fri, 16 Dec 2022 19:30:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> A small oversight with ModuleDescriptor.read when checking the requires table of a Module attribute. The requires entry for java.base should not have ACC_SYNTHETIC set.
> 
> A new test is added. Some of the existing tests used `@Test(expectedExceptions=...)`. I've changed some of these to use assertThrows to narrow it down to method that is expected to throw.

test/jdk/java/lang/module/ModuleDescriptorTest.java line 1364:

> 1362:      * complete set of packages.
> 1363:      */
> 1364:     @Test(expectedExceptions = InvalidModuleDescriptorException.class)

At first I thought you accidentally removed the entire `@Test` annotation instead of just the `expectedExceptions` property. But then this class is annotated with a `@Test` and this method name starts with the `test...`, just like some other existing methods in this class which too don't have a `@Test` annotation. I checked a local run of this test and those other non-annotated methods are currently executed as test methods, which is a good thing. So this change to completely remove the `@Test` is fine.

-------------

PR: https://git.openjdk.org/jdk/pull/11714

From jpai at openjdk.org  Tue Dec 20 15:25:51 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 20 Dec 2022 15:25:51 GMT
Subject: RFR: 8298875: A module requiring "java.base" with flags
 ACC_SYNTHETIC should be rejected
In-Reply-To: <hFS1P8AQtGocnj-mPM7ShSKel9iLl7xxMwIjlmwCXqA=.f7b7da46-1df4-4706-9ee8-47ba200fac9d@github.com>
References: <hFS1P8AQtGocnj-mPM7ShSKel9iLl7xxMwIjlmwCXqA=.f7b7da46-1df4-4706-9ee8-47ba200fac9d@github.com>
Message-ID: <KOX0LYVcjqSfjKnVJnVKKWvLZJ6yz3L4V43o8Ge-Npo=.d99a7e84-c6b3-42d4-b13f-8a358c10419b@github.com>

On Fri, 16 Dec 2022 19:30:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> A small oversight with ModuleDescriptor.read when checking the requires table of a Module attribute. The requires entry for java.base should not have ACC_SYNTHETIC set.
> 
> A new test is added. Some of the existing tests used `@Test(expectedExceptions=...)`. I've changed some of these to use assertThrows to narrow it down to method that is expected to throw.

Marked as reviewed by jpai (Reviewer).

I don't have previous knowledge of this area, but reading the JBS issue and the JVM spec section 4.7.25 https://docs.oracle.com/javase/specs/jvms/se19/html/jvms-4.html#jvms-4.7.25, this change looks fine to me. The test changes too look good.

-------------

PR: https://git.openjdk.org/jdk/pull/11714

From bhuang at openjdk.org  Tue Dec 20 19:07:58 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Tue, 20 Dec 2022 19:07:58 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v5]
In-Reply-To: <uDwwI-PKA1x-jZ1noAhf3jmID9VyD2fBeBGYfs__wpg=.05c55abe-673f-4aac-86d3-35c9c51ad3cf@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <uw2kQJPBcg5iPyVZGL-BiSMkIK7S2htYcOyOTSi_1-w=.2b19fdf9-5978-4ded-b2e9-3d228c586fd6@github.com>
 <uDwwI-PKA1x-jZ1noAhf3jmID9VyD2fBeBGYfs__wpg=.05c55abe-673f-4aac-86d3-35c9c51ad3cf@github.com>
Message-ID: <XyDXua4yOaC8Jul8EY-7-KETHCJeCUqdkPtvOoO4ib0=.c488518f-35b2-46a6-92f7-b86d8da84943@github.com>

On Fri, 16 Dec 2022 11:48:54 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> Bill Huang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8295087
>>  - Added an extra line to the end of the policy file.
>>  - AssertThrows an exception in InconsistentEntries test.
>>  - Refactored to use testng framework for test enviroment setup.
>>  - Converted security manual tests to automated tests.
>
> test/jdk/javax/crypto/CryptoPermissions/InconsistentEntries.java line 52:
> 
>> 50:     private static final String JDK_HOME = System.getProperty("test.jdk");
>> 51:     private static final String TEST_SRC = System.getProperty("test.src");
>> 52:     private static final Path POLICY_DIR = Paths.get(JDK_HOME, "conf", "security",
> 
> This doesn't looks like a safe Test to be automated. Can it create conflict with any other existing Test requiring "testlimited" with  default_local.policy? This need to be verified. Also changing anything inside an installed JDK probably not a good choice. It's just a thought from my side and it could be different for others.

Good points. I searched the entire repo and this is the only instance that uses the "testlimited" with default_local.policy. Looking over the logic, the test sets the crypto.policy property to "testlimited". So I am wondering if the "testlimited" is created for test purposes. If so, are we allowed to rename "testlimited" to be more specific, eg. "testcryptoperms"? 
`Security.setProperty("crypto.policy", "testlimited");`

-------------

PR: https://git.openjdk.org/jdk/pull/10637

From bhuang at openjdk.org  Tue Dec 20 19:13:12 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Tue, 20 Dec 2022 19:13:12 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v5]
In-Reply-To: <uDwwI-PKA1x-jZ1noAhf3jmID9VyD2fBeBGYfs__wpg=.05c55abe-673f-4aac-86d3-35c9c51ad3cf@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <uw2kQJPBcg5iPyVZGL-BiSMkIK7S2htYcOyOTSi_1-w=.2b19fdf9-5978-4ded-b2e9-3d228c586fd6@github.com>
 <uDwwI-PKA1x-jZ1noAhf3jmID9VyD2fBeBGYfs__wpg=.05c55abe-673f-4aac-86d3-35c9c51ad3cf@github.com>
Message-ID: <wilOMw5G9maJsZQIghLzPG0VBC42NEwCzkk23WHD5Fg=.ddcd0d7c-2513-41f9-9106-90334a553c96@github.com>

On Fri, 16 Dec 2022 12:06:14 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> Bill Huang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8295087
>>  - Added an extra line to the end of the policy file.
>>  - AssertThrows an exception in InconsistentEntries test.
>>  - Refactored to use testng framework for test enviroment setup.
>>  - Converted security manual tests to automated tests.
>
> test/jdk/sun/security/provider/PolicyParser/ExtDirs.java line 37:
> 
>> 35:  * @summary standard extensions path is hard-coded in default
>> 36:  *      system policy file
>> 37:  * @run main/othervm/policy=ExtDirs.policy/secure=default ExtDirs
> 
> May be "/secure=default" is optional here.

Yes, you are right and we can remove the /secure. According to the JTReg spec.
`If the /secure option is not used then the default security manager will be installed.`

-------------

PR: https://git.openjdk.org/jdk/pull/10637

From bhuang at openjdk.org  Tue Dec 20 19:23:10 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Tue, 20 Dec 2022 19:23:10 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v6]
In-Reply-To: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
Message-ID: <J2eQc_SMfteNYRozU44midnVyt2Kdqmic39U4QFoGd0=.3c9049d3-7624-4a80-8d9b-002072c73cd5@github.com>

> This task converts 5 manual tests to automated tests.
> 
> sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java 
> sun/security/provider/PolicyParser/ExtDirsChange.java 
> sun/security/provider/PolicyParser/ExtDirs.java 
> java/security/Policy/Root/Root.javajava/security/Policy/Root/Root.java 
> javax/crypto/CryptoPermissions/InconsistentEntries.java

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Implemented review comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10637/files
  - new: https://git.openjdk.org/jdk/pull/10637/files/32b656ca..c6521f21

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10637&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10637&range=04-05

  Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/10637.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10637/head:pull/10637

PR: https://git.openjdk.org/jdk/pull/10637

From redestad at openjdk.org  Tue Dec 20 19:57:55 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 20 Dec 2022 19:57:55 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v13]
In-Reply-To: <_2HYrbXOe6zVuLXHywoy_AjCcGMYR266BcwKUZEA5fs=.1e6f7640-7580-4ff3-ace6-f18f27efbb23@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <pW8HHmh-dQnjrRftd052fBQVulqe_z5KldY76Hp-OmI=.a7a2b6e6-a182-45d2-bd11-16a406126482@github.com>
 <_2HYrbXOe6zVuLXHywoy_AjCcGMYR266BcwKUZEA5fs=.1e6f7640-7580-4ff3-ace6-f18f27efbb23@github.com>
Message-ID: <xEjDlEzYJlPt8HhGk9xE6z57yAwT246Nl0yNpMP3riI=.9aca27c6-348f-4ad2-bff3-4e0262053135@github.com>

On Fri, 16 Dec 2022 22:58:23 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missing & 0xff in StringLatin1::hashCode
>
> src/hotspot/cpu/x86/vm_version_x86.cpp line 1671:
> 
>> 1669:   }
>> 1670:   if (UseAVX >= 2) {
>> 1671:     FLAG_SET_ERGO_IF_DEFAULT(UseVectorizedHashCodeIntrinsic, true);
> 
> This could be just FLAG_SET_DEFAULT instead of FLAG_SET_ERGO_IF_DEFAULT.

Right, it seems HW-dependent intrinsics in generally doesn't mark that they've been enabled ergonomically, rather just make it on "by default" when support is available.

> src/java.base/share/classes/java/lang/StringUTF16.java line 418:
> 
>> 416:             return 0;
>> 417:         } else {
>> 418:             return ArraysSupport.vectorizedHashCode(value, ArraysSupport.UTF16);
> 
> Special case for 1 missing here.

Intentionally left out. Array length is always even for `UTF16` arrays, but we could add a case for `2` that'd return `getChar(bytes, 0)` but I didn't see much of a win when I tested this.

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From redestad at openjdk.org  Tue Dec 20 20:21:57 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 20 Dec 2022 20:21:57 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v13]
In-Reply-To: <_2HYrbXOe6zVuLXHywoy_AjCcGMYR266BcwKUZEA5fs=.1e6f7640-7580-4ff3-ace6-f18f27efbb23@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <pW8HHmh-dQnjrRftd052fBQVulqe_z5KldY76Hp-OmI=.a7a2b6e6-a182-45d2-bd11-16a406126482@github.com>
 <_2HYrbXOe6zVuLXHywoy_AjCcGMYR266BcwKUZEA5fs=.1e6f7640-7580-4ff3-ace6-f18f27efbb23@github.com>
Message-ID: <_h335iIGqDY-NVIC2k0TYzwb6gZS06ynM76d4-nJaUk=.eb491368-9c6f-4edd-8527-ef8f28c45d20@github.com>

On Fri, 16 Dec 2022 23:00:53 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missing & 0xff in StringLatin1::hashCode
>
> src/hotspot/cpu/x86/stubRoutines_x86.cpp line 230:
> 
>> 228: #endif // _LP64
>> 229: 
>> 230: jint StubRoutines::x86::_arrays_hashcode_powers_of_31[] =
> 
> This should be declared only for LP64.

Hmm, I guess same goes for all the new `arrays_hashcode` methods in `c2_MacroAssembler_x86`, since we only wire this up properly on 64-bit. I'll make a pass to put `_LP64` guards around all new methods.

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From redestad at openjdk.org  Tue Dec 20 21:11:40 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 20 Dec 2022 21:11:40 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v14]
In-Reply-To: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
Message-ID: <fU9foJNSAmSImvl8PN0di4DTJc30iMSaOAPPf0tm290=.95de7241-ea06-4a51-9c5e-c3acf260f83f@github.com>

> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
> 
> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
> 
> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
> 
> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
> 
> With the most recent fixes the x64 intrinsic results on my workstation look like this:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
> 
> Baseline:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
> 
> I.e. no measurable overhead compared to baseline even for `size == 1`.
> 
> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
> 
> Benchmark for `Arrays.hashCode`:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
> 
> Baseline:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
> 
> 
> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.

Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 64 commits:

 - Pass the constant mode node through, removing need for all but one instruct declarations
 - FLAG_SET_DEFAULT
 - Merge branch 'master' into 8282664-polyhash
 - Merge branch 'master' into 8282664-polyhash
 - Missing & 0xff in StringLatin1::hashCode
 - Qualified guess on shenandoahSupport fix-up
 - Whitespace
 - Final touch-ups, restored 2-stride with dependency chain breakage
 - Minor cleanup
 - Revert accidental ModuleHashes change
 - ... and 54 more: https://git.openjdk.org/jdk/compare/8dfb6d76...c9e7c561

-------------

Changes: https://git.openjdk.org/jdk/pull/10847/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=13
  Stats: 1021 lines in 33 files changed: 962 ins; 8 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/10847.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10847/head:pull/10847

PR: https://git.openjdk.org/jdk/pull/10847

From redestad at openjdk.org  Tue Dec 20 21:13:55 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 20 Dec 2022 21:13:55 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v13]
In-Reply-To: <PrXrcgFzP4mr0ZI5WrUizT0Sz_wtTl6AJLS_mvW89dQ=.ae6c18d4-8f5e-48cf-b0bf-8d8db7852346@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <pW8HHmh-dQnjrRftd052fBQVulqe_z5KldY76Hp-OmI=.a7a2b6e6-a182-45d2-bd11-16a406126482@github.com>
 <6lAQI6kDDTGbskylHcWReX8ExaB6qkwgqoai7E6ikZY=.8a69a63c-453d-4bbd-8c76-4d477bfb77fe@github.com>
 <mAsTs03BWlAM_YhHXHBNsaJIQqrX95deQyYAYkJwrmE=.7e36f69c-dffc-462a-bf8a-7614153bf8c4@github.com>
 <PrXrcgFzP4mr0ZI5WrUizT0Sz_wtTl6AJLS_mvW89dQ=.ae6c18d4-8f5e-48cf-b0bf-8d8db7852346@github.com>
Message-ID: <a_7dEeMU-LeSDU1irFR-zAjfM_zKhnosJmEe19TyQsA=.d94df28d-8a97-4463-a3f5-e5e39d6b21e4@github.com>

On Mon, 14 Nov 2022 18:28:53 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>>> Also, I'd like to note that C2 auto-vectorization support is not too far away from being able to optimize hash code computations. At some point, I was able to achieve some promising results with modest tweaking of SuperWord pass: https://github.com/iwanowww/jdk/blob/superword/notes.txt http://cr.openjdk.java.net/~vlivanov/superword.reduction/webrev.00/
>> 
>> Intriguing. How far off is this - and do you think it'll be able to match the efficiency we see here with a memoized coefficient table etc?
>> 
>> If we turn this intrinsic into a stub we might also be able to reuse the optimization in other places, including from within the VM (calculating String hashCodes happen in a couple of places, including String deduplication). So I think there are still a few compelling reasons to go the manual route and continue on this path.
>
>> How far off is this ...?
> 
> Back then it looked way too constrained (tight constraints on code shapes). But I considered it as a generally applicable optimization. 
> 
>>  ... do you think it'll be able to match the efficiency we see here with a memoized coefficient table etc?
> 
> Yes, it is able to build the constant table at runtime when folding multiplications of constant coefficients produced during loop unrolling and then packing scalars into a constant vector.
> 
> Moreover, briefly looking at the code shape, the vectorizer would produce a more optimal loop shape (pre-loop would align vector accesses and would use 512-bit vectors when available; vector post-loop could help as well).

Passing the constant node through as an input as suggested by @iwanowww and @sviswa7 meant we could eliminate most of the `instruct` blocks, removing a significant chunk of code and a little bit of complexity from the proposed patch.

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From naoto at openjdk.org  Tue Dec 20 22:06:26 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 20 Dec 2022 22:06:26 GMT
Subject: RFR: 8298971: Move Console implementation into jdk internal
 package [v2]
In-Reply-To: <HB71j22Ejn5KPT1ahxstZMORHL0SDSoHVsuYIESGgCQ=.681ab0d7-e2af-45e1-b6b7-e978877475a5@github.com>
References: <HB71j22Ejn5KPT1ahxstZMORHL0SDSoHVsuYIESGgCQ=.681ab0d7-e2af-45e1-b6b7-e978877475a5@github.com>
Message-ID: <-TL5hqtIWKbqaq4APrH3xoPnvw87gn0Eq-AD4SgeZks=.fed3ca55-86b2-4b43-acf1-9b767e560508@github.com>

> Moving the built-in implementation of `Console` from `java.io` package into `jdk.internal.io` package. It now implements `JdkConsole` interface and is accessed through `ProxyingConsole`.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Removed JdkConsoleProviderImpl, caching INSTANCE

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11729/files
  - new: https://git.openjdk.org/jdk/pull/11729/files/665b626d..777c0dc0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11729&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11729&range=00-01

  Stats: 55 lines in 2 files changed: 8 ins; 18 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/11729.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11729/head:pull/11729

PR: https://git.openjdk.org/jdk/pull/11729

From naoto at openjdk.org  Tue Dec 20 22:13:48 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 20 Dec 2022 22:13:48 GMT
Subject: RFR: 8298971: Move Console implementation into jdk internal
 package [v2]
In-Reply-To: <yJYKwcbvQdJl7HuDAbuDi0jqSpz7IHyw7Z5mxF_ggBs=.97ca3243-cbf8-4a77-8127-9071912e99d9@github.com>
References: <HB71j22Ejn5KPT1ahxstZMORHL0SDSoHVsuYIESGgCQ=.681ab0d7-e2af-45e1-b6b7-e978877475a5@github.com>
 <Bt0wAMLHUSOEq5L8Ko0_Se-N5C_srDtGp5K-sD-oSCM=.ec34eb7b-efd4-403d-a0be-810eeaaa8c00@github.com>
 <d2UNSmWNsTOApzz0hV___fPn85f9sqGJwXFugSXqU8s=.8971cd08-13a8-446f-89ac-7bcfd85e5287@github.com>
 <yJYKwcbvQdJl7HuDAbuDi0jqSpz7IHyw7Z5mxF_ggBs=.97ca3243-cbf8-4a77-8127-9071912e99d9@github.com>
Message-ID: <t6yameezu8KfaSmYNARJcOxI4N1FeIznKtPr8sjitM4=.b6f57d5e-de21-402f-91f9-3f453dd08f2b@github.com>

On Tue, 20 Dec 2022 14:44:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Actually, I see that it isn't possible for these to be final because we set these up in the `console(...)` instance method of this class. That's because this `JdkConsoleImpl` implements both the `JdkConsole` interface and the `JdkConsoleProvider` interface.
>
> Do you think we could separate out this class into 2 separate implementations? Just like we do in the `jdk.internal.org.jline.JdkConsoleProviderImpl`? That could perhaps make this implementation similar to that other one and a bit simpler? So something like:
> 
> 
> package jdk.internal.io;
> public final class JdkConsoleProviderImpl implements JdkConsoleProvider {
> 	
> 	private static volatile JdkConsole INSTANCE;
> 
> 	@Override
>     public JdkConsole console(boolean isTTY, Charset charset) {
>     	.....
>     	// construct and return a (JdkConsoleImpl instance)
>     }
> 
>     public static synchronized JdkConsole getJdkConsole(Charset cs) {
>         return INSTANCE != null ? INSTANCE : new JdkConsoleImpl(cs);
>     }
> 
>     private static final class JdkConsoleImpl implements JdkConsole {
>     	private final Charset charset;
>     	private final Object readLock;
> 	    private final Object writeLock;
> 	    private final Reader reader;
> 	    private final Writer out;
> 	    private final PrintWriter pw;
> 	    private final Formatter formatter;
> 	    private char[] rcb;
> 	    private boolean restoreEcho;
> 	    private boolean shutdownHookInstalled;
> 
> 
> 	    private JdkConsoleImpl(Charset cs) {
> 	    	this.charset = cs;
> 	    	....
> 	    }
> 
> 	    // other methods from JdkConsole
> 
>     }
> 
> 
> }

Thanks, Jai. Yes, the reason I dropped those `final`s were they are not final. Anyway I got rid of `JdkConsoleProviderImpl` altogether, as we know this is the last resort impl, so no need to have `ServiceLoader` to instantiate it.

-------------

PR: https://git.openjdk.org/jdk/pull/11729

From naoto at openjdk.org  Tue Dec 20 22:13:50 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 20 Dec 2022 22:13:50 GMT
Subject: RFR: 8298971: Move Console implementation into jdk internal
 package [v2]
In-Reply-To: <ht1TrKJvRoq4nkRqZ_6-Gl2CJ9kUbAdO4SSURvm2CF4=.8b0c0940-b380-4d97-a9bf-b1dc923baff0@github.com>
References: <HB71j22Ejn5KPT1ahxstZMORHL0SDSoHVsuYIESGgCQ=.681ab0d7-e2af-45e1-b6b7-e978877475a5@github.com>
 <ht1TrKJvRoq4nkRqZ_6-Gl2CJ9kUbAdO4SSURvm2CF4=.8b0c0940-b380-4d97-a9bf-b1dc923baff0@github.com>
Message-ID: <6LYmiD718PwZbHCLdZmTxWwIYoAYTA3S73dafWdFdT8=.0c6f4657-f6a4-4ef4-8474-8e5edad40b6c@github.com>

On Tue, 20 Dec 2022 14:24:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed JdkConsoleProviderImpl, caching INSTANCE
>
> src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 336:
> 
>> 334:     public JdkConsole console(boolean isTTY, Charset charset) {
>> 335:         if (isTTY) {
>> 336:             if (INSTANCE == null) {
> 
> This would need a double checked locking, isn't it? Something like:
> 
> if (INSTANCE == null) {
>    synchronized (JdkConsoleImpl.class) {
>       if (INSTANCE != null) {
>           return INSTANCE;
>       }
>       ...// rest of the current code that's in if block
> 
> 
> Having said that perhaps the singleton instance isn't needed here and the `java.io.Console` deal with the caching?

You are right. `JdkConsoleImpl` is instantiated within the static initializer of `Console`, there is no need to cache it. `Console.cons` is guaranteed to be a singleton. Removed tha caching altogther.

-------------

PR: https://git.openjdk.org/jdk/pull/11729

From mchung at openjdk.org  Tue Dec 20 23:18:49 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 20 Dec 2022 23:18:49 GMT
Subject: RFR: 8298875: A module requiring "java.base" with flags
 ACC_SYNTHETIC should be rejected
In-Reply-To: <hFS1P8AQtGocnj-mPM7ShSKel9iLl7xxMwIjlmwCXqA=.f7b7da46-1df4-4706-9ee8-47ba200fac9d@github.com>
References: <hFS1P8AQtGocnj-mPM7ShSKel9iLl7xxMwIjlmwCXqA=.f7b7da46-1df4-4706-9ee8-47ba200fac9d@github.com>
Message-ID: <_9t5JsU8dL7Xre5kkHIJ401RVNdDZ4HJqFYTrANc1fA=.90995fd7-6d39-4d99-b15e-6362f33bd88f@github.com>

On Fri, 16 Dec 2022 19:30:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> A small oversight with ModuleDescriptor.read when checking the requires table of a Module attribute. The requires entry for java.base should not have ACC_SYNTHETIC set.
> 
> A new test is added. Some of the existing tests used `@Test(expectedExceptions=...)`. I've changed some of these to use assertThrows to narrow it down to method that is expected to throw.

This change looks good.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11714

From honkar at openjdk.org  Tue Dec 20 23:34:32 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 20 Dec 2022 23:34:32 GMT
Subject: RFR: JDK-8299052: ViewportOverlapping test fails on Win10 & Win11
Message-ID: <ZJOwyL6GVkhkOZAMX3dlI8ZCABXk0bC0KYwcw96YAxw=.6beb9013-2ed7-4764-b7c2-ce0a8e5deaed@github.com>

ViewportOverlapping was failing intermittently on Windows (Win10 & 11). Added robot.setAutoWaitForIdle() to ViewportOverlapping and its base class (OverlappingTestBase) to stabilize the test.

Additionally added awt & swings tests to exclusiveAccess.dir in TEST.ROOT.

-------------

Commit messages:
 - updated copyright year
 - problemlist change
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/11747/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11747&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299052
  Stats: 22 lines in 4 files changed: 9 ins; 3 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/11747.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11747/head:pull/11747

PR: https://git.openjdk.org/jdk/pull/11747

From sviswanathan at openjdk.org  Wed Dec 21 00:14:54 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 21 Dec 2022 00:14:54 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v13]
In-Reply-To: <a_7dEeMU-LeSDU1irFR-zAjfM_zKhnosJmEe19TyQsA=.d94df28d-8a97-4463-a3f5-e5e39d6b21e4@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <pW8HHmh-dQnjrRftd052fBQVulqe_z5KldY76Hp-OmI=.a7a2b6e6-a182-45d2-bd11-16a406126482@github.com>
 <6lAQI6kDDTGbskylHcWReX8ExaB6qkwgqoai7E6ikZY=.8a69a63c-453d-4bbd-8c76-4d477bfb77fe@github.com>
 <mAsTs03BWlAM_YhHXHBNsaJIQqrX95deQyYAYkJwrmE=.7e36f69c-dffc-462a-bf8a-7614153bf8c4@github.com>
 <PrXrcgFzP4mr0ZI5WrUizT0Sz_wtTl6AJLS_mvW89dQ=.ae6c18d4-8f5e-48cf-b0bf-8d8db7852346@github.com>
 <a_7dEeMU-LeSDU1irFR-zAjfM_zKhnosJmEe19TyQsA=.d94df28d-8a97-4463-a3f5-e5e39d6b21e4@github.com>
Message-ID: <HcQ7WJUZIa-jvv-COz7L3XGOLqMkV5fHf_l-4tmdj6k=.8ba6ebce-b84c-4bfd-954d-44ca693421b8@github.com>

On Tue, 20 Dec 2022 21:11:18 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>>> How far off is this ...?
>> 
>> Back then it looked way too constrained (tight constraints on code shapes). But I considered it as a generally applicable optimization. 
>> 
>>>  ... do you think it'll be able to match the efficiency we see here with a memoized coefficient table etc?
>> 
>> Yes, it is able to build the constant table at runtime when folding multiplications of constant coefficients produced during loop unrolling and then packing scalars into a constant vector.
>> 
>> Moreover, briefly looking at the code shape, the vectorizer would produce a more optimal loop shape (pre-loop would align vector accesses and would use 512-bit vectors when available; vector post-loop could help as well).
>
> Passing the constant node through as an input as suggested by @iwanowww and @sviswa7 meant we could eliminate most of the `instruct` blocks, removing a significant chunk of code and a little bit of complexity from the proposed patch.

@cl4es Thanks for passing the constant node through, the code looks much cleaner now. The attached patch should handle the signed bytes/shorts as well. Please take a look. 
[signed.patch](https://github.com/openjdk/jdk/files/10273480/signed.patch)

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From jpai at openjdk.org  Wed Dec 21 00:35:49 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 21 Dec 2022 00:35:49 GMT
Subject: RFR: 8298971: Move Console implementation into jdk internal
 package [v2]
In-Reply-To: <-TL5hqtIWKbqaq4APrH3xoPnvw87gn0Eq-AD4SgeZks=.fed3ca55-86b2-4b43-acf1-9b767e560508@github.com>
References: <HB71j22Ejn5KPT1ahxstZMORHL0SDSoHVsuYIESGgCQ=.681ab0d7-e2af-45e1-b6b7-e978877475a5@github.com>
 <-TL5hqtIWKbqaq4APrH3xoPnvw87gn0Eq-AD4SgeZks=.fed3ca55-86b2-4b43-acf1-9b767e560508@github.com>
Message-ID: <wWPJW4JrPFJC_HNJtlJFXH5AhXY5G-ZVu_FEd8yjVWc=.39f9cd04-2cd4-414b-b799-f9fdc052b901@github.com>

On Tue, 20 Dec 2022 22:06:26 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Moving the built-in implementation of `Console` from `java.io` package into `jdk.internal.io` package. It now implements `JdkConsole` interface and is accessed through `ProxyingConsole`.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed JdkConsoleProviderImpl, caching INSTANCE

Thank you for these changes Naoto. This version looks much simpler. The changes look good to me.

I'm not knowledgeable in C or JNI code, but in this case it's just moving the existing code from one file to another, so looks good to me.

I've just one minor nit that I've added inline.

src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 166:

> 164:     @Override
> 165:     public Charset charset() {
> 166:         assert charset != null : "charset() should not return null";

Maybe we could add a `Objects.requireNonNull(charset)` in the constructor of this `JdkConsoleImpl` and remove this `assert`, since `charset` is `final`?

-------------

Marked as reviewed by jpai (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11729

From jpai at openjdk.org  Wed Dec 21 01:14:49 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 21 Dec 2022 01:14:49 GMT
Subject: RFR: JDK-8299052: ViewportOverlapping test fails intermittently on
 Win10 & Win11
In-Reply-To: <ZJOwyL6GVkhkOZAMX3dlI8ZCABXk0bC0KYwcw96YAxw=.6beb9013-2ed7-4764-b7c2-ce0a8e5deaed@github.com>
References: <ZJOwyL6GVkhkOZAMX3dlI8ZCABXk0bC0KYwcw96YAxw=.6beb9013-2ed7-4764-b7c2-ce0a8e5deaed@github.com>
Message-ID: <m3z28VJnQEMM38GGtwCj_AQsiHZr62IBBHKGg-cnL7s=.14543ee8-4371-4f79-a2ec-a238ea708c19@github.com>

On Tue, 20 Dec 2022 23:25:30 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> ViewportOverlapping was failing intermittently on Windows (Win10 & 11). Added robot.setAutoWaitForIdle() to ViewportOverlapping and its base class (OverlappingTestBase) to stabilize the test.
> 
> Additionally added awt & swings tests to exclusiveAccess.dir in TEST.ROOT.

test/jdk/TEST.ROOT line 36:

> 34: com/sun/net/httpserver/simpleserver \
> 35: java/awt \
> 36: javax/swing

Hello Harshitha, I don't have any knowledge of the client area, but I see that there are a large number of tests that are present in `test/jdk/java/awt` and `test/jdk/javax/swing`. Adding these 2 directories to `exclusiveAccess.dirs` would mean that none of the tests in `java/awt` will be run when any other test in `java/awt` is currently in progress. Same with the `javax/swing` directory. So it could increase the duration of the tiers in which these tests run. Is there a CI run which shows if this changes the test run duration drastically?

-------------

PR: https://git.openjdk.org/jdk/pull/11747

From sviswanathan at openjdk.org  Wed Dec 21 01:58:59 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 21 Dec 2022 01:58:59 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v14]
In-Reply-To: <fU9foJNSAmSImvl8PN0di4DTJc30iMSaOAPPf0tm290=.95de7241-ea06-4a51-9c5e-c3acf260f83f@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <fU9foJNSAmSImvl8PN0di4DTJc30iMSaOAPPf0tm290=.95de7241-ea06-4a51-9c5e-c3acf260f83f@github.com>
Message-ID: <-qoflnp34219qc7cA_xaazdxkbFkEOzdZfCbOeYPCxA=.5f57ad5e-a099-425d-81e1-87e2eda09cf2@github.com>

On Tue, 20 Dec 2022 21:11:40 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
>> 
>> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
>> 
>> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
>> 
>> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
>> 
>> With the most recent fixes the x64 intrinsic results on my workstation look like this:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
>> 
>> Baseline:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
>> 
>> I.e. no measurable overhead compared to baseline even for `size == 1`.
>> 
>> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
>> 
>> Benchmark for `Arrays.hashCode`:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
>> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
>> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
>> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
>> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
>> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
>> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
>> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
>> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
>> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
>> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
>> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
>> 
>> Baseline:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
>> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
>> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
>> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
>> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
>> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
>> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
>> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
>> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
>> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
>> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
>> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
>> 
>> 
>> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.
>
> Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 64 commits:
> 
>  - Pass the constant mode node through, removing need for all but one instruct declarations
>  - FLAG_SET_DEFAULT
>  - Merge branch 'master' into 8282664-polyhash
>  - Merge branch 'master' into 8282664-polyhash
>  - Missing & 0xff in StringLatin1::hashCode
>  - Qualified guess on shenandoahSupport fix-up
>  - Whitespace
>  - Final touch-ups, restored 2-stride with dependency chain breakage
>  - Minor cleanup
>  - Revert accidental ModuleHashes change
>  - ... and 54 more: https://git.openjdk.org/jdk/compare/8dfb6d76...c9e7c561

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 3420:

> 3418:   arrays_hashcode_elload(tmp3, Address(ary1, index, Address::times(elsize), -elsize), eltype, is_string_hashcode);
> 3419:   addl(result, tmp3);
> 3420:   jmp(END);

This jmp can be removed.

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From sviswanathan at openjdk.org  Wed Dec 21 01:59:01 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 21 Dec 2022 01:59:01 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v13]
In-Reply-To: <xEjDlEzYJlPt8HhGk9xE6z57yAwT246Nl0yNpMP3riI=.9aca27c6-348f-4ad2-bff3-4e0262053135@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <pW8HHmh-dQnjrRftd052fBQVulqe_z5KldY76Hp-OmI=.a7a2b6e6-a182-45d2-bd11-16a406126482@github.com>
 <_2HYrbXOe6zVuLXHywoy_AjCcGMYR266BcwKUZEA5fs=.1e6f7640-7580-4ff3-ace6-f18f27efbb23@github.com>
 <xEjDlEzYJlPt8HhGk9xE6z57yAwT246Nl0yNpMP3riI=.9aca27c6-348f-4ad2-bff3-4e0262053135@github.com>
Message-ID: <2l2l7-2EKQr3UORegtVHtWN0uf9AUH8awtUPvC0MfS0=.8f94982f-f399-4ffd-b494-117cb73bf606@github.com>

On Tue, 20 Dec 2022 19:52:34 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/StringUTF16.java line 418:
>> 
>>> 416:             return 0;
>>> 417:         } else {
>>> 418:             return ArraysSupport.vectorizedHashCode(value, ArraysSupport.UTF16);
>> 
>> Special case for 1 missing here.
>
> Intentionally left out. Array length is always even for `UTF16` arrays, but we could add a case for `2` that'd return `getChar(bytes, 0)` but I didn't see much of a win when I tested this.

I do see a 1.5x gain with this special case added:
       return switch (value.length) {
            case 0 -> 0;
            case 2 -> getChar(value, 0);
            default -> ArraysSupport.vectorizedHashCode(value, ArraysSupport.UTF16);
        };
before: 0.987 ns/op 
after: 0.640 ns/op

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From naoto at openjdk.org  Wed Dec 21 02:30:21 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 21 Dec 2022 02:30:21 GMT
Subject: RFR: 8298971: Move Console implementation into jdk internal
 package [v3]
In-Reply-To: <HB71j22Ejn5KPT1ahxstZMORHL0SDSoHVsuYIESGgCQ=.681ab0d7-e2af-45e1-b6b7-e978877475a5@github.com>
References: <HB71j22Ejn5KPT1ahxstZMORHL0SDSoHVsuYIESGgCQ=.681ab0d7-e2af-45e1-b6b7-e978877475a5@github.com>
Message-ID: <HuPy3jVf8Bw6n2rUdoPT0pbvWlBxQicubMtUi82hS7Q=.f35f38f6-d987-46c3-afc7-dc36f77f8b31@github.com>

> Moving the built-in implementation of `Console` from `java.io` package into `jdk.internal.io` package. It now implements `JdkConsole` interface and is accessed through `ProxyingConsole`.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Replaced assert with requireNonNull

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11729/files
  - new: https://git.openjdk.org/jdk/pull/11729/files/777c0dc0..1f6b4f4f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11729&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11729&range=01-02

  Stats: 4 lines in 1 file changed: 3 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11729.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11729/head:pull/11729

PR: https://git.openjdk.org/jdk/pull/11729

From naoto at openjdk.org  Wed Dec 21 02:30:22 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 21 Dec 2022 02:30:22 GMT
Subject: RFR: 8298971: Move Console implementation into jdk internal
 package [v2]
In-Reply-To: <wWPJW4JrPFJC_HNJtlJFXH5AhXY5G-ZVu_FEd8yjVWc=.39f9cd04-2cd4-414b-b799-f9fdc052b901@github.com>
References: <HB71j22Ejn5KPT1ahxstZMORHL0SDSoHVsuYIESGgCQ=.681ab0d7-e2af-45e1-b6b7-e978877475a5@github.com>
 <-TL5hqtIWKbqaq4APrH3xoPnvw87gn0Eq-AD4SgeZks=.fed3ca55-86b2-4b43-acf1-9b767e560508@github.com>
 <wWPJW4JrPFJC_HNJtlJFXH5AhXY5G-ZVu_FEd8yjVWc=.39f9cd04-2cd4-414b-b799-f9fdc052b901@github.com>
Message-ID: <aH3TKyI_ovajG5Euh0SNmkxsnhgbuJ-85GYCO8NIwVs=.86855b8c-4db4-4c22-a784-e922e2ed82e6@github.com>

On Wed, 21 Dec 2022 00:33:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed JdkConsoleProviderImpl, caching INSTANCE
>
> src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 166:
> 
>> 164:     @Override
>> 165:     public Charset charset() {
>> 166:         assert charset != null : "charset() should not return null";
> 
> Maybe we could add a `Objects.requireNonNull(charset)` in the constructor of this `JdkConsoleImpl` and remove this `assert`, since `charset` is `final`?

Good point. Replaced `assert` with `Objects.requireNonNull(charset)`

-------------

PR: https://git.openjdk.org/jdk/pull/11729

From jpai at openjdk.org  Wed Dec 21 04:47:48 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 21 Dec 2022 04:47:48 GMT
Subject: RFR: 8298971: Move Console implementation into jdk internal
 package [v3]
In-Reply-To: <HuPy3jVf8Bw6n2rUdoPT0pbvWlBxQicubMtUi82hS7Q=.f35f38f6-d987-46c3-afc7-dc36f77f8b31@github.com>
References: <HB71j22Ejn5KPT1ahxstZMORHL0SDSoHVsuYIESGgCQ=.681ab0d7-e2af-45e1-b6b7-e978877475a5@github.com>
 <HuPy3jVf8Bw6n2rUdoPT0pbvWlBxQicubMtUi82hS7Q=.f35f38f6-d987-46c3-afc7-dc36f77f8b31@github.com>
Message-ID: <zvnCFI2N0QxdlHdTHPX9Eu5Wwpn7xXANh-QRv6y-UAw=.abfbab5b-5413-45a2-858d-6c842608ef5e@github.com>

On Wed, 21 Dec 2022 02:30:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Moving the built-in implementation of `Console` from `java.io` package into `jdk.internal.io` package. It now implements `JdkConsole` interface and is accessed through `ProxyingConsole`.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replaced assert with requireNonNull

Marked as reviewed by jpai (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11729

From ssahoo at openjdk.org  Wed Dec 21 05:32:52 2022
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Wed, 21 Dec 2022 05:32:52 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v6]
In-Reply-To: <J2eQc_SMfteNYRozU44midnVyt2Kdqmic39U4QFoGd0=.3c9049d3-7624-4a80-8d9b-002072c73cd5@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <J2eQc_SMfteNYRozU44midnVyt2Kdqmic39U4QFoGd0=.3c9049d3-7624-4a80-8d9b-002072c73cd5@github.com>
Message-ID: <9qHBH4y4aFfz5kjAB-2E_qeDbR_hHZu37eAFSznLm_k=.833859a4-01bf-4244-abb0-79e22901fb44@github.com>

On Tue, 20 Dec 2022 19:23:10 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task converts 5 manual tests to automated tests.
>> 
>> sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java 
>> sun/security/provider/PolicyParser/ExtDirsChange.java 
>> sun/security/provider/PolicyParser/ExtDirs.java 
>> java/security/Policy/Root/Root.javajava/security/Policy/Root/Root.java 
>> javax/crypto/CryptoPermissions/InconsistentEntries.java
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments.

Marked as reviewed by ssahoo (Committer).

-------------

PR: https://git.openjdk.org/jdk/pull/10637

From ssahoo at openjdk.org  Wed Dec 21 05:32:54 2022
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Wed, 21 Dec 2022 05:32:54 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v5]
In-Reply-To: <XyDXua4yOaC8Jul8EY-7-KETHCJeCUqdkPtvOoO4ib0=.c488518f-35b2-46a6-92f7-b86d8da84943@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <uw2kQJPBcg5iPyVZGL-BiSMkIK7S2htYcOyOTSi_1-w=.2b19fdf9-5978-4ded-b2e9-3d228c586fd6@github.com>
 <uDwwI-PKA1x-jZ1noAhf3jmID9VyD2fBeBGYfs__wpg=.05c55abe-673f-4aac-86d3-35c9c51ad3cf@github.com>
 <XyDXua4yOaC8Jul8EY-7-KETHCJeCUqdkPtvOoO4ib0=.c488518f-35b2-46a6-92f7-b86d8da84943@github.com>
Message-ID: <EYdknAXN1rmWTizxAkSFplPjCuDlpurVCyOfQI02YLo=.4d5933d2-d3d1-47dc-9338-846355f41163@github.com>

On Tue, 20 Dec 2022 19:05:13 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> test/jdk/javax/crypto/CryptoPermissions/InconsistentEntries.java line 52:
>> 
>>> 50:     private static final String JDK_HOME = System.getProperty("test.jdk");
>>> 51:     private static final String TEST_SRC = System.getProperty("test.src");
>>> 52:     private static final Path POLICY_DIR = Paths.get(JDK_HOME, "conf", "security",
>> 
>> This doesn't looks like a safe Test to be automated. Can it create conflict with any other existing Test requiring "testlimited" with  default_local.policy? This need to be verified. Also changing anything inside an installed JDK probably not a good choice. It's just a thought from my side and it could be different for others.
>
> Good points. I searched the entire repo and this is the only instance that uses the "testlimited" with default_local.policy. Looking over the logic, the test sets the crypto.policy property to "testlimited". So I am wondering if the "testlimited" is created for test purposes. If so, are we allowed to rename "testlimited" to be more specific, eg. "testcryptoperms"? 
> `Security.setProperty("crypto.policy", "testlimited");`

As long as it create no conflict with other Tests at runtime.. i am fine to keep it same.

-------------

PR: https://git.openjdk.org/jdk/pull/10637

From aturbanov at openjdk.org  Wed Dec 21 11:20:51 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 21 Dec 2022 11:20:51 GMT
Subject: RFR: 8298971: Move Console implementation into jdk internal
 package [v3]
In-Reply-To: <HuPy3jVf8Bw6n2rUdoPT0pbvWlBxQicubMtUi82hS7Q=.f35f38f6-d987-46c3-afc7-dc36f77f8b31@github.com>
References: <HB71j22Ejn5KPT1ahxstZMORHL0SDSoHVsuYIESGgCQ=.681ab0d7-e2af-45e1-b6b7-e978877475a5@github.com>
 <HuPy3jVf8Bw6n2rUdoPT0pbvWlBxQicubMtUi82hS7Q=.f35f38f6-d987-46c3-afc7-dc36f77f8b31@github.com>
Message-ID: <ClxKUwSIBMxYv-i6FVxAsLFLA6ezdz-EzNf11ilCjoQ=.bbabd3ae-901d-4314-85d0-c2cd32eee917@github.com>

On Wed, 21 Dec 2022 02:30:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Moving the built-in implementation of `Console` from `java.io` package into `jdk.internal.io` package. It now implements `JdkConsole` interface and is accessed through `ProxyingConsole`.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replaced assert with requireNonNull

src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 60:

> 58: 
> 59:     @Override
> 60:     public JdkConsole format(String fmt, Object ...args) {

Nit:
Suggestion:

    public JdkConsole format(String fmt, Object ... args) {

-------------

PR: https://git.openjdk.org/jdk/pull/11729

From aturbanov at openjdk.org  Wed Dec 21 11:27:53 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 21 Dec 2022 11:27:53 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v2]
In-Reply-To: <L0YQ-HpkzstQ-kaNwoO3BxLqgcluDK5Lzt8R9c9ZGSs=.637129c6-047c-4197-8ed2-70d0a203ec90@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <L0YQ-HpkzstQ-kaNwoO3BxLqgcluDK5Lzt8R9c9ZGSs=.637129c6-047c-4197-8ed2-70d0a203ec90@github.com>
Message-ID: <oftmdk5A6rGAHm4W3xDHpZqClT49BU1k9c00ukQjSQs=.538b3026-5015-498d-9f49-a93746d87b94@github.com>

On Mon, 12 Dec 2022 20:53:27 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> This is an approach to adding a flag to jlink that will allow --compress to take the same types of arguments as jmod, thus bringing the two into alignment. This likely requires a CSR and a discussion on whether we should deprecate or simply remove the original numeric compression arguments.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Swapping deprecations in properties

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/DefaultCompressPlugin.java line 106:

> 104:                     break;
> 105:                 default:
> 106:                     if(level.length() == 5 && level.startsWith("zip-")) {

Suggestion:

                    if (level.length() == 5 && level.startsWith("zip-")) {

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From itakiguchi at openjdk.org  Wed Dec 21 16:05:25 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Wed, 21 Dec 2022 16:05:25 GMT
Subject: RFR: 8299194: CustomTzIDCheckDST.java may fail at future date
Message-ID: <WLaw7cFwSjOG5fYL5QXPjGUxemrk37_SN2fSBxFkmjY=.e2602944-b688-4d04-98e3-5b0ec0fa787c@github.com>

test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java may fail at future date.
I used following standalone testcase

import java.util.Calendar;
import java.util.Date;
import java.util.SimpleTimeZone;

public class CheckDST {
????private static String CUSTOM_TZ = "MEZ-1MESZ,M3.5.0,M10.5.0";
????public static void main(String args[]) throws Throwable {
????????runTZTest();
????}

????/* TZ code will always be set to "MEZ-1MESZ,M3.5.0,M10.5.0".
?????* This ensures the transition periods for Daylights Savings should be at March's last
?????* Sunday and October's last Sunday.
?????*/
????private static void runTZTest() {
????????Date time = new Date();
????????if (new SimpleTimeZone(3600000, "MEZ-1MESZ", Calendar.MARCH, -1, Calendar.SUNDAY, 0,
????????????????Calendar.OCTOBER, -1, Calendar.SUNDAY, 0).inDaylightTime(time)) {
????????????// We are in Daylight savings period.
????????????if (time.toString().endsWith("GMT+02:00 " + Integer.toString(time.getYear() + 1900)))
????????????????return;
????????} else {
????????????if (time.toString().endsWith("GMT+01:00 " + Integer.toString(time.getYear() + 1900)))
????????????????return;
????????}

????????// Reaching here means time zone did not match up as expected.
????????throw new RuntimeException("Got unexpected timezone information: " + time);
????}
}


I tested CheckDST with faketime, then I got following results

$ TZ=GMT faketime -m "2023-03-25 22:59:59" env TZ="MEZ-1MESZ,M3.5.0,M10.5.0" $HOME/jdk-21-b02/bin/java CheckDST
$ TZ=GMT faketime -m "2023-03-25 23:00:00" env TZ="MEZ-1MESZ,M3.5.0,M10.5.0" $HOME/jdk-21-b02/bin/java CheckDST
Exception in thread "main" java.lang.RuntimeException: Got unexpected timezone information: Sun Mar 26 00:00:00 GMT+01:00 2023
????????at CheckDST.runTZTest(CheckDST.java:28)
????????at CheckDST.main(CheckDST.java:8)


I assume `TZ=MEZ-1MESZ`refers Europe/Berlin timezone.
In this case, `TZ` environment variable should be `MEZ-1MESZ,M3.5.0,M10.5.0/3` (`/3` is missing in testcase)

CustomTzIDCheckDST should run with daylight saving time.
Add Simulate Southern Hemisphere by `MEZ-1MESZ,M10.5.0,M3.5.0/3`

Tested by standalone testcase

$ cat CheckDST1.java
import java.util.Calendar;
import java.util.Date;
import java.util.List;
import java.util.SimpleTimeZone;
import java.util.TimeZone;
import java.time.DayOfWeek;
import java.time.ZonedDateTime;
import java.time.temporal.TemporalAdjusters;
public class CheckDST1 {
    // Northern Hemisphere
    private static String CUSTOM_TZ = "MEZ-1MESZ,M3.5.0,M10.5.0/3";
    // Simulate Southern Hemisphere
    private static String CUSTOM_TZ2 = "MEZ-1MESZ,M10.5.0,M3.5.0/3";
    public static void main(String args[]) throws Throwable {
        runTZTest();
    }

    /* TZ code will always be set to "MEZ-1MESZ,M3.5.0,M10.5.0/3".
     * This ensures the transition periods for Daylights Savings should be at March's last
     * Sunday and October's last Sunday.
     */
    private static void runTZTest() {
        Date time = new Date();
        String tzStr = System.getenv("TZ");
        if (tzStr == null)
            throw new RuntimeException("Got unexpected timezone information: TZ is null");
        boolean nor = tzStr.matches(".*,M3\..*,M10\..*");
        TimeZone tz = new SimpleTimeZone(3600000, tzStr,
            nor ? Calendar.MARCH : Calendar.OCTOBER, -1,
            Calendar.SUNDAY, 3600000, SimpleTimeZone.UTC_TIME,
            nor ? Calendar.OCTOBER : Calendar.MARCH, -1,
            Calendar.SUNDAY, 3600000, SimpleTimeZone.UTC_TIME,
            3600000);
        System.out.println(time);
        if (tz.inDaylightTime(time)) {
            // We are in Daylight savings period.
            if (time.toString().endsWith("GMT+02:00 " + Integer.toString(time.getYear() + 1900)))
                return;
        } else {
            if (time.toString().endsWith("GMT+01:00 " + Integer.toString(time.getYear() + 1900)))
                return;
        }

        // Reaching here means time zone did not match up as expected.
        throw new RuntimeException("Got unexpected timezone information: " + tzStr + " " + time);
    }

    private static ZonedDateTime getLastSundayOfMonth(ZonedDateTime date) {
        return date.with(TemporalAdjusters.lastInMonth(DayOfWeek.SUNDAY));
    }
}


Check Europe/Berlin timezone settings

$ zdump -v Europe/Berlin | grep 2023
Europe/Berlin  Sun Mar 26 00:59:59 2023 UTC = Sun Mar 26 01:59:59 2023 CET isdst=0 gmtoff=3600
Europe/Berlin  Sun Mar 26 01:00:00 2023 UTC = Sun Mar 26 03:00:00 2023 CEST isdst=1 gmtoff=7200
Europe/Berlin  Sun Oct 29 00:59:59 2023 UTC = Sun Oct 29 02:59:59 2023 CEST isdst=1 gmtoff=7200
Europe/Berlin  Sun Oct 29 01:00:00 2023 UTC = Sun Oct 29 02:00:00 2023 CET isdst=0 gmtoff=3600


Test results are as follows:

Northern Hemisphere side

$ TZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
Sun Mar 26 01:59:59 MEZ 2023
$ TZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
Sun Mar 26 01:59:59 GMT+01:00 2023

$ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
Sun Mar 26 03:00:00 MESZ 2023
$ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
Sun Mar 26 03:00:00 GMT+02:00 2023

$ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
Sun Oct 29 02:59:59 MESZ 2023
$ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
Sun Oct 29 02:59:59 GMT+02:00 2023

$ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
Sun Oct 29 02:00:00 MEZ 2023
$ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
Sun Oct 29 02:00:00 GMT+01:00 2023


Southern Hemisphere

$ TZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
Sun Mar 26 02:59:59 MESZ 2023
$bTZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
Sun Mar 26 02:59:59 GMT+02:00 2023

$ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
Sun Mar 26 02:00:00 MEZ 2023
$ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
Sun Mar 26 02:00:00 GMT+01:00 2023

$ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
Sun Oct 29 01:59:59 MEZ 2023
$ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
Sun Oct 29 01:59:59 GMT+01:00 2023

$ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
Sun Oct 29 03:00:00 MESZ 2023
$ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
Sun Oct 29 03:00:00 GMT+02:00 2023

-------------

Commit messages:
 - 8299194: CustomTzIDCheckDST.java may fail at future date

Changes: https://git.openjdk.org/jdk/pull/11756/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11756&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299194
  Stats: 21 lines in 1 file changed: 16 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/11756.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11756/head:pull/11756

PR: https://git.openjdk.org/jdk/pull/11756

From redestad at openjdk.org  Wed Dec 21 17:01:17 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 21 Dec 2022 17:01:17 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v15]
In-Reply-To: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
Message-ID: <IXuNCeg52JvoM46OEEbYH6jBsNIdcGpQJxHFUpUom8k=.77f5ffc6-9b3b-42f5-81af-7be02542d4cc@github.com>

> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
> 
> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
> 
> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
> 
> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
> 
> With the most recent fixes the x64 intrinsic results on my workstation look like this:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
> 
> Baseline:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
> 
> I.e. no measurable overhead compared to baseline even for `size == 1`.
> 
> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
> 
> Benchmark for `Arrays.hashCode`:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
> 
> Baseline:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
> 
> 
> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.

Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:

 - Handle signed subword arrays, contributed by @sviswa7
 - @sviswa7 comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10847/files
  - new: https://git.openjdk.org/jdk/pull/10847/files/c9e7c561..16733c4d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=13-14

  Stats: 51 lines in 3 files changed: 36 ins; 6 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/10847.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10847/head:pull/10847

PR: https://git.openjdk.org/jdk/pull/10847

From redestad at openjdk.org  Wed Dec 21 17:04:07 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 21 Dec 2022 17:04:07 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v14]
In-Reply-To: <-qoflnp34219qc7cA_xaazdxkbFkEOzdZfCbOeYPCxA=.5f57ad5e-a099-425d-81e1-87e2eda09cf2@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <fU9foJNSAmSImvl8PN0di4DTJc30iMSaOAPPf0tm290=.95de7241-ea06-4a51-9c5e-c3acf260f83f@github.com>
 <-qoflnp34219qc7cA_xaazdxkbFkEOzdZfCbOeYPCxA=.5f57ad5e-a099-425d-81e1-87e2eda09cf2@github.com>
Message-ID: <bclAawiKeVSb0AFZtA84gepj1BLL1twPZS0qOubFgfs=.15c44a2b-9085-46f3-a073-352dad5bf70c@github.com>

On Wed, 21 Dec 2022 01:02:35 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 64 commits:
>> 
>>  - Pass the constant mode node through, removing need for all but one instruct declarations
>>  - FLAG_SET_DEFAULT
>>  - Merge branch 'master' into 8282664-polyhash
>>  - Merge branch 'master' into 8282664-polyhash
>>  - Missing & 0xff in StringLatin1::hashCode
>>  - Qualified guess on shenandoahSupport fix-up
>>  - Whitespace
>>  - Final touch-ups, restored 2-stride with dependency chain breakage
>>  - Minor cleanup
>>  - Revert accidental ModuleHashes change
>>  - ... and 54 more: https://git.openjdk.org/jdk/compare/8dfb6d76...c9e7c561
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 3420:
> 
>> 3418:   arrays_hashcode_elload(tmp3, Address(ary1, index, Address::times(elsize), -elsize), eltype, is_string_hashcode);
>> 3419:   addl(result, tmp3);
>> 3420:   jmp(END);
> 
> This jmp can be removed.

Ok, special-cased for `value.length == 2`, removed the superfluous `jmp`, and committed your patch to implement the vectorization for `short`s and signed `byte`s.

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From honkar at openjdk.org  Wed Dec 21 17:27:57 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 21 Dec 2022 17:27:57 GMT
Subject: RFR: JDK-8299052: ViewportOverlapping test fails intermittently on
 Win10 & Win11
In-Reply-To: <m3z28VJnQEMM38GGtwCj_AQsiHZr62IBBHKGg-cnL7s=.14543ee8-4371-4f79-a2ec-a238ea708c19@github.com>
References: <ZJOwyL6GVkhkOZAMX3dlI8ZCABXk0bC0KYwcw96YAxw=.6beb9013-2ed7-4764-b7c2-ce0a8e5deaed@github.com>
 <m3z28VJnQEMM38GGtwCj_AQsiHZr62IBBHKGg-cnL7s=.14543ee8-4371-4f79-a2ec-a238ea708c19@github.com>
Message-ID: <lmAhQF7EiYZIrlh96_1ok58GPeak2LWG3afAfP4XolQ=.c07eaf59-0849-42b5-b25d-ff32eb2c5547@github.com>

On Wed, 21 Dec 2022 01:12:12 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> ViewportOverlapping was failing intermittently on Windows (Win10 & 11). Added robot.setAutoWaitForIdle() to ViewportOverlapping and its base class (OverlappingTestBase) to stabilize the test.
>> 
>> Additionally added awt & swings tests to exclusiveAccess.dir in TEST.ROOT.
>
> test/jdk/TEST.ROOT line 36:
> 
>> 34: com/sun/net/httpserver/simpleserver \
>> 35: java/awt \
>> 36: javax/swing
> 
> Hello Harshitha, I don't have any knowledge of the client area, but I see that there are a large number of tests that are present in `test/jdk/java/awt` and `test/jdk/javax/swing`. Adding these 2 directories to `exclusiveAccess.dirs` would mean that none of the tests in `java/awt` will be run when any other test in `java/awt` is currently in progress. Same with the `javax/swing` directory. So it could increase the duration of the tiers in which these tests run. Is there a CI run which shows if this changes the test run duration drastically?

@jaikiran Thank you for the details. I'll check if the duration of run differed drastically. I thought all the client tests run in non-concurrent mode by default or does this differ for headful and headless test?

-------------

PR: https://git.openjdk.org/jdk/pull/11747

From redestad at openjdk.org  Wed Dec 21 17:29:23 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 21 Dec 2022 17:29:23 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v16]
In-Reply-To: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
Message-ID: <cPQkHqc5OHG2ytU7dCawy438CddgDCTQFzHvjloUxaE=.3216df79-1f3f-45e9-97c0-acb5a304b1ae@github.com>

> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
> 
> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
> 
> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
> 
> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
> 
> With the most recent fixes the x64 intrinsic results on my workstation look like this:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
> 
> Baseline:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
> 
> I.e. no measurable overhead compared to baseline even for `size == 1`.
> 
> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
> 
> Benchmark for `Arrays.hashCode`:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
> 
> Baseline:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
> 
> 
> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Treat Op_VectorizedHashCode as other similar Ops in split_unique_types

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10847/files
  - new: https://git.openjdk.org/jdk/pull/10847/files/16733c4d..62e98e1b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=14-15

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10847.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10847/head:pull/10847

PR: https://git.openjdk.org/jdk/pull/10847

From naoto at openjdk.org  Wed Dec 21 17:40:23 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 21 Dec 2022 17:40:23 GMT
Subject: RFR: 8298971: Move Console implementation into jdk internal
 package [v4]
In-Reply-To: <HB71j22Ejn5KPT1ahxstZMORHL0SDSoHVsuYIESGgCQ=.681ab0d7-e2af-45e1-b6b7-e978877475a5@github.com>
References: <HB71j22Ejn5KPT1ahxstZMORHL0SDSoHVsuYIESGgCQ=.681ab0d7-e2af-45e1-b6b7-e978877475a5@github.com>
Message-ID: <BOUyxNin7r4meqvRfRWrECRsDD1e0ypAh5Ba2WuP_EQ=.a153a36c-09e5-4b8d-a3cc-3824b22bcf4e@github.com>

> Moving the built-in implementation of `Console` from `java.io` package into `jdk.internal.io` package. It now implements `JdkConsole` interface and is accessed through `ProxyingConsole`.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11729/files
  - new: https://git.openjdk.org/jdk/pull/11729/files/1f6b4f4f..86c20f1b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11729&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11729&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11729.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11729/head:pull/11729

PR: https://git.openjdk.org/jdk/pull/11729

From naoto at openjdk.org  Wed Dec 21 17:40:24 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 21 Dec 2022 17:40:24 GMT
Subject: RFR: 8298971: Move Console implementation into jdk internal
 package [v3]
In-Reply-To: <ClxKUwSIBMxYv-i6FVxAsLFLA6ezdz-EzNf11ilCjoQ=.bbabd3ae-901d-4314-85d0-c2cd32eee917@github.com>
References: <HB71j22Ejn5KPT1ahxstZMORHL0SDSoHVsuYIESGgCQ=.681ab0d7-e2af-45e1-b6b7-e978877475a5@github.com>
 <HuPy3jVf8Bw6n2rUdoPT0pbvWlBxQicubMtUi82hS7Q=.f35f38f6-d987-46c3-afc7-dc36f77f8b31@github.com>
 <ClxKUwSIBMxYv-i6FVxAsLFLA6ezdz-EzNf11ilCjoQ=.bbabd3ae-901d-4314-85d0-c2cd32eee917@github.com>
Message-ID: <75KnsHT0StbGZar60ssWF6-fCOVPYb0PIY10xTX1WV4=.4fa40a02-c082-4ed4-987a-fcd376c7bc56@github.com>

On Wed, 21 Dec 2022 11:18:25 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replaced assert with requireNonNull
>
> src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 60:
> 
>> 58: 
>> 59:     @Override
>> 60:     public JdkConsole format(String fmt, Object ...args) {
> 
> Nit:
> Suggestion:
> 
>     public JdkConsole format(String fmt, Object ... args) {

Thanks. Fix incorporated.

-------------

PR: https://git.openjdk.org/jdk/pull/11729

From naoto at openjdk.org  Wed Dec 21 18:12:58 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 21 Dec 2022 18:12:58 GMT
Subject: Integrated: 8298971: Move Console implementation into jdk internal
 package
In-Reply-To: <HB71j22Ejn5KPT1ahxstZMORHL0SDSoHVsuYIESGgCQ=.681ab0d7-e2af-45e1-b6b7-e978877475a5@github.com>
References: <HB71j22Ejn5KPT1ahxstZMORHL0SDSoHVsuYIESGgCQ=.681ab0d7-e2af-45e1-b6b7-e978877475a5@github.com>
Message-ID: <t3dujEsl__uXgvsh1oXpkqvfOqycuyo-Pg1X9NgQeKw=.805824f0-88d5-4880-a4c7-1ce4b2e47689@github.com>

On Mon, 19 Dec 2022 19:23:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Moving the built-in implementation of `Console` from `java.io` package into `jdk.internal.io` package. It now implements `JdkConsole` interface and is accessed through `ProxyingConsole`.

This pull request has now been integrated.

Changeset: 7e59a0ec
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7e59a0ecb672292814abdf7f2e31a5f5868c43d8
Stats:     157 lines in 4 files changed: 83 ins; 58 del; 16 mod

8298971: Move Console implementation into jdk internal package

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/11729

From sviswanathan at openjdk.org  Wed Dec 21 18:13:54 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 21 Dec 2022 18:13:54 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v16]
In-Reply-To: <cPQkHqc5OHG2ytU7dCawy438CddgDCTQFzHvjloUxaE=.3216df79-1f3f-45e9-97c0-acb5a304b1ae@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <cPQkHqc5OHG2ytU7dCawy438CddgDCTQFzHvjloUxaE=.3216df79-1f3f-45e9-97c0-acb5a304b1ae@github.com>
Message-ID: <fwuK3HPC0oiK1zhQnn7fg2oEgq-PZ00BVCmXbGHjx84=.3095e021-88bd-4f8a-a03f-2a66063d5b5b@github.com>

On Wed, 21 Dec 2022 17:29:23 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
>> 
>> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
>> 
>> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
>> 
>> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
>> 
>> With the most recent fixes the x64 intrinsic results on my workstation look like this:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
>> 
>> Baseline:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
>> 
>> I.e. no measurable overhead compared to baseline even for `size == 1`.
>> 
>> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
>> 
>> Benchmark for `Arrays.hashCode`:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
>> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
>> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
>> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
>> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
>> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
>> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
>> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
>> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
>> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
>> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
>> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
>> 
>> Baseline:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
>> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
>> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
>> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
>> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
>> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
>> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
>> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
>> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
>> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
>> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
>> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
>> 
>> 
>> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Treat Op_VectorizedHashCode as other similar Ops in split_unique_types

The PR looks good to me.

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10847

From rhalade at openjdk.org  Wed Dec 21 18:57:55 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 21 Dec 2022 18:57:55 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v6]
In-Reply-To: <J2eQc_SMfteNYRozU44midnVyt2Kdqmic39U4QFoGd0=.3c9049d3-7624-4a80-8d9b-002072c73cd5@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <J2eQc_SMfteNYRozU44midnVyt2Kdqmic39U4QFoGd0=.3c9049d3-7624-4a80-8d9b-002072c73cd5@github.com>
Message-ID: <bPVh_aHz398yv1Q5Qk48H_8ddTTkOxC3AkVOR-gDEkA=.666bc926-d579-4d75-a2bb-ccc9e6f032a4@github.com>

On Tue, 20 Dec 2022 19:23:10 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task converts 5 manual tests to automated tests.
>> 
>> sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java 
>> sun/security/provider/PolicyParser/ExtDirsChange.java 
>> sun/security/provider/PolicyParser/ExtDirs.java 
>> java/security/Policy/Root/Root.javajava/security/Policy/Root/Root.java 
>> javax/crypto/CryptoPermissions/InconsistentEntries.java
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments.

test/jdk/sun/security/provider/PolicyParser/ExtDirs.java line 33:

> 31: 
> 32: /*
> 33:  * @test

Why are these tags duplicated here?

-------------

PR: https://git.openjdk.org/jdk/pull/10637

From rhalade at openjdk.org  Wed Dec 21 18:57:57 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 21 Dec 2022 18:57:57 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v3]
In-Reply-To: <aCzEuNkifbMrbyl3CJkWfNqtBK45oFLV0gbVfPQ8kQw=.c82f097b-b74f-4266-98d8-0b6db933098e@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <_gtGeGQGY5V3HLRua2ryf6n4hkVg9gZ4y9wl0GPmTtw=.43cd512a-930c-4e44-94b8-25dedfe386b9@github.com>
 <3cpKUXzxJQ5c1sYqlZWiusWlVvS494Ya8u_x-RfdGXk=.cd3fbb26-cfc2-495c-a565-547c828f549d@github.com>
 <pA_X_gCTNuB9O0p9q-OczKmxNkD6y-Wcs1_JG00VpHk=.6219516c-1d4c-4f4d-b090-e28c2992ee96@github.com>
 <aCzEuNkifbMrbyl3CJkWfNqtBK45oFLV0gbVfPQ8kQw=.c82f097b-b74f-4266-98d8-0b6db933098e@github.com>
Message-ID: <ZZzxDukj_fA9LOPrVNIe6oeOmsuTrbFFEt_TpLuNAqk=.e7a6236b-cd17-407e-8679-81249907d385@github.com>

On Wed, 19 Oct 2022 16:49:33 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

>> Are you saying that we don't need to run the ExtDir2.policy and ExtDir3.policy?
>
> Its fine, ignore my previous comment.

you can add multiple run tags under same test tag, no need to repeat tag, bug, and summary tags.

-------------

PR: https://git.openjdk.org/jdk/pull/10637

From bhuang at openjdk.org  Wed Dec 21 20:00:51 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Wed, 21 Dec 2022 20:00:51 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v6]
In-Reply-To: <bPVh_aHz398yv1Q5Qk48H_8ddTTkOxC3AkVOR-gDEkA=.666bc926-d579-4d75-a2bb-ccc9e6f032a4@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <J2eQc_SMfteNYRozU44midnVyt2Kdqmic39U4QFoGd0=.3c9049d3-7624-4a80-8d9b-002072c73cd5@github.com>
 <bPVh_aHz398yv1Q5Qk48H_8ddTTkOxC3AkVOR-gDEkA=.666bc926-d579-4d75-a2bb-ccc9e6f032a4@github.com>
Message-ID: <biX2juSzVryWWGuHnrLeyzOHVH4zzUQhLGHwBgIlyKE=.0dd655b0-7f5c-4e61-bd17-8daba35fc110@github.com>

On Wed, 21 Dec 2022 18:51:32 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implemented review comments.
>
> test/jdk/sun/security/provider/PolicyParser/ExtDirs.java line 33:
> 
>> 31: 
>> 32: /*
>> 33:  * @test
> 
> Why are these tags duplicated here?

Multiple "run" in a single test fails the whole test when one test run fails and all subsequent test run get terminated. Multiple tests with only one "run" each allows all test run to be excused, and they can be run in parallel.

-------------

PR: https://git.openjdk.org/jdk/pull/10637

From aivanov at openjdk.org  Wed Dec 21 20:06:51 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 Dec 2022 20:06:51 GMT
Subject: RFR: JDK-8299052: ViewportOverlapping test fails intermittently on
 Win10 & Win11
In-Reply-To: <lmAhQF7EiYZIrlh96_1ok58GPeak2LWG3afAfP4XolQ=.c07eaf59-0849-42b5-b25d-ff32eb2c5547@github.com>
References: <ZJOwyL6GVkhkOZAMX3dlI8ZCABXk0bC0KYwcw96YAxw=.6beb9013-2ed7-4764-b7c2-ce0a8e5deaed@github.com>
 <m3z28VJnQEMM38GGtwCj_AQsiHZr62IBBHKGg-cnL7s=.14543ee8-4371-4f79-a2ec-a238ea708c19@github.com>
 <lmAhQF7EiYZIrlh96_1ok58GPeak2LWG3afAfP4XolQ=.c07eaf59-0849-42b5-b25d-ff32eb2c5547@github.com>
Message-ID: <W_HEgUOBCsJbzgbVW_WNWLgfgOAyqVI05WNAzeQYIrg=.ea10afc2-3854-4ad8-9ebe-fbd00fec52ce@github.com>

On Wed, 21 Dec 2022 17:25:20 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/TEST.ROOT line 36:
>> 
>>> 34: com/sun/net/httpserver/simpleserver \
>>> 35: java/awt \
>>> 36: javax/swing
>> 
>> Hello Harshitha, I don't have any knowledge of the client area, but I see that there are a large number of tests that are present in `test/jdk/java/awt` and `test/jdk/javax/swing`. Adding these 2 directories to `exclusiveAccess.dirs` would mean that none of the tests in `java/awt` will be run when any other test in `java/awt` is currently in progress. Same with the `javax/swing` directory. So it could increase the duration of the tiers in which these tests run. Is there a CI run which shows if this changes the test run duration drastically?
>
> @jaikiran Thank you for the details. I'll check if the duration of run differed drastically. I thought all the client tests run in non-concurrent mode by default or does this differ for headful and headless test?

*Headful* tests are not supposed concurrently: they display UI and often use Robot to send input events to the UI. Running such tests concurrently leads to obscure failures. In our CI system, `JTREG_JOBS=1` is passed to `make` when running headful tests.

There's a set of *headless* tests which can be run concurrently. Such tests will be affected if they're run concurrently.

-------------

PR: https://git.openjdk.org/jdk/pull/11747

From aivanov at openjdk.org  Wed Dec 21 20:19:49 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 Dec 2022 20:19:49 GMT
Subject: RFR: JDK-8299052: ViewportOverlapping test fails intermittently on
 Win10 & Win11
In-Reply-To: <ZJOwyL6GVkhkOZAMX3dlI8ZCABXk0bC0KYwcw96YAxw=.6beb9013-2ed7-4764-b7c2-ce0a8e5deaed@github.com>
References: <ZJOwyL6GVkhkOZAMX3dlI8ZCABXk0bC0KYwcw96YAxw=.6beb9013-2ed7-4764-b7c2-ce0a8e5deaed@github.com>
Message-ID: <KXg7eI2il-twcbge-5wMqEXxYpVYScrdqQTwBNL7hno=.fb5b37aa-9bc0-4002-add1-bec40cfa18c5@github.com>

On Tue, 20 Dec 2022 23:25:30 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> ViewportOverlapping was failing intermittently on Windows (Win10 & 11). Added robot.setAutoWaitForIdle() to ViewportOverlapping and its base class (OverlappingTestBase) to stabilize the test.
> 
> Additionally added awt & swings tests to exclusiveAccess.dir in TEST.ROOT.

Maybe also expand imports in `OverlappingTestBase.java`?

test/jdk/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java line 464:

> 462:             robot.setAutoWaitForIdle(true);
> 463:         }catch(Exception ignorex) {
> 464:         }

Does it make sense to extract this code into a new method?

-------------

PR: https://git.openjdk.org/jdk/pull/11747

From rhalade at openjdk.org  Wed Dec 21 20:41:53 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 21 Dec 2022 20:41:53 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v6]
In-Reply-To: <biX2juSzVryWWGuHnrLeyzOHVH4zzUQhLGHwBgIlyKE=.0dd655b0-7f5c-4e61-bd17-8daba35fc110@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <J2eQc_SMfteNYRozU44midnVyt2Kdqmic39U4QFoGd0=.3c9049d3-7624-4a80-8d9b-002072c73cd5@github.com>
 <bPVh_aHz398yv1Q5Qk48H_8ddTTkOxC3AkVOR-gDEkA=.666bc926-d579-4d75-a2bb-ccc9e6f032a4@github.com>
 <biX2juSzVryWWGuHnrLeyzOHVH4zzUQhLGHwBgIlyKE=.0dd655b0-7f5c-4e61-bd17-8daba35fc110@github.com>
Message-ID: <QIxuMKJKXqHo4DKYh9tFn7v2LsUY9KMpOM98m43JYBw=.e70b1f67-6854-47e8-82f9-83fb707d056a@github.com>

On Wed, 21 Dec 2022 19:58:18 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> test/jdk/sun/security/provider/PolicyParser/ExtDirs.java line 33:
>> 
>>> 31: 
>>> 32: /*
>>> 33:  * @test
>> 
>> Why are these tags duplicated here?
>
> Multiple "run" in a single test fails the whole test when one test run fails and all subsequent test run get terminated. Multiple tests with only one "run" each allows all test run to be excused, and they can be run in parallel.

I have not seen this used in any other tests. It is a good learning, I didn't knew that multiple tests in single file are run in parallel. It seems like good option. Do you know of any other regression test written this way?

-------------

PR: https://git.openjdk.org/jdk/pull/10637

From naoto at openjdk.org  Wed Dec 21 20:56:50 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 21 Dec 2022 20:56:50 GMT
Subject: RFR: 8299194: CustomTzIDCheckDST.java may fail at future date
In-Reply-To: <WLaw7cFwSjOG5fYL5QXPjGUxemrk37_SN2fSBxFkmjY=.e2602944-b688-4d04-98e3-5b0ec0fa787c@github.com>
References: <WLaw7cFwSjOG5fYL5QXPjGUxemrk37_SN2fSBxFkmjY=.e2602944-b688-4d04-98e3-5b0ec0fa787c@github.com>
Message-ID: <DycgcJGMLRqXOU3WFz00H2PpX0eAYx7M1wA0jXHyllI=.006a128d-4cda-4db1-ba3d-82b6afe95a92@github.com>

On Wed, 21 Dec 2022 15:57:29 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java may fail at future date.
> I used following standalone testcase
> 
> import java.util.Calendar;
> import java.util.Date;
> import java.util.SimpleTimeZone;
> 
> public class CheckDST {
> ????private static String CUSTOM_TZ = "MEZ-1MESZ,M3.5.0,M10.5.0";
> ????public static void main(String args[]) throws Throwable {
> ????????runTZTest();
> ????}
> 
> ????/* TZ code will always be set to "MEZ-1MESZ,M3.5.0,M10.5.0".
> ?????* This ensures the transition periods for Daylights Savings should be at March's last
> ?????* Sunday and October's last Sunday.
> ?????*/
> ????private static void runTZTest() {
> ????????Date time = new Date();
> ????????if (new SimpleTimeZone(3600000, "MEZ-1MESZ", Calendar.MARCH, -1, Calendar.SUNDAY, 0,
> ????????????????Calendar.OCTOBER, -1, Calendar.SUNDAY, 0).inDaylightTime(time)) {
> ????????????// We are in Daylight savings period.
> ????????????if (time.toString().endsWith("GMT+02:00 " + Integer.toString(time.getYear() + 1900)))
> ????????????????return;
> ????????} else {
> ????????????if (time.toString().endsWith("GMT+01:00 " + Integer.toString(time.getYear() + 1900)))
> ????????????????return;
> ????????}
> 
> ????????// Reaching here means time zone did not match up as expected.
> ????????throw new RuntimeException("Got unexpected timezone information: " + time);
> ????}
> }
> 
> 
> I tested CheckDST with faketime, then I got following results
> 
> $ TZ=GMT faketime -m "2023-03-25 22:59:59" env TZ="MEZ-1MESZ,M3.5.0,M10.5.0" $HOME/jdk-21-b02/bin/java CheckDST
> $ TZ=GMT faketime -m "2023-03-25 23:00:00" env TZ="MEZ-1MESZ,M3.5.0,M10.5.0" $HOME/jdk-21-b02/bin/java CheckDST
> Exception in thread "main" java.lang.RuntimeException: Got unexpected timezone information: Sun Mar 26 00:00:00 GMT+01:00 2023
> ????????at CheckDST.runTZTest(CheckDST.java:28)
> ????????at CheckDST.main(CheckDST.java:8)
> 
> 
> I assume `TZ=MEZ-1MESZ`refers Europe/Berlin timezone.
> In this case, `TZ` environment variable should be `MEZ-1MESZ,M3.5.0,M10.5.0/3` (`/3` is missing in testcase)
> 
> CustomTzIDCheckDST should run with daylight saving time.
> Add Simulate Southern Hemisphere by `MEZ-1MESZ,M10.5.0,M3.5.0/3`
> 
> Tested by standalone testcase
> 
> $ cat CheckDST1.java
> import java.util.Calendar;
> import java.util.Date;
> import java.util.List;
> import java.util.SimpleTimeZone;
> import java.util.TimeZone;
> import java.time.DayOfWeek;
> import java.time.ZonedDateTime;
> import java.time.temporal.TemporalAdjusters;
> public class CheckDST1 {
>     // Northern Hemisphere
>     private static String CUSTOM_TZ = "MEZ-1MESZ,M3.5.0,M10.5.0/3";
>     // Simulate Southern Hemisphere
>     private static String CUSTOM_TZ2 = "MEZ-1MESZ,M10.5.0,M3.5.0/3";
>     public static void main(String args[]) throws Throwable {
>         runTZTest();
>     }
> 
>     /* TZ code will always be set to "MEZ-1MESZ,M3.5.0,M10.5.0/3".
>      * This ensures the transition periods for Daylights Savings should be at March's last
>      * Sunday and October's last Sunday.
>      */
>     private static void runTZTest() {
>         Date time = new Date();
>         String tzStr = System.getenv("TZ");
>         if (tzStr == null)
>             throw new RuntimeException("Got unexpected timezone information: TZ is null");
>         boolean nor = tzStr.matches(".*,M3\..*,M10\..*");
>         TimeZone tz = new SimpleTimeZone(3600000, tzStr,
>             nor ? Calendar.MARCH : Calendar.OCTOBER, -1,
>             Calendar.SUNDAY, 3600000, SimpleTimeZone.UTC_TIME,
>             nor ? Calendar.OCTOBER : Calendar.MARCH, -1,
>             Calendar.SUNDAY, 3600000, SimpleTimeZone.UTC_TIME,
>             3600000);
>         System.out.println(time);
>         if (tz.inDaylightTime(time)) {
>             // We are in Daylight savings period.
>             if (time.toString().endsWith("GMT+02:00 " + Integer.toString(time.getYear() + 1900)))
>                 return;
>         } else {
>             if (time.toString().endsWith("GMT+01:00 " + Integer.toString(time.getYear() + 1900)))
>                 return;
>         }
> 
>         // Reaching here means time zone did not match up as expected.
>         throw new RuntimeException("Got unexpected timezone information: " + tzStr + " " + time);
>     }
> 
>     private static ZonedDateTime getLastSundayOfMonth(ZonedDateTime date) {
>         return date.with(TemporalAdjusters.lastInMonth(DayOfWeek.SUNDAY));
>     }
> }
> 
> 
> Check Europe/Berlin timezone settings
> 
> $ zdump -v Europe/Berlin | grep 2023
> Europe/Berlin  Sun Mar 26 00:59:59 2023 UTC = Sun Mar 26 01:59:59 2023 CET isdst=0 gmtoff=3600
> Europe/Berlin  Sun Mar 26 01:00:00 2023 UTC = Sun Mar 26 03:00:00 2023 CEST isdst=1 gmtoff=7200
> Europe/Berlin  Sun Oct 29 00:59:59 2023 UTC = Sun Oct 29 02:59:59 2023 CEST isdst=1 gmtoff=7200
> Europe/Berlin  Sun Oct 29 01:00:00 2023 UTC = Sun Oct 29 02:00:00 2023 CET isdst=0 gmtoff=3600
> 
> 
> Test results are as follows:
> 
> Northern Hemisphere side
> 
> $ TZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
> Sun Mar 26 01:59:59 MEZ 2023
> $ TZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
> Sun Mar 26 01:59:59 GMT+01:00 2023
> 
> $ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
> Sun Mar 26 03:00:00 MESZ 2023
> $ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
> Sun Mar 26 03:00:00 GMT+02:00 2023
> 
> $ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
> Sun Oct 29 02:59:59 MESZ 2023
> $ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
> Sun Oct 29 02:59:59 GMT+02:00 2023
> 
> $ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
> Sun Oct 29 02:00:00 MEZ 2023
> $ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
> Sun Oct 29 02:00:00 GMT+01:00 2023
> 
> 
> Southern Hemisphere side
> 
> $ TZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
> Sun Mar 26 02:59:59 MESZ 2023
> $bTZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
> Sun Mar 26 02:59:59 GMT+02:00 2023
> 
> $ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
> Sun Mar 26 02:00:00 MEZ 2023
> $ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
> Sun Mar 26 02:00:00 GMT+01:00 2023
> 
> $ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
> Sun Oct 29 01:59:59 MEZ 2023
> $ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
> Sun Oct 29 01:59:59 GMT+01:00 2023
> 
> $ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
> Sun Oct 29 03:00:00 MESZ 2023
> $ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
> Sun Oct 29 03:00:00 GMT+02:00 2023

Thanks for the fix. Looks good overall. A couple of minor comments/questions.

test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java line 61:

> 59:     }
> 60: 
> 61:     /* TZ code will always be set to "MEZ-1MESZ,M3.5.0,M10.5.0/3".

Probably adding "northern hemisphere" is helpful here.

test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java line 70:

> 68:         if (tzStr == null)
> 69:             throw new RuntimeException("Got unexpected timezone information: TZ is null");
> 70:         boolean nor = tzStr.matches(".*,M3\\..*,M10\\..*");

Do we need to use RegEx? A simple comparison with `CUSTOM_TZ` does not work?

-------------

PR: https://git.openjdk.org/jdk/pull/11756

From bhuang at openjdk.org  Wed Dec 21 21:39:52 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Wed, 21 Dec 2022 21:39:52 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v6]
In-Reply-To: <QIxuMKJKXqHo4DKYh9tFn7v2LsUY9KMpOM98m43JYBw=.e70b1f67-6854-47e8-82f9-83fb707d056a@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <J2eQc_SMfteNYRozU44midnVyt2Kdqmic39U4QFoGd0=.3c9049d3-7624-4a80-8d9b-002072c73cd5@github.com>
 <bPVh_aHz398yv1Q5Qk48H_8ddTTkOxC3AkVOR-gDEkA=.666bc926-d579-4d75-a2bb-ccc9e6f032a4@github.com>
 <biX2juSzVryWWGuHnrLeyzOHVH4zzUQhLGHwBgIlyKE=.0dd655b0-7f5c-4e61-bd17-8daba35fc110@github.com>
 <QIxuMKJKXqHo4DKYh9tFn7v2LsUY9KMpOM98m43JYBw=.e70b1f67-6854-47e8-82f9-83fb707d056a@github.com>
Message-ID: <Ns6FEjEH1NScO2Trgvcu2Ph1e1NgRImJZ6GByQmi-4k=.7018d4f4-00a5-4290-9c4a-f725bcdbc29a@github.com>

On Wed, 21 Dec 2022 20:39:03 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> Multiple "run" in a single test fails the whole test when one test run fails and all subsequent test run get terminated. Multiple tests with only one "run" each allows all test run to be excused, and they can be run in parallel.
>
> I have not seen this used in any other tests. It is a good learning, I didn't knew that multiple tests in single file are run in parallel. It seems like good option. Do you know of any other regression test written this way?

I didn't know that until Leonid posted this [comment](https://github.com/openjdk/jdk/pull/9813#discussion_r942908285) in one of my PRs. We do have a lot of tests written in this way and each test run will be given a unique id after the file name. For example, ExtDirs.java has two test run, and they will be named as ExtDirs.java#id0 and ExtDirs.java#id1. We can search "name:*.java#id*" in a Core Lib Mach5 run, it will show thousands of results.

-------------

PR: https://git.openjdk.org/jdk/pull/10637

From honkar at openjdk.org  Wed Dec 21 21:50:49 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 21 Dec 2022 21:50:49 GMT
Subject: RFR: JDK-8299052: ViewportOverlapping test fails intermittently on
 Win10 & Win11
In-Reply-To: <W_HEgUOBCsJbzgbVW_WNWLgfgOAyqVI05WNAzeQYIrg=.ea10afc2-3854-4ad8-9ebe-fbd00fec52ce@github.com>
References: <ZJOwyL6GVkhkOZAMX3dlI8ZCABXk0bC0KYwcw96YAxw=.6beb9013-2ed7-4764-b7c2-ce0a8e5deaed@github.com>
 <m3z28VJnQEMM38GGtwCj_AQsiHZr62IBBHKGg-cnL7s=.14543ee8-4371-4f79-a2ec-a238ea708c19@github.com>
 <lmAhQF7EiYZIrlh96_1ok58GPeak2LWG3afAfP4XolQ=.c07eaf59-0849-42b5-b25d-ff32eb2c5547@github.com>
 <W_HEgUOBCsJbzgbVW_WNWLgfgOAyqVI05WNAzeQYIrg=.ea10afc2-3854-4ad8-9ebe-fbd00fec52ce@github.com>
Message-ID: <L4VQY6JayQjdN-Avnc_FCMNpubkEZzgc6LUhgzZKAQI=.1276219a-1abe-4cec-aa77-24762f55b529@github.com>

On Wed, 21 Dec 2022 20:03:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> @jaikiran Thank you for the details. I'll check if the duration of run differed drastically. I thought all the client tests run in non-concurrent mode by default or does this differ for headful and headless test?
>
> *Headful* tests are not supposed concurrently: they display UI and often use Robot to send input events to the UI. Running such tests concurrently leads to obscure failures. In our CI system, `JTREG_JOBS=1` is passed to `make` when running headful tests.
> 
> There's a set of *headless* tests which can be run concurrently. Such tests will be affected if they're run concurrently.

@aivanov-jdk If it affects the run time of certain group of tests then it is better not to add it to `exclusiveAccess.dirs` and explicitly specify the `JTREG_JOBS=1` instead as both produce same results?

-------------

PR: https://git.openjdk.org/jdk/pull/11747

From rhalade at openjdk.org  Wed Dec 21 21:50:52 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 21 Dec 2022 21:50:52 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v6]
In-Reply-To: <Ns6FEjEH1NScO2Trgvcu2Ph1e1NgRImJZ6GByQmi-4k=.7018d4f4-00a5-4290-9c4a-f725bcdbc29a@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <J2eQc_SMfteNYRozU44midnVyt2Kdqmic39U4QFoGd0=.3c9049d3-7624-4a80-8d9b-002072c73cd5@github.com>
 <bPVh_aHz398yv1Q5Qk48H_8ddTTkOxC3AkVOR-gDEkA=.666bc926-d579-4d75-a2bb-ccc9e6f032a4@github.com>
 <biX2juSzVryWWGuHnrLeyzOHVH4zzUQhLGHwBgIlyKE=.0dd655b0-7f5c-4e61-bd17-8daba35fc110@github.com>
 <QIxuMKJKXqHo4DKYh9tFn7v2LsUY9KMpOM98m43JYBw=.e70b1f67-6854-47e8-82f9-83fb707d056a@github.com>
 <Ns6FEjEH1NScO2Trgvcu2Ph1e1NgRImJZ6GByQmi-4k=.7018d4f4-00a5-4290-9c4a-f725bcdbc29a@github.com>
Message-ID: <XJtlqDZURgbgOvtqN5f4zfoTgYYzzHaJPHFuYW77s6I=.55d267ab-fab5-4885-83c0-73814896e4c4@github.com>

On Wed, 21 Dec 2022 21:37:27 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> I have not seen this used in any other tests. It is a good learning, I didn't knew that multiple tests in single file are run in parallel. It seems like good option. Do you know of any other regression test written this way?
>
> I didn't know that until Leonid posted this [comment](https://github.com/openjdk/jdk/pull/9813#discussion_r942908285) in one of my PRs. We do have a lot of tests written in this way and each test run will be given a unique id after the file name. For example, ExtDirs.java has two test run, and they will be named as ExtDirs.java#id0 and ExtDirs.java#id1. We can search "name:*.java#id*" in a Core Lib Mach5 run, it will show thousands of results.

Thanks for this. Fix looks good to me.

-------------

PR: https://git.openjdk.org/jdk/pull/10637

From rhalade at openjdk.org  Wed Dec 21 21:53:50 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 21 Dec 2022 21:53:50 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v6]
In-Reply-To: <J2eQc_SMfteNYRozU44midnVyt2Kdqmic39U4QFoGd0=.3c9049d3-7624-4a80-8d9b-002072c73cd5@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <J2eQc_SMfteNYRozU44midnVyt2Kdqmic39U4QFoGd0=.3c9049d3-7624-4a80-8d9b-002072c73cd5@github.com>
Message-ID: <u3UT5U3eN6WEmtAddULuMBHnLzJK_bty4YYZNnvo47A=.29b83826-3226-47e2-ad27-e8859163d191@github.com>

On Tue, 20 Dec 2022 19:23:10 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task converts 5 manual tests to automated tests.
>> 
>> sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java 
>> sun/security/provider/PolicyParser/ExtDirsChange.java 
>> sun/security/provider/PolicyParser/ExtDirs.java 
>> java/security/Policy/Root/Root.javajava/security/Policy/Root/Root.java 
>> javax/crypto/CryptoPermissions/InconsistentEntries.java
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments.

Marked as reviewed by rhalade (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10637

From itakiguchi at openjdk.org  Wed Dec 21 23:21:42 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Wed, 21 Dec 2022 23:21:42 GMT
Subject: RFR: 8299194: CustomTzIDCheckDST.java may fail at future date [v2]
In-Reply-To: <WLaw7cFwSjOG5fYL5QXPjGUxemrk37_SN2fSBxFkmjY=.e2602944-b688-4d04-98e3-5b0ec0fa787c@github.com>
References: <WLaw7cFwSjOG5fYL5QXPjGUxemrk37_SN2fSBxFkmjY=.e2602944-b688-4d04-98e3-5b0ec0fa787c@github.com>
Message-ID: <Uqhc4a1mr4igkK3RvMbKdsU9gNTSZ0APehejZAoIgfo=.cfa0aafb-4f76-4db7-afd2-00790b65b294@github.com>

> test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java may fail at future date.
> I used following standalone testcase
> 
> import java.util.Calendar;
> import java.util.Date;
> import java.util.SimpleTimeZone;
> 
> public class CheckDST {
> ????private static String CUSTOM_TZ = "MEZ-1MESZ,M3.5.0,M10.5.0";
> ????public static void main(String args[]) throws Throwable {
> ????????runTZTest();
> ????}
> 
> ????/* TZ code will always be set to "MEZ-1MESZ,M3.5.0,M10.5.0".
> ?????* This ensures the transition periods for Daylights Savings should be at March's last
> ?????* Sunday and October's last Sunday.
> ?????*/
> ????private static void runTZTest() {
> ????????Date time = new Date();
> ????????if (new SimpleTimeZone(3600000, "MEZ-1MESZ", Calendar.MARCH, -1, Calendar.SUNDAY, 0,
> ????????????????Calendar.OCTOBER, -1, Calendar.SUNDAY, 0).inDaylightTime(time)) {
> ????????????// We are in Daylight savings period.
> ????????????if (time.toString().endsWith("GMT+02:00 " + Integer.toString(time.getYear() + 1900)))
> ????????????????return;
> ????????} else {
> ????????????if (time.toString().endsWith("GMT+01:00 " + Integer.toString(time.getYear() + 1900)))
> ????????????????return;
> ????????}
> 
> ????????// Reaching here means time zone did not match up as expected.
> ????????throw new RuntimeException("Got unexpected timezone information: " + time);
> ????}
> }
> 
> 
> I tested CheckDST with faketime, then I got following results
> 
> $ TZ=GMT faketime -m "2023-03-25 22:59:59" env TZ="MEZ-1MESZ,M3.5.0,M10.5.0" $HOME/jdk-21-b02/bin/java CheckDST
> $ TZ=GMT faketime -m "2023-03-25 23:00:00" env TZ="MEZ-1MESZ,M3.5.0,M10.5.0" $HOME/jdk-21-b02/bin/java CheckDST
> Exception in thread "main" java.lang.RuntimeException: Got unexpected timezone information: Sun Mar 26 00:00:00 GMT+01:00 2023
> ????????at CheckDST.runTZTest(CheckDST.java:28)
> ????????at CheckDST.main(CheckDST.java:8)
> 
> 
> I assume `TZ=MEZ-1MESZ`refers Europe/Berlin timezone.
> In this case, `TZ` environment variable should be `MEZ-1MESZ,M3.5.0,M10.5.0/3` (`/3` is missing in testcase)
> 
> CustomTzIDCheckDST should run with daylight saving time.
> Add Simulate Southern Hemisphere by `MEZ-1MESZ,M10.5.0,M3.5.0/3`
> 
> Tested by standalone testcase
> 
> $ cat CheckDST1.java
> import java.util.Calendar;
> import java.util.Date;
> import java.util.List;
> import java.util.SimpleTimeZone;
> import java.util.TimeZone;
> import java.time.DayOfWeek;
> import java.time.ZonedDateTime;
> import java.time.temporal.TemporalAdjusters;
> public class CheckDST1 {
>     // Northern Hemisphere
>     private static String CUSTOM_TZ = "MEZ-1MESZ,M3.5.0,M10.5.0/3";
>     // Simulate Southern Hemisphere
>     private static String CUSTOM_TZ2 = "MEZ-1MESZ,M10.5.0,M3.5.0/3";
>     public static void main(String args[]) throws Throwable {
>         runTZTest();
>     }
> 
>     /* TZ code will always be set to "MEZ-1MESZ,M3.5.0,M10.5.0/3".
>      * This ensures the transition periods for Daylights Savings should be at March's last
>      * Sunday and October's last Sunday.
>      */
>     private static void runTZTest() {
>         Date time = new Date();
>         String tzStr = System.getenv("TZ");
>         if (tzStr == null)
>             throw new RuntimeException("Got unexpected timezone information: TZ is null");
>         boolean nor = tzStr.matches(".*,M3\..*,M10\..*");
>         TimeZone tz = new SimpleTimeZone(3600000, tzStr,
>             nor ? Calendar.MARCH : Calendar.OCTOBER, -1,
>             Calendar.SUNDAY, 3600000, SimpleTimeZone.UTC_TIME,
>             nor ? Calendar.OCTOBER : Calendar.MARCH, -1,
>             Calendar.SUNDAY, 3600000, SimpleTimeZone.UTC_TIME,
>             3600000);
>         System.out.println(time);
>         if (tz.inDaylightTime(time)) {
>             // We are in Daylight savings period.
>             if (time.toString().endsWith("GMT+02:00 " + Integer.toString(time.getYear() + 1900)))
>                 return;
>         } else {
>             if (time.toString().endsWith("GMT+01:00 " + Integer.toString(time.getYear() + 1900)))
>                 return;
>         }
> 
>         // Reaching here means time zone did not match up as expected.
>         throw new RuntimeException("Got unexpected timezone information: " + tzStr + " " + time);
>     }
> 
>     private static ZonedDateTime getLastSundayOfMonth(ZonedDateTime date) {
>         return date.with(TemporalAdjusters.lastInMonth(DayOfWeek.SUNDAY));
>     }
> }
> 
> 
> Check Europe/Berlin timezone settings
> 
> $ zdump -v Europe/Berlin | grep 2023
> Europe/Berlin  Sun Mar 26 00:59:59 2023 UTC = Sun Mar 26 01:59:59 2023 CET isdst=0 gmtoff=3600
> Europe/Berlin  Sun Mar 26 01:00:00 2023 UTC = Sun Mar 26 03:00:00 2023 CEST isdst=1 gmtoff=7200
> Europe/Berlin  Sun Oct 29 00:59:59 2023 UTC = Sun Oct 29 02:59:59 2023 CEST isdst=1 gmtoff=7200
> Europe/Berlin  Sun Oct 29 01:00:00 2023 UTC = Sun Oct 29 02:00:00 2023 CET isdst=0 gmtoff=3600
> 
> 
> Test results are as follows:
> 
> Northern Hemisphere side
> 
> $ TZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
> Sun Mar 26 01:59:59 MEZ 2023
> $ TZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
> Sun Mar 26 01:59:59 GMT+01:00 2023
> 
> $ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
> Sun Mar 26 03:00:00 MESZ 2023
> $ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
> Sun Mar 26 03:00:00 GMT+02:00 2023
> 
> $ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
> Sun Oct 29 02:59:59 MESZ 2023
> $ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
> Sun Oct 29 02:59:59 GMT+02:00 2023
> 
> $ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
> Sun Oct 29 02:00:00 MEZ 2023
> $ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
> Sun Oct 29 02:00:00 GMT+01:00 2023
> 
> 
> Southern Hemisphere side
> 
> $ TZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
> Sun Mar 26 02:59:59 MESZ 2023
> $bTZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
> Sun Mar 26 02:59:59 GMT+02:00 2023
> 
> $ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
> Sun Mar 26 02:00:00 MEZ 2023
> $ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
> Sun Mar 26 02:00:00 GMT+01:00 2023
> 
> $ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
> Sun Oct 29 01:59:59 MEZ 2023
> $ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
> Sun Oct 29 01:59:59 GMT+01:00 2023
> 
> $ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
> Sun Oct 29 03:00:00 MESZ 2023
> $ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
> Sun Oct 29 03:00:00 GMT+02:00 2023

Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:

  8299194: CustomTzIDCheckDST.java may fail at future date

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11756/files
  - new: https://git.openjdk.org/jdk/pull/11756/files/a17d83d0..df2e8a86

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11756&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11756&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11756.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11756/head:pull/11756

PR: https://git.openjdk.org/jdk/pull/11756

From itakiguchi at openjdk.org  Wed Dec 21 23:25:51 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Wed, 21 Dec 2022 23:25:51 GMT
Subject: RFR: 8299194: CustomTzIDCheckDST.java may fail at future date [v2]
In-Reply-To: <DycgcJGMLRqXOU3WFz00H2PpX0eAYx7M1wA0jXHyllI=.006a128d-4cda-4db1-ba3d-82b6afe95a92@github.com>
References: <WLaw7cFwSjOG5fYL5QXPjGUxemrk37_SN2fSBxFkmjY=.e2602944-b688-4d04-98e3-5b0ec0fa787c@github.com>
 <DycgcJGMLRqXOU3WFz00H2PpX0eAYx7M1wA0jXHyllI=.006a128d-4cda-4db1-ba3d-82b6afe95a92@github.com>
Message-ID: <VfoUpM1KesqwredVnMK7Bb5obOaW_Eks7rIG6ZsPjYI=.75ab50c8-33a9-4300-9b5d-b52c459d7148@github.com>

On Wed, 21 Dec 2022 20:54:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8299194: CustomTzIDCheckDST.java may fail at future date
>
> Thanks for the fix. Looks good overall. A couple of minor comments/questions.

Thanks @naotoj .
I appreciate you suggestion.
Please review it again.

-------------

PR: https://git.openjdk.org/jdk/pull/11756

From stsypanov at openjdk.org  Thu Dec 22 09:37:51 2022
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 22 Dec 2022 09:37:51 GMT
Subject: RFR: 8293630: Simplify TreeMap.get() with
 Comparator.naturalOrder() [v5]
In-Reply-To: <gV_EahOUQIDq-71mp4aC8bFtrZyw_oKe9m9RuFP-0Uo=.f6bfbdc1-cc7d-43b6-8595-82f26be793ee@github.com>
References: <gV_EahOUQIDq-71mp4aC8bFtrZyw_oKe9m9RuFP-0Uo=.f6bfbdc1-cc7d-43b6-8595-82f26be793ee@github.com>
Message-ID: <8IQPBNMB5qcrmTDwzBsIFYsP4M4c3oeNCgx7V5O_e6I=.de9802bb-3109-47c8-b2b6-0555c36411de@github.com>

> We can use `Comparator.naturalOrder()` for cases when a `TreeMap` instance is constructed without comparator. This allows to squash two branches in `TreeMap.get()` into one.
> 
> P.S. I think the comment of `TreeMap.getEntryUsingComparator()` is outdated. Should we also change it?

Sergey Tsypanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Merge branch 'master' into tree-map-simpl
 - 8293630: Inline natural()
 - Update src/java.base/share/classes/java/util/TreeMap.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Update src/java.base/share/classes/java/util/TreeMap.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Merge remote-tracking branch 'origin/tree-map-simpl' into tree-map-simpl
 - Simplify TreeMap.get() with Comparator.naturalOrder()
 - Merge branch 'master' into tree-map-simpl
 - Simplify TreeMap.get() with Comparator.naturalOrder()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9901/files
  - new: https://git.openjdk.org/jdk/pull/9901/files/ae6e2320..ca1d40b6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9901&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9901&range=03-04

  Stats: 529520 lines in 6935 files changed: 265880 ins; 185707 del; 77933 mod
  Patch: https://git.openjdk.org/jdk/pull/9901.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9901/head:pull/9901

PR: https://git.openjdk.org/jdk/pull/9901

From redestad at openjdk.org  Thu Dec 22 13:12:54 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 22 Dec 2022 13:12:54 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v13]
In-Reply-To: <HcQ7WJUZIa-jvv-COz7L3XGOLqMkV5fHf_l-4tmdj6k=.8ba6ebce-b84c-4bfd-954d-44ca693421b8@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <pW8HHmh-dQnjrRftd052fBQVulqe_z5KldY76Hp-OmI=.a7a2b6e6-a182-45d2-bd11-16a406126482@github.com>
 <6lAQI6kDDTGbskylHcWReX8ExaB6qkwgqoai7E6ikZY=.8a69a63c-453d-4bbd-8c76-4d477bfb77fe@github.com>
 <mAsTs03BWlAM_YhHXHBNsaJIQqrX95deQyYAYkJwrmE=.7e36f69c-dffc-462a-bf8a-7614153bf8c4@github.com>
 <PrXrcgFzP4mr0ZI5WrUizT0Sz_wtTl6AJLS_mvW89dQ=.ae6c18d4-8f5e-48cf-b0bf-8d8db7852346@github.com>
 <a_7dEeMU-LeSDU1irFR-zAjfM_zKhnosJmEe19TyQsA=.d94df28d-8a97-4463-a3f5-e5e39d6b21e4@github.com>
 <HcQ7WJUZIa-jvv-COz7L3XGOLqMkV5fHf_l-4tmdj6k=.8ba6ebce-b84c-4bfd-954d-44ca693421b8@github.com>
Message-ID: <GwPWVNPHk3QnaOvUHwLV8skXet8ybGQ6Wgi4es9Ds1s=.cb28475d-97fd-422b-aa6e-694f32314e21@github.com>

On Wed, 21 Dec 2022 00:11:34 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Passing the constant node through as an input as suggested by @iwanowww and @sviswa7 meant we could eliminate most of the `instruct` blocks, removing a significant chunk of code and a little bit of complexity from the proposed patch.
>
> @cl4es Thanks for passing the constant node through, the code looks much cleaner now. The attached patch should handle the signed bytes/shorts as well. Please take a look. 
> [signed.patch](https://github.com/openjdk/jdk/files/10273480/signed.patch)

I ran tests and some quick microbenchmarking to validate @sviswa7's patch to activate vectorization for `short` and `byte` arrays and it looks good:

Before:

Benchmark                   (size)  Mode  Cnt     Score    Error  Units
ArraysHashCode.bytes         10000  avgt    5  7845.586 ? 23.440  ns/op
ArraysHashCode.chars         10000  avgt    5  1203.163 ? 11.995  ns/op
ArraysHashCode.ints          10000  avgt    5  1131.915 ?  7.843  ns/op
ArraysHashCode.multibytes    10000  avgt    5  4136.487 ?  5.790  ns/op
ArraysHashCode.multichars    10000  avgt    5   671.328 ? 17.629  ns/op
ArraysHashCode.multiints     10000  avgt    5   699.051 ?  8.135  ns/op
ArraysHashCode.multishorts   10000  avgt    5  4139.300 ? 10.633  ns/op
ArraysHashCode.shorts        10000  avgt    5  7844.019 ? 26.071  ns/op


After: 

Benchmark                   (size)  Mode  Cnt     Score    Error  Units
ArraysHashCode.bytes         10000  avgt    5  1193.208 ?  1.965  ns/op
ArraysHashCode.chars         10000  avgt    5  1193.311 ?  5.941  ns/op
ArraysHashCode.ints          10000  avgt    5  1132.592 ? 10.410  ns/op
ArraysHashCode.multibytes    10000  avgt    5   657.343 ? 25.343  ns/op
ArraysHashCode.multichars    10000  avgt    5   672.668 ?  5.229  ns/op
ArraysHashCode.multiints     10000  avgt    5   697.143 ?  3.929  ns/op
ArraysHashCode.multishorts   10000  avgt    5   666.738 ? 12.236  ns/op
ArraysHashCode.shorts        10000  avgt    5  1193.563 ?  5.449  ns/op

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From bhuang at openjdk.org  Thu Dec 22 16:53:58 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Thu, 22 Dec 2022 16:53:58 GMT
Subject: Integrated: JDK-8295087: Manual Test to Automated Test Conversion
In-Reply-To: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
Message-ID: <U3Nb7ZbLHzomaBBfehqIMIAm3bjbpHX6iLxj4o178PE=.c9bab129-ba1a-4873-8236-4affcbcb91ad@github.com>

On Mon, 10 Oct 2022 21:39:05 GMT, Bill Huang <bhuang at openjdk.org> wrote:

> This task converts 5 manual tests to automated tests.
> 
> sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java 
> sun/security/provider/PolicyParser/ExtDirsChange.java 
> sun/security/provider/PolicyParser/ExtDirs.java 
> java/security/Policy/Root/Root.javajava/security/Policy/Root/Root.java 
> javax/crypto/CryptoPermissions/InconsistentEntries.java

This pull request has now been integrated.

Changeset: a3693ccc
Author:    Bill Huang <bhuang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a3693ccc617d06137a61050b34646e8a90ed3d7e
Stats:     173 lines in 13 files changed: 71 ins; 32 del; 70 mod

8295087: Manual Test to Automated Test Conversion

Reviewed-by: ssahoo, rhalade

-------------

PR: https://git.openjdk.org/jdk/pull/10637

From naoto at openjdk.org  Thu Dec 22 17:29:52 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 22 Dec 2022 17:29:52 GMT
Subject: RFR: 8299194: CustomTzIDCheckDST.java may fail at future date [v2]
In-Reply-To: <Uqhc4a1mr4igkK3RvMbKdsU9gNTSZ0APehejZAoIgfo=.cfa0aafb-4f76-4db7-afd2-00790b65b294@github.com>
References: <WLaw7cFwSjOG5fYL5QXPjGUxemrk37_SN2fSBxFkmjY=.e2602944-b688-4d04-98e3-5b0ec0fa787c@github.com>
 <Uqhc4a1mr4igkK3RvMbKdsU9gNTSZ0APehejZAoIgfo=.cfa0aafb-4f76-4db7-afd2-00790b65b294@github.com>
Message-ID: <OEgcOztNqozclXfAuMpRchNBBVoCuM8Wn3X9_1Nj6iE=.37d8dae4-53f2-4cc9-ba6a-03f90adf27b3@github.com>

On Wed, 21 Dec 2022 23:21:42 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java may fail at future date.
>> I used following standalone testcase
>> 
>> import java.util.Calendar;
>> import java.util.Date;
>> import java.util.SimpleTimeZone;
>> 
>> public class CheckDST {
>> ????private static String CUSTOM_TZ = "MEZ-1MESZ,M3.5.0,M10.5.0";
>> ????public static void main(String args[]) throws Throwable {
>> ????????runTZTest();
>> ????}
>> 
>> ????/* TZ code will always be set to "MEZ-1MESZ,M3.5.0,M10.5.0".
>> ?????* This ensures the transition periods for Daylights Savings should be at March's last
>> ?????* Sunday and October's last Sunday.
>> ?????*/
>> ????private static void runTZTest() {
>> ????????Date time = new Date();
>> ????????if (new SimpleTimeZone(3600000, "MEZ-1MESZ", Calendar.MARCH, -1, Calendar.SUNDAY, 0,
>> ????????????????Calendar.OCTOBER, -1, Calendar.SUNDAY, 0).inDaylightTime(time)) {
>> ????????????// We are in Daylight savings period.
>> ????????????if (time.toString().endsWith("GMT+02:00 " + Integer.toString(time.getYear() + 1900)))
>> ????????????????return;
>> ????????} else {
>> ????????????if (time.toString().endsWith("GMT+01:00 " + Integer.toString(time.getYear() + 1900)))
>> ????????????????return;
>> ????????}
>> 
>> ????????// Reaching here means time zone did not match up as expected.
>> ????????throw new RuntimeException("Got unexpected timezone information: " + time);
>> ????}
>> }
>> 
>> 
>> I tested CheckDST with faketime, then I got following results
>> 
>> $ TZ=GMT faketime -m "2023-03-25 22:59:59" env TZ="MEZ-1MESZ,M3.5.0,M10.5.0" $HOME/jdk-21-b02/bin/java CheckDST
>> $ TZ=GMT faketime -m "2023-03-25 23:00:00" env TZ="MEZ-1MESZ,M3.5.0,M10.5.0" $HOME/jdk-21-b02/bin/java CheckDST
>> Exception in thread "main" java.lang.RuntimeException: Got unexpected timezone information: Sun Mar 26 00:00:00 GMT+01:00 2023
>> ????????at CheckDST.runTZTest(CheckDST.java:28)
>> ????????at CheckDST.main(CheckDST.java:8)
>> 
>> 
>> I assume `TZ=MEZ-1MESZ`refers Europe/Berlin timezone.
>> In this case, `TZ` environment variable should be `MEZ-1MESZ,M3.5.0,M10.5.0/3` (`/3` is missing in testcase)
>> 
>> CustomTzIDCheckDST should run with daylight saving time.
>> Add Simulate Southern Hemisphere by `MEZ-1MESZ,M10.5.0,M3.5.0/3`
>> 
>> Tested by standalone testcase
>> 
>> $ cat CheckDST1.java
>> import java.util.Calendar;
>> import java.util.Date;
>> import java.util.List;
>> import java.util.SimpleTimeZone;
>> import java.util.TimeZone;
>> import java.time.DayOfWeek;
>> import java.time.ZonedDateTime;
>> import java.time.temporal.TemporalAdjusters;
>> public class CheckDST1 {
>>     // Northern Hemisphere
>>     private static String CUSTOM_TZ = "MEZ-1MESZ,M3.5.0,M10.5.0/3";
>>     // Simulate Southern Hemisphere
>>     private static String CUSTOM_TZ2 = "MEZ-1MESZ,M10.5.0,M3.5.0/3";
>>     public static void main(String args[]) throws Throwable {
>>         runTZTest();
>>     }
>> 
>>     /* TZ code will always be set to "MEZ-1MESZ,M3.5.0,M10.5.0/3".
>>      * This ensures the transition periods for Daylights Savings should be at March's last
>>      * Sunday and October's last Sunday.
>>      */
>>     private static void runTZTest() {
>>         Date time = new Date();
>>         String tzStr = System.getenv("TZ");
>>         if (tzStr == null)
>>             throw new RuntimeException("Got unexpected timezone information: TZ is null");
>>         boolean nor = tzStr.matches(".*,M3\..*,M10\..*");
>>         TimeZone tz = new SimpleTimeZone(3600000, tzStr,
>>             nor ? Calendar.MARCH : Calendar.OCTOBER, -1,
>>             Calendar.SUNDAY, 3600000, SimpleTimeZone.UTC_TIME,
>>             nor ? Calendar.OCTOBER : Calendar.MARCH, -1,
>>             Calendar.SUNDAY, 3600000, SimpleTimeZone.UTC_TIME,
>>             3600000);
>>         System.out.println(time);
>>         if (tz.inDaylightTime(time)) {
>>             // We are in Daylight savings period.
>>             if (time.toString().endsWith("GMT+02:00 " + Integer.toString(time.getYear() + 1900)))
>>                 return;
>>         } else {
>>             if (time.toString().endsWith("GMT+01:00 " + Integer.toString(time.getYear() + 1900)))
>>                 return;
>>         }
>> 
>>         // Reaching here means time zone did not match up as expected.
>>         throw new RuntimeException("Got unexpected timezone information: " + tzStr + " " + time);
>>     }
>> 
>>     private static ZonedDateTime getLastSundayOfMonth(ZonedDateTime date) {
>>         return date.with(TemporalAdjusters.lastInMonth(DayOfWeek.SUNDAY));
>>     }
>> }
>> 
>> 
>> Check Europe/Berlin timezone settings
>> 
>> $ zdump -v Europe/Berlin | grep 2023
>> Europe/Berlin  Sun Mar 26 00:59:59 2023 UTC = Sun Mar 26 01:59:59 2023 CET isdst=0 gmtoff=3600
>> Europe/Berlin  Sun Mar 26 01:00:00 2023 UTC = Sun Mar 26 03:00:00 2023 CEST isdst=1 gmtoff=7200
>> Europe/Berlin  Sun Oct 29 00:59:59 2023 UTC = Sun Oct 29 02:59:59 2023 CEST isdst=1 gmtoff=7200
>> Europe/Berlin  Sun Oct 29 01:00:00 2023 UTC = Sun Oct 29 02:00:00 2023 CET isdst=0 gmtoff=3600
>> 
>> 
>> Test results are as follows:
>> 
>> Northern Hemisphere side
>> 
>> $ TZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
>> Sun Mar 26 01:59:59 MEZ 2023
>> $ TZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
>> Sun Mar 26 01:59:59 GMT+01:00 2023
>> 
>> $ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
>> Sun Mar 26 03:00:00 MESZ 2023
>> $ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
>> Sun Mar 26 03:00:00 GMT+02:00 2023
>> 
>> $ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
>> Sun Oct 29 02:59:59 MESZ 2023
>> $ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
>> Sun Oct 29 02:59:59 GMT+02:00 2023
>> 
>> $ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
>> Sun Oct 29 02:00:00 MEZ 2023
>> $ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
>> Sun Oct 29 02:00:00 GMT+01:00 2023
>> 
>> 
>> Southern Hemisphere side
>> 
>> $ TZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
>> Sun Mar 26 02:59:59 MESZ 2023
>> $bTZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
>> Sun Mar 26 02:59:59 GMT+02:00 2023
>> 
>> $ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
>> Sun Mar 26 02:00:00 MEZ 2023
>> $ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
>> Sun Mar 26 02:00:00 GMT+01:00 2023
>> 
>> $ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
>> Sun Oct 29 01:59:59 MEZ 2023
>> $ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
>> Sun Oct 29 01:59:59 GMT+01:00 2023
>> 
>> $ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
>> Sun Oct 29 03:00:00 MESZ 2023
>> $ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
>> Sun Oct 29 03:00:00 GMT+02:00 2023
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8299194: CustomTzIDCheckDST.java may fail at future date

LGTM.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11756

From honkar at openjdk.org  Thu Dec 22 18:15:07 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 22 Dec 2022 18:15:07 GMT
Subject: RFR: JDK-8299052: ViewportOverlapping test fails intermittently on
 Win10 & Win11 [v2]
In-Reply-To: <ZJOwyL6GVkhkOZAMX3dlI8ZCABXk0bC0KYwcw96YAxw=.6beb9013-2ed7-4764-b7c2-ce0a8e5deaed@github.com>
References: <ZJOwyL6GVkhkOZAMX3dlI8ZCABXk0bC0KYwcw96YAxw=.6beb9013-2ed7-4764-b7c2-ce0a8e5deaed@github.com>
Message-ID: <tyvPceH1cD44Cvhu0H9Nyh9fXjvVM6zRQY58eDGvhGc=.dcccbc38-d120-490e-9b4f-82177e604917@github.com>

> ViewportOverlapping was failing intermittently on Windows (Win10 & 11). Added robot.setAutoWaitForIdle() to ViewportOverlapping and its base class (OverlappingTestBase) to stabilize the test.
> 
> Additionally added awt & swings tests to exclusiveAccess.dir in TEST.ROOT.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  reverted TEST.ROOT changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11747/files
  - new: https://git.openjdk.org/jdk/pull/11747/files/ee4d0762..a5a23745

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11747&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11747&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11747.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11747/head:pull/11747

PR: https://git.openjdk.org/jdk/pull/11747

From smarks at openjdk.org  Thu Dec 22 19:44:35 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 22 Dec 2022 19:44:35 GMT
Subject: RFR: 8299237: add ArraysSupport.newLength test to a test group
Message-ID: <cc-fCuLziUCRc-ZPRoqjRaN8xL6a6j8tzZSL22kiBS8=.7f6ba583-0c52-461f-b737-feb3835076c1@github.com>

This test isn't part of any test group, so it isn't being run regularly! I'm adding it to the jdk_util_other test group.

-------------

Commit messages:
 - Add jdk/internal/util to jdk_util_other test group

Changes: https://git.openjdk.org/jdk/pull/11769/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11769&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299237
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11769.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11769/head:pull/11769

PR: https://git.openjdk.org/jdk/pull/11769

From naoto at openjdk.org  Thu Dec 22 19:49:49 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 22 Dec 2022 19:49:49 GMT
Subject: RFR: 8299237: add ArraysSupport.newLength test to a test group
In-Reply-To: <cc-fCuLziUCRc-ZPRoqjRaN8xL6a6j8tzZSL22kiBS8=.7f6ba583-0c52-461f-b737-feb3835076c1@github.com>
References: <cc-fCuLziUCRc-ZPRoqjRaN8xL6a6j8tzZSL22kiBS8=.7f6ba583-0c52-461f-b737-feb3835076c1@github.com>
Message-ID: <ZYMjUa2xDB9nLHFOVkQiD89HpHuXkzqovQ1CUsvsINc=.25db71c2-84fa-4521-9fda-62f3ca6bd145@github.com>

On Thu, 22 Dec 2022 19:37:12 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> This test isn't part of any test group, so it isn't being run regularly! I'm adding it to the jdk_util_other test group.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11769

From rriggs at openjdk.org  Thu Dec 22 19:49:49 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 22 Dec 2022 19:49:49 GMT
Subject: RFR: 8299237: add ArraysSupport.newLength test to a test group
In-Reply-To: <cc-fCuLziUCRc-ZPRoqjRaN8xL6a6j8tzZSL22kiBS8=.7f6ba583-0c52-461f-b737-feb3835076c1@github.com>
References: <cc-fCuLziUCRc-ZPRoqjRaN8xL6a6j8tzZSL22kiBS8=.7f6ba583-0c52-461f-b737-feb3835076c1@github.com>
Message-ID: <4ndZvcgpVQ443eesaUOxT0cTQgqlUfKR-wfpI-ZAdEY=.43b3c471-cec3-419a-89da-94af2a8269b1@github.com>

On Thu, 22 Dec 2022 19:37:12 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> This test isn't part of any test group, so it isn't being run regularly! I'm adding it to the jdk_util_other test group.

LGTM;  Test fixes are ok for JDK 20 backport.

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11769

From smarks at openjdk.org  Thu Dec 22 19:52:48 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 22 Dec 2022 19:52:48 GMT
Subject: RFR: 8299237: add ArraysSupport.newLength test to a test group
In-Reply-To: <4ndZvcgpVQ443eesaUOxT0cTQgqlUfKR-wfpI-ZAdEY=.43b3c471-cec3-419a-89da-94af2a8269b1@github.com>
References: <cc-fCuLziUCRc-ZPRoqjRaN8xL6a6j8tzZSL22kiBS8=.7f6ba583-0c52-461f-b737-feb3835076c1@github.com>
 <4ndZvcgpVQ443eesaUOxT0cTQgqlUfKR-wfpI-ZAdEY=.43b3c471-cec3-419a-89da-94af2a8269b1@github.com>
Message-ID: <vLVYLM1pfelzN331WhaiTwrv_hgtEgWSTybEopcL9Fc=.4f03705b-79dc-48a1-9487-907b946e8566@github.com>

On Thu, 22 Dec 2022 19:47:30 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> This test isn't part of any test group, so it isn't being run regularly! I'm adding it to the jdk_util_other test group.
>
> LGTM;  Test fixes are ok for JDK 20 backport.

@RogerRiggs 
> LGTM; Test fixes are ok for JDK 20 backport.

Thanks. Do you think I should push this into JDK 20 instead of 21?

-------------

PR: https://git.openjdk.org/jdk/pull/11769

From rriggs at openjdk.org  Thu Dec 22 20:01:50 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 22 Dec 2022 20:01:50 GMT
Subject: RFR: 8299237: add ArraysSupport.newLength test to a test group
In-Reply-To: <vLVYLM1pfelzN331WhaiTwrv_hgtEgWSTybEopcL9Fc=.4f03705b-79dc-48a1-9487-907b946e8566@github.com>
References: <cc-fCuLziUCRc-ZPRoqjRaN8xL6a6j8tzZSL22kiBS8=.7f6ba583-0c52-461f-b737-feb3835076c1@github.com>
 <4ndZvcgpVQ443eesaUOxT0cTQgqlUfKR-wfpI-ZAdEY=.43b3c471-cec3-419a-89da-94af2a8269b1@github.com>
 <vLVYLM1pfelzN331WhaiTwrv_hgtEgWSTybEopcL9Fc=.4f03705b-79dc-48a1-9487-907b946e8566@github.com>
Message-ID: <LwKy8IufhkvjrByMf9Ss9mWCL4x70Z1BUJIO5JHfO-I=.97aafda4-f76f-4a8e-af65-c965907c9fc0@github.com>

On Thu, 22 Dec 2022 19:49:42 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Thanks. Do you think I should push this into JDK 20 instead of 21?

Yes, if the test should be run (and has not been running) pushing to 20 will get it running sooner on the release that ships next.

-------------

PR: https://git.openjdk.org/jdk/pull/11769

From smarks at openjdk.org  Thu Dec 22 20:01:52 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 22 Dec 2022 20:01:52 GMT
Subject: RFR: 8299237: add ArraysSupport.newLength test to a test group
In-Reply-To: <cc-fCuLziUCRc-ZPRoqjRaN8xL6a6j8tzZSL22kiBS8=.7f6ba583-0c52-461f-b737-feb3835076c1@github.com>
References: <cc-fCuLziUCRc-ZPRoqjRaN8xL6a6j8tzZSL22kiBS8=.7f6ba583-0c52-461f-b737-feb3835076c1@github.com>
Message-ID: <zGRibYlcpVmjj-NMId1ucOWyN_ptXDhZ71hg2gVwzkE=.a9262519-f990-4acc-935f-fe5d59223ebb@github.com>

On Thu, 22 Dec 2022 19:37:12 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> This test isn't part of any test group, so it isn't being run regularly! I'm adding it to the jdk_util_other test group.

OK, I guess I'll need to withdraw this PR and open a new one against JDK 20.

-------------

PR: https://git.openjdk.org/jdk/pull/11769

From rriggs at openjdk.org  Thu Dec 22 20:06:50 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 22 Dec 2022 20:06:50 GMT
Subject: RFR: 8299237: add ArraysSupport.newLength test to a test group
In-Reply-To: <cc-fCuLziUCRc-ZPRoqjRaN8xL6a6j8tzZSL22kiBS8=.7f6ba583-0c52-461f-b737-feb3835076c1@github.com>
References: <cc-fCuLziUCRc-ZPRoqjRaN8xL6a6j8tzZSL22kiBS8=.7f6ba583-0c52-461f-b737-feb3835076c1@github.com>
Message-ID: <abIWJSlQc6O_dW0NVhSgNwHWUlmXsyYtaMjSXB_twzo=.071eacdf-a8b9-4c2f-8a09-ad432792df0b@github.com>

On Thu, 22 Dec 2022 19:37:12 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> This test isn't part of any test group, so it isn't being run regularly! I'm adding it to the jdk_util_other test group.

Or you can push to 21 and then use the lightweight "/backport" command.

-------------

PR: https://git.openjdk.org/jdk/pull/11769

From naoto at openjdk.org  Thu Dec 22 20:06:51 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 22 Dec 2022 20:06:51 GMT
Subject: RFR: 8299237: add ArraysSupport.newLength test to a test group
In-Reply-To: <cc-fCuLziUCRc-ZPRoqjRaN8xL6a6j8tzZSL22kiBS8=.7f6ba583-0c52-461f-b737-feb3835076c1@github.com>
References: <cc-fCuLziUCRc-ZPRoqjRaN8xL6a6j8tzZSL22kiBS8=.7f6ba583-0c52-461f-b737-feb3835076c1@github.com>
Message-ID: <OKUtrKoL0DzEujM1yccZ4gibFeesRRJ9xk3iiOkgzJs=.a259354d-3304-46a3-83b0-7d275d4e0799@github.com>

On Thu, 22 Dec 2022 19:37:12 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> This test isn't part of any test group, so it isn't being run regularly! I'm adding it to the jdk_util_other test group.

I think backporting should do in this case (and simpler)

-------------

PR: https://git.openjdk.org/jdk/pull/11769

From sspitsyn at openjdk.org  Thu Dec 22 20:18:59 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 22 Dec 2022 20:18:59 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v2]
In-Reply-To: <mBAIPYIyFTsHqBrLMOSuKna6IR-wbWgF1IVxnl2JGe0=.7c7fac27-8946-412e-9f27-d34ebec273c8@github.com>
References: <Q9aSWyhdNcS73UVmoosyrDRJZnqqAPk_G99quTgutxA=.76691773-e4c2-4190-bc6d-e54d11f1ae33@github.com>
 <mBAIPYIyFTsHqBrLMOSuKna6IR-wbWgF1IVxnl2JGe0=.7c7fac27-8946-412e-9f27-d34ebec273c8@github.com>
Message-ID: <2z4gV3aDtKkV50pWAs-mLvlmITcV3v7rlg0WJ17Lajg=.2f7ef31e-42bf-48f6-bceb-e70c9136992c@github.com>

On Wed, 23 Nov 2022 10:14:23 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This problem has two sides.
>> One is that the `VirtualThread::run() `cashes the field `notifyJvmtiEvents` value.
>> It caused the native method `notifyJvmtiUnmountBegin()` not called after the field `notifyJvmtiEvents`
>> value has been set to `true` when an agent library is loaded into running VM.
>> The fix is to get rid of this cashing.
>> Another is that enabling `notifyJvmtiEvents` notifications needs a synchronization.
>> Otherwise, a VTMS transition start can be missed which will cause some asserts to fire.
>> The fix is to use a JvmtiVTMSTransitionDisabler helper for sync.
>> 
>> Testing:
>> The originally failed tests are passed now:
>> 
>> runtime/vthread/RedefineClass.java
>> runtime/vthread/TestObjectAllocationSampleEvent.java 
>> 
>> In progress:
>> Run the tiers 1-6 to make sure there are no regression.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove caching if notifyJvmtiEvents in yieldContinuation

This is artificial comment to keep the PR alive.

-------------

PR: https://git.openjdk.org/jdk/pull/11304

From smarks at openjdk.org  Thu Dec 22 20:27:48 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 22 Dec 2022 20:27:48 GMT
Subject: RFR: 8299237: add ArraysSupport.newLength test to a test group
In-Reply-To: <cc-fCuLziUCRc-ZPRoqjRaN8xL6a6j8tzZSL22kiBS8=.7f6ba583-0c52-461f-b737-feb3835076c1@github.com>
References: <cc-fCuLziUCRc-ZPRoqjRaN8xL6a6j8tzZSL22kiBS8=.7f6ba583-0c52-461f-b737-feb3835076c1@github.com>
Message-ID: <8KirJkyWEn2UhW-Vc3SVWwOKEs16g3zVPhprFy_UsZ8=.b6451dd9-149f-449c-8b8a-4cf7fd53c831@github.com>

On Thu, 22 Dec 2022 19:37:12 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> This test isn't part of any test group, so it isn't being run regularly! I'm adding it to the jdk_util_other test group.

Yeah it would probably be simpler but it would clutter up the history. I've already started cloning jdk20 anyway, no big deal.

-------------

PR: https://git.openjdk.org/jdk/pull/11769

From itakiguchi at openjdk.org  Thu Dec 22 21:09:53 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Thu, 22 Dec 2022 21:09:53 GMT
Subject: Integrated: 8299194: CustomTzIDCheckDST.java may fail at future date
In-Reply-To: <WLaw7cFwSjOG5fYL5QXPjGUxemrk37_SN2fSBxFkmjY=.e2602944-b688-4d04-98e3-5b0ec0fa787c@github.com>
References: <WLaw7cFwSjOG5fYL5QXPjGUxemrk37_SN2fSBxFkmjY=.e2602944-b688-4d04-98e3-5b0ec0fa787c@github.com>
Message-ID: <NOhSk2Ag9ccfBz_XLDMH6P3SyIMB3KyrCbZX8RkyN5U=.a55d087a-b5fb-45d6-9380-660f60e2f9e0@github.com>

On Wed, 21 Dec 2022 15:57:29 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java may fail at future date.
> I used following standalone testcase
> 
> import java.util.Calendar;
> import java.util.Date;
> import java.util.SimpleTimeZone;
> 
> public class CheckDST {
> ????private static String CUSTOM_TZ = "MEZ-1MESZ,M3.5.0,M10.5.0";
> ????public static void main(String args[]) throws Throwable {
> ????????runTZTest();
> ????}
> 
> ????/* TZ code will always be set to "MEZ-1MESZ,M3.5.0,M10.5.0".
> ?????* This ensures the transition periods for Daylights Savings should be at March's last
> ?????* Sunday and October's last Sunday.
> ?????*/
> ????private static void runTZTest() {
> ????????Date time = new Date();
> ????????if (new SimpleTimeZone(3600000, "MEZ-1MESZ", Calendar.MARCH, -1, Calendar.SUNDAY, 0,
> ????????????????Calendar.OCTOBER, -1, Calendar.SUNDAY, 0).inDaylightTime(time)) {
> ????????????// We are in Daylight savings period.
> ????????????if (time.toString().endsWith("GMT+02:00 " + Integer.toString(time.getYear() + 1900)))
> ????????????????return;
> ????????} else {
> ????????????if (time.toString().endsWith("GMT+01:00 " + Integer.toString(time.getYear() + 1900)))
> ????????????????return;
> ????????}
> 
> ????????// Reaching here means time zone did not match up as expected.
> ????????throw new RuntimeException("Got unexpected timezone information: " + time);
> ????}
> }
> 
> 
> I tested CheckDST with faketime, then I got following results
> 
> $ TZ=GMT faketime -m "2023-03-25 22:59:59" env TZ="MEZ-1MESZ,M3.5.0,M10.5.0" $HOME/jdk-21-b02/bin/java CheckDST
> $ TZ=GMT faketime -m "2023-03-25 23:00:00" env TZ="MEZ-1MESZ,M3.5.0,M10.5.0" $HOME/jdk-21-b02/bin/java CheckDST
> Exception in thread "main" java.lang.RuntimeException: Got unexpected timezone information: Sun Mar 26 00:00:00 GMT+01:00 2023
> ????????at CheckDST.runTZTest(CheckDST.java:28)
> ????????at CheckDST.main(CheckDST.java:8)
> 
> 
> I assume `TZ=MEZ-1MESZ`refers Europe/Berlin timezone.
> In this case, `TZ` environment variable should be `MEZ-1MESZ,M3.5.0,M10.5.0/3` (`/3` is missing in testcase)
> 
> CustomTzIDCheckDST should run with daylight saving time.
> Add Simulate Southern Hemisphere by `MEZ-1MESZ,M10.5.0,M3.5.0/3`
> 
> Tested by standalone testcase
> 
> $ cat CheckDST1.java
> import java.util.Calendar;
> import java.util.Date;
> import java.util.List;
> import java.util.SimpleTimeZone;
> import java.util.TimeZone;
> import java.time.DayOfWeek;
> import java.time.ZonedDateTime;
> import java.time.temporal.TemporalAdjusters;
> public class CheckDST1 {
>     // Northern Hemisphere
>     private static String CUSTOM_TZ = "MEZ-1MESZ,M3.5.0,M10.5.0/3";
>     // Simulate Southern Hemisphere
>     private static String CUSTOM_TZ2 = "MEZ-1MESZ,M10.5.0,M3.5.0/3";
>     public static void main(String args[]) throws Throwable {
>         runTZTest();
>     }
> 
>     /* TZ code will always be set to "MEZ-1MESZ,M3.5.0,M10.5.0/3".
>      * This ensures the transition periods for Daylights Savings should be at March's last
>      * Sunday and October's last Sunday.
>      */
>     private static void runTZTest() {
>         Date time = new Date();
>         String tzStr = System.getenv("TZ");
>         if (tzStr == null)
>             throw new RuntimeException("Got unexpected timezone information: TZ is null");
>         boolean nor = tzStr.matches(".*,M3\..*,M10\..*");
>         TimeZone tz = new SimpleTimeZone(3600000, tzStr,
>             nor ? Calendar.MARCH : Calendar.OCTOBER, -1,
>             Calendar.SUNDAY, 3600000, SimpleTimeZone.UTC_TIME,
>             nor ? Calendar.OCTOBER : Calendar.MARCH, -1,
>             Calendar.SUNDAY, 3600000, SimpleTimeZone.UTC_TIME,
>             3600000);
>         System.out.println(time);
>         if (tz.inDaylightTime(time)) {
>             // We are in Daylight savings period.
>             if (time.toString().endsWith("GMT+02:00 " + Integer.toString(time.getYear() + 1900)))
>                 return;
>         } else {
>             if (time.toString().endsWith("GMT+01:00 " + Integer.toString(time.getYear() + 1900)))
>                 return;
>         }
> 
>         // Reaching here means time zone did not match up as expected.
>         throw new RuntimeException("Got unexpected timezone information: " + tzStr + " " + time);
>     }
> 
>     private static ZonedDateTime getLastSundayOfMonth(ZonedDateTime date) {
>         return date.with(TemporalAdjusters.lastInMonth(DayOfWeek.SUNDAY));
>     }
> }
> 
> 
> Check Europe/Berlin timezone settings
> 
> $ zdump -v Europe/Berlin | grep 2023
> Europe/Berlin  Sun Mar 26 00:59:59 2023 UTC = Sun Mar 26 01:59:59 2023 CET isdst=0 gmtoff=3600
> Europe/Berlin  Sun Mar 26 01:00:00 2023 UTC = Sun Mar 26 03:00:00 2023 CEST isdst=1 gmtoff=7200
> Europe/Berlin  Sun Oct 29 00:59:59 2023 UTC = Sun Oct 29 02:59:59 2023 CEST isdst=1 gmtoff=7200
> Europe/Berlin  Sun Oct 29 01:00:00 2023 UTC = Sun Oct 29 02:00:00 2023 CET isdst=0 gmtoff=3600
> 
> 
> Test results are as follows:
> 
> Northern Hemisphere side
> 
> $ TZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
> Sun Mar 26 01:59:59 MEZ 2023
> $ TZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
> Sun Mar 26 01:59:59 GMT+01:00 2023
> 
> $ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
> Sun Mar 26 03:00:00 MESZ 2023
> $ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
> Sun Mar 26 03:00:00 GMT+02:00 2023
> 
> $ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
> Sun Oct 29 02:59:59 MESZ 2023
> $ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
> Sun Oct 29 02:59:59 GMT+02:00 2023
> 
> $ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
> Sun Oct 29 02:00:00 MEZ 2023
> $ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
> Sun Oct 29 02:00:00 GMT+01:00 2023
> 
> 
> Southern Hemisphere side
> 
> $ TZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
> Sun Mar 26 02:59:59 MESZ 2023
> $bTZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
> Sun Mar 26 02:59:59 GMT+02:00 2023
> 
> $ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
> Sun Mar 26 02:00:00 MEZ 2023
> $ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
> Sun Mar 26 02:00:00 GMT+01:00 2023
> 
> $ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
> Sun Oct 29 01:59:59 MEZ 2023
> $ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
> Sun Oct 29 01:59:59 GMT+01:00 2023
> 
> $ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
> Sun Oct 29 03:00:00 MESZ 2023
> $ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
> Sun Oct 29 03:00:00 GMT+02:00 2023

This pull request has now been integrated.

Changeset: 5e2de896
Author:    Ichiroh Takiguchi <itakiguchi at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5e2de89628aaf6acb8e458fb417426ca5e477bea
Stats:     21 lines in 1 file changed: 16 ins; 0 del; 5 mod

8299194: CustomTzIDCheckDST.java may fail at future date

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/11756

From smarks at openjdk.org  Thu Dec 22 21:28:54 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 22 Dec 2022 21:28:54 GMT
Subject: RFR: 8299237: add ArraysSupport.newLength test to a test group
In-Reply-To: <cc-fCuLziUCRc-ZPRoqjRaN8xL6a6j8tzZSL22kiBS8=.7f6ba583-0c52-461f-b737-feb3835076c1@github.com>
References: <cc-fCuLziUCRc-ZPRoqjRaN8xL6a6j8tzZSL22kiBS8=.7f6ba583-0c52-461f-b737-feb3835076c1@github.com>
Message-ID: <1-DUh3yXUyrRXFy9Ms-xfHWPVWa9zS9Jnvg1VRPBpPU=.014d98b1-0350-4180-9595-dd1956801805@github.com>

On Thu, 22 Dec 2022 19:37:12 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> This test isn't part of any test group, so it isn't being run regularly! I'm adding it to the jdk_util_other test group.

Closing this in favor of PR https://github.com/openjdk/jdk20/pull/73 on JDK 20.

-------------

PR: https://git.openjdk.org/jdk/pull/11769

From smarks at openjdk.org  Thu Dec 22 21:28:54 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 22 Dec 2022 21:28:54 GMT
Subject: Withdrawn: 8299237: add ArraysSupport.newLength test to a test group
In-Reply-To: <cc-fCuLziUCRc-ZPRoqjRaN8xL6a6j8tzZSL22kiBS8=.7f6ba583-0c52-461f-b737-feb3835076c1@github.com>
References: <cc-fCuLziUCRc-ZPRoqjRaN8xL6a6j8tzZSL22kiBS8=.7f6ba583-0c52-461f-b737-feb3835076c1@github.com>
Message-ID: <jZZ3L3lwVqXmSkdsn925imM-DtPMA6REgPVg1B_Ex1U=.10873794-fd62-4c09-a8dd-cba92c06bb72@github.com>

On Thu, 22 Dec 2022 19:37:12 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> This test isn't part of any test group, so it isn't being run regularly! I'm adding it to the jdk_util_other test group.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11769

From naoto at openjdk.org  Thu Dec 22 21:35:24 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 22 Dec 2022 21:35:24 GMT
Subject: [jdk20] RFR: 8299237: add ArraysSupport.newLength test to a test
 group
In-Reply-To: <wou7GkohMvXKpfcmNRZpUY2qji9OItnBJdESZzFVfSc=.23ced690-f513-476e-9b5f-d6d8ab2c8ad1@github.com>
References: <wou7GkohMvXKpfcmNRZpUY2qji9OItnBJdESZzFVfSc=.23ced690-f513-476e-9b5f-d6d8ab2c8ad1@github.com>
Message-ID: <8TOf95HFsWGDb8tKPQRx5WTgaj_5vVZIpAv5xYKtHmU=.76817cc5-2b2e-4c14-8ca9-17d32e896779@github.com>

On Thu, 22 Dec 2022 21:25:39 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> It was running as part of tier4 (which is kind of a catch-all tier) but since it's (an internal) part of java.util, it should really be in tier1. This adds the test/jdk/jdk/internal/util directory to the :jdk_util_other test group.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk20/pull/73

From smarks at openjdk.org  Thu Dec 22 21:35:24 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 22 Dec 2022 21:35:24 GMT
Subject: [jdk20] RFR: 8299237: add ArraysSupport.newLength test to a test group
Message-ID: <wou7GkohMvXKpfcmNRZpUY2qji9OItnBJdESZzFVfSc=.23ced690-f513-476e-9b5f-d6d8ab2c8ad1@github.com>

It was running as part of tier4 (which is kind of a catch-all tier) but since it's (an internal) part of java.util, it should really be in tier1. This adds the test/jdk/jdk/internal/util directory to the :jdk_util_other test group.

-------------

Commit messages:
 - 8299237: add ArraysSupport.newLength test to a test group

Changes: https://git.openjdk.org/jdk20/pull/73/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=73&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299237
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk20/pull/73.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/73/head:pull/73

PR: https://git.openjdk.org/jdk20/pull/73

From smarks at openjdk.org  Thu Dec 22 21:58:56 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 22 Dec 2022 21:58:56 GMT
Subject: [jdk20] Integrated: 8299237: add ArraysSupport.newLength test to a
 test group
In-Reply-To: <wou7GkohMvXKpfcmNRZpUY2qji9OItnBJdESZzFVfSc=.23ced690-f513-476e-9b5f-d6d8ab2c8ad1@github.com>
References: <wou7GkohMvXKpfcmNRZpUY2qji9OItnBJdESZzFVfSc=.23ced690-f513-476e-9b5f-d6d8ab2c8ad1@github.com>
Message-ID: <M_nTd2MFX82Vl4JUDQPx77ksF4GYCzWJMXW7ML3_-w0=.e37a7c3b-fe90-4108-ae60-60995e31f839@github.com>

On Thu, 22 Dec 2022 21:25:39 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> It was running as part of tier4 (which is kind of a catch-all tier) but since it's (an internal) part of java.util, it should really be in tier1. This adds the test/jdk/jdk/internal/util directory to the :jdk_util_other test group.

This pull request has now been integrated.

Changeset: 33042a49
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/33042a49d75011958e5030679433e6b2a779d90a
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8299237: add ArraysSupport.newLength test to a test group

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk20/pull/73

From serb at openjdk.org  Thu Dec 22 22:23:52 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 22 Dec 2022 22:23:52 GMT
Subject: RFR: JDK-8299052: ViewportOverlapping test fails intermittently on
 Win10 & Win11 [v2]
In-Reply-To: <tyvPceH1cD44Cvhu0H9Nyh9fXjvVM6zRQY58eDGvhGc=.dcccbc38-d120-490e-9b4f-82177e604917@github.com>
References: <ZJOwyL6GVkhkOZAMX3dlI8ZCABXk0bC0KYwcw96YAxw=.6beb9013-2ed7-4764-b7c2-ce0a8e5deaed@github.com>
 <tyvPceH1cD44Cvhu0H9Nyh9fXjvVM6zRQY58eDGvhGc=.dcccbc38-d120-490e-9b4f-82177e604917@github.com>
Message-ID: <vhxMsdi8o_pMRRShVIXrVQEP0QOfYhuytb3eIFCIIpg=.592cc57a-b4ad-4564-b69b-fbfa6c385b83@github.com>

On Thu, 22 Dec 2022 18:15:07 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> ViewportOverlapping was failing intermittently on Windows (Win10 & 11). Added robot.setAutoWaitForIdle() to ViewportOverlapping and its base class (OverlappingTestBase) to stabilize the test.
>> 
>> Additionally added awt & swings tests to exclusiveAccess.dir in TEST.ROOT.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted TEST.ROOT changes

What was the reason for failure? Something was too fast or too slow?

-------------

PR: https://git.openjdk.org/jdk/pull/11747

From aivanov at openjdk.org  Thu Dec 22 22:27:48 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 Dec 2022 22:27:48 GMT
Subject: RFR: JDK-8299052: ViewportOverlapping test fails intermittently on
 Win10 & Win11 [v2]
In-Reply-To: <L4VQY6JayQjdN-Avnc_FCMNpubkEZzgc6LUhgzZKAQI=.1276219a-1abe-4cec-aa77-24762f55b529@github.com>
References: <ZJOwyL6GVkhkOZAMX3dlI8ZCABXk0bC0KYwcw96YAxw=.6beb9013-2ed7-4764-b7c2-ce0a8e5deaed@github.com>
 <m3z28VJnQEMM38GGtwCj_AQsiHZr62IBBHKGg-cnL7s=.14543ee8-4371-4f79-a2ec-a238ea708c19@github.com>
 <lmAhQF7EiYZIrlh96_1ok58GPeak2LWG3afAfP4XolQ=.c07eaf59-0849-42b5-b25d-ff32eb2c5547@github.com>
 <W_HEgUOBCsJbzgbVW_WNWLgfgOAyqVI05WNAzeQYIrg=.ea10afc2-3854-4ad8-9ebe-fbd00fec52ce@github.com>
 <L4VQY6JayQjdN-Avnc_FCMNpubkEZzgc6LUhgzZKAQI=.1276219a-1abe-4cec-aa77-24762f55b529@github.com>
Message-ID: <gfUtTprBhBIUtGTwS7jdOOUWBLLw_NHrT5u66fOpno0=.d0f351d0-81d2-453c-9ad2-d994ff16b86f@github.com>

On Wed, 21 Dec 2022 21:48:24 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> *Headful* tests are not supposed concurrently: they display UI and often use Robot to send input events to the UI. Running such tests concurrently leads to obscure failures. In our CI system, `JTREG_JOBS=1` is passed to `make` when running headful tests.
>> 
>> There's a set of *headless* tests which can be run concurrently. Such tests will be affected if they're run concurrently.
>
> @aivanov-jdk If it affects the run time of certain group of tests then it is better not to add it to `exclusiveAccess.dirs` and explicitly specify the `JTREG_JOBS=1` instead as both produce same results?

As discussed, *headless* suite is affected. Therefore neither `java/awt` nor `javax/swing` should be added to `exclusiveAccess.dirs`.

-------------

PR: https://git.openjdk.org/jdk/pull/11747

From jwilhelm at openjdk.org  Fri Dec 23 10:56:14 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Fri, 23 Dec 2022 10:56:14 GMT
Subject: RFR: Merge jdk20
Message-ID: <dcbxW50q2KMbb5q8mKS1UJ3Ihxpb8U-MSd2dt29r5R0=.65568df4-6705-4285-8cae-0e0043311df3@github.com>

Forwardport JDK 20 -> JDK 21

-------------

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8299237: add ArraysSupport.newLength test to a test group
 - 8299230: Use https: in links
 - 8299015: Ensure that HttpResponse.BodySubscribers.ofFile writes all bytes
 - 8299207: [Testbug] Add back test/jdk/java/awt/Graphics2D/DrawPrimitivesTest.java
 - 8298176: remove OpaqueZeroTripGuardPostLoop once main-loop disappears
 - 8299077: [REDO] JDK-4512626 Non-editable JTextArea provides no visual indication of keyboard focus

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=11773&range=00.0
 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=11773&range=00.1

Changes: https://git.openjdk.org/jdk/pull/11773/files
  Stats: 572 lines in 15 files changed: 407 ins; 76 del; 89 mod
  Patch: https://git.openjdk.org/jdk/pull/11773.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11773/head:pull/11773

PR: https://git.openjdk.org/jdk/pull/11773

From jwilhelm at openjdk.org  Fri Dec 23 11:28:55 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Fri, 23 Dec 2022 11:28:55 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <dcbxW50q2KMbb5q8mKS1UJ3Ihxpb8U-MSd2dt29r5R0=.65568df4-6705-4285-8cae-0e0043311df3@github.com>
References: <dcbxW50q2KMbb5q8mKS1UJ3Ihxpb8U-MSd2dt29r5R0=.65568df4-6705-4285-8cae-0e0043311df3@github.com>
Message-ID: <Qpqs-x1BDsAeBRIOYkSaGMve-66Gv1MsBzE83e5C_Nc=.b629f16d-7df6-482d-bcc0-d9d8a27380fd@github.com>

On Fri, 23 Dec 2022 10:48:19 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: 19ce23c6
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/19ce23c6459a452c8d3856b9ed96bfa54a8346ae
Stats:     572 lines in 15 files changed: 407 ins; 76 del; 89 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/11773

From luhenry at openjdk.org  Fri Dec 23 22:53:55 2022
From: luhenry at openjdk.org (Ludovic Henry)
Date: Fri, 23 Dec 2022 22:53:55 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v16]
In-Reply-To: <cPQkHqc5OHG2ytU7dCawy438CddgDCTQFzHvjloUxaE=.3216df79-1f3f-45e9-97c0-acb5a304b1ae@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <cPQkHqc5OHG2ytU7dCawy438CddgDCTQFzHvjloUxaE=.3216df79-1f3f-45e9-97c0-acb5a304b1ae@github.com>
Message-ID: <SMBfjuXn6QGSDX90RguJm7iQ__bTrpeUT6ETOCwPcXs=.d861a25e-961a-4dd3-95c7-09e0434e27ad@github.com>

On Wed, 21 Dec 2022 17:29:23 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
>> 
>> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
>> 
>> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
>> 
>> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
>> 
>> With the most recent fixes the x64 intrinsic results on my workstation look like this:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
>> 
>> Baseline:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
>> 
>> I.e. no measurable overhead compared to baseline even for `size == 1`.
>> 
>> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
>> 
>> Benchmark for `Arrays.hashCode`:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
>> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
>> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
>> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
>> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
>> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
>> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
>> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
>> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
>> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
>> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
>> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
>> 
>> Baseline:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
>> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
>> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
>> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
>> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
>> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
>> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
>> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
>> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
>> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
>> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
>> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
>> 
>> 
>> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Treat Op_VectorizedHashCode as other similar Ops in split_unique_types

Marked as reviewed by luhenry (Committer).

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From duke at openjdk.org  Sat Dec 24 09:11:21 2022
From: duke at openjdk.org (Markus KARG)
Date: Sat, 24 Dec 2022 09:11:21 GMT
Subject: RFR: JDK-8299336 - InputStream::DEFAULT_BUFFER_SIZE should be 16384
Message-ID: <LD1mjUQ5E01OMV3QicgbhdeCMxWVbnbSmGbVmjexW9Y=.214c934a-7a21-46ad-b8c2-9920302e47d7@github.com>

I/O had always been much slower than CPU and memory access, and thanks to physical constraints, always will be.
While CPUs can get shrinked more and more, and can hold more and more memory cache on or nearby a CPU core, the distance between CPU core and I/O device cannot get reduced much: It will stay "far" away.
Due to this simple logic (and other factors), the spread between performance of CPU and memory access on one hand, and performance of I/O on the other hand, increases with every new CPU generation.
As a consequence, internal adjustment factors of the JDK need to get revised from time to time to ensure optimum performance and each hardware generation.

One such factor is the size of the temporary transfer buffer used internally by `InputStream::transferTo`.
Since its introduction with JDK 9 many years (hence hardware generations) have passed, so it's time to check the appropriateness of that buffer's size.

Using JMH on a typical, modern cloud platform, it was proven that the current 8K buffer is (much) too small on modern hardware:
The small buffer clearly stands in the way of faster transfers.
The ops/s of a simple `FileInputStream.transferTo(ByteArrayOutputStream)` operation on JDK 21 could be doubled (!) by only doubling the buffer size from 8K to 16K, which seems to be a considerable and cheap deal.
Doubling the buffer even more shows only marginal improvements of approx. 1% to 3% per duplication of size, which does not justify additional memory consumption.


TransferToPerformance.transferTo 8192 1048576 thrpt 25 1349.929 ? 47.057 ops/s
TransferToPerformance.transferTo 16384 1048576 thrpt 25 2633.560 ? 93.337 ops/s
TransferToPerformance.transferTo 32768 1048576 thrpt 25 2721.025 ? 89.555 ops/s
TransferToPerformance.transferTo 65536 1048576 thrpt 25 2855.949 ? 96.623 ops/s
TransferToPerformance.transferTo 131072 1048576 thrpt 25 2903.062 ? 40.798 ops/s


Even on small or limited platforms, an investment of 8K additonal temporary buffer is very cheap and very useful, as it doubles the performance of `InputStream::transferTo`, in particular for legacy (non-NIO) applications still using `FileInputStream` and `ByteArrayOutputStream`.
I dare to say, even if not proven, that is a very considerable (possibly the major) number of existing applications, as NIO was only adopted gradually by programmers.

Due to the given reasons, it should be approporiate to change `DEFAULT_BUFFER_SIZE` from 8192 to 16384.

-------------

Commit messages:
 - JDK-8299336

Changes: https://git.openjdk.org/jdk/pull/11783/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11783&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299336
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11783.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11783/head:pull/11783

PR: https://git.openjdk.org/jdk/pull/11783

From lichtenberger.johannes at gmail.com  Sat Dec 24 10:41:39 2022
From: lichtenberger.johannes at gmail.com (Johannes Lichtenberger)
Date: Sat, 24 Dec 2022 11:41:39 +0100
Subject: RFR: JDK-8299336 - InputStream::DEFAULT_BUFFER_SIZE should be
 16384
In-Reply-To: <LD1mjUQ5E01OMV3QicgbhdeCMxWVbnbSmGbVmjexW9Y=.214c934a-7a21-46ad-b8c2-9920302e47d7@github.com>
References: <LD1mjUQ5E01OMV3QicgbhdeCMxWVbnbSmGbVmjexW9Y=.214c934a-7a21-46ad-b8c2-9920302e47d7@github.com>
Message-ID: <CAGXNUvbBKDg7FwyGZf11NTMP1cGTM7P7Gc4J9rQt28-6ZNLj8g@mail.gmail.com>

I'm also looking forward to io_uring support on Linux kernels which support
it and the Windows equivalent :-) The first one should come with one of the
project Loom updates sometime.

Kind regards
Johannes

Markus KARG <duke at openjdk.org> schrieb am Sa., 24. Dez. 2022, 10:11:

> I/O had always been much slower than CPU and memory access, and thanks to
> physical constraints, always will be.
> While CPUs can get shrinked more and more, and can hold more and more
> memory cache on or nearby a CPU core, the distance between CPU core and I/O
> device cannot get reduced much: It will stay "far" away.
> Due to this simple logic (and other factors), the spread between
> performance of CPU and memory access on one hand, and performance of I/O on
> the other hand, increases with every new CPU generation.
> As a consequence, internal adjustment factors of the JDK need to get
> revised from time to time to ensure optimum performance and each hardware
> generation.
>
> One such factor is the size of the temporary transfer buffer used
> internally by `InputStream::transferTo`.
> Since its introduction with JDK 9 many years (hence hardware generations)
> have passed, so it's time to check the appropriateness of that buffer's
> size.
>
> Using JMH on a typical, modern cloud platform, it was proven that the
> current 8K buffer is (much) too small on modern hardware:
> The small buffer clearly stands in the way of faster transfers.
> The ops/s of a simple `FileInputStream.transferTo(ByteArrayOutputStream)`
> operation on JDK 21 could be doubled (!) by only doubling the buffer size
> from 8K to 16K, which seems to be a considerable and cheap deal.
> Doubling the buffer even more shows only marginal improvements of approx.
> 1% to 3% per duplication of size, which does not justify additional memory
> consumption.
>
>
> TransferToPerformance.transferTo 8192 1048576 thrpt 25 1349.929 ? 47.057
> ops/s
> TransferToPerformance.transferTo 16384 1048576 thrpt 25 2633.560 ? 93.337
> ops/s
> TransferToPerformance.transferTo 32768 1048576 thrpt 25 2721.025 ? 89.555
> ops/s
> TransferToPerformance.transferTo 65536 1048576 thrpt 25 2855.949 ? 96.623
> ops/s
> TransferToPerformance.transferTo 131072 1048576 thrpt 25 2903.062 ? 40.798
> ops/s
>
>
> Even on small or limited platforms, an investment of 8K additonal
> temporary buffer is very cheap and very useful, as it doubles the
> performance of `InputStream::transferTo`, in particular for legacy
> (non-NIO) applications still using `FileInputStream` and
> `ByteArrayOutputStream`.
> I dare to say, even if not proven, that is a very considerable (possibly
> the major) number of existing applications, as NIO was only adopted
> gradually by programmers.
>
> Due to the given reasons, it should be approporiate to change
> `DEFAULT_BUFFER_SIZE` from 8192 to 16384.
>
> -------------
>
> Commit messages:
>  - JDK-8299336
>
> Changes: https://git.openjdk.org/jdk/pull/11783/files
>  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11783&range=00
>   Issue: https://bugs.openjdk.org/browse/JDK-8299336
>   Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
>   Patch: https://git.openjdk.org/jdk/pull/11783.diff
>   Fetch: git fetch https://git.openjdk.org/jdk pull/11783/head:pull/11783
>
> PR: https://git.openjdk.org/jdk/pull/11783
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221224/7205f75f/attachment-0001.htm>

From alanb at openjdk.org  Tue Dec 27 07:53:53 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 27 Dec 2022 07:53:53 GMT
Subject: Integrated: 8298875: A module requiring "java.base" with flags
 ACC_SYNTHETIC should be rejected
In-Reply-To: <hFS1P8AQtGocnj-mPM7ShSKel9iLl7xxMwIjlmwCXqA=.f7b7da46-1df4-4706-9ee8-47ba200fac9d@github.com>
References: <hFS1P8AQtGocnj-mPM7ShSKel9iLl7xxMwIjlmwCXqA=.f7b7da46-1df4-4706-9ee8-47ba200fac9d@github.com>
Message-ID: <oKQLhkHpHp_wyGew8-XjZzb5mEE2GC2qUjKTcSlIx_I=.cebb1700-2822-42a1-ad56-9370abdd35ea@github.com>

On Fri, 16 Dec 2022 19:30:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> A small oversight with ModuleDescriptor.read when checking the requires table of a Module attribute. The requires entry for java.base should not have ACC_SYNTHETIC set.
> 
> A new test is added. Some of the existing tests used `@Test(expectedExceptions=...)`. I've changed some of these to use assertThrows to narrow it down to method that is expected to throw.

This pull request has now been integrated.

Changeset: 11fd651a
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/11fd651ab1820770e3c65cd49589416098987a87
Stats:     75 lines in 2 files changed: 34 ins; 17 del; 24 mod

8298875: A module requiring "java.base" with flags ACC_SYNTHETIC should be rejected

Reviewed-by: jpai, mchung

-------------

PR: https://git.openjdk.org/jdk/pull/11714

From mernst at openjdk.org  Tue Dec 27 14:26:39 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Tue, 27 Dec 2022 14:26:39 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v3]
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <G6y9-__VIQjwSKAhHqAaBz9XhPTAsANIlDIZqrlAlow=.efb3bc20-d266-4717-84ee-b970989f8e44@github.com>

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

Michael Ernst 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 ../jdk-openjdk into typos-typos
 - Reinstate typos in Apache code that is copied into the JDK
 - Merge ../jdk-openjdk into typos-typos
 - Remove file that was removed upstream
 - Fix inconsistency in capitalization
 - Undo change in zlip
 - Fix typos

-------------

Changes: https://git.openjdk.org/jdk/pull/10029/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10029&range=02
  Stats: 11 lines in 10 files changed: 0 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/10029.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10029/head:pull/10029

PR: https://git.openjdk.org/jdk/pull/10029

From mernst at openjdk.org  Tue Dec 27 14:26:40 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Tue, 27 Dec 2022 14:26:40 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <o4GUMwlhtn6ng4FZjHRzZ3iqJD0dlAWKnXsufxhmbqk=.4920d482-3bba-4814-88b6-6a7e839349e2@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <gOXCJJl7JqlhdMiDjhu5kbAGieFHPelXHl_XvNG3Pyw=.881b6edb-36c1-4044-99da-18b45b28a69b@github.com>
 <o4GUMwlhtn6ng4FZjHRzZ3iqJD0dlAWKnXsufxhmbqk=.4920d482-3bba-4814-88b6-6a7e839349e2@github.com>
Message-ID: <KQM3bb5WQ1wCnIsc8lnqTrD54nkWyrhnHyk7hkSfp70=.5924492b-d7e8-4a26-bbe7-f78f0c9f9959@github.com>

On Mon, 28 Nov 2022 09:00:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Could someone who knows the undocumented ins and outs of creating JDK pull requests could split this pull request up into multiple PRs?  Then it can be merged, rather than wasting all the effort that went into it.
>
>> Could someone who knows the undocumented ins and outs of creating JDK pull requests could split this pull request up into multiple PRs? Then it can be merged, rather than wasting all the effort that went into it.
> 
> I've raised https://github.com/openjdk/jdk/pull/11385 for one set of changes from this current PR. I'll pick up the other ones shortly in different PRs.

Many thanks to those (especially @jaikiran) who helped to merge many of these typo fixes.
I have pulled master and resolved merge conflicts.  Only 11 typo fixes remain.
Could someone shepherd those into the codebase?  Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From plevart at openjdk.org  Tue Dec 27 14:57:48 2022
From: plevart at openjdk.org (Peter Levart)
Date: Tue, 27 Dec 2022 14:57:48 GMT
Subject: RFR: JDK-8299336 - InputStream::DEFAULT_BUFFER_SIZE should be
 16384
In-Reply-To: <LD1mjUQ5E01OMV3QicgbhdeCMxWVbnbSmGbVmjexW9Y=.214c934a-7a21-46ad-b8c2-9920302e47d7@github.com>
References: <LD1mjUQ5E01OMV3QicgbhdeCMxWVbnbSmGbVmjexW9Y=.214c934a-7a21-46ad-b8c2-9920302e47d7@github.com>
Message-ID: <-zvTb1FuimdzPEgt29j6Bo9KzaY0ze5W9A7OAB5rOns=.999ac218-c941-42f4-a894-8582fe957ef5@github.com>

On Fri, 23 Dec 2022 22:28:34 GMT, Markus KARG <duke at openjdk.org> wrote:

> I/O had always been much slower than CPU and memory access, and thanks to physical constraints, always will be.
> While CPUs can get shrinked more and more, and can hold more and more memory cache on or nearby a CPU core, the distance between CPU core and I/O device cannot get reduced much: It will stay "far" away.
> Due to this simple logic (and other factors), the spread between performance of CPU and memory access on one hand, and performance of I/O on the other hand, increases with every new CPU generation.
> As a consequence, internal adjustment factors of the JDK need to get revised from time to time to ensure optimum performance and each hardware generation.
> 
> One such factor is the size of the temporary transfer buffer used internally by `InputStream::transferTo`.
> Since its introduction with JDK 9 many years (hence hardware generations) have passed, so it's time to check the appropriateness of that buffer's size.
> 
> Using JMH on a typical, modern cloud platform, it was proven that the current 8K buffer is (much) too small on modern hardware:
> The small buffer clearly stands in the way of faster transfers.
> The ops/s of a simple `FileInputStream.transferTo(ByteArrayOutputStream)` operation on JDK 21 could be doubled (!) by only doubling the buffer size from 8K to 16K, which seems to be a considerable and cheap deal.
> Doubling the buffer even more shows only marginal improvements of approx. 1% to 3% per duplication of size, which does not justify additional memory consumption.
> 
> 
> TransferToPerformance.transferTo 8192 1048576 thrpt 25 1349.929 ? 47.057 ops/s
> TransferToPerformance.transferTo 16384 1048576 thrpt 25 2633.560 ? 93.337 ops/s
> TransferToPerformance.transferTo 32768 1048576 thrpt 25 2721.025 ? 89.555 ops/s
> TransferToPerformance.transferTo 65536 1048576 thrpt 25 2855.949 ? 96.623 ops/s
> TransferToPerformance.transferTo 131072 1048576 thrpt 25 2903.062 ? 40.798 ops/s
> 
> 
> Even on small or limited platforms, an investment of 8K additonal temporary buffer is very cheap and very useful, as it doubles the performance of `InputStream::transferTo`, in particular for legacy (non-NIO) applications still using `FileInputStream` and `ByteArrayOutputStream`.
> I dare to say, even if not proven, that is a very considerable (possibly the major) number of existing applications, as NIO was only adopted gradually by programmers.
> 
> Due to the given reasons, it should be approporiate to change `DEFAULT_BUFFER_SIZE` from 8192 to 16384.

Hello Markus!
Could you show the JMH code that produced the benchmark results?

-------------

PR: https://git.openjdk.org/jdk/pull/11783

From duke at openjdk.org  Tue Dec 27 16:36:15 2022
From: duke at openjdk.org (Oliver Kopp)
Date: Tue, 27 Dec 2022 16:36:15 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v7]
In-Reply-To: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
References: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
Message-ID: <eXlOgRir1du0CecMNEXH7ollDF0ij6O7V2kqVF3pDEw=.9d4e03e5-a1f7-48c4-a026-c62ac925550d@github.com>

> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image".
> 
> Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods

Oliver Kopp has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into fix-8240567
 - Refine test
   
   Co-authored-by: Christoph <siedlerkiller at gmail.com>
 - Adapt number to have javac working (and refine test)
 - Remove obsolete comment
 - Begin to craft test
 - Reduce comment text
 - Reduce number of included ModuleDescriptors
 - Fix generated RETURN statement
 - Fixes JDK-8240567
   
   Co-authored-by: Christoph <siedlerkiller at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10704/files
  - new: https://git.openjdk.org/jdk/pull/10704/files/16fa5292..8f0abd23

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10704&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10704&range=05-06

  Stats: 380657 lines in 4960 files changed: 188407 ins; 130791 del; 61459 mod
  Patch: https://git.openjdk.org/jdk/pull/10704.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10704/head:pull/10704

PR: https://git.openjdk.org/jdk/pull/10704

From duke at openjdk.org  Tue Dec 27 16:37:48 2022
From: duke at openjdk.org (Markus KARG)
Date: Tue, 27 Dec 2022 16:37:48 GMT
Subject: RFR: JDK-8299336 - InputStream::DEFAULT_BUFFER_SIZE should be
 16384
In-Reply-To: <-zvTb1FuimdzPEgt29j6Bo9KzaY0ze5W9A7OAB5rOns=.999ac218-c941-42f4-a894-8582fe957ef5@github.com>
References: <LD1mjUQ5E01OMV3QicgbhdeCMxWVbnbSmGbVmjexW9Y=.214c934a-7a21-46ad-b8c2-9920302e47d7@github.com>
 <-zvTb1FuimdzPEgt29j6Bo9KzaY0ze5W9A7OAB5rOns=.999ac218-c941-42f4-a894-8582fe957ef5@github.com>
Message-ID: <ZGw-leEaHLDwJoo9OlPJZY9aqeqvMoLJYQ4m9c0w1z4=.e8a99e19-d731-4e21-b5da-37eedeaeac02@github.com>

On Tue, 27 Dec 2022 14:55:31 GMT, Peter Levart <plevart at openjdk.org> wrote:

> Hello Markus! Could you show the JMH code that produced the benchmark results?

The following lines make use of a custom method I have added to `InputStream` in a custom build of JDK 21, so JMH can control the size of the buffer. The test runs approx. 42 Minutes, and the result depends on the actual hardware you are using. The common sense of all tested hardware so far is that going from 8K to 16K you have a *strong* gain, but the *additional* gain is lower with duplicating buffer size further. You have *double* performance with the specific cloud VM I was using, while you only have approx. only *20%* gain on my personal laptop with local SSD. Anyways, you always have a *considerable* gain.


public class TransferToPerformance {

    public static void main(final String[] args) throws IOException {
        Main.main(args);
    }

    @State(Scope.Benchmark)
    public static class Config {

        @Param({ "1048576" })
        public int streamSize;

        @Param({ "8192", "16384", "32768", "65536", "131072" })
        public int bufferSize;

        public InputStream source;
        public OutputStream target;
        private Path path;

        @Setup(Level.Invocation)
        public void setUp() throws IOException {
            InputStream.setBufferSize(bufferSize); // static utility method using custom build of JDK 21
            path = Files.createTempFile("a-", ".bin");
            var bytes = createRandomBytes(streamSize);
            Files.deleteIfExists(this.path);
            Files.write(this.path, bytes, CREATE, TRUNCATE_EXISTING, WRITE);
            source = new FileInputStream(this.path.toFile());
            target = new ByteArrayOutputStream();
        }

        @TearDown(Level.Invocation)
        public void tearDown() throws IOException {
            source.close();
            target.close();
            source = null;
            target = null;
            Files.deleteIfExists(this.path);
        }
    }

    private static final Random RND = new Random(); 

    private static byte[] createRandomBytes(int size) {
        var bytes = new byte[size];
        RND.nextBytes(bytes);
        return bytes;
    }

    @Benchmark
    public final void transferTo(Config config, Blackhole blackhole) throws IOException {
        blackhole.consume(config.source.transferTo(config.target));
        config.target.flush();
        config.target.close();
    }

}

-------------

PR: https://git.openjdk.org/jdk/pull/11783

From cwimmer at openjdk.org  Tue Dec 27 20:20:27 2022
From: cwimmer at openjdk.org (Christian Wimmer)
Date: Tue, 27 Dec 2022 20:20:27 GMT
Subject: RFR: JDK-8262994: Refactor String.split to help method inlining
Message-ID: <Qx8nXCwS2-gs7luRXNRLpkauOlFYRrEZnSI5KNPJ_Lc=.db350bf4-d4a8-470b-ab95-764b6f9fb87c@github.com>

The method `String.split` contains a fast-path when the regular expression parameter is not really a regular expression, but just a single split character.
This fast path vs. slow path check can be constant folded when the regular expression parameter is a literal constant - a quite frequent pattern (for example, all JDK usages of `String.split` have a constant expression parameter). But method inlining in JIT and AOT compilers can usually not inline `String.split` because the method body is too large. Factoring out the actual fast-path splitting logic into a separate method solves this problem: the JIT or AOT compiler can inline `String.split`, constant-fold the fast/slow path check, and then only the invoke of either the fast path or the slow path remains.

-------------

Commit messages:
 - JDK-8262994: Refactor String.split to help method inlining

Changes: https://git.openjdk.org/jdk/pull/11791/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11791&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8262994
  Stats: 40 lines in 1 file changed: 8 ins; 2 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/11791.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11791/head:pull/11791

PR: https://git.openjdk.org/jdk/pull/11791

From duke at openjdk.org  Tue Dec 27 23:39:51 2022
From: duke at openjdk.org (Ismael Juma)
Date: Tue, 27 Dec 2022 23:39:51 GMT
Subject: RFR: JDK-8262994: Refactor String.split to help method inlining
In-Reply-To: <Qx8nXCwS2-gs7luRXNRLpkauOlFYRrEZnSI5KNPJ_Lc=.db350bf4-d4a8-470b-ab95-764b6f9fb87c@github.com>
References: <Qx8nXCwS2-gs7luRXNRLpkauOlFYRrEZnSI5KNPJ_Lc=.db350bf4-d4a8-470b-ab95-764b6f9fb87c@github.com>
Message-ID: <vnPbbKkqmAszESKiu1c6CL8Jk0xJTyTSZsVJ5tLekdY=.45264b20-9c51-46f4-a006-e222ad8f3d08@github.com>

On Tue, 27 Dec 2022 20:12:51 GMT, Christian Wimmer <cwimmer at openjdk.org> wrote:

> The method `String.split` contains a fast-path when the regular expression parameter is not really a regular expression, but just a single split character.
> This fast path vs. slow path check can be constant folded when the regular expression parameter is a literal constant - a quite frequent pattern (for example, all JDK usages of `String.split` have a constant expression parameter). But method inlining in JIT and AOT compilers can usually not inline `String.split` because the method body is too large. Factoring out the actual fast-path splitting logic into a separate method solves this problem: the JIT or AOT compiler can inline `String.split`, constant-fold the fast/slow path check, and then only the invoke of either the fast path or the slow path remains.

src/java.base/share/classes/java/lang/String.java line 3133:

> 3131:         {
> 3132:             // All the checks above can potentially be constant folded by
> 3133:             // a JIT/AOT compiler when the regex is a constant string.

Probably worth mentioning explicitly that the private `split` was extracted to help with inlining (to reduce the probability of future regressions).

-------------

PR: https://git.openjdk.org/jdk/pull/11791

From duke at openjdk.org  Wed Dec 28 08:46:09 2022
From: duke at openjdk.org (Oliver Kopp)
Date: Wed, 28 Dec 2022 08:46:09 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v8]
In-Reply-To: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
References: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
Message-ID: <rjn1TfK4bJk9tO-HGwlTEIfjZvMUaJM9MQlrf-adkfY=.d81a0ec9-cae0-4bc3-8289-957ce43dbd33@github.com>

> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image".
> 
> Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods

Oliver Kopp has updated the pull request incrementally with two additional commits since the last revision:

 - Refine tests
   
   Co-authored-by: Christoph <siedlerkiller at gmail.com>
   Co-authored-by: Carl Christian Snethlage <50491877+calixtus at users.noreply.github.com>
 - Revert to original SystemModulesPlugin
   
   Co-authored-by: Christoph <siedlerkiller at gmail.com>
   Co-authored-by: Carl Christian Snethlage <50491877+calixtus at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10704/files
  - new: https://git.openjdk.org/jdk/pull/10704/files/8f0abd23..96362d54

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10704&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10704&range=06-07

  Stats: 69 lines in 2 files changed: 16 ins; 45 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/10704.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10704/head:pull/10704

PR: https://git.openjdk.org/jdk/pull/10704

From mbaesken at openjdk.org  Wed Dec 28 12:26:23 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 28 Dec 2022 12:26:23 GMT
Subject: RFR: JDK-8299388: java/util/regex/NegativeArraySize.java fails on
 Alpine and sometimes Windows
Message-ID: <wX3x7TDrW4ZEJbPgeqmWbPdhAWvi3GH4IfRRlQ-gbsI=.c25b8773-9253-4630-951e-863a0897c71f@github.com>

The test java/util/regex/NegativeArraySize.java seems to have high memory requirements, and these requirements lead to some errors.
On Alpine Linux we run regularly into this error when executing the test:
result: Failed. Unexpected exit from test [exit code: 137]
This seems to be OOM related.
Probably we should avoid running the test on Alpine.

On Windows the test usually works, but seems to depend as well on the memory situation of the machine.
Once we got this error recently :
OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00000006c0000000, 5368709120, 0) failed; error='The paging file is too small for this operation to complete' (DOS error/errno=1455)
OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00000006c0000000, 5368709120, 0) failed; error='The paging file is too small for this operation to complete' (DOS error/errno=1455)
result: Failed. Unexpected exit from test [exit code: 1]

The hs_err file generated showed :


# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 5368709120 bytes for G1 virtual space
# Possible reasons:
# The system is out of physical RAM or swap space
# The process is running with CompressedOops enabled, and the Java Heap may be blocking the growth of the native heap


So it looks like having 5g maxMemory as a requirement is not sufficient for the test (the reported mmap value is already slightly above 5g).

-------------

Commit messages:
 - JDK-8299388

Changes: https://git.openjdk.org/jdk/pull/11796/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11796&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299388
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11796.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11796/head:pull/11796

PR: https://git.openjdk.org/jdk/pull/11796

From mbaesken at openjdk.org  Wed Dec 28 14:30:56 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 28 Dec 2022 14:30:56 GMT
Subject: RFR: JDK-8298170 : Introduce a macro for exception check,
 free and return
In-Reply-To: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
References: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
Message-ID: <lGGwZvwa0eAtXlap63EaW0vJxvWj_u_g1eG_0D7HaaI=.ee110e67-29a4-4120-a048-d1835913e3d0@github.com>

On Tue, 6 Dec 2022 15:20:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have a number of places in the codebase  where a macro could help when we check an exception and afterwrads free something and return.

okay, if keeping the block in the code that contains free and return, we probably just stay with what we have


if ((*env)->ExceptionCheck(env)) {
  free(xyz);
  return val;
}

-------------

PR: https://git.openjdk.org/jdk/pull/11539

From mbaesken at openjdk.org  Wed Dec 28 14:30:56 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 28 Dec 2022 14:30:56 GMT
Subject: Withdrawn: JDK-8298170 : Introduce a macro for exception check,
 free and return
In-Reply-To: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
References: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
Message-ID: <hovzXng89xaaB2qEqOczilkrVMvf20YRYcHirL9CZ8k=.24116009-ed32-4562-9c00-a859bb2c8494@github.com>

On Tue, 6 Dec 2022 15:20:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have a number of places in the codebase  where a macro could help when we check an exception and afterwrads free something and return.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11539

From stsypanov at openjdk.org  Wed Dec 28 20:44:48 2022
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 28 Dec 2022 20:44:48 GMT
Subject: RFR: JDK-8262994: Refactor String.split to help method inlining
In-Reply-To: <Qx8nXCwS2-gs7luRXNRLpkauOlFYRrEZnSI5KNPJ_Lc=.db350bf4-d4a8-470b-ab95-764b6f9fb87c@github.com>
References: <Qx8nXCwS2-gs7luRXNRLpkauOlFYRrEZnSI5KNPJ_Lc=.db350bf4-d4a8-470b-ab95-764b6f9fb87c@github.com>
Message-ID: <ad2Zj_AZmx3Dp8fP_wi3zwIF38jI9TAttio64QkR7Oc=.317ea2b3-eba0-4a87-8e16-8b01c3241cdb@github.com>

On Tue, 27 Dec 2022 20:12:51 GMT, Christian Wimmer <cwimmer at openjdk.org> wrote:

> The method `String.split` contains a fast-path when the regular expression parameter is not really a regular expression, but just a single split character.
> This fast path vs. slow path check can be constant folded when the regular expression parameter is a literal constant - a quite frequent pattern (for example, all JDK usages of `String.split` have a constant expression parameter). But method inlining in JIT and AOT compilers can usually not inline `String.split` because the method body is too large. Factoring out the actual fast-path splitting logic into a separate method solves this problem: the JIT or AOT compiler can inline `String.split`, constant-fold the fast/slow path check, and then only the invoke of either the fast path or the slow path remains.

Is there any benchmark proving the benefit?

-------------

PR: https://git.openjdk.org/jdk/pull/11791

From mdoerr at openjdk.org  Thu Dec 29 10:03:50 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 29 Dec 2022 10:03:50 GMT
Subject: RFR: JDK-8299388: java/util/regex/NegativeArraySize.java fails on
 Alpine and sometimes Windows
In-Reply-To: <wX3x7TDrW4ZEJbPgeqmWbPdhAWvi3GH4IfRRlQ-gbsI=.c25b8773-9253-4630-951e-863a0897c71f@github.com>
References: <wX3x7TDrW4ZEJbPgeqmWbPdhAWvi3GH4IfRRlQ-gbsI=.c25b8773-9253-4630-951e-863a0897c71f@github.com>
Message-ID: <sKXUrFtKmVUwT3Ui0L6SZzbuC5yyeum2LwxnJW97dhI=.6542874b-14d2-4ca0-a0c9-501e9399ab22@github.com>

On Wed, 28 Dec 2022 12:19:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The test java/util/regex/NegativeArraySize.java seems to have high memory requirements, and these requirements lead to some errors.
> On Alpine Linux we run regularly into this error when executing the test:
> result: Failed. Unexpected exit from test [exit code: 137]
> This seems to be OOM related.
> Probably we should avoid running the test on Alpine.
> 
> On Windows the test usually works, but seems to depend as well on the memory situation of the machine.
> Once we got this error recently :
> OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00000006c0000000, 5368709120, 0) failed; error='The paging file is too small for this operation to complete' (DOS error/errno=1455)
> OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00000006c0000000, 5368709120, 0) failed; error='The paging file is too small for this operation to complete' (DOS error/errno=1455)
> result: Failed. Unexpected exit from test [exit code: 1]
> 
> The hs_err file generated showed :
> 
> 
> # There is insufficient memory for the Java Runtime Environment to continue.
> # Native memory allocation (mmap) failed to map 5368709120 bytes for G1 virtual space
> # Possible reasons:
> # The system is out of physical RAM or swap space
> # The process is running with CompressedOops enabled, and the Java Heap may be blocking the growth of the native heap
> 
> 
> So it looks like having 5g maxMemory as a requirement is not sufficient for the test (the reported mmap value is already slightly above 5g).

Looks reasonable. Let's hear what other people think.

test/jdk/java/util/regex/NegativeArraySize.java line 28:

> 26:  * @bug 8223174
> 27:  * @summary Pattern.compile() can throw confusing NegativeArraySizeException
> 28:  * @requires os.maxMemory >= 6g & vm.bits == 64  & !vm.musl

Double whitespace.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11796

From mbaesken at openjdk.org  Thu Dec 29 10:26:11 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 29 Dec 2022 10:26:11 GMT
Subject: RFR: JDK-8299388: java/util/regex/NegativeArraySize.java fails on
 Alpine and sometimes Windows [v2]
In-Reply-To: <wX3x7TDrW4ZEJbPgeqmWbPdhAWvi3GH4IfRRlQ-gbsI=.c25b8773-9253-4630-951e-863a0897c71f@github.com>
References: <wX3x7TDrW4ZEJbPgeqmWbPdhAWvi3GH4IfRRlQ-gbsI=.c25b8773-9253-4630-951e-863a0897c71f@github.com>
Message-ID: <iM7LHVsiIxXI5tLX02rPgtrixe7HnBwvMY2nyuMbKNk=.3873715f-c8b9-4f5c-9bfa-cdd438b6dbac@github.com>

> The test java/util/regex/NegativeArraySize.java seems to have high memory requirements, and these requirements lead to some errors.
> On Alpine Linux we run regularly into this error when executing the test:
> result: Failed. Unexpected exit from test [exit code: 137]
> This seems to be OOM related.
> Probably we should avoid running the test on Alpine.
> 
> On Windows the test usually works, but seems to depend as well on the memory situation of the machine.
> Once we got this error recently :
> OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00000006c0000000, 5368709120, 0) failed; error='The paging file is too small for this operation to complete' (DOS error/errno=1455)
> OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00000006c0000000, 5368709120, 0) failed; error='The paging file is too small for this operation to complete' (DOS error/errno=1455)
> result: Failed. Unexpected exit from test [exit code: 1]
> 
> The hs_err file generated showed :
> 
> 
> # There is insufficient memory for the Java Runtime Environment to continue.
> # Native memory allocation (mmap) failed to map 5368709120 bytes for G1 virtual space
> # Possible reasons:
> # The system is out of physical RAM or swap space
> # The process is running with CompressedOops enabled, and the Java Heap may be blocking the growth of the native heap
> 
> 
> So it looks like having 5g maxMemory as a requirement is not sufficient for the test (the reported mmap value is already slightly above 5g).

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Remove double whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11796/files
  - new: https://git.openjdk.org/jdk/pull/11796/files/8d947dae..c04f185e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11796&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11796&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11796.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11796/head:pull/11796

PR: https://git.openjdk.org/jdk/pull/11796

From mbaesken at openjdk.org  Thu Dec 29 10:26:11 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 29 Dec 2022 10:26:11 GMT
Subject: RFR: JDK-8299388: java/util/regex/NegativeArraySize.java fails on
 Alpine and sometimes Windows [v2]
In-Reply-To: <sKXUrFtKmVUwT3Ui0L6SZzbuC5yyeum2LwxnJW97dhI=.6542874b-14d2-4ca0-a0c9-501e9399ab22@github.com>
References: <wX3x7TDrW4ZEJbPgeqmWbPdhAWvi3GH4IfRRlQ-gbsI=.c25b8773-9253-4630-951e-863a0897c71f@github.com>
 <sKXUrFtKmVUwT3Ui0L6SZzbuC5yyeum2LwxnJW97dhI=.6542874b-14d2-4ca0-a0c9-501e9399ab22@github.com>
Message-ID: <KwwXV58zIb-GPOtaoRPmSHKdcQF-Mv_gZEPMxIXW8_w=.c3c32752-0e65-4544-9f0c-1c1514069e2b@github.com>

On Thu, 29 Dec 2022 10:00:30 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove double whitespace
>
> test/jdk/java/util/regex/NegativeArraySize.java line 28:
> 
>> 26:  * @bug 8223174
>> 27:  * @summary Pattern.compile() can throw confusing NegativeArraySizeException
>> 28:  * @requires os.maxMemory >= 6g & vm.bits == 64  & !vm.musl
> 
> Double whitespace.

I removed the double whitespace.

-------------

PR: https://git.openjdk.org/jdk/pull/11796

From mbaesken at openjdk.org  Thu Dec 29 12:16:51 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 29 Dec 2022 12:16:51 GMT
Subject: RFR: JDK-8299388: java/util/regex/NegativeArraySize.java fails on
 Alpine and sometimes Windows [v2]
In-Reply-To: <iM7LHVsiIxXI5tLX02rPgtrixe7HnBwvMY2nyuMbKNk=.3873715f-c8b9-4f5c-9bfa-cdd438b6dbac@github.com>
References: <wX3x7TDrW4ZEJbPgeqmWbPdhAWvi3GH4IfRRlQ-gbsI=.c25b8773-9253-4630-951e-863a0897c71f@github.com>
 <iM7LHVsiIxXI5tLX02rPgtrixe7HnBwvMY2nyuMbKNk=.3873715f-c8b9-4f5c-9bfa-cdd438b6dbac@github.com>
Message-ID: <MpNyRiDKmrMG7P5k1Yz-83qI_E9HDDEDIKDP5cFZQDs=.7d0439b4-7c93-481b-9894-0f24632d1f75@github.com>

On Thu, 29 Dec 2022 10:26:11 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The test java/util/regex/NegativeArraySize.java seems to have high memory requirements, and these requirements lead to some errors.
>> On Alpine Linux we run regularly into this error when executing the test:
>> result: Failed. Unexpected exit from test [exit code: 137]
>> This seems to be OOM related.
>> Probably we should avoid running the test on Alpine.
>> 
>> On Windows the test usually works, but seems to depend as well on the memory situation of the machine.
>> Once we got this error recently :
>> OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00000006c0000000, 5368709120, 0) failed; error='The paging file is too small for this operation to complete' (DOS error/errno=1455)
>> OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00000006c0000000, 5368709120, 0) failed; error='The paging file is too small for this operation to complete' (DOS error/errno=1455)
>> result: Failed. Unexpected exit from test [exit code: 1]
>> 
>> The hs_err file generated showed :
>> 
>> 
>> # There is insufficient memory for the Java Runtime Environment to continue.
>> # Native memory allocation (mmap) failed to map 5368709120 bytes for G1 virtual space
>> # Possible reasons:
>> # The system is out of physical RAM or swap space
>> # The process is running with CompressedOops enabled, and the Java Heap may be blocking the growth of the native heap
>> 
>> 
>> So it looks like having 5g maxMemory as a requirement is not sufficient for the test (the reported mmap value is already slightly above 5g).
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove double whitespace

Hi Martin, thanks for the review !

> Looks reasonable. Let's hear what other people think.

Indeed we might discuss better ways of making the test more reliable.  However it is not so easy to predict / handle all potential error situations of the test that are caused by various memory limitations.

-------------

PR: https://git.openjdk.org/jdk/pull/11796

From alanb at openjdk.org  Thu Dec 29 17:08:49 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 29 Dec 2022 17:08:49 GMT
Subject: RFR: JDK-8299388: java/util/regex/NegativeArraySize.java fails on
 Alpine and sometimes Windows [v2]
In-Reply-To: <iM7LHVsiIxXI5tLX02rPgtrixe7HnBwvMY2nyuMbKNk=.3873715f-c8b9-4f5c-9bfa-cdd438b6dbac@github.com>
References: <wX3x7TDrW4ZEJbPgeqmWbPdhAWvi3GH4IfRRlQ-gbsI=.c25b8773-9253-4630-951e-863a0897c71f@github.com>
 <iM7LHVsiIxXI5tLX02rPgtrixe7HnBwvMY2nyuMbKNk=.3873715f-c8b9-4f5c-9bfa-cdd438b6dbac@github.com>
Message-ID: <nNVP_fljx9wtyenOJYQ1OsOJmTZFkesHSJYeGiM0z2M=.954483e5-e7df-4d74-81e7-99bb59eadc15@github.com>

On Thu, 29 Dec 2022 10:26:11 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The test java/util/regex/NegativeArraySize.java seems to have high memory requirements, and these requirements lead to some errors.
>> On Alpine Linux we run regularly into this error when executing the test:
>> result: Failed. Unexpected exit from test [exit code: 137]
>> This seems to be OOM related.
>> Probably we should avoid running the test on Alpine.
>> 
>> On Windows the test usually works, but seems to depend as well on the memory situation of the machine.
>> Once we got this error recently :
>> OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00000006c0000000, 5368709120, 0) failed; error='The paging file is too small for this operation to complete' (DOS error/errno=1455)
>> OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00000006c0000000, 5368709120, 0) failed; error='The paging file is too small for this operation to complete' (DOS error/errno=1455)
>> result: Failed. Unexpected exit from test [exit code: 1]
>> 
>> The hs_err file generated showed :
>> 
>> 
>> # There is insufficient memory for the Java Runtime Environment to continue.
>> # Native memory allocation (mmap) failed to map 5368709120 bytes for G1 virtual space
>> # Possible reasons:
>> # The system is out of physical RAM or swap space
>> # The process is running with CompressedOops enabled, and the Java Heap may be blocking the growth of the native heap
>> 
>> 
>> So it looks like having 5g maxMemory as a requirement is not sufficient for the test (the reported mmap value is already slightly above 5g).
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove double whitespace

Looks okay.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11796

From mbaesken at openjdk.org  Fri Dec 30 07:46:54 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Dec 2022 07:46:54 GMT
Subject: Integrated: JDK-8299388: java/util/regex/NegativeArraySize.java fails
 on Alpine and sometimes Windows
In-Reply-To: <wX3x7TDrW4ZEJbPgeqmWbPdhAWvi3GH4IfRRlQ-gbsI=.c25b8773-9253-4630-951e-863a0897c71f@github.com>
References: <wX3x7TDrW4ZEJbPgeqmWbPdhAWvi3GH4IfRRlQ-gbsI=.c25b8773-9253-4630-951e-863a0897c71f@github.com>
Message-ID: <oiS5G_eA6stIB-zr8QsgO2fJbyBAsY6fmOwB5g-poG4=.c996817a-b453-492e-88ec-6d2869c74dba@github.com>

On Wed, 28 Dec 2022 12:19:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The test java/util/regex/NegativeArraySize.java seems to have high memory requirements, and these requirements lead to some errors.
> On Alpine Linux we run regularly into this error when executing the test:
> result: Failed. Unexpected exit from test [exit code: 137]
> This seems to be OOM related.
> Probably we should avoid running the test on Alpine.
> 
> On Windows the test usually works, but seems to depend as well on the memory situation of the machine.
> Once we got this error recently :
> OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00000006c0000000, 5368709120, 0) failed; error='The paging file is too small for this operation to complete' (DOS error/errno=1455)
> OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00000006c0000000, 5368709120, 0) failed; error='The paging file is too small for this operation to complete' (DOS error/errno=1455)
> result: Failed. Unexpected exit from test [exit code: 1]
> 
> The hs_err file generated showed :
> 
> 
> # There is insufficient memory for the Java Runtime Environment to continue.
> # Native memory allocation (mmap) failed to map 5368709120 bytes for G1 virtual space
> # Possible reasons:
> # The system is out of physical RAM or swap space
> # The process is running with CompressedOops enabled, and the Java Heap may be blocking the growth of the native heap
> 
> 
> So it looks like having 5g maxMemory as a requirement is not sufficient for the test (the reported mmap value is already slightly above 5g).

This pull request has now been integrated.

Changeset: c2e3d728
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c2e3d7284814cd6b49f44b4de18e0f92310422b0
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8299388: java/util/regex/NegativeArraySize.java fails on Alpine and sometimes Windows

Reviewed-by: mdoerr, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/11796

From zjx001202 at gmail.com  Fri Dec 30 12:12:45 2022
From: zjx001202 at gmail.com (Glavo)
Date: Fri, 30 Dec 2022 20:12:45 +0800
Subject: The javadocs of some methods in NIO Buffer are missing @since
Message-ID: <CAJL5A3=e=r-3g9A+9ELwB8qnpMrC2NBKUxdwN+abx3-0pvZXeg@mail.gmail.com>

Java 9 overrides the rewind, flip and other methods of Buffer in subclasses
of Buffer such as ByteBuffer.
The methods in these subclasses do not add @since 9 to javadoc.

I think this is an oversight, because this modification destroys some code.
When compiling them with JDK 9+ and using the -target 8 option instead of
-release 8,
the generated class file crashes when running in Java 8.

IDEs cannot detect this error because there is no @since document.
Therefore, I think it is important to add @since to them, and they need to
be back ported to Java 11/17.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221230/30ff79bd/attachment-0001.htm>

From joe.darcy at oracle.com  Fri Dec 30 18:42:28 2022
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 30 Dec 2022 10:42:28 -0800
Subject: The javadocs of some methods in NIO Buffer are missing @since
In-Reply-To: <CAJL5A3=e=r-3g9A+9ELwB8qnpMrC2NBKUxdwN+abx3-0pvZXeg@mail.gmail.com>
References: <CAJL5A3=e=r-3g9A+9ELwB8qnpMrC2NBKUxdwN+abx3-0pvZXeg@mail.gmail.com>
Message-ID: <7aa9059c-7e0e-6c61-a87c-b9a537f2a8df@oracle.com>

On 12/30/2022 4:12 AM, Glavo wrote:
> Java 9 overrides the rewind, flip and other methods of Buffer in 
> subclasses of Buffer such as ByteBuffer.
> The methods in these subclasses do not add @since 9 to javadoc.
>
> I think this is an oversight, because this modification destroys some 
> code.
> When compiling them with JDK 9+ and using the -target 8 option instead 
> of -release 8,
> the generated class file crashes when running in Java 8.

Which is exactly why compiling with "javac -source $OLD -target $OLD" 
*without* setting the bootclasspath was not a recommended option and 
started generating a warning as of JDK 7:

https://web.archive.org/web/20101225145622/http://blogs.sun.com/darcy/entry/bootclasspath_older_source

>
> IDEs cannot detect this error because there is no @since document.
> Therefore, I think it is important to add @since to them, and they 
> need to be back ported to Java 11/17.


The solution to a misconfigured build is to configure the build 
properly, which includes using --release $FOO where available.

-Joe


From zjx001202 at gmail.com  Fri Dec 30 19:11:13 2022
From: zjx001202 at gmail.com (Glavo)
Date: Sat, 31 Dec 2022 03:11:13 +0800
Subject: The javadocs of some methods in NIO Buffer are missing @since
In-Reply-To: <7aa9059c-7e0e-6c61-a87c-b9a537f2a8df@oracle.com>
References: <CAJL5A3=e=r-3g9A+9ELwB8qnpMrC2NBKUxdwN+abx3-0pvZXeg@mail.gmail.com>
 <7aa9059c-7e0e-6c61-a87c-b9a537f2a8df@oracle.com>
Message-ID: <CAJL5A3=LtA9DBQn_byuSeTOx4gJaDmg6nKesFCYiFdibcU=DfA@mail.gmail.com>

I agree that it is a good choice to use -release or set bootclasspath.
However, this is not always realistic.

Using -release means that we will encounter many JPMS problems.
For example, using --add-exports for system modules is not allowed when
using -release.

In addition, sometimes we may want to deliberately bypass the restriction
of -release:
We may use some new APIs of higher Java versions in our code.
As long as we check the Java version at runtime and ensure that the code
path is not executed
when running on a lower version of Java, this is also reasonable.

For setting bootclasspath... Well, although I know it should be like this
in theory, I've never seen anyone set it.
Since I have installed the corresponding version of JDK, why don't I
compile with it directly?

Let's return to this issue. Whether use -release or set bootclasspath, I
think it's just a workaround.
Whether the compiler will check this problem or not, it is our original
task to let users and static analysts
understand this problem from the document.
I think there is no doubt that the lack of @since is an oversight.



On Sat, Dec 31, 2022 at 2:42 AM Joe Darcy <joe.darcy at oracle.com> wrote:

> On 12/30/2022 4:12 AM, Glavo wrote:
> > Java 9 overrides the rewind, flip and other methods of Buffer in
> > subclasses of Buffer such as ByteBuffer.
> > The methods in these subclasses do not add @since 9 to javadoc.
> >
> > I think this is an oversight, because this modification destroys some
> > code.
> > When compiling them with JDK 9+ and using the -target 8 option instead
> > of -release 8,
> > the generated class file crashes when running in Java 8.
>
> Which is exactly why compiling with "javac -source $OLD -target $OLD"
> *without* setting the bootclasspath was not a recommended option and
> started generating a warning as of JDK 7:
>
>
> https://web.archive.org/web/20101225145622/http://blogs.sun.com/darcy/entry/bootclasspath_older_source
>
> >
> > IDEs cannot detect this error because there is no @since document.
> > Therefore, I think it is important to add @since to them, and they
> > need to be back ported to Java 11/17.
>
>
> The solution to a misconfigured build is to configure the build
> properly, which includes using --release $FOO where available.
>
> -Joe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221231/b56c8b27/attachment.htm>

From Alan.Bateman at oracle.com  Sat Dec 31 08:38:37 2022
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 31 Dec 2022 08:38:37 +0000
Subject: The javadocs of some methods in NIO Buffer are missing @since
In-Reply-To: <CAJL5A3=LtA9DBQn_byuSeTOx4gJaDmg6nKesFCYiFdibcU=DfA@mail.gmail.com>
References: <CAJL5A3=e=r-3g9A+9ELwB8qnpMrC2NBKUxdwN+abx3-0pvZXeg@mail.gmail.com>
 <7aa9059c-7e0e-6c61-a87c-b9a537f2a8df@oracle.com>
 <CAJL5A3=LtA9DBQn_byuSeTOx4gJaDmg6nKesFCYiFdibcU=DfA@mail.gmail.com>
Message-ID: <46d254cd-4f0d-f81c-8e2b-20579e4379ac@oracle.com>

On 30/12/2022 19:11, Glavo wrote:
> I agree that it is a good choice to use -release or set bootclasspath. 
> However, this is not always realistic.
>
> Using -release means that we will encounter many JPMS problems.
> For example, using --add-exports for system modules is not allowed 
> when using -release.

This combination of options doesn't make sense. If you are going off 
piste and compiling against JDK internal classes then you'll need to 
have that JDK present on your file system. A release number maps to the 
language and APIs in that release, it can't be expected to know about 
JDK internal classes that happen to be a JDK build as they can vary and 
shimmer by vendor or update. Maybe if you could expand a bit on what you 
are doing so it can help you avoid the configuration issue in your build.


>
> In addition, sometimes we may want to deliberately bypass the 
> restriction of -release:
> We may use some new APIs of higher Java versions in our code.
> As long as we check the Java version at runtime and ensure that the 
> code path is not executed
> when running on a lower version of Java, this is also reasonable.
>
This reads like you want to compile to --release 8 but have static 
references in version 52 class files to APIs that were added in Java 9+, 
is that right? This may be a setup for a world of hurt and maybe you 
should explore Multi-Release JAR files for this.

-Alan