From dholmes at openjdk.org  Thu Sep  1 04:51:08 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 1 Sep 2022 04:51:08 GMT
Subject: RFR: 8230374: maxOutputSize, instead of javatest.maxOutputSize,
 should be used in TEST.properties
In-Reply-To: <TP-KpPaBpJ7_BCt0k6pk8Bht6S4OLK7-XgHcAVoA0GQ=.63c90aa1-3db5-4e3e-a0c2-5eb0a9835abf@github.com>
References: <TP-KpPaBpJ7_BCt0k6pk8Bht6S4OLK7-XgHcAVoA0GQ=.63c90aa1-3db5-4e3e-a0c2-5eb0a9835abf@github.com>
Message-ID: <UBYGj7DDxuHbTobo_H4BgE0EF31692ea1uFocTe22Lw=.ea79f3a2-f604-4b9d-8e3b-bf505e77d73f@github.com>

On Mon, 29 Aug 2022 21:25:29 GMT, Rahul Prabhu <duke at openjdk.org> wrote:

> Rewrote javatest.maxOutputSize as maxOutputSize in the TEST.properties file in test/jdk/jdk/lambda to match the same declarations in other TEST.properties files. The jtreg specification with the correct syntax for maxOutputSize is at https://openjdk.org/jtreg/tag-spec.html.

Fix looks good. Thanks.

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

Marked as reviewed by dholmes (Reviewer).

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

From darcy at openjdk.org  Thu Sep  1 05:23:25 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 1 Sep 2022 05:23:25 GMT
Subject: RFR: JDK-8173605: Remove support for source and target 1.7 option
 in javac [v2]
In-Reply-To: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>
References: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>
Message-ID: <PhjxTbUT9SG0f9E9xTuaJtcO2dXs2BXBUiykCQN0VR8=.e1d79c6c-208e-4aa9-bd60-266e6d387842@github.com>

> Update to remove support for -source/-target/--release 7 from javac.
> 
> As seen in the PR, many test fails are affected. Further refactorings of javac's implementation that can be made from dropping 7 support are left as future work.

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

 - Update copyrights.
 - Delete unneeded test.
 - Merge branch 'master' into JDK-8173605
 - Merge branch 'master' into JDK-8173605
 - Small refactoring to remove more stale code.
 - Remove effectively dead code.
 - Adjust data for CheckExamples test.
 - Partial restore of DEFAULT_METHODS Source.Feature for test java/lang/invoke/defineHiddenClass/PreviewHiddenClass.java.
 - Merge branch 'master' into JDK-8173605
 - Fix MultiReleaseJars.java.
 - ... and 17 more: https://git.openjdk.org/jdk/compare/a81a20ee...b2039d68

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10074/files
  - new: https://git.openjdk.org/jdk/pull/10074/files/f3095350..b2039d68

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

  Stats: 14641 lines in 536 files changed: 4475 ins; 7382 del; 2784 mod
  Patch: https://git.openjdk.org/jdk/pull/10074.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10074/head:pull/10074

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

From aturbanov at openjdk.org  Thu Sep  1 06:24:58 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 1 Sep 2022 06:24:58 GMT
Subject: RFR: 8293197: Avoid double racy reads from non-volatile fields in
 SharedSecrets
Message-ID: <GvvKthp1tV-BsDwulYsu5nGEYXKnibDPse5MVdQHyyg=.f7ce5178-d88e-44d6-9103-6d94de127cef@github.com>

After integration of [JDK-8259021](https://bugs.openjdk.org/browse/JDK-8259021) a few more fields were added to `SharedSecrets` class. It make sense to update their reading code to use the same idiom.

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

Commit messages:
 - [PATCH] SharedSecrets should avoid double racy reads from non-volatile fields
 - [PATCH] SharedSecrets should avoid double racy reads from non-volatile fields

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

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

From jpai at openjdk.org  Thu Sep  1 06:32:04 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 1 Sep 2022 06:32:04 GMT
Subject: RFR: 8293008: Replace uses of StringBuffer with StringBuilder in
 MergeCollation [v2]
In-Reply-To: <Hv1r0u6eG8WTefw4fMJOQ9s8_OQf_REWuIS6Fo9lPcI=.490e6586-bc2b-418a-93b9-61b5e7081ede@github.com>
References: <xd8CMsCBvuQT6uJHCsO1DF6yNs3ZY6BB1Y-Fs82F1as=.98656fc5-e52d-4fa3-8e7d-3150d4b154ff@github.com>
 <S-iuHneomZKuiz0qOIBcdl-GBTXQEs0W0k2tmdcooN4=.00ac5745-2628-4084-aba2-e6d2e449b9d4@github.com>
 <Hv1r0u6eG8WTefw4fMJOQ9s8_OQf_REWuIS6Fo9lPcI=.490e6586-bc2b-418a-93b9-61b5e7081ede@github.com>
Message-ID: <XuJVWWQ6dKmu8Vj2wN2lWtbNVUpmhSMLSHzs8uhvsko=.15b28926-68bd-4ebb-ba40-2552c9bcb86d@github.com>

On Wed, 31 Aug 2022 08:40:29 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/PatternEntry.java line 55:
>> 
>>> 53:      * Gets the current extension, quoted
>>> 54:      */
>>> 55:     public void appendQuotedExtension(StringBuilder toAddTo) {
>> 
>> Hello Andrey, this and the other `public` method that's changed in this (package private) class don't seem to be used anywhere else other than this class itself. So maybe you could change them to `private` as part of this change?
>
> Changed a few of methods to `private`

Thank you Andrey for doing those changes.

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

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

From dholmes at openjdk.org  Thu Sep  1 06:33:13 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 1 Sep 2022 06:33:13 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v7]
In-Reply-To: <5dksriRuuZ4zEr_XQTk9zVcJ2Y77KoX9POg8H40IMtI=.b5e1ea74-dfb0-413a-b731-47f7d7106351@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <LP-gofubXbRsQ_VDAN1CcBqr3ethNG7WAW963kJHXYU=.cf685c2f-09db-427f-a718-746c928613dd@github.com>
 <xgVZFbSZN7cVLZ5jdSecQKr-3Jc25uS9prS5AJgV9sQ=.e5a94319-565c-47b0-b461-705bf2ae439f@github.com>
 <oGzFPebmEl9Sww4TzDlySv-11G55f3RBlpEl-sg6HEc=.00521a1b-8e66-4f6d-8d74-3f5afdef0f6a@github.com>
 <5dksriRuuZ4zEr_XQTk9zVcJ2Y77KoX9POg8H40IMtI=.b5e1ea74-dfb0-413a-b731-47f7d7106351@github.com>
Message-ID: <fv-KUmviw7HBex58cHnMkY7hpPXFTMEOSGfFav4u-Yk=.18356296-4f30-4cf8-878d-3388f6aeffe3@github.com>

On Mon, 29 Aug 2022 08:21:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I don't think we need to distinguish between platform and virtual threads here at all. Isn't it the case that virtual threads also have a run() method and they too terminate when run() completes as described (together with UEH)? The fact most Thread run() methods call something else's run() method is immaterial. We don't know what a run() method will do, but whatever it is once it completes then the thread has terminated.
>
> There are subtle differences (invoking a virtual Thread's run method directly does no nothing) but that is too much detail and would confusing to say anything about in the introduction paragraphs.
> 
> The following is closer to what I think we should have. The existing paragraph 2 describes starting a thread so this is where the Thread.run method is introduced. Paragraph 3 follows to describe termination.
> 
> 
>  * <p> {@code Thread} defines constructors and a {@link Builder} to create threads.
>  * {@linkplain #start() Starting} a thread schedules it to execute its {@link #run() run}
>  * method. The newly started thread executes concurrently with the thread that caused
>  * it to start.
>  *
>  * <p> A thread <i>terminates</i> if either its {@code run} method completes normally,
>  * or if its {@code run} method completes abruptly and the appropriate {@linkplain
>  * Thread.UncaughtExceptionHandler uncaught exception handler} completes normally or
>  * abruptly. With no code left to run, the thread has completed execution. Thread
>  * defines the {@link #join() join} method to wait for a thread to terminate.

That sounds reasonable to me.

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

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

From jpai at openjdk.org  Thu Sep  1 06:49:12 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 1 Sep 2022 06:49:12 GMT
Subject: RFR: 8291651: CleanerTest.java fails with "Cleanable was cleaned"
 [v2]
In-Reply-To: <cytpsxC9SqxBaZgmRdzaickPRbrr4jw1jqBiO3DvTh4=.66b513fd-766d-483d-82a8-9d426a35a14e@github.com>
References: <xW9iVEgPhMgwpp947y2xnmN6MtBcSsyZyJc8Lg9ujls=.85bb46f3-e403-453a-9bc0-3bd73d02f159@github.com>
 <cytpsxC9SqxBaZgmRdzaickPRbrr4jw1jqBiO3DvTh4=.66b513fd-766d-483d-82a8-9d426a35a14e@github.com>
Message-ID: <CFag3NlywdUcJTcWB8rSfxcRRx0u6cQC1ltJTFMbkAk=.04fb63c0-2041-49ce-a696-948b22256e75@github.com>

On Tue, 30 Aug 2022 18:33:24 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> CleanerTest is failing intermittently on Aarch64, with -Xcomp, and using a VirtualThread for the Cleaner in the test.
>> The extensively relies on references processing and invokes GC on a very short cycle.
>> The existing 10ms delay between GC requests is too short for the changes to reference states to be reliably visible.
>> 
>> The delay between gc requests is extended to 200ms and the tests pass reliably.
>> There are small improvements in diagnostic messages and cleanup of unused imports.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup of messages that describe the cleaning function to be run or not.
>   Switched to using jtreg @enablePreview.

Thank you Roger for the changes. This looks fine to me.

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

Marked as reviewed by jpai (Reviewer).

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

From simonis at openjdk.org  Thu Sep  1 08:12:13 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Thu, 1 Sep 2022 08:12:13 GMT
Subject: RFR: 8282648: Weaken the InflaterInputStream specification in
 order to allow faster Zip implementations [v13]
In-Reply-To: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
Message-ID: <vL7P5C1LXdAFDBbdgAi0UGT8ku8JaPEik5HR5wvI7b0=.69349a3a-4f24-4a6f-9c5d-86020e869c5f@github.com>

> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might  write more bytes than the returned number of inflated bytes into the buffer `b`.
> 
> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`.
> 
> ### TL;DR
> 
> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI.
> 
> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer.
> 
> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit.
> 
> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`*
 k*`]` (where *k* is the number of inflated bytes).
> 
> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)).

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

  Changed 'current ZIP entry' to 'current JAR entry' in JarInputStream.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/7986/files
  - new: https://git.openjdk.org/jdk/pull/7986/files/d82c7526..5a4916b0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=7986&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=7986&range=11-12

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

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

From simonis at openjdk.org  Thu Sep  1 08:12:16 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Thu, 1 Sep 2022 08:12:16 GMT
Subject: RFR: 8282648: Weaken the InflaterInputStream specification in
 order to allow faster Zip implementations [v12]
In-Reply-To: <wkJxgzgxGxONYFioHAYNg-to3e2XtwDfvk5TSO-Z_Ac=.aab06671-d4e8-42d0-9b99-6189733fe812@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
 <jWLIEKu7IV1OOuZ86T8tip7pDLyGgM70xji8FAKToLw=.0c024cdc-aee1-428f-bada-3b8ae64dab12@github.com>
 <wkJxgzgxGxONYFioHAYNg-to3e2XtwDfvk5TSO-Z_Ac=.aab06671-d4e8-42d0-9b99-6189733fe812@github.com>
Message-ID: <lezB7uMAEeipBjmPdldIzdTyvQ37XDzejpCSq1bLaks=.eca3ab49-69f5-4fac-9f6b-861354bf9a8d@github.com>

On Wed, 31 Aug 2022 21:05:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated JavaDoc according to @mbreinhold's suggestions
>
> src/java.base/share/classes/java/util/jar/JarInputStream.java line 170:
> 
>> 168: 
>> 169:     /**
>> 170:      * Reads from the current ZIP entry into an array of bytes, returning the number of
> 
> Please change "Reads from the current ZIP entry..." to "Reads from the current JAR entry..."

Thanks for your review and for spotting this copy&paste error. I've fixed it.

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

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

From mdoerr at openjdk.org  Thu Sep  1 09:18:15 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 1 Sep 2022 09:18:15 GMT
Subject: RFR: 8292407: Improve Weak CAS VarHandle/Unsafe tests resilience
 under spurious failures [v4]
In-Reply-To: <QKoEMnS5UaEO3pBhtO1rOzY0mThmX4nxxYvgZmsOGzk=.f5b7d0c3-5095-4f61-8b60-2b93ee2f1ab7@github.com>
References: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
 <yyHd_Cl23ylTOouofEaOw5dexOSe4o1IyOdfbp4rnJc=.1113239f-c032-498a-b1c7-67e0d49df4f4@github.com>
 <bHeg5aBjvQxuSvi1UjQBmXG-r_taV6pn53xN08Mx3yo=.665f36d3-f656-468d-904a-5f9f04dde8ca@github.com>
 <QKoEMnS5UaEO3pBhtO1rOzY0mThmX4nxxYvgZmsOGzk=.f5b7d0c3-5095-4f61-8b60-2b93ee2f1ab7@github.com>
Message-ID: <FVHM3bI1G4lzQGcyY8G9Ckkij58HrHw1tIXCzt1ysUc=.db1218d7-f15a-458c-9e4a-fdc2c3274eac@github.com>

On Wed, 31 Aug 2022 08:05:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> It's awkward to manage this across various hardware, esp. if the hardware is less mature (perhaps combined with a less mature HotSpot implementation). The approach looks reasonable, but it would be nice if we could just increase the retries and waiting values on weak LL/SC hardware or at least follow up with something like that later on.
>> 
>> As a quick experiment could we annotate fields with `@Contended` and see if that reduces the number of retries?
>
> @PaulSandoz, @TheRealMDoerr -- are you okay with this?

@shipilev yes, looks much better, now. Thanks for the extra effort!

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

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

From shade at openjdk.org  Thu Sep  1 09:24:14 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 1 Sep 2022 09:24:14 GMT
Subject: RFR: 8292407: Improve Weak CAS VarHandle/Unsafe tests resilience
 under spurious failures [v7]
In-Reply-To: <s2tBQ2MlyYZ9aY6dCJOtrcbQs8owrzZh1D3sZuYv2r8=.53b6c755-edd6-4d38-aca0-be4c5ed16137@github.com>
References: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
 <s2tBQ2MlyYZ9aY6dCJOtrcbQs8owrzZh1D3sZuYv2r8=.53b6c755-edd6-4d38-aca0-be4c5ed16137@github.com>
Message-ID: <3JMIv7h27wOkfHOCG6g50IeXgy5SWsbuDK3OzoUdFLs=.940449bb-83b5-4dbd-81b0-2c936ed373fd@github.com>

On Tue, 30 Aug 2022 14:18:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We have a few reports that existing Weak* VarHandle tests are still flaky, for example on large AArch64 machines or small RISC-V machines.
>> 
>> The flakiness is intrinsic to the nature of Weak* operations under tests, that can spuriously fail. The last attempt to fix these was [JDK-8155739](https://bugs.openjdk.org/browse/JDK-8155739). We need to strengthen these a bit more.
>> 
>> The actual values depend on the successful testing on known-failing platforms. I ballparked bumping the attempts 5x and introducing the delay would help without exploding test time in worst cases.
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Rewind back to 100 attempts, 1ms delay
>  - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
>  - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
>  - Pull Handles.get out of the weak retry loop
>  - Drop weakDelay to 1
>  - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
>  - Rework timeouts
>  - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
>  - Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
>  - Update copyrights
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/b3450e93...fd6aa17b

Thanks! I'll integrate then.

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

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

From shade at openjdk.org  Thu Sep  1 09:25:39 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 1 Sep 2022 09:25:39 GMT
Subject: Integrated: 8292407: Improve Weak CAS VarHandle/Unsafe tests
 resilience under spurious failures
In-Reply-To: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
References: <np1aZWFJaRKsj1sIV9ApLzsfOVBeeBDIvpFK3GCKE-M=.750836c2-eb6e-4ae8-ba9e-b1e20c3f0e95@github.com>
Message-ID: <GWir6SAanbw6yMeBXIp2iu9z32VXBIGgatqkHNY4rnk=.c1ed4e96-21d7-41ba-a88f-1b97b51a2a23@github.com>

On Tue, 16 Aug 2022 08:23:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> We have a few reports that existing Weak* VarHandle tests are still flaky, for example on large AArch64 machines or small RISC-V machines.
> 
> The flakiness is intrinsic to the nature of Weak* operations under tests, that can spuriously fail. The last attempt to fix these was [JDK-8155739](https://bugs.openjdk.org/browse/JDK-8155739). We need to strengthen these a bit more.
> 
> The actual values depend on the successful testing on known-failing platforms. I ballparked bumping the attempts 5x and introducing the delay would help without exploding test time in worst cases.

This pull request has now been integrated.

Changeset: 6e6202c1
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6e6202c14d0f6dd26369f21883ff317057aa469f
Stats:     951 lines in 45 files changed: 800 ins; 0 del; 151 mod

8292407: Improve Weak CAS VarHandle/Unsafe tests resilience under spurious failures

Reviewed-by: yadongwang, fyang, vkempik, psandoz

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

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

From ecki at zusammenkunft.net  Thu Sep  1 09:54:46 2022
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Thu, 1 Sep 2022 09:54:46 +0000
Subject: RFR: 8293197: Avoid double racy reads from non-volatile fields in
 SharedSecrets
In-Reply-To: <GvvKthp1tV-BsDwulYsu5nGEYXKnibDPse5MVdQHyyg=.f7ce5178-d88e-44d6-9103-6d94de127cef@github.com>
References: <GvvKthp1tV-BsDwulYsu5nGEYXKnibDPse5MVdQHyyg=.f7ce5178-d88e-44d6-9103-6d94de127cef@github.com>
Message-ID: <AM9P193MB1142E189FA92CDF9D05982D6FF7B9@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>

BTW, after then ensures it looks like a good candidate for a system-assert for not-null for all of those fields, right?

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: core-libs-dev <core-libs-dev-retn at openjdk.org> im Auftrag von Andrey Turbanov <aturbanov at openjdk.org>
Gesendet: Thursday, September 1, 2022 8:24:58 AM
An: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>; security-dev at openjdk.org <security-dev at openjdk.org>
Betreff: RFR: 8293197: Avoid double racy reads from non-volatile fields in SharedSecrets

After integration of [JDK-8259021](https://bugs.openjdk.org/browse/JDK-8259021) a few more fields were added to `SharedSecrets` class. It make sense to update their reading code to use the same idiom.

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

Commit messages:
 - [PATCH] SharedSecrets should avoid double racy reads from non-volatile fields
 - [PATCH] SharedSecrets should avoid double racy reads from non-volatile fields

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

PR: https://git.openjdk.org/jdk/pull/10076
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220901/5f8d016f/attachment-0001.htm>

From lancea at openjdk.org  Thu Sep  1 10:52:10 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 1 Sep 2022 10:52:10 GMT
Subject: RFR: 8282648: Weaken the InflaterInputStream specification in
 order to allow faster Zip implementations [v13]
In-Reply-To: <vL7P5C1LXdAFDBbdgAi0UGT8ku8JaPEik5HR5wvI7b0=.69349a3a-4f24-4a6f-9c5d-86020e869c5f@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
 <vL7P5C1LXdAFDBbdgAi0UGT8ku8JaPEik5HR5wvI7b0=.69349a3a-4f24-4a6f-9c5d-86020e869c5f@github.com>
Message-ID: <LjHR3KFb94QzVtisWp0ky8ItEJmW9kObNtxhPmsel3g=.d4222f11-3ee1-46ed-b6bf-7e5046ad519a@github.com>

On Thu, 1 Sep 2022 08:12:13 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might  write more bytes than the returned number of inflated bytes into the buffer `b`.
>> 
>> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`.
>> 
>> ### TL;DR
>> 
>> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI.
>> 
>> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer.
>> 
>> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit.
>> 
>> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`
 *k*`]` (where *k* is the number of inflated bytes).
>> 
>> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)).
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed 'current ZIP entry' to 'current JAR entry' in JarInputStream.java

Typo cleanup looks fine

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

Marked as reviewed by lancea (Reviewer).

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

From mchhipa at openjdk.org  Thu Sep  1 11:38:09 2022
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Thu, 1 Sep 2022 11:38:09 GMT
Subject: RFR: JDK-8289510 : Improve test coverage for XPath Axes: namespace
 [v4]
In-Reply-To: <fvhggtrPyzXPEjKIMleUFn-TjYFfaAZKouH6asWZ4S4=.de353a67-3391-467d-bea7-1bdde7f84d6a@github.com>
References: <fvhggtrPyzXPEjKIMleUFn-TjYFfaAZKouH6asWZ4S4=.de353a67-3391-467d-bea7-1bdde7f84d6a@github.com>
Message-ID: <zwo1qnmNlIyk_CDzm99_qyofKWU-fQMXIrGpRWZG6bA=.2c722ffb-8d91-45ce-bd2b-b669926add1b@github.com>

> Added tests for namespace Axis. Tests incluse namspace expressions, namespace node counts and namespace node scope.

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

  Implemented the review comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9906/files
  - new: https://git.openjdk.org/jdk/pull/9906/files/a75a6dc3..a8d4039e

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

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

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

From itakiguchi at openjdk.org  Thu Sep  1 12:27:18 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Thu, 1 Sep 2022 12:27:18 GMT
Subject: RFR: 8292899: CustomTzIDCheckDST.java testcase failed on AIX
 platform
In-Reply-To: <RGVghAZZdpMU51-j6Z2vcU2DvTebzKju-FgOAtzRFXU=.9efc2b3a-c239-46d0-84b7-bcd4f033401d@github.com>
References: <PNcxR0GeF8sv1NdX-W0X84nw3LGunbNrYe8r3RzNEGc=.a9d5f9fb-8d79-48c0-8e23-584f684e471f@github.com>
 <RGVghAZZdpMU51-j6Z2vcU2DvTebzKju-FgOAtzRFXU=.9efc2b3a-c239-46d0-84b7-bcd4f033401d@github.com>
Message-ID: <QkESU7Vh82g-Uu6ar54LXRGSeK2pJ0vS2P0LRx2DIk8=.2eaa5b47-25f6-4ef0-b536-70b49f2165a2@github.com>

On Fri, 26 Aug 2022 18:56:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> After `test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java` testcase was integrated, it failed on the AIX platform.
>> 
>> Error output
>> 
>> STDERR:
>>  stdout: [];
>>  stderr: [Exception in thread "main" java.lang.RuntimeException: Got unexpected timezone information: Thu Aug 25 09:29:10 CEST 2022
>>         at CustomTzIDCheckDST.runTZTest(CustomTzIDCheckDST.java:71)
>>         at CustomTzIDCheckDST.main(CustomTzIDCheckDST.java:50)
>> ]
>> 
>> 
>> By my investigation, `TZ=MEZ-1MESZ,M3.5.0,M10.5.0` timezone was changed to `Europe/Berlin` timezone on AIX platform.
>> It seems this situation is happened because older AIX did not support `MEZ-1MESZ,M3.5.0,M10.5.0` timezone by TZ environment variable.
>> https://www.ibm.com/support/pages/managing-time-zone-variable-posix
>> AIX special code was implemented into `src/java.base/unix/native/libjava/TimeZone_md.c`.
>> Current AIX supports `TZ=EST5EDT,M3.2.0/2:00:00,M11.1.0/2:00:00` style.
>> I think implementation change is required. 
>> 
>> Some pre-submit tests are failed, but I think these are not related this change since modified parts are just for AIX platform.
>
> src/java.base/unix/native/libjava/TimeZone_md.c line 589:
> 
>> 587:     // But Hotspot does not support XPG_SUS_ENV=ON.
>> 588:     // Ignore daylight saving settings to calculate current time difference
>> 589:     localtm.tm_isdst = 0;
> 
> Is it OK to reset it always? Could this defy the original purpose of the fix to https://bugs.openjdk.org/browse/JDK-8285838?

I executed test program [JDK-8285838](https://bugs.openjdk.org/browse/JDK-8285838) on RHEL8 x86_64.
TZ="MEZ-1MESZ,M3.5.0,M10.5.0" means I'm on daylight saving time on today. 
By JDK18

$ TZ="MEZ-1MESZ,M3.5.0,M10.5.0" jdk-18/bin/java -showversion TimeTest.java
openjdk version "18" 2022-03-22
OpenJDK Runtime Environment (build 18+36-2087)
OpenJDK 64-Bit Server VM (build 18+36-2087, mixed mode, sharing)
Calendar.getInstance().getTime() = Thu Sep 01 11:52:09 GMT+01:00 2022
SimpleDateFormat = 01.09.2022 11:52:09.747

By JDK20

$ TZ="MEZ-1MESZ,M3.5.0,M10.5.0" jdk-20-b12/bin/java -showversion TimeTest.java
openjdk version "20-ea" 2023-03-21
OpenJDK Runtime Environment (build 20-ea+12-790)
OpenJDK 64-Bit Server VM (build 20-ea+12-790, mixed mode, sharing)
Calendar.getInstance().getTime() = Thu Sep 01 12:52:21 GMT+02:00 2022
SimpleDateFormat = 01.09.2022 12:52:21.269

Expected result is GMT+02:00.
It means the output is the current time difference between GMT and MESZ.

On modified build

$ TZ="MEZ-1MESZ,M3.5.0,M10.5.0" jdk/build/aix-ppc64-server-release/images/jdk/bin/java TimeTest.java
Calendar.getInstance().getTime() = Thu Sep 01 12:53:12 GMT+02:00 2022
SimpleDateFormat = 01.09.2022 12:53:12.930


According to AIX docs for mktime()
https://www.ibm.com/docs/en/aix/7.2?topic=c-ctime-localtime-gmtime-mktime-difftime-asctime-tzset-subroutine

> The value of the ```tm_isdst``` field determines the following actions of the **mktime** subroutine:
> "0" means "Initially presumes that Daylight Saving Time (DST) is not in effect."

If daylight saving time ends by August, timezone should be GMT+01:00

$ TZ="MEZ-1MESZ,M3.5.0,M8.5.0" jdk/build/aix-ppc64-server-release/images/jdk/bin/java TimeTest.java  
Calendar.getInstance().getTime() = Thu Sep 01 11:53:36 GMT+01:00 2022
SimpleDateFormat = 01.09.2022 11:53:36.189


According to simple C testcase

$ cat sf.c
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
 
int main(void)
{
    char buf[100];
    struct tm localtm;
    struct tm gmt;
    time_t clock = time(NULL);
    int gmt_off;

#if defined(_AIX)
    putenv("XPG_SUS_ENV=ON");
#endif
    if (localtime_r(&clock, &localtm) == NULL) {
        return 1;
    }
    if (gmtime_r(&clock, &gmt) == NULL) {
        return 1;
    }
    strftime(buf, sizeof(buf),"%z", &localtm);
    printf("strftime: %s\n",buf);
    localtm.tm_isdst = 0;
    gmt_off = (int)(difftime(mktime(&localtm), mktime(&gmt)) / 60.0);
    sprintf(buf, (const char *)"%c%02.2d%02.2d",
            gmt_off < 0 ? '-' : '+' , abs(gmt_off / 60), gmt_off % 60);
    printf("difftime: %s\n",buf);
    return 0;
}

On RHEL8:

$ TZ="MEZ-1MESZ,M3.5.0,M10.5.0" ./sf
strftime: +0200
difftime: +0200
$ TZ="ZZZ-1ZZZZ-3,M3.5.0,M10.5.0" ./sf
strftime: +0300
difftime: +0300
$ TZ="ZZZ-1ZZZZ-3,M3.5.0,M8.5.0" ./sf
strftime: +0100
difftime: +0100

On AIX:

$ TZ="MEZ-1MESZ,M3.5.0,M10.5.0" ./sf
strftime: +0200
difftime: +0200
$ TZ="ZZZ-1ZZZZ-3,M3.5.0,M10.5.0" ./sf
strftime: +0300
difftime: +0300
$ TZ="ZZZ-1ZZZZ-3,M3.5.0,M8.5.0" ./sf
strftime: +0100
difftime: +0100

I assume the modified code should be fine.

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

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

From rriggs at openjdk.org  Thu Sep  1 14:07:15 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 1 Sep 2022 14:07:15 GMT
Subject: Integrated: 8291651: CleanerTest.java fails with
 "Cleanable was cleaned"
In-Reply-To: <xW9iVEgPhMgwpp947y2xnmN6MtBcSsyZyJc8Lg9ujls=.85bb46f3-e403-453a-9bc0-3bd73d02f159@github.com>
References: <xW9iVEgPhMgwpp947y2xnmN6MtBcSsyZyJc8Lg9ujls=.85bb46f3-e403-453a-9bc0-3bd73d02f159@github.com>
Message-ID: <JJfyCe8Ey6WA60I-8L4QAtgyNC6o18lo8jJFvFgv3Vs=.0461c6fc-81bf-4201-aeec-96b3c5529048@github.com>

On Fri, 26 Aug 2022 19:09:45 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> CleanerTest is failing intermittently on Aarch64, with -Xcomp, and using a VirtualThread for the Cleaner in the test.
> The extensively relies on references processing and invokes GC on a very short cycle.
> The existing 10ms delay between GC requests is too short for the changes to reference states to be reliably visible.
> 
> The delay between gc requests is extended to 200ms and the tests pass reliably.
> There are small improvements in diagnostic messages and cleanup of unused imports.

This pull request has now been integrated.

Changeset: 2d10d4f5
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2d10d4f54ebd9d46f70a18695bf60f30dda92522
Stats:     19 lines in 1 file changed: 3 ins; 3 del; 13 mod

8291651: CleanerTest.java fails with "Cleanable was cleaned"

Reviewed-by: jpai, dfuchs

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

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

From duke at openjdk.org  Thu Sep  1 14:43:12 2022
From: duke at openjdk.org (Bill Huang)
Date: Thu, 1 Sep 2022 14:43:12 GMT
Subject: RFR: JDK-8289510 : Improve test coverage for XPath Axes: namespace
 [v4]
In-Reply-To: <zwo1qnmNlIyk_CDzm99_qyofKWU-fQMXIrGpRWZG6bA=.2c722ffb-8d91-45ce-bd2b-b669926add1b@github.com>
References: <fvhggtrPyzXPEjKIMleUFn-TjYFfaAZKouH6asWZ4S4=.de353a67-3391-467d-bea7-1bdde7f84d6a@github.com>
 <zwo1qnmNlIyk_CDzm99_qyofKWU-fQMXIrGpRWZG6bA=.2c722ffb-8d91-45ce-bd2b-b669926add1b@github.com>
Message-ID: <g4pv1mISTnzZnLrCUmj0TfemfZVFZTwPgCQLCEn369I=.b1cac103-63f4-429c-a784-5d446bf1ef5f@github.com>

On Thu, 1 Sep 2022 11:38:09 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

>> Added tests for namespace Axis. Tests incluse namspace expressions, namespace node counts and namespace node scope.
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented the review comments.

Marked as reviewed by bwhuang-us at github.com (no known OpenJDK username).

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

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

From naoto at openjdk.org  Thu Sep  1 15:49:17 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 1 Sep 2022 15:49:17 GMT
Subject: Integrated: 8293154: TemporalQueries java doc error
In-Reply-To: <vfGW9kmfaPQ8dxueJKopIwNonzfqYl21UUYzDMRyPL8=.fd1aeab4-2367-4177-a61b-f65c7d4d9c5d@github.com>
References: <vfGW9kmfaPQ8dxueJKopIwNonzfqYl21UUYzDMRyPL8=.fd1aeab4-2367-4177-a61b-f65c7d4d9c5d@github.com>
Message-ID: <IOrDps5yOI6Cn_4F-e84PjJFC4w5srCv_0PflrjHhjA=.b8926937-4332-4312-807f-012075e3afb8@github.com>

On Wed, 31 Aug 2022 17:08:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Simple doc fix.

This pull request has now been integrated.

Changeset: 6a1b0b56
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6a1b0b5649dd4f2a970df0839bf77bdb899fbd6f
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8293154: TemporalQueries java doc error

Reviewed-by: rriggs, lancea

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

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

From cjplummer at openjdk.org  Thu Sep  1 16:45:42 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 1 Sep 2022 16:45:42 GMT
Subject: RFR: 8292201: serviceability/sa/ClhsdbThreadContext.java fails with
 "'Thread "Common-Cleaner"' missing from stdout/stderr"
Message-ID: <uqus5rEbdj85oIby3rXWTEDsVYGxRBVGNRO6hpvHL84=.562cbe00-9e5d-4d53-a37b-22e466aaf8e4@github.com>

While dumping all registers (and doing a findpc on each), the following exception occurred for r8:


 r8: 0x000000750e4fdffc
Error: java.lang.ArrayIndexOutOfBoundsException: Index 4099 out of bounds for length 4096
java.lang.ArrayIndexOutOfBoundsException: Index 4099 out of bounds for length 4096
at jdk.hotspot.agent/sun.jvm.hotspot.debugger.Page.getLong(Page.java:182)
at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.getLong(PageCache.java:100)
at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readCInteger(DebuggerBase.java:364)
at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readAddressValue(DebuggerBase.java:462)
at jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgDebuggerLocal.readAddress(WindbgDebuggerLocal.java:312)
at jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgAddress.getAddressAt(WindbgAddress.java:71)
at jdk.hotspot.agent/sun.jvm.hotspot.utilities.PointerFinder.find(PointerFinder.java:58)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.printThreadContextOn(JavaThread.java:493)


This exception is the result of using PointerFinder ("findpc") on invalid address that starts on the last 32-bit word of a page. "page" in this case is referring to a page in SA's PageCache, which are always 4k in size. Note findpc is frequently done using an invalid address. In this test case it is being called on each x64 register, which could contain anything. findpc relies on getting some sort of AddressException when this happens, and will then say the address points to something that is unknown. However, in the case of the address pointing to the last 32-bot word of a page, it results in an ArrayIndexOutOfBoundsException when the page cache tries to read past the end of the page. This is happening in Page.getLong(), which you can see in the stack trace.

The main culprit here is some weakening of the alignment checks being done. The alignment check should have resulted in an UnalignedAddressException long before we ever got to Page.getLong(). However, we have the following override, which is allowing the unaligned address to pass the alignment check.


           public void checkAlignment(long address, long alignment) {
             // Need to override default checkAlignment because we need to
             // relax alignment constraints on Bsd/x86
             if ( (address % alignment != 0)
                &&(alignment != 8 || address % 4 != 0)) {
                throw new UnalignedAddressException(
                        "Trying to read at address: "
                      + addressValueToString(address)
                      + " with alignment: " + alignment,
                        address);
             }
           }
        };


This allows a pointer to a 64-bit value to only be 32-bit aligned. But there's more to it than that. I modified ClhsdbFindPC.java to fetch a tid (a thread address), and did a findpc on the address OR'd with 0xffc. `findpc` uses PointerFinder. This forced a read of a 64-bit value that starts in the last 32-bits of a page. It passed on linux-x64 but failed on windowx-x64 in the same manner described in the description of this CR. The difference between the two implementations is that windows relies on the default implementation of DebuggerBase.readCInteger() whereas linux has an override. DebuggerBase.readCInteger() does the following:


  public long readCInteger(long address, long numBytes, boolean isUnsigned) {
    utils.checkAlignment(address, numBytes);
    if (useFastAccessors) {
      if (isUnsigned) {
        switch((int) numBytes) {
        case 1: return cache.getByte(address) & 0xFF;
        case 2: return cache.getShort(address, bigEndian) & 0xFFFF;
        case 4: return cache.getInt(address, bigEndian) & 0xFFFFFFFFL;
        case 8: return cache.getLong(address, bigEndian);
...


There is an alignment check here, but it is the "relaxed" override shown above, which allows 64-bit addresses on 32-bit boundaries. The override in LinuxDebuggerLocal is:


    /** Need to override this to relax alignment checks on x86. */
    public long readCInteger(long address, long numBytes, boolean isUnsigned)
        throws UnmappedAddressException, UnalignedAddressException {
        // Only slightly relaxed semantics -- this is a hack, but is
        // necessary on x86 where it seems the compiler is
        // putting some global 64-bit data on 32-bit boundaries
        if (numBytes == 8) {
            utils.checkAlignment(address, 4);
        } else {
            utils.checkAlignment(address, numBytes);
        }
        byte[] data = readBytes(address, numBytes);
        return utils.dataToCInteger(data, isUnsigned);


Although there is a relaxed alignment check here also, the code that reads from the address does not assume all the bytes are on the same page. It uses readBytes() intead of cache.getLong(), so it won't run into the PageCache issue with reading a 64-bit value that starts in the last 32-bit word of a page.

I think the introduction of these relaxed alignment checks has a muddled history, probably made more muddled by ports cloning code that maybe wasn't necessary. Probably also initial fixes (the relaxed alignment check) seemed to work at first, but later the PageCache issue was discovered, leading to readBytes() workaround in the LinuxDebuggerLocal.readCInteger() override, but was not also done on other ports (so we got this CR for windows).

For 64-bit support it's clear this easing of the 64-bit alignment is not needed, and getting rid of it would result in the proper UnalignedAddressException being thrown. The question is whether it is still needed for 32-bit x86, and if so is it needed on all ports.

I can't test linux-x86, so I can't tell if it still allows 64-bit values on 32-bit aligned addresses, so for now I'll assume it does. So the approach being taken is whenever an address of a 64-bit type points to the last 32-bit word of a page, use readBytes() to get the 64-bit value one byte at a time. It still uses the page cache in the end, but it doesn't try to get all 8 bytes from the same page. Note for 64-bit systems, the conditoin will never arise because of the removal of the relaxed alignment check. Instead there will be an UnalignedAddressException at an early point when the alignment check is made.

One windfall of this change is now we always read 64-bit values from the page cache in a way that is much more efficient than reading a byte at a time. This has resulted in about a 25% performance improvement in a test I have that does a heap dump.

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

Commit messages:
 - Fix jcheck error
 - Undo some temp test changes.
 - Fix 64-bit alignment requirements

Changes: https://git.openjdk.org/jdk/pull/10090/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10090&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292201
  Stats: 227 lines in 11 files changed: 52 ins; 154 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/10090.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10090/head:pull/10090

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

From darcy at openjdk.org  Thu Sep  1 16:46:21 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 1 Sep 2022 16:46:21 GMT
Subject: Integrated: JDK-8173605: Remove support for source and target 1.7
 option in javac
In-Reply-To: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>
References: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>
Message-ID: <gbPQrgcQ4ahoMdC7kieutONxygrBOxirKmi5HmDu-10=.d68cd13f-d992-443b-9353-2a19ef40cd8d@github.com>

On Tue, 30 Aug 2022 00:04:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update to remove support for -source/-target/--release 7 from javac.
> 
> As seen in the PR, many test fails are affected. Further refactorings of javac's implementation that can be made from dropping 7 support are left as future work.

This pull request has now been integrated.

Changeset: 2d18dda3
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2d18dda3f2074a4f8b9a0c62ece9ac6d5284e93b
Stats:     4595 lines in 156 files changed: 25 ins; 4413 del; 157 mod

8173605: Remove support for source and target 1.7 option in javac

Reviewed-by: vromero

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

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

From darcy at openjdk.org  Thu Sep  1 17:06:13 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 1 Sep 2022 17:06:13 GMT
Subject: RFR: 8282648: Weaken the InflaterInputStream specification in
 order to allow faster Zip implementations [v13]
In-Reply-To: <vL7P5C1LXdAFDBbdgAi0UGT8ku8JaPEik5HR5wvI7b0=.69349a3a-4f24-4a6f-9c5d-86020e869c5f@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
 <vL7P5C1LXdAFDBbdgAi0UGT8ku8JaPEik5HR5wvI7b0=.69349a3a-4f24-4a6f-9c5d-86020e869c5f@github.com>
Message-ID: <QItyHjxMDSy6z71mYVMspGIq88MZbQ_ntGo3MzLl0g8=.a76a1ed6-dc15-4fec-a22d-4eb4acfc75b7@github.com>

On Thu, 1 Sep 2022 08:12:13 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might  write more bytes than the returned number of inflated bytes into the buffer `b`.
>> 
>> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`.
>> 
>> ### TL;DR
>> 
>> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI.
>> 
>> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer.
>> 
>> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit.
>> 
>> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`
 *k*`]` (where *k* is the number of inflated bytes).
>> 
>> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)).
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed 'current ZIP entry' to 'current JAR entry' in JarInputStream.java

Marked as reviewed by darcy (Reviewer).

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

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

From cjplummer at openjdk.org  Thu Sep  1 17:20:33 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 1 Sep 2022 17:20:33 GMT
Subject: RFR: 8292201: serviceability/sa/ClhsdbThreadContext.java fails
 with "'Thread "Common-Cleaner"' missing from stdout/stderr" [v2]
In-Reply-To: <uqus5rEbdj85oIby3rXWTEDsVYGxRBVGNRO6hpvHL84=.562cbe00-9e5d-4d53-a37b-22e466aaf8e4@github.com>
References: <uqus5rEbdj85oIby3rXWTEDsVYGxRBVGNRO6hpvHL84=.562cbe00-9e5d-4d53-a37b-22e466aaf8e4@github.com>
Message-ID: <dOBlU3su4cbQkS7_aGDx4RE1J1vEJYCPnIpYUquT6hk=.0c8d0c44-ac78-4252-a9fa-c3a1c3b840cf@github.com>

> While dumping all registers (and doing a findpc on each), the following exception occurred for r8:
> 
> 
>  r8: 0x000000750e4fdffc
> Error: java.lang.ArrayIndexOutOfBoundsException: Index 4099 out of bounds for length 4096
> java.lang.ArrayIndexOutOfBoundsException: Index 4099 out of bounds for length 4096
> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.Page.getLong(Page.java:182)
> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.getLong(PageCache.java:100)
> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readCInteger(DebuggerBase.java:364)
> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readAddressValue(DebuggerBase.java:462)
> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgDebuggerLocal.readAddress(WindbgDebuggerLocal.java:312)
> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgAddress.getAddressAt(WindbgAddress.java:71)
> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.PointerFinder.find(PointerFinder.java:58)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.printThreadContextOn(JavaThread.java:493)
> 
> 
> This exception is the result of using PointerFinder ("findpc") on invalid address that starts on the last 32-bit word of a page. "page" in this case is referring to a page in SA's PageCache, which are always 4k in size. Note findpc is frequently done using an invalid address. In this test case it is being called on each x64 register, which could contain anything. findpc relies on getting some sort of AddressException when this happens, and will then say the address points to something that is unknown. However, in the case of the address pointing to the last 32-bot word of a page, it results in an ArrayIndexOutOfBoundsException when the page cache tries to read past the end of the page. This is happening in Page.getLong(), which you can see in the stack trace.
> 
> The main culprit here is some weakening of the alignment checks being done. The alignment check should have resulted in an UnalignedAddressException long before we ever got to Page.getLong(). However, we have the following override, which is allowing the unaligned address to pass the alignment check.
> 
> 
>            public void checkAlignment(long address, long alignment) {
>              // Need to override default checkAlignment because we need to
>              // relax alignment constraints on Bsd/x86
>              if ( (address % alignment != 0)
>                 &&(alignment != 8 || address % 4 != 0)) {
>                 throw new UnalignedAddressException(
>                         "Trying to read at address: "
>                       + addressValueToString(address)
>                       + " with alignment: " + alignment,
>                         address);
>              }
>            }
>         };
> 
> 
> This allows a pointer to a 64-bit value to only be 32-bit aligned. But there's more to it than that. I modified ClhsdbFindPC.java to fetch a tid (a thread address), and did a findpc on the address OR'd with 0xffc. `findpc` uses PointerFinder. This forced a read of a 64-bit value that starts in the last 32-bits of a page. It passed on linux-x64 but failed on windowx-x64 in the same manner described in the description of this CR. The difference between the two implementations is that windows relies on the default implementation of DebuggerBase.readCInteger() whereas linux has an override. DebuggerBase.readCInteger() does the following:
> 
> 
>   public long readCInteger(long address, long numBytes, boolean isUnsigned) {
>     utils.checkAlignment(address, numBytes);
>     if (useFastAccessors) {
>       if (isUnsigned) {
>         switch((int) numBytes) {
>         case 1: return cache.getByte(address) & 0xFF;
>         case 2: return cache.getShort(address, bigEndian) & 0xFFFF;
>         case 4: return cache.getInt(address, bigEndian) & 0xFFFFFFFFL;
>         case 8: return cache.getLong(address, bigEndian);
> ...
> 
> 
> There is an alignment check here, but it is the "relaxed" override shown above, which allows 64-bit addresses on 32-bit boundaries. The override in LinuxDebuggerLocal is:
> 
> 
>     /** Need to override this to relax alignment checks on x86. */
>     public long readCInteger(long address, long numBytes, boolean isUnsigned)
>         throws UnmappedAddressException, UnalignedAddressException {
>         // Only slightly relaxed semantics -- this is a hack, but is
>         // necessary on x86 where it seems the compiler is
>         // putting some global 64-bit data on 32-bit boundaries
>         if (numBytes == 8) {
>             utils.checkAlignment(address, 4);
>         } else {
>             utils.checkAlignment(address, numBytes);
>         }
>         byte[] data = readBytes(address, numBytes);
>         return utils.dataToCInteger(data, isUnsigned);
> 
> 
> Although there is a relaxed alignment check here also, the code that reads from the address does not assume all the bytes are on the same page. It uses readBytes() intead of cache.getLong(), so it won't run into the PageCache issue with reading a 64-bit value that starts in the last 32-bit word of a page.
> 
> I think the introduction of these relaxed alignment checks has a muddled history, probably made more muddled by ports cloning code that maybe wasn't necessary. Probably also initial fixes (the relaxed alignment check) seemed to work at first, but later the PageCache issue was discovered, leading to readBytes() workaround in the LinuxDebuggerLocal.readCInteger() override, but was not also done on other ports (so we got this CR for windows).
> 
> For 64-bit support it's clear this easing of the 64-bit alignment is not needed, and getting rid of it would result in the proper UnalignedAddressException being thrown. The question is whether it is still needed for 32-bit x86, and if so is it needed on all ports.
> 
> I can't test linux-x86, so I can't tell if it still allows 64-bit values on 32-bit aligned addresses, so for now I'll assume it does. So the approach being taken is whenever an address of a 64-bit type points to the last 32-bit word of a page, use readBytes() to get the 64-bit value one byte at a time. It still uses the page cache in the end, but it doesn't try to get all 8 bytes from the same page. Note for 64-bit systems, the conditoin will never arise because of the removal of the relaxed alignment check. Instead there will be an UnalignedAddressException at an early point when the alignment check is made.
> 
> One windfall of this change is now we always read 64-bit values from the page cache in a way that is much more efficient than reading a byte at a time. This has resulted in about a 25% performance improvement in a test I have that does a heap dump.

Chris Plummer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge
 - Fix jcheck error
 - Undo some temp test changes.
 - Fix 64-bit alignment requirements

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

Changes: https://git.openjdk.org/jdk/pull/10090/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10090&range=01
  Stats: 227 lines in 11 files changed: 52 ins; 154 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/10090.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10090/head:pull/10090

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

From cjplummer at openjdk.org  Thu Sep  1 17:25:41 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 1 Sep 2022 17:25:41 GMT
Subject: RFR: 8292201: serviceability/sa/ClhsdbThreadContext.java fails
 with "'Thread "Common-Cleaner"' missing from stdout/stderr" [v2]
In-Reply-To: <dOBlU3su4cbQkS7_aGDx4RE1J1vEJYCPnIpYUquT6hk=.0c8d0c44-ac78-4252-a9fa-c3a1c3b840cf@github.com>
References: <uqus5rEbdj85oIby3rXWTEDsVYGxRBVGNRO6hpvHL84=.562cbe00-9e5d-4d53-a37b-22e466aaf8e4@github.com>
 <dOBlU3su4cbQkS7_aGDx4RE1J1vEJYCPnIpYUquT6hk=.0c8d0c44-ac78-4252-a9fa-c3a1c3b840cf@github.com>
Message-ID: <kf6u2Ok7dcRyHuyP9mY6ptMlPbIzAyPx1TzVxFUo8Sg=.16479923-aa2d-4f9c-9047-66b81b964337@github.com>

On Thu, 1 Sep 2022 17:20:33 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> While dumping all registers (and doing a findpc on each), the following exception occurred for r8:
>> 
>> 
>>  r8: 0x000000750e4fdffc
>> Error: java.lang.ArrayIndexOutOfBoundsException: Index 4099 out of bounds for length 4096
>> java.lang.ArrayIndexOutOfBoundsException: Index 4099 out of bounds for length 4096
>> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.Page.getLong(Page.java:182)
>> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.getLong(PageCache.java:100)
>> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readCInteger(DebuggerBase.java:364)
>> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readAddressValue(DebuggerBase.java:462)
>> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgDebuggerLocal.readAddress(WindbgDebuggerLocal.java:312)
>> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgAddress.getAddressAt(WindbgAddress.java:71)
>> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.PointerFinder.find(PointerFinder.java:58)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.printThreadContextOn(JavaThread.java:493)
>> 
>> 
>> This exception is the result of using PointerFinder ("findpc") on invalid address that starts on the last 32-bit word of a page. "page" in this case is referring to a page in SA's PageCache, which are always 4k in size. Note findpc is frequently done using an invalid address. In this test case it is being called on each x64 register, which could contain anything. findpc relies on getting some sort of AddressException when this happens, and will then say the address points to something that is unknown. However, in the case of the address pointing to the last 32-bot word of a page, it results in an ArrayIndexOutOfBoundsException when the page cache tries to read past the end of the page. This is happening in Page.getLong(), which you can see in the stack trace.
>> 
>> The main culprit here is some weakening of the alignment checks being done. The alignment check should have resulted in an UnalignedAddressException long before we ever got to Page.getLong(). However, we have the following override, which is allowing the unaligned address to pass the alignment check.
>> 
>> 
>>            public void checkAlignment(long address, long alignment) {
>>              // Need to override default checkAlignment because we need to
>>              // relax alignment constraints on Bsd/x86
>>              if ( (address % alignment != 0)
>>                 &&(alignment != 8 || address % 4 != 0)) {
>>                 throw new UnalignedAddressException(
>>                         "Trying to read at address: "
>>                       + addressValueToString(address)
>>                       + " with alignment: " + alignment,
>>                         address);
>>              }
>>            }
>>         };
>> 
>> 
>> This allows a pointer to a 64-bit value to only be 32-bit aligned. But there's more to it than that. I modified ClhsdbFindPC.java to fetch a tid (a thread address), and did a findpc on the address OR'd with 0xffc. `findpc` uses PointerFinder. This forced a read of a 64-bit value that starts in the last 32-bits of a page. It passed on linux-x64 but failed on windowx-x64 in the same manner described in the description of this CR. The difference between the two implementations is that windows relies on the default implementation of DebuggerBase.readCInteger() whereas linux has an override. DebuggerBase.readCInteger() does the following:
>> 
>> 
>>   public long readCInteger(long address, long numBytes, boolean isUnsigned) {
>>     utils.checkAlignment(address, numBytes);
>>     if (useFastAccessors) {
>>       if (isUnsigned) {
>>         switch((int) numBytes) {
>>         case 1: return cache.getByte(address) & 0xFF;
>>         case 2: return cache.getShort(address, bigEndian) & 0xFFFF;
>>         case 4: return cache.getInt(address, bigEndian) & 0xFFFFFFFFL;
>>         case 8: return cache.getLong(address, bigEndian);
>> ...
>> 
>> 
>> There is an alignment check here, but it is the "relaxed" override shown above, which allows 64-bit addresses on 32-bit boundaries. The override in LinuxDebuggerLocal is:
>> 
>> 
>>     /** Need to override this to relax alignment checks on x86. */
>>     public long readCInteger(long address, long numBytes, boolean isUnsigned)
>>         throws UnmappedAddressException, UnalignedAddressException {
>>         // Only slightly relaxed semantics -- this is a hack, but is
>>         // necessary on x86 where it seems the compiler is
>>         // putting some global 64-bit data on 32-bit boundaries
>>         if (numBytes == 8) {
>>             utils.checkAlignment(address, 4);
>>         } else {
>>             utils.checkAlignment(address, numBytes);
>>         }
>>         byte[] data = readBytes(address, numBytes);
>>         return utils.dataToCInteger(data, isUnsigned);
>> 
>> 
>> Although there is a relaxed alignment check here also, the code that reads from the address does not assume all the bytes are on the same page. It uses readBytes() intead of cache.getLong(), so it won't run into the PageCache issue with reading a 64-bit value that starts in the last 32-bit word of a page.
>> 
>> I think the introduction of these relaxed alignment checks has a muddled history, probably made more muddled by ports cloning code that maybe wasn't necessary. Probably also initial fixes (the relaxed alignment check) seemed to work at first, but later the PageCache issue was discovered, leading to readBytes() workaround in the LinuxDebuggerLocal.readCInteger() override, but was not also done on other ports (so we got this CR for windows).
>> 
>> For 64-bit support it's clear this easing of the 64-bit alignment is not needed, and getting rid of it would result in the proper UnalignedAddressException being thrown. The question is whether it is still needed for 32-bit x86, and if so is it needed on all ports.
>> 
>> I can't test linux-x86, so I can't tell if it still allows 64-bit values on 32-bit aligned addresses, so for now I'll assume it does. So the approach being taken is whenever an address of a 64-bit type points to the last 32-bit word of a page, use readBytes() to get the 64-bit value one byte at a time. It still uses the page cache in the end, but it doesn't try to get all 8 bytes from the same page. Note for 64-bit systems, the conditoin will never arise because of the removal of the relaxed alignment check. Instead there will be an UnalignedAddressException at an early point when the alignment check is made.
>> 
>> One windfall of this change is now we always read 64-bit values from the page cache in a way that is much more efficient than reading a byte at a time. This has resulted in about a 25% performance improvement in a test I have that does a heap dump.
>
> Chris Plummer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge
>  - Fix jcheck error
>  - Undo some temp test changes.
>  - Fix 64-bit alignment requirements

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java line 46:

> 44:   private RemoteDebugger remoteDebugger;
> 45:   private RemoteThreadFactory threadFactory;
> 46:   private boolean unalignedAccessesOkay = false;

After getting rid of the `readCInteger` and `readJLong` overrides below, `unalignedAccessesOkay` is no longer needed. The `DebuggerBase` superclass understands the alignment requirements.

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

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

From joehw at openjdk.org  Thu Sep  1 17:33:28 2022
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 1 Sep 2022 17:33:28 GMT
Subject: RFR: JDK-8292990 Improve test coverage for XPath Axes: parent
In-Reply-To: <5OiZYwF-cPSeGG_PlFiq_KKSHwfn1OBZPf58bHzxTVU=.1b1e498d-1d87-4fec-aadd-b7d10ea1b39e@github.com>
References: <5OiZYwF-cPSeGG_PlFiq_KKSHwfn1OBZPf58bHzxTVU=.1b1e498d-1d87-4fec-aadd-b7d10ea1b39e@github.com>
Message-ID: <yKKWmLqtV-_NAZeQijgEgSfOgzAZqb0e8znEBcum0o4=.65e8ae10-6987-4e54-a662-464c4ccc680c@github.com>

On Wed, 31 Aug 2022 20:16:33 GMT, Bill Huang <duke at openjdk.org> wrote:

> The goal of this task is validating the parent axis contains the parent of the context node. Context nodes include 
> - root node 
> - element nodes 
> - text nodes 
> - attribute nodes 
> - namespace nodes 
> - comment nodes

test/jaxp/javax/xml/jaxp/unittest/xpath/XPathExpParentTest.java line 56:

> 54:         return new Object[][]{
> 55:                 {"//Customer/parent::*", "//Customers"},
> 56:                 {"//Customer[1]/text()/parent::*", "//Customer"},

I see that the 2nd parameter meant to be the parent, it thus needs to return a single and unique node. But "//Customer" may return multiple nodes.

test/jaxp/javax/xml/jaxp/unittest/xpath/XPathExpParentTest.java line 86:

> 84: 
> 85:                 // parent of document root
> 86:                 {"/.."},

The nature of these two statements seems to be quite different. It might be worth to explain a bit more, a reference to the spec or note from the Slack discussion, sth. that might help the reader of these tests.

test/jaxp/javax/xml/jaxp/unittest/xpath/XPathExpParentTest.java line 145:

> 143: 
> 144:     /**
> 145:      * Verifies that XPath relative expressions provide a parent node.

The context node happens to be the parent node of the 2nd statement. Needs to document it in the description and the params below.

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

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

From joehw at openjdk.org  Thu Sep  1 17:40:13 2022
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 1 Sep 2022 17:40:13 GMT
Subject: RFR: JDK-8289510 : Improve test coverage for XPath Axes: namespace
 [v4]
In-Reply-To: <zwo1qnmNlIyk_CDzm99_qyofKWU-fQMXIrGpRWZG6bA=.2c722ffb-8d91-45ce-bd2b-b669926add1b@github.com>
References: <fvhggtrPyzXPEjKIMleUFn-TjYFfaAZKouH6asWZ4S4=.de353a67-3391-467d-bea7-1bdde7f84d6a@github.com>
 <zwo1qnmNlIyk_CDzm99_qyofKWU-fQMXIrGpRWZG6bA=.2c722ffb-8d91-45ce-bd2b-b669926add1b@github.com>
Message-ID: <5DhhsU_0oP4C__a-IDaX9da-DOvGkE0iGX8x_ZSVzqo=.82d34c18-7ac3-4c58-b1cb-87b3ada6fa46@github.com>

On Thu, 1 Sep 2022 11:38:09 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

>> Added tests for namespace Axis. Tests incluse namspace expressions, namespace node counts and namespace node scope.
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented the review comments.

Marked as reviewed by joehw (Reviewer).

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

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

From mchhipa at openjdk.org  Thu Sep  1 17:45:24 2022
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Thu, 1 Sep 2022 17:45:24 GMT
Subject: Integrated: JDK-8289510 : Improve test coverage for XPath Axes:
 namespace
In-Reply-To: <fvhggtrPyzXPEjKIMleUFn-TjYFfaAZKouH6asWZ4S4=.de353a67-3391-467d-bea7-1bdde7f84d6a@github.com>
References: <fvhggtrPyzXPEjKIMleUFn-TjYFfaAZKouH6asWZ4S4=.de353a67-3391-467d-bea7-1bdde7f84d6a@github.com>
Message-ID: <Nt_cKjGtnkzA2Y_T1TCwpaq8KBhYwoC3kA8-mngb40Q=.9c5b3a4a-11e7-441b-965a-0bd7ee530930@github.com>

On Wed, 17 Aug 2022 15:32:49 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

> Added tests for namespace Axis. Tests incluse namspace expressions, namespace node counts and namespace node scope.

This pull request has now been integrated.

Changeset: 3d254d3c
Author:    Mahendra Chhipa <mchhipa at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3d254d3c8ea7f409e8f709413f80d88913eb0ce8
Stats:     245 lines in 1 file changed: 245 ins; 0 del; 0 mod

8289510: Improve test coverage for XPath Axes: namespace

Reviewed-by: joehw

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

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

From duke at openjdk.org  Thu Sep  1 18:28:12 2022
From: duke at openjdk.org (Bill Huang)
Date: Thu, 1 Sep 2022 18:28:12 GMT
Subject: RFR: JDK-8292990 Improve test coverage for XPath Axes: parent [v2]
In-Reply-To: <5OiZYwF-cPSeGG_PlFiq_KKSHwfn1OBZPf58bHzxTVU=.1b1e498d-1d87-4fec-aadd-b7d10ea1b39e@github.com>
References: <5OiZYwF-cPSeGG_PlFiq_KKSHwfn1OBZPf58bHzxTVU=.1b1e498d-1d87-4fec-aadd-b7d10ea1b39e@github.com>
Message-ID: <vAXDEHXESV63prv0UEjW8otPOZ_8aHVIBX3p0Rnih8E=.97238ac2-c468-40a4-aea7-179b8f73e6c2@github.com>

> The goal of this task is validating the parent axis contains the parent of the context node. Context nodes include 
> - root node 
> - element nodes 
> - text nodes 
> - attribute nodes 
> - namespace nodes 
> - comment nodes

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/10107/files
  - new: https://git.openjdk.org/jdk/pull/10107/files/887bc08f..637b5899

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

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

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

From svkamath at openjdk.org  Thu Sep  1 18:31:07 2022
From: svkamath at openjdk.org (Smita Kamath)
Date: Thu, 1 Sep 2022 18:31:07 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v6]
In-Reply-To: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
Message-ID: <0im5_Of4jj3BHOipBt4VkAuX3327nQbKtW_sYnzcVUU=.0153ab0a-aa0c-4c12-a150-407a85cf8d0c@github.com>

> 8289552: Make intrinsic conversions between bit representations of half precision values and floats

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

  Addressed review comments, updated microbenchmark

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9781/files
  - new: https://git.openjdk.org/jdk/pull/9781/files/1570e244..a4bfb34a

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

  Stats: 47 lines in 5 files changed: 45 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9781.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9781/head:pull/9781

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

From svkamath at openjdk.org  Thu Sep  1 18:31:10 2022
From: svkamath at openjdk.org (Smita Kamath)
Date: Thu, 1 Sep 2022 18:31:10 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v5]
In-Reply-To: <firCQ343CaIl9G9Xq3fcvBA7q1B7xi0psDuRwFkfFKQ=.cb71ecfa-02e2-4864-b9f2-8697093775a9@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <sJ_q2ta1gG9tCk0gp2HMx7f9E8vwIAm_rP9I5g9oduE=.a3df505a-eb92-4561-ac71-db3bb07a4cfd@github.com>
 <firCQ343CaIl9G9Xq3fcvBA7q1B7xi0psDuRwFkfFKQ=.cb71ecfa-02e2-4864-b9f2-8697093775a9@github.com>
Message-ID: <pqAguxYYHcoyAbFw2L8dOd-34-YYGBE9G42n8RRxvww=.e4c421bb-08cf-442a-b630-cb561778bd64@github.com>

On Thu, 25 Aug 2022 03:15:52 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated copyright comment
>
> src/hotspot/cpu/x86/x86_64.ad line 11330:
> 
>> 11328:   ins_pipe( pipe_slow );
>> 11329: %}
>> 11330: 
> 
> For HF2F, good to also add optimized rule with LoadS to benefit from vcvtph2ps memory src form of instruction.
> match(Set dst (ConvHF2F ( LoadS mem)));

Hi @sviswa7 , with this rule, I dont see additional performance gain. So I have not added it in the latest update.

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

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

From joehw at openjdk.org  Thu Sep  1 19:09:10 2022
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 1 Sep 2022 19:09:10 GMT
Subject: RFR: JDK-8292990 Improve test coverage for XPath Axes: parent [v2]
In-Reply-To: <vAXDEHXESV63prv0UEjW8otPOZ_8aHVIBX3p0Rnih8E=.97238ac2-c468-40a4-aea7-179b8f73e6c2@github.com>
References: <5OiZYwF-cPSeGG_PlFiq_KKSHwfn1OBZPf58bHzxTVU=.1b1e498d-1d87-4fec-aadd-b7d10ea1b39e@github.com>
 <vAXDEHXESV63prv0UEjW8otPOZ_8aHVIBX3p0Rnih8E=.97238ac2-c468-40a4-aea7-179b8f73e6c2@github.com>
Message-ID: <dxF7lguBpAb0Hs3ElyRHpvtq1Ko0CpDOTUjya0NA4HQ=.da171caf-4ddb-42a5-b73e-f98af447abb4@github.com>

On Thu, 1 Sep 2022 18:28:12 GMT, Bill Huang <duke at openjdk.org> wrote:

>> The goal of this task is validating the parent axis contains the parent of the context node. Context nodes include 
>> - root node 
>> - element nodes 
>> - text nodes 
>> - attribute nodes 
>> - namespace nodes 
>> - comment nodes
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments.

Marked as reviewed by joehw (Reviewer).

test/jaxp/javax/xml/jaxp/unittest/xpath/XPathExpParentTest.java line 150:

> 148: 
> 149:     /**
> 150:      * Verifies that XPath relative expressions provide a same node as the context node.

typo s/a same node/the same node.  No need to refresh the patch.

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

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

From kvn at openjdk.org  Thu Sep  1 19:34:13 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 1 Sep 2022 19:34:13 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v6]
In-Reply-To: <0im5_Of4jj3BHOipBt4VkAuX3327nQbKtW_sYnzcVUU=.0153ab0a-aa0c-4c12-a150-407a85cf8d0c@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <0im5_Of4jj3BHOipBt4VkAuX3327nQbKtW_sYnzcVUU=.0153ab0a-aa0c-4c12-a150-407a85cf8d0c@github.com>
Message-ID: <ro42qRph88lxGmssQXronCZwsHRhhOc0ftvR6lAUgDU=.8865a004-85e8-4918-b603-cfb9920053d7@github.com>

On Thu, 1 Sep 2022 18:31:07 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> 8289552: Make intrinsic conversions between bit representations of half precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments, updated microbenchmark

Thank you for adding JMH benchmarks and data. I submitted testing.

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

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

From duke at openjdk.org  Thu Sep  1 19:56:33 2022
From: duke at openjdk.org (Rahul Prabhu)
Date: Thu, 1 Sep 2022 19:56:33 GMT
Subject: Integrated: 8230374: maxOutputSize, instead of javatest.maxOutputSize,
 should be used in TEST.properties
In-Reply-To: <TP-KpPaBpJ7_BCt0k6pk8Bht6S4OLK7-XgHcAVoA0GQ=.63c90aa1-3db5-4e3e-a0c2-5eb0a9835abf@github.com>
References: <TP-KpPaBpJ7_BCt0k6pk8Bht6S4OLK7-XgHcAVoA0GQ=.63c90aa1-3db5-4e3e-a0c2-5eb0a9835abf@github.com>
Message-ID: <W7dkOYemX3ctxK-hRw_saNwlNXxUh2bv205ohzgV4EI=.3bed71ac-ddab-43ba-bf6c-e252d1a9f389@github.com>

On Mon, 29 Aug 2022 21:25:29 GMT, Rahul Prabhu <duke at openjdk.org> wrote:

> Rewrote javatest.maxOutputSize as maxOutputSize in the TEST.properties file in test/jdk/jdk/lambda to match the same declarations in other TEST.properties files. The jtreg specification with the correct syntax for maxOutputSize is at https://openjdk.org/jtreg/tag-spec.html.

This pull request has now been integrated.

Changeset: 04d8069b
Author:    Ruprabhu25 <ruprabhu25 at gmail.com>
Committer: Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/04d8069bacc6259fc5bf9de6963bb099fcfc4961
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8230374: maxOutputSize, instead of javatest.maxOutputSize, should be used in TEST.properties

Reviewed-by: dholmes

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

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

From duke at openjdk.org  Thu Sep  1 20:20:40 2022
From: duke at openjdk.org (Bill Huang)
Date: Thu, 1 Sep 2022 20:20:40 GMT
Subject: RFR: JDK-8292990 Improve test coverage for XPath Axes: parent [v3]
In-Reply-To: <5OiZYwF-cPSeGG_PlFiq_KKSHwfn1OBZPf58bHzxTVU=.1b1e498d-1d87-4fec-aadd-b7d10ea1b39e@github.com>
References: <5OiZYwF-cPSeGG_PlFiq_KKSHwfn1OBZPf58bHzxTVU=.1b1e498d-1d87-4fec-aadd-b7d10ea1b39e@github.com>
Message-ID: <JlZYktlUvyPbLoQ_yjqb6NKWCIcB1xnZeD81xjcwEv8=.02168b98-c73e-4748-bf3a-55396a2c829a@github.com>

> The goal of this task is validating the parent axis contains the parent of the context node. Context nodes include 
> - root node 
> - element nodes 
> - text nodes 
> - attribute nodes 
> - namespace nodes 
> - comment nodes

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

  Fixed typos.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10107/files
  - new: https://git.openjdk.org/jdk/pull/10107/files/637b5899..656067f1

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

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

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

From kvn at openjdk.org  Thu Sep  1 20:26:11 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 1 Sep 2022 20:26:11 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v6]
In-Reply-To: <0im5_Of4jj3BHOipBt4VkAuX3327nQbKtW_sYnzcVUU=.0153ab0a-aa0c-4c12-a150-407a85cf8d0c@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <0im5_Of4jj3BHOipBt4VkAuX3327nQbKtW_sYnzcVUU=.0153ab0a-aa0c-4c12-a150-407a85cf8d0c@github.com>
Message-ID: <sqmlHdJ-96lB9jGZ4U3FZpckVdEg01oqx5u04lBqf7E=.fde52570-9545-48d9-80fe-979a7906f6e5@github.com>

On Thu, 1 Sep 2022 18:31:07 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> 8289552: Make intrinsic conversions between bit representations of half precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments, updated microbenchmark

Looks like it is not ready. My JDK builds failed:

Exception in thread "main" java.nio.file.NoSuchFileException: /workspace/closed/src/jdk.compiler/share/data/symbols/../../../../../../open/src/jdk.compiler/share/data/symbols/java.base-7.sym.txt
	at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)

Also some compilers complain about missing parentheses in lines 482, 487, 488, 489, 522:

src/hotspot/share/runtime/sharedRuntime.cpp:482:31: note: place parentheses around the '&' expression to silence this warning
  jint f_signif_bits = doppel & 0x007fffff | msb;

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

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

From psandoz at openjdk.org  Thu Sep  1 20:38:12 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 1 Sep 2022 20:38:12 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v6]
In-Reply-To: <0im5_Of4jj3BHOipBt4VkAuX3327nQbKtW_sYnzcVUU=.0153ab0a-aa0c-4c12-a150-407a85cf8d0c@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <0im5_Of4jj3BHOipBt4VkAuX3327nQbKtW_sYnzcVUU=.0153ab0a-aa0c-4c12-a150-407a85cf8d0c@github.com>
Message-ID: <aidBQQBOjKCk6kghCSBV6qGHFUIOrTOaWza1W9d1_18=.168c7f9e-1ac0-4c26-94ae-722a5da48e71@github.com>

On Thu, 1 Sep 2022 18:31:07 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> 8289552: Make intrinsic conversions between bit representations of half precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments, updated microbenchmark

Likely requires a merge with master.

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

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

From darcy at openjdk.org  Thu Sep  1 20:44:27 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 1 Sep 2022 20:44:27 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v6]
In-Reply-To: <0im5_Of4jj3BHOipBt4VkAuX3327nQbKtW_sYnzcVUU=.0153ab0a-aa0c-4c12-a150-407a85cf8d0c@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <0im5_Of4jj3BHOipBt4VkAuX3327nQbKtW_sYnzcVUU=.0153ab0a-aa0c-4c12-a150-407a85cf8d0c@github.com>
Message-ID: <jp3g1e-Vjzar_GlVAN7CqFoj-EpNAcKwiX-C_HXDEhY=.eb36da15-a147-4730-b0af-da5825b58bb9@github.com>

On Thu, 1 Sep 2022 18:31:07 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> 8289552: Make intrinsic conversions between bit representations of half precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments, updated microbenchmark

Yes; I removed support for --release 7 in JDK 20 early today.


On Thu, Sep 1, 2022 at 1:36 PM Paul Sandoz ***@***.***> wrote:

> Likely requires a merge with master.
>
> ?
> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jdk/pull/9781#issuecomment-1234753280>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AHPLHYCD2RZXG427WU2322DV4EHT3ANCNFSM55WURKVA>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>

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

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

From kvn at openjdk.org  Thu Sep  1 21:21:28 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 1 Sep 2022 21:21:28 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v6]
In-Reply-To: <jp3g1e-Vjzar_GlVAN7CqFoj-EpNAcKwiX-C_HXDEhY=.eb36da15-a147-4730-b0af-da5825b58bb9@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <0im5_Of4jj3BHOipBt4VkAuX3327nQbKtW_sYnzcVUU=.0153ab0a-aa0c-4c12-a150-407a85cf8d0c@github.com>
 <jp3g1e-Vjzar_GlVAN7CqFoj-EpNAcKwiX-C_HXDEhY=.eb36da15-a147-4730-b0af-da5825b58bb9@github.com>
Message-ID: <SkGmDPFWhQZGaglHmdt3p72B17yxGc8flLEei7F_H3s=.a6e53ae9-aac9-406a-8b7e-6886572ae3f2@github.com>

On Thu, 1 Sep 2022 20:40:35 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Yes; I removed support for --release 7 in JDK 20 early today.

Yes, I missed that my merge of master did not apply because I modified tests, Joe fixed, to test his changes.

Resubmitting testing after resolving the issue. Still missed parentheses issue should be fixed.

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

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

From duke at openjdk.org  Thu Sep  1 21:31:53 2022
From: duke at openjdk.org (Bill Huang)
Date: Thu, 1 Sep 2022 21:31:53 GMT
Subject: Integrated: JDK-8292990 Improve test coverage for XPath Axes: parent
In-Reply-To: <5OiZYwF-cPSeGG_PlFiq_KKSHwfn1OBZPf58bHzxTVU=.1b1e498d-1d87-4fec-aadd-b7d10ea1b39e@github.com>
References: <5OiZYwF-cPSeGG_PlFiq_KKSHwfn1OBZPf58bHzxTVU=.1b1e498d-1d87-4fec-aadd-b7d10ea1b39e@github.com>
Message-ID: <Yy7ZAp86QDXTzF6-OIL8-rQRR9O-6nWEUweJylxLZdc=.5438ca08-a5a7-406b-8602-317e0db350bb@github.com>

On Wed, 31 Aug 2022 20:16:33 GMT, Bill Huang <duke at openjdk.org> wrote:

> The goal of this task is validating the parent axis contains the parent of the context node. Context nodes include 
> - root node 
> - element nodes 
> - text nodes 
> - attribute nodes 
> - namespace nodes 
> - comment nodes

This pull request has now been integrated.

Changeset: e3939737
Author:    Bill Huang <bill.w.huang at oracle.com>
Committer: Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e393973761eec8fe08d901d93fc5a9261b6faf14
Stats:     165 lines in 2 files changed: 165 ins; 0 del; 0 mod

8292990: Improve test coverage for XPath Axes: parent

Reviewed-by: joehw

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

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

From svkamath at openjdk.org  Thu Sep  1 23:22:46 2022
From: svkamath at openjdk.org (Smita Kamath)
Date: Thu, 1 Sep 2022 23:22:46 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v7]
In-Reply-To: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
Message-ID: <6VkHnbPePwUy3s-i63Wgcxuf60z7MpHtpD2BT4q1I38=.4f5e812c-1198-4be4-8b11-ccd738773fdd@github.com>

> 8289552: Make intrinsic conversions between bit representations of half precision values and floats

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

  Added missing parantheses

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9781/files
  - new: https://git.openjdk.org/jdk/pull/9781/files/a4bfb34a..cc22a401

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=05-06

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

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

From sviswanathan at openjdk.org  Thu Sep  1 23:48:51 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 1 Sep 2022 23:48:51 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v7]
In-Reply-To: <6VkHnbPePwUy3s-i63Wgcxuf60z7MpHtpD2BT4q1I38=.4f5e812c-1198-4be4-8b11-ccd738773fdd@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <6VkHnbPePwUy3s-i63Wgcxuf60z7MpHtpD2BT4q1I38=.4f5e812c-1198-4be4-8b11-ccd738773fdd@github.com>
Message-ID: <naiq27__-QOfBF2Nu3Ws65Kb0KfKpGjrSyt3F3Vnnd8=.2d44592c-977b-4085-9a82-921333a2bf5e@github.com>

On Thu, 1 Sep 2022 23:22:46 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> 8289552: Make intrinsic conversions between bit representations of half precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added missing parantheses

Some minor naming/formatting comments. Rest of the patch looks good to me.

src/hotspot/share/runtime/sharedRuntime.cpp line 487:

> 485:   jshort signif_bits = (jshort)(f_signif_bits >> (13 + exp_delta));
> 486: 
> 487:   jint lsb = (f_signif_bits & (1 << 13 + exp_delta));

It will be more clear to have the parenthesis like this:
jint lsb = f_signif_bits & (1 << (13 + exp_delta));

src/hotspot/share/runtime/sharedRuntime.cpp line 522:

> 520: 
> 521:   // Add the bias of float exponent and shift
> 522:   int float_exp_bits = ((hf_exp + 127) << 24 - 1);

It will be more clear to have the parenthesis like this:
int float_exp_bits = (hf_exp + 127) << (24 - 1);

May be we should refer to src/java.base/share/classes/java/lang/Float.java:floatToFloat16 and Float16toFloat in comments.

src/hotspot/share/runtime/sharedRuntime.cpp line 525:

> 523: 
> 524:   // Combine sign, exponent and significand bits
> 525:   return (jfloat) ((hf_sign_bit << 16) | float_exp_bits | (hf_significand_bits << significand_shift));

You could call SharedRuntime::i2f here as well to be consistent to line 517.

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

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

From sviswanathan at openjdk.org  Thu Sep  1 23:48:54 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 1 Sep 2022 23:48:54 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v6]
In-Reply-To: <0im5_Of4jj3BHOipBt4VkAuX3327nQbKtW_sYnzcVUU=.0153ab0a-aa0c-4c12-a150-407a85cf8d0c@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <0im5_Of4jj3BHOipBt4VkAuX3327nQbKtW_sYnzcVUU=.0153ab0a-aa0c-4c12-a150-407a85cf8d0c@github.com>
Message-ID: <kAEbFaYbgpAw-PNFHpp8IOELcPS1R9o2hGwAwnGunM0=.f6344c6b-b16f-4814-90e8-4d10110c5125@github.com>

On Thu, 1 Sep 2022 18:31:07 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> 8289552: Make intrinsic conversions between bit representations of half precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments, updated microbenchmark

src/hotspot/cpu/x86/assembler_x86.cpp line 1931:

> 1929: }
> 1930: 
> 1931: void Assembler::vcvtps2ph(Address dst, KRegister mask, XMMRegister src, int imm8, int vector_len) {

This could be named as evcvtps2ph as the instruction with mask register is evex only.

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

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

From sviswanathan at openjdk.org  Thu Sep  1 23:48:57 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 1 Sep 2022 23:48:57 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v5]
In-Reply-To: <pqAguxYYHcoyAbFw2L8dOd-34-YYGBE9G42n8RRxvww=.e4c421bb-08cf-442a-b630-cb561778bd64@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <sJ_q2ta1gG9tCk0gp2HMx7f9E8vwIAm_rP9I5g9oduE=.a3df505a-eb92-4561-ac71-db3bb07a4cfd@github.com>
 <firCQ343CaIl9G9Xq3fcvBA7q1B7xi0psDuRwFkfFKQ=.cb71ecfa-02e2-4864-b9f2-8697093775a9@github.com>
 <pqAguxYYHcoyAbFw2L8dOd-34-YYGBE9G42n8RRxvww=.e4c421bb-08cf-442a-b630-cb561778bd64@github.com>
Message-ID: <QuJCMOC2O5riRYAMkSuo5RIbCkGY6ZOiSuCUHI4li44=.199b14e3-254f-4b71-bfd2-6d635734658a@github.com>

On Thu, 1 Sep 2022 18:26:52 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> src/hotspot/cpu/x86/x86_64.ad line 11330:
>> 
>>> 11328:   ins_pipe( pipe_slow );
>>> 11329: %}
>>> 11330: 
>> 
>> For HF2F, good to also add optimized rule with LoadS to benefit from vcvtph2ps memory src form of instruction.
>> match(Set dst (ConvHF2F ( LoadS mem)));
>
> Hi @sviswa7 , with this rule, I dont see additional performance gain. So I have not added it in the latest update.

ok, sounds good.

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

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

From svkamath at openjdk.org  Fri Sep  2 00:52:49 2022
From: svkamath at openjdk.org (Smita Kamath)
Date: Fri, 2 Sep 2022 00:52:49 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v8]
In-Reply-To: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
Message-ID: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com>

> 8289552: Make intrinsic conversions between bit representations of half precision values and floats

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

  Addressed review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9781/files
  - new: https://git.openjdk.org/jdk/pull/9781/files/cc22a401..6b828e60

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=06-07

  Stats: 11 lines in 4 files changed: 2 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/9781.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9781/head:pull/9781

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

From sviswanathan at openjdk.org  Fri Sep  2 00:57:33 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 2 Sep 2022 00:57:33 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v8]
In-Reply-To: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com>
Message-ID: <7tLBlRgmm_3A4CTKkxrx649IQdokoSPXzQAOsWBwF2A=.eeb0bb7c-276d-431a-a6cc-fdbe2c15822d@github.com>

On Fri, 2 Sep 2022 00:52:49 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> 8289552: Make intrinsic conversions between bit representations of half precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments

Marked as reviewed by sviswanathan (Reviewer).

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

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

From duke at openjdk.org  Fri Sep  2 06:45:55 2022
From: duke at openjdk.org (duke)
Date: Fri, 2 Sep 2022 06:45:55 GMT
Subject: Withdrawn: 8279283 - BufferedInputStream should override transferTo
In-Reply-To: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
Message-ID: <PVI-0afyLOq9DZwdCV0Ot_NzZn8VaGwxdw4g0vgvSZ0=.1e9d7be4-4b07-47da-8e1e-d2dc1c1f47fb@github.com>

On Sun, 26 Dec 2021 17:30:41 GMT, Markus KARG <duke at openjdk.org> wrote:

> Implementation of JDK-8279283

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Fri Sep  2 07:37:49 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 2 Sep 2022 07:37:49 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v5]
In-Reply-To: <ZgOSlE0-1thQUJ2l90Exh0uHujmbCRLkeOxpVMaoaRo=.78e967da-6edc-4a4e-be34-73af811bf109@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <ZgOSlE0-1thQUJ2l90Exh0uHujmbCRLkeOxpVMaoaRo=.78e967da-6edc-4a4e-be34-73af811bf109@github.com>
Message-ID: <dXJ1yHWeIQA8O--NLaDd6gobzGPNkcigbjQXqDJGMwA=.5a68b411-4095-43a5-996a-fcd7127de706@github.com>

On Mon, 27 Dec 2021 13:43:12 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Implementation of JDK-8279283
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed missing BufferedInputStream

Will this be reopened somewhen? The proposed changes seems useful

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

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

From alanb at openjdk.org  Fri Sep  2 07:52:56 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 2 Sep 2022 07:52:56 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v5]
In-Reply-To: <ZgOSlE0-1thQUJ2l90Exh0uHujmbCRLkeOxpVMaoaRo=.78e967da-6edc-4a4e-be34-73af811bf109@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <ZgOSlE0-1thQUJ2l90Exh0uHujmbCRLkeOxpVMaoaRo=.78e967da-6edc-4a4e-be34-73af811bf109@github.com>
Message-ID: <fUd2IQyjdQaJIC69d_qoj2tWNfM5_NQBmYrjutyVufQ=.fead6a73-ac76-4cce-bbfe-00bab8c8729d@github.com>

On Mon, 27 Dec 2021 13:43:12 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Implementation of JDK-8279283
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed missing BufferedInputStream

> /open
> 
> I will continue work on this in the next weeks.

It's probably best to change to back to draft until there is an updated proposal.

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

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

From duke at openjdk.org  Fri Sep  2 12:38:52 2022
From: duke at openjdk.org (Markus KARG)
Date: Fri, 2 Sep 2022 12:38:52 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v5]
In-Reply-To: <fUd2IQyjdQaJIC69d_qoj2tWNfM5_NQBmYrjutyVufQ=.fead6a73-ac76-4cce-bbfe-00bab8c8729d@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <ZgOSlE0-1thQUJ2l90Exh0uHujmbCRLkeOxpVMaoaRo=.78e967da-6edc-4a4e-be34-73af811bf109@github.com>
 <fUd2IQyjdQaJIC69d_qoj2tWNfM5_NQBmYrjutyVufQ=.fead6a73-ac76-4cce-bbfe-00bab8c8729d@github.com>
Message-ID: <fVFFgHrvgJtfegwBHHJ9hxZ8gidE8CrFX1fwLIZPjqs=.b5e7356d-6a6e-459d-b319-dfaab3f6a77d@github.com>

On Fri, 2 Sep 2022 07:50:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> It's probably best to change to back to draft until there is an updated proposal.

I would love to, but how to do that? I mean, there is no button in Github that would allow *me* to do that.

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

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

From ysatowse at openjdk.org  Fri Sep  2 12:44:14 2022
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Fri, 2 Sep 2022 12:44:14 GMT
Subject: RFR: 8292579: (tz) Update Timezone Data to 2022c
Message-ID: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>

Please review this PR.  The PR adopts the official tzdata2022c as it is.
It means the pre-1970s data merged in tzdata2022c doesn't exist.
All tests have been passed with no failures.

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

Commit messages:
 - Merge branch 'master' into tz2022c
 - The first fix for tz2022c

Changes: https://git.openjdk.org/jdk/pull/10012/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10012&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292579
  Stats: 1021 lines in 15 files changed: 256 ins; 613 del; 152 mod
  Patch: https://git.openjdk.org/jdk/pull/10012.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10012/head:pull/10012

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

From ysatowse at openjdk.org  Fri Sep  2 12:44:14 2022
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Fri, 2 Sep 2022 12:44:14 GMT
Subject: RFR: 8292579: (tz) Update Timezone Data to 2022c
In-Reply-To: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
References: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
Message-ID: <nTaD7dc81zimRwiA3LtERDRb5re55iW29C3pQJaEhOk=.33ba4b3c-6efd-49a8-9a67-e2d6f3bff840@github.com>

On Thu, 25 Aug 2022 02:26:19 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  The PR adopts the official tzdata2022c as it is.
> It means the pre-1970s data merged in tzdata2022c doesn't exist.
> All tests have been passed with no failures.

The test failure seems to be irrelevant to this fix.
Problem listed by [JDK-8292498](https://bugs.openjdk.org/browse/JDK-8292498) and also mentioned as that the failure may occur on non-Windows platforms.

https://bugs.openjdk.org/browse/JDK-8292498?focusedCommentId=14518336&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14518336

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

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

From jpai at openjdk.org  Fri Sep  2 13:39:55 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 2 Sep 2022 13:39:55 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v5]
In-Reply-To: <fVFFgHrvgJtfegwBHHJ9hxZ8gidE8CrFX1fwLIZPjqs=.b5e7356d-6a6e-459d-b319-dfaab3f6a77d@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <ZgOSlE0-1thQUJ2l90Exh0uHujmbCRLkeOxpVMaoaRo=.78e967da-6edc-4a4e-be34-73af811bf109@github.com>
 <fUd2IQyjdQaJIC69d_qoj2tWNfM5_NQBmYrjutyVufQ=.fead6a73-ac76-4cce-bbfe-00bab8c8729d@github.com>
 <fVFFgHrvgJtfegwBHHJ9hxZ8gidE8CrFX1fwLIZPjqs=.b5e7356d-6a6e-459d-b319-dfaab3f6a77d@github.com>
Message-ID: <eSo6sKR7ThQ9m5DoPWuJMYN1B8cLeoUXLLj1yzaZhMY=.c1538c16-b50c-4a4b-bcb1-40af6d2e2849@github.com>

On Fri, 2 Sep 2022 12:34:49 GMT, Markus KARG <duke at openjdk.org> wrote:

> I mean, there is no button in Github that would allow me to do that.

On the right side of the page (at the top), search for "Still in progress?" "Convert to draft". That's a link (and I agree it's not easy to spot)

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

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

From duke at openjdk.org  Fri Sep  2 16:00:07 2022
From: duke at openjdk.org (Markus KARG)
Date: Fri, 2 Sep 2022 16:00:07 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v5]
In-Reply-To: <eSo6sKR7ThQ9m5DoPWuJMYN1B8cLeoUXLLj1yzaZhMY=.c1538c16-b50c-4a4b-bcb1-40af6d2e2849@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <ZgOSlE0-1thQUJ2l90Exh0uHujmbCRLkeOxpVMaoaRo=.78e967da-6edc-4a4e-be34-73af811bf109@github.com>
 <fUd2IQyjdQaJIC69d_qoj2tWNfM5_NQBmYrjutyVufQ=.fead6a73-ac76-4cce-bbfe-00bab8c8729d@github.com>
 <fVFFgHrvgJtfegwBHHJ9hxZ8gidE8CrFX1fwLIZPjqs=.b5e7356d-6a6e-459d-b319-dfaab3f6a77d@github.com>
 <eSo6sKR7ThQ9m5DoPWuJMYN1B8cLeoUXLLj1yzaZhMY=.c1538c16-b50c-4a4b-bcb1-40af6d2e2849@github.com>
Message-ID: <og-lsommq7pxDcEvoGVd2dS7KvBGKVOxAZ_oYLLUTMg=.7a7d22b1-df3b-41d9-93ee-4b53cb95eaeb@github.com>

On Fri, 2 Sep 2022 13:37:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> > I mean, there is no button in Github that would allow me to do that.
> 
> On the right side of the page (at the top), search for "Still in progress?" "Convert to draft". That's a link (and I agree it's not easy to spot)

Thanks, this worked! :-)

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

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

From psandoz at openjdk.org  Fri Sep  2 16:01:46 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 2 Sep 2022 16:01:46 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v8]
In-Reply-To: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com>
Message-ID: <PW-upYG-MoofJiqF-QfKJM9Bz2okgDRFVZQk0WLgB24=.e82ee272-fe79-4f33-84dd-0d9efcb01fdf@github.com>

On Fri, 2 Sep 2022 00:52:49 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> 8289552: Make intrinsic conversions between bit representations of half precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments

Can you please file a follow up issue to write a test (gtest?) for the `f2hf` and `hf2f` methods? If a bug is lurking in those it will otherwise be really hard to track down. (Perhaps an alternative to a gtest is to to somehow call those methods natively from Java using Panama, then we can reuse all the existing testing logic.)

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

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

From naoto at openjdk.org  Fri Sep  2 16:10:50 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 2 Sep 2022 16:10:50 GMT
Subject: RFR: 8292899: CustomTzIDCheckDST.java testcase failed on AIX
 platform
In-Reply-To: <PNcxR0GeF8sv1NdX-W0X84nw3LGunbNrYe8r3RzNEGc=.a9d5f9fb-8d79-48c0-8e23-584f684e471f@github.com>
References: <PNcxR0GeF8sv1NdX-W0X84nw3LGunbNrYe8r3RzNEGc=.a9d5f9fb-8d79-48c0-8e23-584f684e471f@github.com>
Message-ID: <95LInlZmHTHhUklLvDuKpCjKJm999OPziR2BB-NTxYo=.21818a57-c3e4-4d0b-a07b-3a5c35f66519@github.com>

On Fri, 26 Aug 2022 07:26:46 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> After `test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java` testcase was integrated, it failed on the AIX platform.
> 
> Error output
> 
> STDERR:
>  stdout: [];
>  stderr: [Exception in thread "main" java.lang.RuntimeException: Got unexpected timezone information: Thu Aug 25 09:29:10 CEST 2022
>         at CustomTzIDCheckDST.runTZTest(CustomTzIDCheckDST.java:71)
>         at CustomTzIDCheckDST.main(CustomTzIDCheckDST.java:50)
> ]
> 
> 
> By my investigation, `TZ=MEZ-1MESZ,M3.5.0,M10.5.0` timezone was changed to `Europe/Berlin` timezone on AIX platform.
> It seems this situation is happened because older AIX did not support `MEZ-1MESZ,M3.5.0,M10.5.0` timezone by TZ environment variable.
> https://www.ibm.com/support/pages/managing-time-zone-variable-posix
> AIX special code was implemented into `src/java.base/unix/native/libjava/TimeZone_md.c`.
> Current AIX supports `TZ=EST5EDT,M3.2.0/2:00:00,M11.1.0/2:00:00` style.
> I think implementation change is required. 
> 
> Some pre-submit tests are failed, but I think these are not related this change since modified parts are just for AIX platform.

LGTM. Thanks for verifying the results.

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

Marked as reviewed by naoto (Reviewer).

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

From naoto at openjdk.org  Fri Sep  2 16:24:43 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 2 Sep 2022 16:24:43 GMT
Subject: RFR: 8292579: (tz) Update Timezone Data to 2022c
In-Reply-To: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
References: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
Message-ID: <uFtogqDZlheTYFpDBAMSEksag8cg8flSitscaHFvUjk=.bf9ec68e-c7b3-4a2f-bb43-2042ea24083b@github.com>

On Thu, 25 Aug 2022 02:26:19 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  The PR adopts the official tzdata2022c as it is.
> It means the pre-1970s data merged in tzdata2022c doesn't exist.
> All tests have been passed with no failures.

LGTM

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

Marked as reviewed by naoto (Reviewer).

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

From svkamath at openjdk.org  Fri Sep  2 16:58:45 2022
From: svkamath at openjdk.org (Smita Kamath)
Date: Fri, 2 Sep 2022 16:58:45 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v8]
In-Reply-To: <PW-upYG-MoofJiqF-QfKJM9Bz2okgDRFVZQk0WLgB24=.e82ee272-fe79-4f33-84dd-0d9efcb01fdf@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com>
 <PW-upYG-MoofJiqF-QfKJM9Bz2okgDRFVZQk0WLgB24=.e82ee272-fe79-4f33-84dd-0d9efcb01fdf@github.com>
Message-ID: <UY4Xubiqcd3C2HNXn7ETdJLal7qqdjPx7HKMYaecp7E=.ac2a77f6-685c-48de-881c-2791a048c267@github.com>

On Fri, 2 Sep 2022 15:59:23 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressed review comments
>
> Can you please file a follow up issue to write a test (gtest?) for the `f2hf` and `hf2f` methods? If a bug is lurking in those it will otherwise be really hard to track down. (Perhaps an alternative to a gtest is to to somehow call those methods natively from Java using Panama, then we can reuse all the existing testing logic.)

@PaulSandoz - Bug link- https://bugs.openjdk.org/browse/JDK-8293323

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

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

From bchristi at openjdk.org  Fri Sep  2 17:14:46 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 2 Sep 2022 17:14:46 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: <psjqgL0cZpYCti-HRY4zW-fYVOwIbgjVztJxBfUJn4E=.9e853f96-a44a-4ae1-be0b-7ba0bb84be3c@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

Sorry for the delay. I'll try to get back to this soon.

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

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

From smarks at openjdk.org  Fri Sep  2 17:36:44 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 2 Sep 2022 17:36:44 GMT
Subject: RFR: 8065554: MatchResult should provide values of named-capturing
 groups [v5]
In-Reply-To: <KkOryNFXfJ_1UM12g_OtmKC2WOEIc5xch9hWnnmBbHc=.375dddea-362a-4161-ae6c-fdc98f3a7c0d@github.com>
References: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
 <KkOryNFXfJ_1UM12g_OtmKC2WOEIc5xch9hWnnmBbHc=.375dddea-362a-4161-ae6c-fdc98f3a7c0d@github.com>
Message-ID: <Rl3WLzouQnYXKpIPtvgJlcX-Lj1W3SDZ_d1noGqYX7g=.542438bc-5c54-4491-82e0-1e9b689dcbca@github.com>

On Wed, 31 Aug 2022 13:26:32 GMT, Raffaello Giulietti <duke at openjdk.org> wrote:

>> Add support for named groups to java.util.regex.MatchResult
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8065554: MatchResult should provide values of named-capturing groups

src/java.base/share/classes/java/util/regex/MatchResult.java line 319:

> 317:      *
> 318:      * @throws UnsupportedOperationException
> 319:      *          The default implementation of this method always throws

The `@throws` clause needs to state a general contract over all implementations, so it should say something like, "@throws UOE if the implementation does not support named groups". Then, the specification for the default implementation always throwing UOE should be moved to `@implSpec`.

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

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

From smarks at openjdk.org  Fri Sep  2 17:40:42 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 2 Sep 2022 17:40:42 GMT
Subject: RFR: 8065554: MatchResult should provide values of named-capturing
 groups [v5]
In-Reply-To: <KkOryNFXfJ_1UM12g_OtmKC2WOEIc5xch9hWnnmBbHc=.375dddea-362a-4161-ae6c-fdc98f3a7c0d@github.com>
References: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
 <KkOryNFXfJ_1UM12g_OtmKC2WOEIc5xch9hWnnmBbHc=.375dddea-362a-4161-ae6c-fdc98f3a7c0d@github.com>
Message-ID: <QAYRj7rZCmTqEbtfIGiHVtGtC855mSvEA3_NiG04Sq0=.027f7f3e-3f61-4e84-8196-3427c96f4d7e@github.com>

On Wed, 31 Aug 2022 13:26:32 GMT, Raffaello Giulietti <duke at openjdk.org> wrote:

>> Add support for named groups to java.util.regex.MatchResult
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8065554: MatchResult should provide values of named-capturing groups

src/java.base/share/classes/java/util/regex/MatchResult.java line 347:

> 345:      *
> 346:      * @throws UnsupportedOperationException
> 347:      *          The default implementation of this method always throws

Similar comment here as above, though it has nothing to do with named groups. The `@throws` clause should say it throws UOE if "the implementation cannot report whether or not it has a match" or some such. This is a bit odd, but the specification needs to be permissive enough so that it doesn't invalidate existing implementations outside the JDK.

As before, the "always throws" should be moved to `@implSpec`.

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

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

From duke at openjdk.org  Fri Sep  2 18:38:05 2022
From: duke at openjdk.org (Raffaello Giulietti)
Date: Fri, 2 Sep 2022 18:38:05 GMT
Subject: RFR: 8065554: MatchResult should provide values of named-capturing
 groups [v6]
In-Reply-To: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
References: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
Message-ID: <nKng1s1ZRiQY9FCmuSiwRo2Pl_oMP8a0zqC2pJS_y24=.ff7e9863-f795-472a-bbfb-5469135f675f@github.com>

> Add support for named groups to java.util.regex.MatchResult

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

  8065554: MatchResult should provide values of named-capturing groups

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10000/files
  - new: https://git.openjdk.org/jdk/pull/10000/files/365a01eb..c431a5f7

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

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

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

From duke at openjdk.org  Fri Sep  2 18:38:06 2022
From: duke at openjdk.org (Raffaello Giulietti)
Date: Fri, 2 Sep 2022 18:38:06 GMT
Subject: RFR: 8065554: MatchResult should provide values of named-capturing
 groups [v5]
In-Reply-To: <Rl3WLzouQnYXKpIPtvgJlcX-Lj1W3SDZ_d1noGqYX7g=.542438bc-5c54-4491-82e0-1e9b689dcbca@github.com>
References: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
 <KkOryNFXfJ_1UM12g_OtmKC2WOEIc5xch9hWnnmBbHc=.375dddea-362a-4161-ae6c-fdc98f3a7c0d@github.com>
 <Rl3WLzouQnYXKpIPtvgJlcX-Lj1W3SDZ_d1noGqYX7g=.542438bc-5c54-4491-82e0-1e9b689dcbca@github.com>
Message-ID: <jK8cgUuMDGYSR6h4-hnoLL7I3HI29yuVarfF9ZACCpU=.1c11c219-a00c-4059-98a8-8265597d710c@github.com>

On Fri, 2 Sep 2022 17:33:21 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8065554: MatchResult should provide values of named-capturing groups
>
> src/java.base/share/classes/java/util/regex/MatchResult.java line 319:
> 
>> 317:      *
>> 318:      * @throws UnsupportedOperationException
>> 319:      *          The default implementation of this method always throws
> 
> The `@throws` clause needs to state a general contract over all implementations, so it should say something like, "@throws UOE if the implementation does not support named groups". Then, the specification for the default implementation always throwing UOE should be moved to `@implSpec`.

Done

> src/java.base/share/classes/java/util/regex/MatchResult.java line 347:
> 
>> 345:      *
>> 346:      * @throws UnsupportedOperationException
>> 347:      *          The default implementation of this method always throws
> 
> Similar comment here as above, though it has nothing to do with named groups. The `@throws` clause should say it throws UOE if "the implementation cannot report whether or not it has a match" or some such. This is a bit odd, but the specification needs to be permissive enough so that it doesn't invalidate existing implementations outside the JDK.
> 
> As before, the "always throws" should be moved to `@implSpec`.

Done

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

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

From asemenyuk at openjdk.org  Fri Sep  2 22:28:39 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 2 Sep 2022 22:28:39 GMT
Subject: RFR: 8291915: jpackage: use multiple Features in MSI installer
In-Reply-To: <-4YIBqE_eqivCDLzL-1iwmZ0iDusC1qP1EA9iX2ZMnE=.38379074-0205-4ca2-9c1f-119e43b71ad6@github.com>
References: <-4YIBqE_eqivCDLzL-1iwmZ0iDusC1qP1EA9iX2ZMnE=.38379074-0205-4ca2-9c1f-119e43b71ad6@github.com>
Message-ID: <CDfEq7Gj-4ygqb6QpTbMQ7b3qSubrbeWlbD5VFaVkI8=.ada5524a-ad27-4822-8ba0-90c8ff13c24a@github.com>

On Thu, 4 Aug 2022 17:00:38 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> This change splits existing single Feature `DefaultFeature` into 3 different feautures:
> 
>  - `DefaultFeature_Files`: application and runtime files
>  - `DefaultFeature_Shortcuts`: application Desktop and Start Menu shortcuts
>  - `DefaultFeature_FileAssociations`: File Association components
> 
> These 3 Features are nested under the existing top-level Feature.
> 
> Currently the use of File references in Shortcuts and FileAssociations causes ICE69 MSI warnings like this one:
> 
> 
> warning LGHT1076 : ICE69: Mismatched component reference. Entry 'reg12F3244EB2A37CCDB282E815ADFD174A' of the Registry table belongs to component 'cprogid9f99d1ff794e3df6bee07ba710a5501a'. However, the formatted string in column 'Value' references file 'file9846f81ce394345095918903022c1072' which belongs to component 'cfile9846f81ce394345095918903022c1072'. Components are in the same feature.
> 
> 
> This warning seems to be completely harmless when the File, referenced from the Shortcut or Verb elements, belongs to the same Feature. Though, this warning becomes and error when the File belongs to other Feature.
> 
> To solve this problem for Shortcut and Verb - install-time `ARPMAINLAUNCHERLOCATION` is introduced, that points to the main application launcher in a form: `[INSTALLDIR]launcher.exe`. With such property no `ICE69` warnings are raised.
> 
> It appeared that such solution is not possible for the Shortcut Icon reference, that points to the icon file. Instead this icon file is additionally included into Shortcuts ComponentGroup. This way `ICE69` warning is raised (as before) instead of an error.
> 
> Added test uses `ADDLOCAL` options to test the installation of Features separately. To pass this option to installation handlers I've added it to `JPackageCommand`, this seemed to be the easiest way to pass it  without changing handler signatures.
> 
> It appeared, that default checks in `PackageTest` assume "all-or-nothing" installation scenario and contain non-trivial logic to determine which checks (files, desktop, FA) to run. I've iterated multiple times on this logic adding more flags (that can be controllable from the test itself) and ended up with helper methods in `WindowsHelper` that checks install arguments on `JPackageCommand` assuming `ADDLOCAL` and known Feature names there. This solution, while being the simplest of all attempts, is quite clunky, it may be better to introduce more fine-grained control over these checks from the test itself (such change is potentially disruptive to the test-suite).
> 
> It was also discovered, that `ADDLOCAL` option is not supported with `unpack` mode, and separate Features are not currently checked in this mode.
> 
> Testing:
> 
>  - `WinFeaturesTest` that installs and checks Features one by one
>  - `FileAssociationsTest` and `WinShortcutTest` test runs with `install` enabled

update

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

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

From alanb at openjdk.org  Sat Sep  3 07:26:47 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 3 Sep 2022 07:26:47 GMT
Subject: RFR: 8293197: Avoid double racy reads from non-volatile fields in
 SharedSecrets
In-Reply-To: <GvvKthp1tV-BsDwulYsu5nGEYXKnibDPse5MVdQHyyg=.f7ce5178-d88e-44d6-9103-6d94de127cef@github.com>
References: <GvvKthp1tV-BsDwulYsu5nGEYXKnibDPse5MVdQHyyg=.f7ce5178-d88e-44d6-9103-6d94de127cef@github.com>
Message-ID: <lLWJU_xZvo7T9tHiWPgB36H7jToE4jRrNNmcbIkZ7JA=.b054bd0f-92e1-4649-9948-ba3011815a11@github.com>

On Tue, 30 Aug 2022 07:10:36 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> After integration of [JDK-8259021](https://bugs.openjdk.org/browse/JDK-8259021) a few more fields were added to `SharedSecrets` class. It make sense to update their reading code to use the same idiom.

Surprising that the additions since JDK-8259021 didn't follow the same pattern but I think some of these were in other repos at the time.

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

Marked as reviewed by alanb (Reviewer).

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

From alanb at openjdk.org  Sat Sep  3 07:27:42 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 3 Sep 2022 07:27:42 GMT
Subject: RFR: 8292579: (tz) Update Timezone Data to 2022c
In-Reply-To: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
References: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
Message-ID: <VF0kY5jdbwsZRo4nz9zR9TKVrEU00SANMxjL8ujRBOI=.521bad94-0a4f-4a17-9fdf-223d6d6b727c@github.com>

On Thu, 25 Aug 2022 02:26:19 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  The PR adopts the official tzdata2022c as it is.
> It means the pre-1970s data merged in tzdata2022c doesn't exist.
> All tests have been passed with no failures.

Marked as reviewed by alanb (Reviewer).

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

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

From itakiguchi at openjdk.org  Sun Sep  4 07:25:09 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Sun, 4 Sep 2022 07:25:09 GMT
Subject: Integrated: 8292899: CustomTzIDCheckDST.java testcase failed on AIX
 platform
In-Reply-To: <PNcxR0GeF8sv1NdX-W0X84nw3LGunbNrYe8r3RzNEGc=.a9d5f9fb-8d79-48c0-8e23-584f684e471f@github.com>
References: <PNcxR0GeF8sv1NdX-W0X84nw3LGunbNrYe8r3RzNEGc=.a9d5f9fb-8d79-48c0-8e23-584f684e471f@github.com>
Message-ID: <mNw0hAO6ml7PmdHeptrkROhVF4GwrgqiykDJ3aGfEA8=.54781c90-8eb4-4a85-a777-cc941ff77462@github.com>

On Fri, 26 Aug 2022 07:26:46 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> After `test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java` testcase was integrated, it failed on the AIX platform.
> 
> Error output
> 
> STDERR:
>  stdout: [];
>  stderr: [Exception in thread "main" java.lang.RuntimeException: Got unexpected timezone information: Thu Aug 25 09:29:10 CEST 2022
>         at CustomTzIDCheckDST.runTZTest(CustomTzIDCheckDST.java:71)
>         at CustomTzIDCheckDST.main(CustomTzIDCheckDST.java:50)
> ]
> 
> 
> By my investigation, `TZ=MEZ-1MESZ,M3.5.0,M10.5.0` timezone was changed to `Europe/Berlin` timezone on AIX platform.
> It seems this situation is happened because older AIX did not support `MEZ-1MESZ,M3.5.0,M10.5.0` timezone by TZ environment variable.
> https://www.ibm.com/support/pages/managing-time-zone-variable-posix
> AIX special code was implemented into `src/java.base/unix/native/libjava/TimeZone_md.c`.
> Current AIX supports `TZ=EST5EDT,M3.2.0/2:00:00,M11.1.0/2:00:00` style.
> I think implementation change is required. 
> 
> Some pre-submit tests are failed, but I think these are not related this change since modified parts are just for AIX platform.

This pull request has now been integrated.

Changeset: 3464019d
Author:    Ichiroh Takiguchi <itakiguchi at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3464019d7e8fe57adc910339c00ba79884c77852
Stats:     17 lines in 1 file changed: 11 ins; 1 del; 5 mod

8292899: CustomTzIDCheckDST.java testcase failed on AIX platform

Reviewed-by: naoto

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

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

From cstein at openjdk.org  Mon Sep  5 06:12:18 2022
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 5 Sep 2022 06:12:18 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7 [v6]
In-Reply-To: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
Message-ID: <4lMzpkkcl7esFeW4hbYTCoAsGPZfAcoRvdSahdVtte4=.e1de0004-3f48-455d-8828-da495c6fe123@github.com>

> Please review the change to update to using jtreg 7.
> 
> 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.

Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Update configure to check for jtreg 7 or later
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Revert junit.java
   
   Commit https://github.com/openjdk/jdk/commit/45c3e898ed538545921395372fe507e9111401e1 deleted this file
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Update to new JUnit JAR file
   
   With version 7 of `jtreg` comes JUnit Platform 1.8.2 (also known as "JUnit 5.8.2").
   This change updates the hard-coded library tag value to the new JUnit JAR file.
   Therefore, it partly addresses https://bugs.openjdk.org/browse/JDK-8292316,
   in order to unblock the "Update to use jtreg 7" PR 9393:
   https://github.com/openjdk/jdk/pull/9393
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
 - ... and 4 more: https://git.openjdk.org/jdk/compare/3464019d...16b140ab

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

Changes: https://git.openjdk.org/jdk/pull/9393/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9393&range=05
  Stats: 11 lines in 8 files changed: 0 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/9393.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9393/head:pull/9393

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

From stuefe at openjdk.org  Mon Sep  5 06:39:21 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 5 Sep 2022 06:39:21 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7 [v6]
In-Reply-To: <4lMzpkkcl7esFeW4hbYTCoAsGPZfAcoRvdSahdVtte4=.e1de0004-3f48-455d-8828-da495c6fe123@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
 <4lMzpkkcl7esFeW4hbYTCoAsGPZfAcoRvdSahdVtte4=.e1de0004-3f48-455d-8828-da495c6fe123@github.com>
Message-ID: <Zr0lLSTR0cPm37H6h6dz4LSuH8MM57uCBMjbNlNehtU=.c3d67fa3-98fe-412b-9158-4f2087732caf@github.com>

On Mon, 5 Sep 2022 06:12:18 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review the change to update to using jtreg 7.
>> 
>> 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.
>
> Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Update configure to check for jtreg 7 or later
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Revert junit.java
>    
>    Commit https://github.com/openjdk/jdk/commit/45c3e898ed538545921395372fe507e9111401e1 deleted this file
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Update to new JUnit JAR file
>    
>    With version 7 of `jtreg` comes JUnit Platform 1.8.2 (also known as "JUnit 5.8.2").
>    This change updates the hard-coded library tag value to the new JUnit JAR file.
>    Therefore, it partly addresses https://bugs.openjdk.org/browse/JDK-8292316,
>    in order to unblock the "Update to use jtreg 7" PR 9393:
>    https://github.com/openjdk/jdk/pull/9393
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/3464019d...16b140ab

Is jtreg 7 downward compatible? Can I use it to test older JDKs, if yes, down to which version?

Thanks!

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

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

From cstein at openjdk.org  Mon Sep  5 07:21:41 2022
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 5 Sep 2022 07:21:41 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7 [v6]
In-Reply-To: <Zr0lLSTR0cPm37H6h6dz4LSuH8MM57uCBMjbNlNehtU=.c3d67fa3-98fe-412b-9158-4f2087732caf@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
 <4lMzpkkcl7esFeW4hbYTCoAsGPZfAcoRvdSahdVtte4=.e1de0004-3f48-455d-8828-da495c6fe123@github.com>
 <Zr0lLSTR0cPm37H6h6dz4LSuH8MM57uCBMjbNlNehtU=.c3d67fa3-98fe-412b-9158-4f2087732caf@github.com>
Message-ID: <6OOJkTK0YdlUyt8mUZytcutfeolSChmgx_EX9_Ll4jg=.41414343-4750-45c9-a0d8-d043611401cc@github.com>

On Mon, 5 Sep 2022 06:36:04 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Is jtreg 7 downward compatible? Can I use it to test older JDKs, if yes, down to which version?

Yes, down to JDK 11.

Quote from [Coming soon: jtreg 7](https://mail.openjdk.org/pipermail/jdk-dev/2022-August/006869.html)

> Also starting with version 7, jtreg is compiled with JDK 11 and so requires a recent release of JDK 11 to run it.

And it should have said more correctly: _...requires a recent release of JDK 11 **or later** to run it._

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

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

From stuefe at openjdk.org  Mon Sep  5 07:42:41 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 5 Sep 2022 07:42:41 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7 [v6]
In-Reply-To: <6OOJkTK0YdlUyt8mUZytcutfeolSChmgx_EX9_Ll4jg=.41414343-4750-45c9-a0d8-d043611401cc@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
 <4lMzpkkcl7esFeW4hbYTCoAsGPZfAcoRvdSahdVtte4=.e1de0004-3f48-455d-8828-da495c6fe123@github.com>
 <Zr0lLSTR0cPm37H6h6dz4LSuH8MM57uCBMjbNlNehtU=.c3d67fa3-98fe-412b-9158-4f2087732caf@github.com>
 <6OOJkTK0YdlUyt8mUZytcutfeolSChmgx_EX9_Ll4jg=.41414343-4750-45c9-a0d8-d043611401cc@github.com>
Message-ID: <y1H-GRoi8DLRX5RBo2m_upPWFc6MVReLm2KMYQOxT_I=.3c7dc4dc-3e52-4b62-9442-03e701af5181@github.com>

On Mon, 5 Sep 2022 07:18:09 GMT, Christian Stein <cstein at openjdk.org> wrote:

> > Is jtreg 7 downward compatible? Can I use it to test older JDKs, if yes, down to which version?
> 
> Yes, down to JDK 11.
> 
> Quote from [Coming soon: jtreg 7](https://mail.openjdk.org/pipermail/jdk-dev/2022-August/006869.html)
> 
> > Also starting with version 7, jtreg is compiled with JDK 11 and so requires a recent release of JDK 11 to run it.

I read this to mean JT_JAVA, so the JVM running jtreg, not the testee VM.

But you are saying that the testee VM (`-jdk` option) can be JDK11 or later? I wonder whether I can use jtreg7 to test downport JDKs, especially since you wrote 

"This did affect some existing JDK tests, but those tests that
relied on specific jar file names have already been updated."

So I guess at the minimum we would have to downport those test changes to be able to test older JDKs with the new jtreg, right?

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

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

From cstein at openjdk.org  Mon Sep  5 07:50:33 2022
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 5 Sep 2022 07:50:33 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 7 [v6]
In-Reply-To: <y1H-GRoi8DLRX5RBo2m_upPWFc6MVReLm2KMYQOxT_I=.3c7dc4dc-3e52-4b62-9442-03e701af5181@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
 <4lMzpkkcl7esFeW4hbYTCoAsGPZfAcoRvdSahdVtte4=.e1de0004-3f48-455d-8828-da495c6fe123@github.com>
 <Zr0lLSTR0cPm37H6h6dz4LSuH8MM57uCBMjbNlNehtU=.c3d67fa3-98fe-412b-9158-4f2087732caf@github.com>
 <6OOJkTK0YdlUyt8mUZytcutfeolSChmgx_EX9_Ll4jg=.41414343-4750-45c9-a0d8-d043611401cc@github.com>
 <y1H-GRoi8DLRX5RBo2m_upPWFc6MVReLm2KMYQOxT_I=.3c7dc4dc-3e52-4b62-9442-03e701af5181@github.com>
Message-ID: <AQk5-CjYT8YZknv6oZRuwHnTzE9f1ws9cMlTeExlexo=.d078f624-9fbb-42f7-94a0-c7ef50565e86@github.com>

On Mon, 5 Sep 2022 07:38:33 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> So I guess at the minimum we would have to downport those test changes to be able to test older JDKs with the new jtreg, right?

Yes. Otherwise those tests will fail as they still do depend on hard-coded names of 3rd-party JAR files. Find backport candidates listed as Sub-Tasks number 3 to 5 at https://bugs.openjdk.org/browse/JDK-8289798 (Sub-Tasks number 1 and 2 were closed without changes.)

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

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

From asotona at openjdk.org  Mon Sep  5 12:49:20 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 5 Sep 2022 12:49:20 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell
Message-ID: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>

LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.

Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.

Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 

Please review.

Thanks,
Adam

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

Commit messages:
 - removed obsolete SuppressWarnings
 - 8289613: Drop use of Thread.stop in jshell

Changes: https://git.openjdk.org/jdk/pull/10166/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10166&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289613
  Stats: 54 lines in 2 files changed: 41 ins; 11 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10166.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10166/head:pull/10166

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

From alanb at openjdk.org  Mon Sep  5 13:21:34 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 5 Sep 2022 13:21:34 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell
In-Reply-To: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
Message-ID: <eukIvPsEpzdhKUSIVWmju1MrWq1XQ6GBU1uQHp-Z6oQ=.a625f68a-253f-4d9d-af45-b2caa0cbb309@github.com>

On Mon, 5 Sep 2022 12:39:41 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.
> 
> Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
> Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.
> 
> Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 
> 
> Please review.
> 
> Thanks,
> Adam

This is the last usage of Thread.stop in the JDK so this change is welcome.

The instrumentation to check a flag at jump instrumentation looks reasonable, and works here because the method is public on a public class in an exported package. I hadn't noticed that jdk.jshell.execution is exported and the addition to LocalExecutionControl means it's a new API so I assume forces you to write javadoc.

If a user presses control-C in jshell does it also interrupt the thread or will it just set the stop flag? If it also interrupts then you have another choice to check the interrupt status (assumes all code is well behaved of course).

Is there one or many LocalExecutionControl objects when I execute a snippet, control-C, execute another? I'm wondering because the allStop flag is static but STOP_LOCK is per instance.

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

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

From forax at openjdk.org  Mon Sep  5 13:35:41 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 5 Sep 2022 13:35:41 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell
In-Reply-To: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
Message-ID: <tuc-oZZY8mb111gU6_rbv5xEFcNEEXbwpQtC5ZGyALY=.a7513ea3-a6ef-44f6-9a51-8f4928b8bb13@github.com>

On Mon, 5 Sep 2022 12:39:41 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.
> 
> Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
> Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.
> 
> Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 
> 
> Please review.
> 
> Thanks,
> Adam

I've checked the code, same question as Alan, i believe you can have multiple instances of LocalExecutionControl, but `allStop` is a global flag.

Usually, the way to get an instance at runtime is either to use a ClassValue on the generated class or to store the instance in a ClassLoader and several one class loaders.
The last option is to pass an instance when defining a class, it only works with hidden classes, not normal classes but that code can be changed in the JDK.

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

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

From jlahoda at openjdk.org  Mon Sep  5 14:38:19 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 5 Sep 2022 14:38:19 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell
In-Reply-To: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
Message-ID: <M-3gpFNgAjDQU4Z2yYzd3WFnrsJq3g1zzLgT8DD6Lzo=.29847941-eadf-491b-a0eb-c0cb5ac4d269@github.com>

On Mon, 5 Sep 2022 12:39:41 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.
> 
> Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
> Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.
> 
> Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 
> 
> Please review.
> 
> Thanks,
> Adam

I believe that one instance of JShell will use only once instance of `ExecutionControl` at one time (although if it fails, it may spawn a new one). But there may be multiple instances of JShell at one time, so I suspect the static field on `LocalExecutionControl` won't work. I apologize for not realizing this sooner.

I think one way to resolve this is, for every `LocalExecutionControl` instance, synthesize a class, possibly named `REPL.$Cancel$`, which would hold the `allStop` field and the `stopCheck` method. This would then be load using the `LocalExecutionControl`'s `LoaderDelegate`, and used by the snippet.

A positive side-effect of this would be that we wouldn't need a new method in the public API, which I think would be preferred.

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

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

From forax at openjdk.org  Mon Sep  5 14:44:56 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 5 Sep 2022 14:44:56 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell
In-Reply-To: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
Message-ID: <LJOOVuo5TpZftXl_2b5YtHghXPv54_NkooDGJLWGU88=.68456000-3d98-4f98-8e56-448fd58dea33@github.com>

On Mon, 5 Sep 2022 12:39:41 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.
> 
> Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
> Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.
> 
> Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 
> 
> Please review.
> 
> Thanks,
> Adam

yes, this is a good plan.

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

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

From asotona at openjdk.org  Mon Sep  5 14:44:56 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 5 Sep 2022 14:44:56 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell
In-Reply-To: <eukIvPsEpzdhKUSIVWmju1MrWq1XQ6GBU1uQHp-Z6oQ=.a625f68a-253f-4d9d-af45-b2caa0cbb309@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
 <eukIvPsEpzdhKUSIVWmju1MrWq1XQ6GBU1uQHp-Z6oQ=.a625f68a-253f-4d9d-af45-b2caa0cbb309@github.com>
Message-ID: <x6K5mbGfTpCj17uacmEi4KzXdi716aLRGM2KZJohIlw=.fa7d68bb-db18-4493-948e-cbff8a6f0aee@github.com>

On Mon, 5 Sep 2022 13:18:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.
>> 
>> Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
>> Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.
>> 
>> Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> This is the last usage of Thread.stop in the JDK so this change is welcome.
> 
> The instrumentation to check a flag at jump instrumentation looks reasonable, and works here because the method is public on a public class in an exported package. I hadn't noticed that jdk.jshell.execution is exported and the addition to LocalExecutionControl means it's a new API so I assume forces you to write javadoc.
> 
> If a user presses control-C in jshell does it also interrupt the thread or will it just set the stop flag? If it also interrupts then you have another choice to check the interrupt status (assumes all code is well behaved of course).
> 
> Is there one or many LocalExecutionControl objects when I execute a snippet, control-C, execute another? I'm wondering because the allStop flag is static but STOP_LOCK is per instance.

I think @AlanBateman proposal to monitor interrupted status is easy to implement and also does not require a new public method nor synthetic class.

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

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

From forax at openjdk.org  Mon Sep  5 15:00:32 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 5 Sep 2022 15:00:32 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell
In-Reply-To: <x6K5mbGfTpCj17uacmEi4KzXdi716aLRGM2KZJohIlw=.fa7d68bb-db18-4493-948e-cbff8a6f0aee@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
 <eukIvPsEpzdhKUSIVWmju1MrWq1XQ6GBU1uQHp-Z6oQ=.a625f68a-253f-4d9d-af45-b2caa0cbb309@github.com>
 <x6K5mbGfTpCj17uacmEi4KzXdi716aLRGM2KZJohIlw=.fa7d68bb-db18-4493-948e-cbff8a6f0aee@github.com>
Message-ID: <bQ2OxhjZUUZ3ll_eVy21MTuu7UjI5M3Gu1sD8WYKf8Q=.d961a06c-9e86-4260-9cd1-ef64c65ae91a@github.com>

On Mon, 5 Sep 2022 14:42:56 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This is the last usage of Thread.stop in the JDK so this change is welcome.
>> 
>> The instrumentation to check a flag at jump instrumentation looks reasonable, and works here because the method is public on a public class in an exported package. I hadn't noticed that jdk.jshell.execution is exported and the addition to LocalExecutionControl means it's a new API so I assume forces you to write javadoc.
>> 
>> If a user presses control-C in jshell does it also interrupt the thread or will it just set the stop flag? If it also interrupts then you have another choice to check the interrupt status (assumes all code is well behaved of course).
>> 
>> Is there one or many LocalExecutionControl objects when I execute a snippet, control-C, execute another? I'm wondering because the allStop flag is static but STOP_LOCK is per instance.
>
> I think @AlanBateman proposal to monitor interrupted status is easy to implement and also does not require a new public method nor synthetic class.

@asotona, the problem is that user code may also react to the interrupted status,
the cancelling has be a mechanism a user can not trigger directly.

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

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

From asotona at openjdk.org  Mon Sep  5 15:53:32 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 5 Sep 2022 15:53:32 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v2]
In-Reply-To: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
Message-ID: <R6D3ECyQWC7o_018IUo4wm4NpniQTdSWvLHRYPo2JlY=.40bdea3e-d024-4316-b777-b29ddf453575@github.com>

> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.
> 
> Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
> Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.
> 
> Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 
> 
> Please review.
> 
> Thanks,
> Adam

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

  alternative implementation where instrumented code is directly checking Thread::interrupted

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10166/files
  - new: https://git.openjdk.org/jdk/pull/10166/files/355ba7f7..0f0e0dd1

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

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

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

From asotona at openjdk.org  Mon Sep  5 15:58:16 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 5 Sep 2022 15:58:16 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v2]
In-Reply-To: <R6D3ECyQWC7o_018IUo4wm4NpniQTdSWvLHRYPo2JlY=.40bdea3e-d024-4316-b777-b29ddf453575@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
 <R6D3ECyQWC7o_018IUo4wm4NpniQTdSWvLHRYPo2JlY=.40bdea3e-d024-4316-b777-b29ddf453575@github.com>
Message-ID: <zfChbHs9EqngR0b3GKMkuAPEpwKTfzDIoyyzCqiJU3I=.24036395-74b4-4250-af18-01e6a5e380c7@github.com>

On Mon, 5 Sep 2022 15:53:32 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.
>> 
>> Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
>> Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.
>> 
>> Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   alternative implementation where instrumented code is directly checking Thread::interrupted

Right, let's try the synthetic class.

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

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

From duke at openjdk.org  Mon Sep  5 16:04:28 2022
From: duke at openjdk.org (Strahinja Stanojevic)
Date: Mon, 5 Sep 2022 16:04:28 GMT
Subject: RFR: JDK-8292914: Introduce a system property that enables stable
 names for lambda classes
Message-ID: <pYF675FND8BK8SUHFnvstPMcoKTcW81zs7yGCli5Mxo=.aac8b180-6101-4320-aa73-7e640952afaf@github.com>

This PR introduces a system property that creates stable names for the lambda classes in the JDK. Instead of using an atomic counter in the lambda name, we can use a 32-bit hash after `$$Lambda$`. Thus, the name becomes `lambdaCapturingClass$$Lambda$hashValue`.
Parameters used to create a stable part of the name (hash value) are a superset of the parameters used for lambda class archiving when the CDS dumping option is enabled. During the stable name creation process,
all the common parameters are in the same form as in the low-level implementation (C part of the code) of the archiving process.
We concatenate all of those parameters in one string `hashData`. We calculate the long hash value for `hashData` in the same manner as the `java.lang.StringUTF16#hashCode` does, and then we hash that value using `Long.toString(longHashValue, Character.MAX_RADIX)`. The desired length for this hash is equal to the length of the `Long.toString(Long.MAX_VALUE, Character.MAX_RADIX)`.
Sometimes, the calculated hash value is shorter than the desired length, so we pad it with the character `#` to hit it. Appending `#` only affects the hash length, but not its stability.

Link to the related issue: https://bugs.openjdk.org/browse/JDK-8292914

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

Commit messages:
 - Remove debug messages. Change hex address preffix for 32 bit arhictecture
 - Debug message to check architecture which gate is running on
 - Debug message to check on which architecture gate is running
 - Debug message to check on which architecture gate is running
 - Test fails on the JDK20 that is not released yet. Since local testing and debugging is not possible beacuse of this, debug message added in this commit
 - JDK-8292914: Introduce a system property that enables stable names for lambda classes

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

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

From duke at openjdk.org  Mon Sep  5 16:08:03 2022
From: duke at openjdk.org (Markus KARG)
Date: Mon, 5 Sep 2022 16:08:03 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v6]
In-Reply-To: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
Message-ID: <tZjhh1uIe_50p7BFSzlD-li_IsWbwUWKtomdhndUwCA=.b672ba83-ed5b-444b-bcc1-bcf82f8a3308@github.com>

> Implementation of JDK-8279283

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

  using getBufIfOpen() instead of direct buf access

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/6935/files
  - new: https://git.openjdk.org/jdk/pull/6935/files/0d3528ea..2c415d0c

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

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

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

From duke at openjdk.org  Mon Sep  5 16:08:04 2022
From: duke at openjdk.org (Markus KARG)
Date: Mon, 5 Sep 2022 16:08:04 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v5]
In-Reply-To: <GlSllPDbK03fJ0U-OO_CRYPl1vSbYjO5sQagwf6UTDk=.b045239e-b0cc-40b5-80a0-b86d73214fcf@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <ZgOSlE0-1thQUJ2l90Exh0uHujmbCRLkeOxpVMaoaRo=.78e967da-6edc-4a4e-be34-73af811bf109@github.com>
 <GlSllPDbK03fJ0U-OO_CRYPl1vSbYjO5sQagwf6UTDk=.b045239e-b0cc-40b5-80a0-b86d73214fcf@github.com>
Message-ID: <ZcW7vycK2VkZS-Vu0ii8HV8baQCA3j_MK4Qk6ZnfBjE=.002f39ee-7e98-4bd6-8ba0-3d3c70026e6e@github.com>

On Thu, 7 Jul 2022 07:34:32 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed missing BufferedInputStream
>
> src/java.base/share/classes/java/io/BufferedInputStream.java line 495:
> 
>> 493:         int avail = count - pos;
>> 494:         if (avail > 0) {
>> 495:             out.write(buf, pos, avail);
> 
> I think `buf` should not be accessed directly but via `getBufIfOpen()` because we need to throw IOE in case `this` is closed.

Thank you, good catch! I just fixed this in https://github.com/openjdk/jdk/pull/6935/commits/2c415d0c9c39cec372c1edb189ac140af2755fa4. ?

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

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

From duke at openjdk.org  Mon Sep  5 16:15:35 2022
From: duke at openjdk.org (Markus KARG)
Date: Mon, 5 Sep 2022 16:15:35 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v5]
In-Reply-To: <CDWfTC_k5Ek7jWFU46GJoAnf0pVVIqwfvyBNivkJGN8=.a47d6652-7a77-4b1e-b521-900604d2b2fe@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <ZgOSlE0-1thQUJ2l90Exh0uHujmbCRLkeOxpVMaoaRo=.78e967da-6edc-4a4e-be34-73af811bf109@github.com>
 <CDWfTC_k5Ek7jWFU46GJoAnf0pVVIqwfvyBNivkJGN8=.a47d6652-7a77-4b1e-b521-900604d2b2fe@github.com>
Message-ID: <unTjSq1cSXuC9uKzm41Z9D67JHVSMOk0GgR1yQqeufY=.3ee68727-4d8b-4758-95bc-3a1418d830ad@github.com>

On Wed, 12 Jan 2022 13:24:12 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed missing BufferedInputStream
>
> src/java.base/share/classes/java/io/BufferedInputStream.java line 501:
> 
>> 499:         return avail + getInIfOpen().transferTo(out);
>> 500:     }
>> 501: 
> 
> Hi Markus, did you double check with all the existing subclasses of `BufferedInputStream` that the new implementation of `transferTo` will not cause trouble, if any of the subclasses is overriding `int read(byte[] b, int off, int len)`? If I'm not mistaken - with this new implementation of `transferTo` then `BufferedInputStream::read(byte[] b, int off, int len)` (a public method that can be overridden) will no longer be called by `transferTo`. This could be causing problems if `read` is overriden to do some special processing in the subclass.

Thank you, good catch! I will check the subclasses contained in OpenJDK! ?

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

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

From duke at openjdk.org  Mon Sep  5 18:05:04 2022
From: duke at openjdk.org (Markus KARG)
Date: Mon, 5 Sep 2022 18:05:04 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v7]
In-Reply-To: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
Message-ID: <iQc17-mZLZe0P2Kc41ZYd4vZDjG4CYV-XDORMUpOo1M=.27d01189-50a8-4c32-916f-2e4d6c1f521d@github.com>

> Implementation of JDK-8279283

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

  HexPrinter::transferTo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/6935/files
  - new: https://git.openjdk.org/jdk/pull/6935/files/2c415d0c..77caacc1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=6935&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=6935&range=05-06

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

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

From alanb at openjdk.org  Mon Sep  5 18:05:46 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 5 Sep 2022 18:05:46 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v2]
In-Reply-To: <R6D3ECyQWC7o_018IUo4wm4NpniQTdSWvLHRYPo2JlY=.40bdea3e-d024-4316-b777-b29ddf453575@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
 <R6D3ECyQWC7o_018IUo4wm4NpniQTdSWvLHRYPo2JlY=.40bdea3e-d024-4316-b777-b29ddf453575@github.com>
Message-ID: <49K0meTAqOz2xAWBvfP8sYwxjm8pZ-wT71N-KjpuRGA=.c8c743ce-be75-4e90-95c1-663ca334b943@github.com>

On Mon, 5 Sep 2022 15:53:32 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.
>> 
>> Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
>> Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.
>> 
>> Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   alternative implementation where instrumented code is directly checking Thread::interrupted

LocalExecutionControl.stop invoking Thread::interrupt is good as that will cause any interruptible methods to wakeup.

I'm less sure about instrumenting every "if" and "goto" to invoke Thread::interrupted but more recent comment suggests are going back to a stop field that polled by code in a generated class so I'll wait until you are done.

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

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

From alanb at openjdk.org  Mon Sep  5 18:35:52 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 5 Sep 2022 18:35:52 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v7]
In-Reply-To: <iQc17-mZLZe0P2Kc41ZYd4vZDjG4CYV-XDORMUpOo1M=.27d01189-50a8-4c32-916f-2e4d6c1f521d@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <iQc17-mZLZe0P2Kc41ZYd4vZDjG4CYV-XDORMUpOo1M=.27d01189-50a8-4c32-916f-2e4d6c1f521d@github.com>
Message-ID: <bSbC1oyhu41M8dzeZHhVSI08UOFj9cVnB-Zs3oW4Sy8=.7e1f43d7-50c5-4bd7-ba2a-a9ad965981ce@github.com>

On Mon, 5 Sep 2022 18:05:04 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Implementation of JDK-8279283
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   HexPrinter::transferTo

It looks like this patch is against a repository that hasn't been sync'ed up since late 2021. BIS has changed, esp. the locking, so this is why you get the merge-conflict label. Look at the implXXX methods to see how the existing methods do the locking.

I think I pointed out in one of the early rounds that you'll have to take the mark (if set) into account. It may be that you just call super.transferTo when markpos == -1.

The other issue that needs consideration is that the draining of the buffered bytes will leak the underlying input stream to the target output stream. It may be safer to also call super.transferTo when (count - pos) > 0.

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

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

From asotona at openjdk.org  Mon Sep  5 19:23:30 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 5 Sep 2022 19:23:30 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v3]
In-Reply-To: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
Message-ID: <nVWcamwX-PTcahYaIcHpHGoo2a5ItBrVNW9ImSd5RvM=.214ebaf8-ad2d-4348-8acc-b74d4e03f175@github.com>

> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.
> 
> Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
> Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.
> 
> Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 
> 
> Please review.
> 
> Thanks,
> Adam

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

 - allStop field and stopCheck method moved to synthetic REPL.$Cancel$
 - Revert "alternative implementation where instrumented code is directly checking Thread::interrupted"
   
   This reverts commit 0f0e0dd17c121955e7806073bb8cc78da1f133ea.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10166/files
  - new: https://git.openjdk.org/jdk/pull/10166/files/0f0e0dd1..30c34b6a

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

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

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

From dfuchs at openjdk.org  Mon Sep  5 20:26:59 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 5 Sep 2022 20:26:59 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v7]
In-Reply-To: <iQc17-mZLZe0P2Kc41ZYd4vZDjG4CYV-XDORMUpOo1M=.27d01189-50a8-4c32-916f-2e4d6c1f521d@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <iQc17-mZLZe0P2Kc41ZYd4vZDjG4CYV-XDORMUpOo1M=.27d01189-50a8-4c32-916f-2e4d6c1f521d@github.com>
Message-ID: <EjqSwyshh75YtKji43w2BJQABwZhJfHH03U_eDauvnY=.fb06ab80-69fd-4c1b-88b4-3c1698fd96b4@github.com>

On Mon, 5 Sep 2022 18:05:04 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Implementation of JDK-8279283
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   HexPrinter::transferTo

test/lib/jdk/test/lib/hexdump/HexPrinter.java line 1194:

> 1192:             byteOffset += size;
> 1193:             return size;
> 1194:         }

This is an indication that overriding `transferTo()` in `BufferedInputStream` has potential compatibility impacts on its subclasses. Therefore I would suggest adding a check in `BufferedInputStream::transferTo` to only override the behavior if not subclassed. Something like:


     if (this.getClass() != BufferedInputStream.class) {
         // a custom subclass may have expectations on which
         // methods tansferTo() will call. Revert to super class
         // behavior for compatibility.
         return super.transferTo(out);
     }
     ... otherwise proceed with the new implementation ...


Then you can revert the changes in this test.

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

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

From mik3hall at gmail.com  Mon Sep  5 23:15:33 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 5 Sep 2022 18:15:33 -0500
Subject: jpackage OS/X --app-image signing 
Message-ID: <1A3AD609-41FA-4FC4-B95D-19F3F0FED372@gmail.com>

The 19 release candidate appears to have new issues on this?

java --version
openjdk 19 2022-09-20
OpenJDK Runtime Environment (build 19+36-2238)
OpenJDK 64-Bit Server VM (build 19+36-2238, mixed mode, sharing)

which jpackage
jpackage: aliased to /Library/Java/JavaVirtualMachines/jdk-19.jdk/Contents/Home/bin/jpackage

jpackage --version
19

jpackage --type app-image --app-image ~/Blackjack_Blastoff/bjb/bjb_jpkg/BlackJack\ Blastoff_Unsigned.app --mac-sign --mac-signing-key-user-name "Developer ID Application: Michael Hall (5X6BXQB3Q7)"                                  
Error: app-image dir (/Users/mjh/Blackjack_Blastoff/bjb/bjb_jpkg/BlackJack Blastoff_Unsigned.app) generated by another jpackage version or malformed .jpackage.xml

ls -l
total 4224
drwxr-xr-x  3 mjh  staff       96 Sep  5 17:50 BlackJack Blastoff_Unsigned.app
?

I don?t think any information is included in the Info.plist or anywhere else that indicates which jpackage version was used to build it. (Maybe an idea?)
But I did recreate with the newly installed 19 release candidate. 
I?m not sure what the .jpackage.xml is about?

ls -l .jpackage.xml
ls: .jpackage.xml: No such file or directory

From asotona at openjdk.org  Tue Sep  6 06:27:39 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 6 Sep 2022 06:27:39 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v3]
In-Reply-To: <nVWcamwX-PTcahYaIcHpHGoo2a5ItBrVNW9ImSd5RvM=.214ebaf8-ad2d-4348-8acc-b74d4e03f175@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
 <nVWcamwX-PTcahYaIcHpHGoo2a5ItBrVNW9ImSd5RvM=.214ebaf8-ad2d-4348-8acc-b74d4e03f175@github.com>
Message-ID: <9mnAHYpCi5pQB-I5e5UVcUga2hHb8Av5LtZsHv2SbdE=.6771eb0a-a309-4966-b4a7-702edecf2936@github.com>

On Mon, 5 Sep 2022 19:23:30 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.
>> 
>> Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
>> Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.
>> 
>> Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - allStop field and stopCheck method moved to synthetic REPL.$Cancel$
>  - Revert "alternative implementation where instrumented code is directly checking Thread::interrupted"
>    
>    This reverts commit 0f0e0dd17c121955e7806073bb8cc78da1f133ea.

The latest version combines all comments. It instruments user code, delegates "allStop" to generated REPL.$Cancel$ class (loaded by specific LoaderDelegate), triggers REPL.$Cancel$.allStop and also interrupts all related threads to wake them up.

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

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

From duke at openjdk.org  Tue Sep  6 08:00:03 2022
From: duke at openjdk.org (Markus KARG)
Date: Tue, 6 Sep 2022 08:00:03 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v7]
In-Reply-To: <EjqSwyshh75YtKji43w2BJQABwZhJfHH03U_eDauvnY=.fb06ab80-69fd-4c1b-88b4-3c1698fd96b4@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <iQc17-mZLZe0P2Kc41ZYd4vZDjG4CYV-XDORMUpOo1M=.27d01189-50a8-4c32-916f-2e4d6c1f521d@github.com>
 <EjqSwyshh75YtKji43w2BJQABwZhJfHH03U_eDauvnY=.fb06ab80-69fd-4c1b-88b4-3c1698fd96b4@github.com>
Message-ID: <4IrMrIGz101qsBIjluHA8uVrsckxMfxDL70NqQpIog8=.9b9c202f-9973-4958-9dd5-91f4aa9f1bb6@github.com>

On Mon, 5 Sep 2022 20:21:01 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   HexPrinter::transferTo
>
> test/lib/jdk/test/lib/hexdump/HexPrinter.java line 1194:
> 
>> 1192:             byteOffset += size;
>> 1193:             return size;
>> 1194:         }
> 
> This is an indication that overriding `transferTo()` in `BufferedInputStream` has potential compatibility impacts on its subclasses. Therefore I would suggest adding a check in `BufferedInputStream::transferTo` to only override the behavior if not subclassed. Something like:
> 
> 
>      if (this.getClass() != BufferedInputStream.class) {
>          // a custom subclass may have expectations on which
>          // methods tansferTo() will call. Revert to super class
>          // behavior for compatibility.
>          return super.transferTo(out);
>      }
>      ... otherwise proceed with the new implementation ...
> 
> 
> Then you can revert the changes in this test.

I do not see that it makes much sense to add such a safety means before I am finished with the inspection of the subclasses. As you can see in this example, it was pretty easy to fix it, and there are only few such subclasses at all. So instead of preparing against possibly non-existing easyt-to-fix problems, I prefer fixing the actual problems. They can only occur inside of the JDK itself, as relying on any particular implementation inside of the JDK by non-JDK classes simply would be a complete programming fault and *must* get fixed.

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

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

From forax at openjdk.org  Tue Sep  6 08:10:48 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 6 Sep 2022 08:10:48 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v3]
In-Reply-To: <nVWcamwX-PTcahYaIcHpHGoo2a5ItBrVNW9ImSd5RvM=.214ebaf8-ad2d-4348-8acc-b74d4e03f175@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
 <nVWcamwX-PTcahYaIcHpHGoo2a5ItBrVNW9ImSd5RvM=.214ebaf8-ad2d-4348-8acc-b74d4e03f175@github.com>
Message-ID: <MHUPVdtqnKJo50BP3ByLUKLPHa49SbTt8lkZjrmtvHM=.35ee2523-330a-4747-925a-c79117d5adef@github.com>

On Mon, 5 Sep 2022 19:23:30 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.
>> 
>> Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
>> Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.
>> 
>> Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - allStop field and stopCheck method moved to synthetic REPL.$Cancel$
>  - Revert "alternative implementation where instrumented code is directly checking Thread::interrupted"
>    
>    This reverts commit 0f0e0dd17c121955e7806073bb8cc78da1f133ea.

Otherwise, it looks good to me

src/jdk.jshell/share/classes/jdk/jshell/execution/LocalExecutionControl.java line 98:

> 96:         var cancelWriter = new ClassWriter(ClassWriter.COMPUTE_FRAMES|ClassWriter.COMPUTE_MAXS);
> 97:         cancelWriter.visit(Opcodes.V19, Opcodes.ACC_PUBLIC, "REPL/$Cancel$", null, "java/lang/Object", null);
> 98:         cancelWriter.visitField(Opcodes.ACC_PUBLIC|Opcodes.ACC_STATIC|Opcodes.ACC_VOLATILE, "allStop", "Z", null, null);

fomatting: operators like '|' usually have a space before and a space after

src/jdk.jshell/share/classes/jdk/jshell/execution/LocalExecutionControl.java line 119:

> 117:     protected String invoke(Method doitMethod) throws Exception {
> 118:         if (allStop == null) {
> 119:             super.load(new ClassBytecodes[]{genCancelClass()});

fomatting: usually, people use spaces like this

  new ClassBytecodes[] {  genCancelClass()  }

src/jdk.jshell/share/classes/jdk/jshell/execution/LocalExecutionControl.java line 200:

> 198:                 allStop.set(null, true);
> 199:             } catch (IllegalArgumentException| IllegalAccessException ex) {
> 200:                 throw new InternalException(ex.getMessage());

to avoid to drop the stack trace of the original exception, it's better to chain the exceptions,

  throw (InternalException) new InternalException().initCause(ex);

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

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

From asotona at openjdk.org  Tue Sep  6 09:09:48 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 6 Sep 2022 09:09:48 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v3]
In-Reply-To: <MHUPVdtqnKJo50BP3ByLUKLPHa49SbTt8lkZjrmtvHM=.35ee2523-330a-4747-925a-c79117d5adef@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
 <nVWcamwX-PTcahYaIcHpHGoo2a5ItBrVNW9ImSd5RvM=.214ebaf8-ad2d-4348-8acc-b74d4e03f175@github.com>
 <MHUPVdtqnKJo50BP3ByLUKLPHa49SbTt8lkZjrmtvHM=.35ee2523-330a-4747-925a-c79117d5adef@github.com>
Message-ID: <eqNFeas5FsuQxyjzY2s30KyP33G_0qrhHoy57sxgpX4=.4fb677ec-34c0-49c8-821a-1412bf816f8c@github.com>

On Tue, 6 Sep 2022 08:04:07 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - allStop field and stopCheck method moved to synthetic REPL.$Cancel$
>>  - Revert "alternative implementation where instrumented code is directly checking Thread::interrupted"
>>    
>>    This reverts commit 0f0e0dd17c121955e7806073bb8cc78da1f133ea.
>
> src/jdk.jshell/share/classes/jdk/jshell/execution/LocalExecutionControl.java line 200:
> 
>> 198:                 allStop.set(null, true);
>> 199:             } catch (IllegalArgumentException| IllegalAccessException ex) {
>> 200:                 throw new InternalException(ex.getMessage());
> 
> to avoid to drop the stack trace of the original exception, it's better to chain the exceptions,
> 
>   throw (InternalException) new InternalException().initCause(ex);

I just followed similar pattern as in other 9 cases of throwing new InternalException in idk.jshell.

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

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

From asotona at openjdk.org  Tue Sep  6 09:14:47 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 6 Sep 2022 09:14:47 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v4]
In-Reply-To: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
Message-ID: <xrJWvyFSxCoKKFHL5TunUs-Gdr7cZJqp6zG-6UgyGOA=.61545fcd-8e13-4f31-9d6f-19a783eb4ed5@github.com>

> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.
> 
> Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
> Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.
> 
> Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 
> 
> Please review.
> 
> Thanks,
> Adam

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

  Minor formating fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10166/files
  - new: https://git.openjdk.org/jdk/pull/10166/files/30c34b6a..c6821bcb

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

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

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

From dfuchs at openjdk.org  Tue Sep  6 09:52:46 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 6 Sep 2022 09:52:46 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v7]
In-Reply-To: <4IrMrIGz101qsBIjluHA8uVrsckxMfxDL70NqQpIog8=.9b9c202f-9973-4958-9dd5-91f4aa9f1bb6@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <iQc17-mZLZe0P2Kc41ZYd4vZDjG4CYV-XDORMUpOo1M=.27d01189-50a8-4c32-916f-2e4d6c1f521d@github.com>
 <EjqSwyshh75YtKji43w2BJQABwZhJfHH03U_eDauvnY=.fb06ab80-69fd-4c1b-88b4-3c1698fd96b4@github.com>
 <4IrMrIGz101qsBIjluHA8uVrsckxMfxDL70NqQpIog8=.9b9c202f-9973-4958-9dd5-91f4aa9f1bb6@github.com>
Message-ID: <kowFc6D23a5547qelVDqTWo6LrHKS6ynU4-4lsxPZHM=.a24e0770-d74e-4d7b-a7e6-636c45669d2d@github.com>

On Tue, 6 Sep 2022 07:55:55 GMT, Markus KARG <duke at openjdk.org> wrote:

>> test/lib/jdk/test/lib/hexdump/HexPrinter.java line 1194:
>> 
>>> 1192:             byteOffset += size;
>>> 1193:             return size;
>>> 1194:         }
>> 
>> This is an indication that overriding `transferTo()` in `BufferedInputStream` has potential compatibility impacts on its subclasses. Therefore I would suggest adding a check in `BufferedInputStream::transferTo` to only override the behavior if not subclassed. Something like:
>> 
>> 
>>      if (this.getClass() != BufferedInputStream.class) {
>>          // a custom subclass may have expectations on which
>>          // methods tansferTo() will call. Revert to super class
>>          // behavior for compatibility.
>>          return super.transferTo(out);
>>      }
>>      ... otherwise proceed with the new implementation ...
>> 
>> 
>> Then you can revert the changes in this test.
>
> I do not see that it makes much sense to add such a safety means before I am finished with the inspection of the subclasses. As you can see in this example, it was pretty easy to fix it, and there are only few such subclasses at all. So instead of preparing against possibly non-existing easyt-to-fix problems, I prefer fixing the actual problems. They can only occur inside of the JDK itself, as relying on any particular implementation inside of the JDK by non-JDK classes simply would be a complete programming fault and *must* get fixed.

It's a well known behavior that overriding the`read(...)` method is sufficient to implement subclass behavior. This will no longer be the case if `transferTo(...)` no longer calls `this.read(...)` as it used to. There are many undocumented behaviors that have been depended on over the year - and though I agree with the sentiment that it's not a good idea to depend on undocumented behavior, this is one that is long standing, and mostly legitimate, especially for those classes that were coded before `transferTo` was added to `InputStream`.

The issue here is that things would mostly work for those custom subclassed, up to the point where some unsuspecting code might call `transferTo`. This could lead to bugs that might become hard to diagnose, and of course would only be seen at runtime.
As a point of comparison, look at what [JEP 425](https://openjdk.org/jeps/425) did to change the locking in `BufferedInputStream` (see how the lock object is used/initialized).

How many classes of `BufferedInputStream` are there in the wild, outside of the JDK?
How many of them have custom behavior implemented in `read`, that would be broken if `transferTo` no longer called `this.read`?

If you're changing an observable behavior, you will need a CSR, you will need to evaluate the compatibility risk and justify it, you will need to write a Release Note to warn about the compatibility risk, so that custom implementations that have such a dependency can be changed to also override `transferTo`.

The main question is whether the advantage of changing the behavior outweigh the risk of regression it might cause in subclasses. Such might be the case - or not.
The middle ground - and safer path - is to override the behaviour only for the base class and those subclasses that do not depend on the default behavior as was done by JEP 425...

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

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

From duke at openjdk.org  Tue Sep  6 11:29:46 2022
From: duke at openjdk.org (Markus KARG)
Date: Tue, 6 Sep 2022 11:29:46 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v7]
In-Reply-To: <kowFc6D23a5547qelVDqTWo6LrHKS6ynU4-4lsxPZHM=.a24e0770-d74e-4d7b-a7e6-636c45669d2d@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <iQc17-mZLZe0P2Kc41ZYd4vZDjG4CYV-XDORMUpOo1M=.27d01189-50a8-4c32-916f-2e4d6c1f521d@github.com>
 <EjqSwyshh75YtKji43w2BJQABwZhJfHH03U_eDauvnY=.fb06ab80-69fd-4c1b-88b4-3c1698fd96b4@github.com>
 <4IrMrIGz101qsBIjluHA8uVrsckxMfxDL70NqQpIog8=.9b9c202f-9973-4958-9dd5-91f4aa9f1bb6@github.com>
 <kowFc6D23a5547qelVDqTWo6LrHKS6ynU4-4lsxPZHM=.a24e0770-d74e-4d7b-a7e6-636c45669d2d@github.com>
Message-ID: <Uz5Q_zmsxgcIBvimEB7eHVmvrvve-2KIMTPnlxqesog=.e5b35f03-d79e-4fe8-a172-e793c9150a26@github.com>

On Tue, 6 Sep 2022 09:49:16 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> It's a well known behavior that overriding the`read(...)` method is sufficient to implement subclass behavior. This will no longer be the case if `transferTo(...)` no longer calls `this.read(...)` as it used to. There are many undocumented behaviors that have been depended on over the year - and though I agree with the sentiment that it's not a good idea to depend on undocumented behavior, this is one that is long standing, and mostly legitimate, especially for those classes that were coded before `transferTo` was added to `InputStream`.
> 
> The issue here is that things would mostly work for those custom subclassed, up to the point where some unsuspecting code might call `transferTo`. This could lead to bugs that might become hard to diagnose, and of course would only be seen at runtime. As a point of comparison, look at what [JEP 425](https://openjdk.org/jeps/425) did to change the locking in `BufferedInputStream` (see how the lock object is used/initialized).
> 
> How many classes of `BufferedInputStream` are there in the wild, outside of the JDK? How many of them have custom behavior implemented in `read`, that would be broken if `transferTo` no longer called `this.read`?
> 
> If you're changing an observable behavior, you will need a CSR, you will need to evaluate the compatibility risk and justify it, you will need to write a Release Note to warn about the compatibility risk, so that custom implementations that have such a dependency can be changed to also override `transferTo`.
> 
> The main question is whether the advantage of changing the behavior outweigh the risk of regression it might cause in subclasses. Such might be the case - or not. The middle ground - and safer path - is to override the behaviour only for the base class and those subclasses that do not depend on the default behavior as was done by JEP 425...

I understand your claim but disagree with the conclusion. You could impose it to *any* behavior change of *any* class -- this is no special case here. I do not see that we need a CSR as I do not change the *documented* behavior (neither the JavaDoc nor the Spec). Also I need to ask back: Do you *really* assume there are such lots of people using `transferTo` with failing subclasses of BIS? I doubt that, actually. You try to fix things possible not broken at all. We should concentrate on facts, not on assumptions, IMHO.

Having said that, I leave it up to @AlanBateman to decide, as I have no strong feelings about the issue you raised.

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

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

From dfuchs at openjdk.org  Tue Sep  6 12:13:44 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 6 Sep 2022 12:13:44 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v7]
In-Reply-To: <Uz5Q_zmsxgcIBvimEB7eHVmvrvve-2KIMTPnlxqesog=.e5b35f03-d79e-4fe8-a172-e793c9150a26@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <iQc17-mZLZe0P2Kc41ZYd4vZDjG4CYV-XDORMUpOo1M=.27d01189-50a8-4c32-916f-2e4d6c1f521d@github.com>
 <EjqSwyshh75YtKji43w2BJQABwZhJfHH03U_eDauvnY=.fb06ab80-69fd-4c1b-88b4-3c1698fd96b4@github.com>
 <4IrMrIGz101qsBIjluHA8uVrsckxMfxDL70NqQpIog8=.9b9c202f-9973-4958-9dd5-91f4aa9f1bb6@github.com>
 <kowFc6D23a5547qelVDqTWo6LrHKS6ynU4-4lsxPZHM=.a24e0770-d74e-4d7b-a7e6-636c45669d2d@github.com>
 <Uz5Q_zmsxgcIBvimEB7eHVmvrvve-2KIMTPnlxqesog=.e5b35f03-d79e-4fe8-a172-e793c9150a26@github.com>
Message-ID: <CoGNeHzyxu1CYND-HWkTueOsLkPYDCnGhhwGfY7s6zo=.759ef08a-48f4-4b58-bc19-1ee2407ee8dc@github.com>

On Tue, 6 Sep 2022 11:26:18 GMT, Markus KARG <duke at openjdk.org> wrote:

>> It's a well known behavior that overriding the`read(...)` method is sufficient to implement subclass behavior. This will no longer be the case if `transferTo(...)` no longer calls `this.read(...)` as it used to. There are many undocumented behaviors that have been depended on over the year - and though I agree with the sentiment that it's not a good idea to depend on undocumented behavior, this is one that is long standing, and mostly legitimate, especially for those classes that were coded before `transferTo` was added to `InputStream`.
>> 
>> The issue here is that things would mostly work for those custom subclassed, up to the point where some unsuspecting code might call `transferTo`. This could lead to bugs that might become hard to diagnose, and of course would only be seen at runtime.
>> As a point of comparison, look at what [JEP 425](https://openjdk.org/jeps/425) did to change the locking in `BufferedInputStream` (see how the lock object is used/initialized).
>> 
>> How many classes of `BufferedInputStream` are there in the wild, outside of the JDK?
>> How many of them have custom behavior implemented in `read`, that would be broken if `transferTo` no longer called `this.read`?
>> 
>> If you're changing an observable behavior, you will need a CSR, you will need to evaluate the compatibility risk and justify it, you will need to write a Release Note to warn about the compatibility risk, so that custom implementations that have such a dependency can be changed to also override `transferTo`.
>> 
>> The main question is whether the advantage of changing the behavior outweigh the risk of regression it might cause in subclasses. Such might be the case - or not.
>> The middle ground - and safer path - is to override the behaviour only for the base class and those subclasses that do not depend on the default behavior as was done by JEP 425...
>
>> It's a well known behavior that overriding the`read(...)` method is sufficient to implement subclass behavior. This will no longer be the case if `transferTo(...)` no longer calls `this.read(...)` as it used to. There are many undocumented behaviors that have been depended on over the year - and though I agree with the sentiment that it's not a good idea to depend on undocumented behavior, this is one that is long standing, and mostly legitimate, especially for those classes that were coded before `transferTo` was added to `InputStream`.
>> 
>> The issue here is that things would mostly work for those custom subclassed, up to the point where some unsuspecting code might call `transferTo`. This could lead to bugs that might become hard to diagnose, and of course would only be seen at runtime. As a point of comparison, look at what [JEP 425](https://openjdk.org/jeps/425) did to change the locking in `BufferedInputStream` (see how the lock object is used/initialized).
>> 
>> How many classes of `BufferedInputStream` are there in the wild, outside of the JDK? How many of them have custom behavior implemented in `read`, that would be broken if `transferTo` no longer called `this.read`?
>> 
>> If you're changing an observable behavior, you will need a CSR, you will need to evaluate the compatibility risk and justify it, you will need to write a Release Note to warn about the compatibility risk, so that custom implementations that have such a dependency can be changed to also override `transferTo`.
>> 
>> The main question is whether the advantage of changing the behavior outweigh the risk of regression it might cause in subclasses. Such might be the case - or not. The middle ground - and safer path - is to override the behaviour only for the base class and those subclasses that do not depend on the default behavior as was done by JEP 425...
> 
> I understand your claim but disagree with the conclusion. You could impose it to *any* behavior change of *any* class -- this is no special case here. I do not see that we need a CSR as I do not change the *documented* behavior (neither the JavaDoc nor the Spec). Also I need to ask back: Do you *really* assume there are such lots of people using `transferTo` with failing subclasses of BIS? I doubt that, actually. You try to fix things possible not broken at all. We should concentrate on facts, not on assumptions, IMHO.
> 
> BTW, even *if* we would add the safety net you proposed, the existing code would be wrong *still*, so we should *not* undo the fixed test, and we still should fix the JDK-internal BIS subclasses. It is no good idea to keep the bad code smell for longer, just because there is a safety net in the superclass. One fine day that safety net will break, and nobody would remember this PR discussion...
> 
> Having said that, I leave it up to @AlanBateman to decide, as I have no strong feelings about the issue you raised.

With the changes you proposed a CSR will definitely be needed.

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

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

From alanb at openjdk.org  Tue Sep  6 12:16:47 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 Sep 2022 12:16:47 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v7]
In-Reply-To: <CoGNeHzyxu1CYND-HWkTueOsLkPYDCnGhhwGfY7s6zo=.759ef08a-48f4-4b58-bc19-1ee2407ee8dc@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <iQc17-mZLZe0P2Kc41ZYd4vZDjG4CYV-XDORMUpOo1M=.27d01189-50a8-4c32-916f-2e4d6c1f521d@github.com>
 <EjqSwyshh75YtKji43w2BJQABwZhJfHH03U_eDauvnY=.fb06ab80-69fd-4c1b-88b4-3c1698fd96b4@github.com>
 <4IrMrIGz101qsBIjluHA8uVrsckxMfxDL70NqQpIog8=.9b9c202f-9973-4958-9dd5-91f4aa9f1bb6@github.com>
 <kowFc6D23a5547qelVDqTWo6LrHKS6ynU4-4lsxPZHM=.a24e0770-d74e-4d7b-a7e6-636c45669d2d@github.com>
 <Uz5Q_zmsxgcIBvimEB7eHVmvrvve-2KIMTPnlxqesog=.e5b35f03-d79e-4fe8-a172-e793c9150a26@github.com>
 <CoGNeHzyxu1CYND-HWkTueOsLkPYDCnGhhwGfY7s6zo=.759ef08a-48f4-4b58-bc19-1ee2407ee8dc@github.com>
Message-ID: <dFY1n2zzS_pwhoDplPeIYajN5BU3A2T8_lFXi9xCEoA=.04b52714-72c8-4d6b-8d75-dae6acc4dbd7@github.com>

On Tue, 6 Sep 2022 12:10:00 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>>> It's a well known behavior that overriding the`read(...)` method is sufficient to implement subclass behavior. This will no longer be the case if `transferTo(...)` no longer calls `this.read(...)` as it used to. There are many undocumented behaviors that have been depended on over the year - and though I agree with the sentiment that it's not a good idea to depend on undocumented behavior, this is one that is long standing, and mostly legitimate, especially for those classes that were coded before `transferTo` was added to `InputStream`.
>>> 
>>> The issue here is that things would mostly work for those custom subclassed, up to the point where some unsuspecting code might call `transferTo`. This could lead to bugs that might become hard to diagnose, and of course would only be seen at runtime. As a point of comparison, look at what [JEP 425](https://openjdk.org/jeps/425) did to change the locking in `BufferedInputStream` (see how the lock object is used/initialized).
>>> 
>>> How many classes of `BufferedInputStream` are there in the wild, outside of the JDK? How many of them have custom behavior implemented in `read`, that would be broken if `transferTo` no longer called `this.read`?
>>> 
>>> If you're changing an observable behavior, you will need a CSR, you will need to evaluate the compatibility risk and justify it, you will need to write a Release Note to warn about the compatibility risk, so that custom implementations that have such a dependency can be changed to also override `transferTo`.
>>> 
>>> The main question is whether the advantage of changing the behavior outweigh the risk of regression it might cause in subclasses. Such might be the case - or not. The middle ground - and safer path - is to override the behaviour only for the base class and those subclasses that do not depend on the default behavior as was done by JEP 425...
>> 
>> I understand your claim but disagree with the conclusion. You could impose it to *any* behavior change of *any* class -- this is no special case here. I do not see that we need a CSR as I do not change the *documented* behavior (neither the JavaDoc nor the Spec). Also I need to ask back: Do you *really* assume there are such lots of people using `transferTo` with failing subclasses of BIS? I doubt that, actually. You try to fix things possible not broken at all. We should concentrate on facts, not on assumptions, IMHO.
>> 
>> BTW, even *if* we would add the safety net you proposed, the existing code would be wrong *still*, so we should *not* undo the fixed test, and we still should fix the JDK-internal BIS subclasses. It is no good idea to keep the bad code smell for longer, just because there is a safety net in the superclass. One fine day that safety net will break, and nobody would remember this PR discussion...
>> 
>> Having said that, I leave it up to @AlanBateman to decide, as I have no strong feelings about the issue you raised.
>
> With the changes you proposed a CSR will definitely be needed.

BIS dates from JDK 1.0 and it's not hard to find examples that extend it. The HexPrinter test reminds us that it has been possible for 25+ years to override the read methods and snoop on all bytes that are read. Adding an override of the transferTo method that bypasses the read methods might break these subclasses. So I think Daniel is right that we have to be cautious.

So I think the feedback that you have now is that bypassing the buffer is problematic when using mark, when there are buffered bytes, or when BIS has been extended. It may be that the starting point is something very conservative like this:


    @Override
    public long transferTo(OutputStream out) throws IOException {
        if (getClass() == BufferedInputStream.class
                && ((count - pos) <= 0) && (markpos == -1)) {
            return getInIfOpen().transferTo(out);
        } else {
            return super.transferTo(out);
        }
    }


There is also the issue of locking and async close to look into.

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

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

From asotona at openjdk.org  Tue Sep  6 12:19:48 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 6 Sep 2022 12:19:48 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v3]
In-Reply-To: <MHUPVdtqnKJo50BP3ByLUKLPHa49SbTt8lkZjrmtvHM=.35ee2523-330a-4747-925a-c79117d5adef@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
 <nVWcamwX-PTcahYaIcHpHGoo2a5ItBrVNW9ImSd5RvM=.214ebaf8-ad2d-4348-8acc-b74d4e03f175@github.com>
 <MHUPVdtqnKJo50BP3ByLUKLPHa49SbTt8lkZjrmtvHM=.35ee2523-330a-4747-925a-c79117d5adef@github.com>
Message-ID: <w8DmLqW4p8GTY1WTT7YQ8kEsTKjW24ZLA6xMNhUr8Jw=.794f348f-0f27-4949-a0ac-3079c26f542c@github.com>

On Tue, 6 Sep 2022 08:06:13 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - allStop field and stopCheck method moved to synthetic REPL.$Cancel$
>>  - Revert "alternative implementation where instrumented code is directly checking Thread::interrupted"
>>    
>>    This reverts commit 0f0e0dd17c121955e7806073bb8cc78da1f133ea.
>
> src/jdk.jshell/share/classes/jdk/jshell/execution/LocalExecutionControl.java line 119:
> 
>> 117:     protected String invoke(Method doitMethod) throws Exception {
>> 118:         if (allStop == null) {
>> 119:             super.load(new ClassBytecodes[]{genCancelClass()});
> 
> fomatting: usually, people use spaces like this
> 
>   new ClassBytecodes[] {  genCancelClass()  }

Fixed, thanks

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

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

From asotona at openjdk.org  Tue Sep  6 12:25:24 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 6 Sep 2022 12:25:24 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v15]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <b5mMEanymucbX0tCOED4m3GZJ9hOrDP_RsxQWl4s-hc=.3330a4a4-d1bc-4286-9edf-1c9c7f7fee7f@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> 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 19 commits:

 - Merge branch 'openjdk:master' into JDK-8244681
 - re-enabled lossy conversions warnings for java.security.jgss, jdk.crypto.ec and jdk.internal.le
 - Merge branch 'openjdk:master' into JDK-8244681
 - Merge branch 'openjdk:master' into JDK-8244681
 - Merge branch 'openjdk:master' into JDK-8244681
 - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module
 - Added man-page line about lossy-conversion lint
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   re-enabled warnings for java.base, java.rmi and java.smartcardio
 - Merge branch 'openjdk:master' into JDK-8244681
 - ... and 9 more: https://git.openjdk.org/jdk/compare/6a1e98cb...4a7ce942

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

Changes: https://git.openjdk.org/jdk/pull/8599/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=14
  Stats: 439 lines in 14 files changed: 437 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8599/head:pull/8599

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

From asotona at openjdk.org  Tue Sep  6 12:26:02 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 6 Sep 2022 12:26:02 GMT
Subject: RFR: 8278863: Add method ClassDesc::ofInternalName [v5]
In-Reply-To: <3WrKiVDNyaAvxuxpWsaiY7FZT_W5WDftJdwUENnqQc0=.518b7bea-2c44-45de-8832-203819529b27@github.com>
References: <3WrKiVDNyaAvxuxpWsaiY7FZT_W5WDftJdwUENnqQc0=.518b7bea-2c44-45de-8832-203819529b27@github.com>
Message-ID: <leBzXMqEyxYBh5zfPeTWEzvPV6k4WvwoT3eq-qn1GB4=.95845295-5e44-4a50-902d-c157bc450946@github.com>

> The symbolic constants API (`java.lang.constant`) was designed, in part, to provide bytecode parsing and generation APIs with a validated, common, symbolic form for constants in Java class files. 
> 
> There is an easy way to create a `ClassDesc` from a binary name (`ClassDesc::of`) or a field descriptor (`ClassDesc::ofDescriptor`) but not from an internal name. But, the internal name is common in low-level bytecode-manipulation code. 
> 
> This patch adds `ClassDesc::ofInternalName` static factory method that creates a `ClassDesc` from class internal name.
> Class internal name validation and extended ClassDescTest are also parts of this patch.
> 
> CSR is linked with the issue.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona 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 'openjdk:master' into JDK-8278863
 - extended ClassDescTest
 - updated ClassDesc::ofInternal javadoc with JVMS link and fixed indentation
 - Update test/jdk/java/lang/constant/ClassDescTest.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - 8278863: Add method ClassDesc::ofInternalName

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9201/files
  - new: https://git.openjdk.org/jdk/pull/9201/files/f422b655..b25351c1

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

  Stats: 276762 lines in 4815 files changed: 142585 ins; 90657 del; 43520 mod
  Patch: https://git.openjdk.org/jdk/pull/9201.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9201/head:pull/9201

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

From duke at openjdk.org  Tue Sep  6 12:34:46 2022
From: duke at openjdk.org (Markus KARG)
Date: Tue, 6 Sep 2022 12:34:46 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v7]
In-Reply-To: <dFY1n2zzS_pwhoDplPeIYajN5BU3A2T8_lFXi9xCEoA=.04b52714-72c8-4d6b-8d75-dae6acc4dbd7@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <iQc17-mZLZe0P2Kc41ZYd4vZDjG4CYV-XDORMUpOo1M=.27d01189-50a8-4c32-916f-2e4d6c1f521d@github.com>
 <EjqSwyshh75YtKji43w2BJQABwZhJfHH03U_eDauvnY=.fb06ab80-69fd-4c1b-88b4-3c1698fd96b4@github.com>
 <4IrMrIGz101qsBIjluHA8uVrsckxMfxDL70NqQpIog8=.9b9c202f-9973-4958-9dd5-91f4aa9f1bb6@github.com>
 <kowFc6D23a5547qelVDqTWo6LrHKS6ynU4-4lsxPZHM=.a24e0770-d74e-4d7b-a7e6-636c45669d2d@github.com>
 <Uz5Q_zmsxgcIBvimEB7eHVmvrvve-2KIMTPnlxqesog=.e5b35f03-d79e-4fe8-a172-e793c9150a26@github.com>
 <CoGNeHzyxu1CYND-HWkTueOsLkPYDCnGhhwGfY7s6zo=.759ef08a-48f4-4b58-bc19-1ee2407ee8dc@github.com>
 <dFY1n2zzS_pwhoDplPeIYajN5BU3A2T8_lFXi9xCEoA=.04b52714-72c8-4d6b-8d75-dae6acc4dbd7@github.com>
Message-ID: <vh4AHBezdlier713UP4M76M5qXvr3bC_pvK8ozrhKNE=.30a19c38-a188-47b4-a45c-5b1f7ea6be7f@github.com>

On Tue, 6 Sep 2022 12:14:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> With the changes you proposed a CSR will definitely be needed.
>
> BIS dates from JDK 1.0 and it's not hard to find examples that extend it. The HexPrinter test reminds us that it has been possible for 25+ years to override the read methods and snoop on all bytes that are read. Adding an override of the transferTo method that bypasses the read methods might break these subclasses. So I think Daniel is right that we have to be cautious.
> 
> So I think the feedback that you have now is that bypassing the buffer is problematic when using mark, when there are buffered bytes, or when BIS has been extended. It may be that the starting point is something very conservative like this:
> 
> 
>     @Override
>     public long transferTo(OutputStream out) throws IOException {
>         if (getClass() == BufferedInputStream.class
>                 && ((count - pos) <= 0) && (markpos == -1)) {
>             return getInIfOpen().transferTo(out);
>         } else {
>             return super.transferTo(out);
>         }
>     }
> 
> 
> There is also the issue of locking and async close to look into.

Thank you for your decision about this issue, so instead of fixing the existing bugs I will implement as you outlined.

BTW, locking and rebasing is on the way.

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

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

From duke at openjdk.org  Tue Sep  6 12:50:50 2022
From: duke at openjdk.org (Markus KARG)
Date: Tue, 6 Sep 2022 12:50:50 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v8]
In-Reply-To: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
Message-ID: <AW23TcDAk3zincTif6LZpUHNqKDsMqdSHGnd071YzYA=.7e44d075-c0d9-48ce-912f-f44008d48551@github.com>

> Implementation of JDK-8279283

Markus KARG has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - proposal by Alan Bateman
 - modified locking
 - HexPrinter::transferTo
 - using getBufIfOpen() instead of direct buf access
 - fixed missing BufferedInputStream
 - removed unused code
 - test for BufferedInputStream.transferTo
 - synchronized BufferedInputStream::transferTo
 - BufferedInputStream::transferTo

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

Changes: https://git.openjdk.org/jdk/pull/6935/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=6935&range=07
  Stats: 240 lines in 3 files changed: 240 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/6935.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/6935/head:pull/6935

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

From duke at openjdk.org  Tue Sep  6 13:04:42 2022
From: duke at openjdk.org (Markus KARG)
Date: Tue, 6 Sep 2022 13:04:42 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v7]
In-Reply-To: <vh4AHBezdlier713UP4M76M5qXvr3bC_pvK8ozrhKNE=.30a19c38-a188-47b4-a45c-5b1f7ea6be7f@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <iQc17-mZLZe0P2Kc41ZYd4vZDjG4CYV-XDORMUpOo1M=.27d01189-50a8-4c32-916f-2e4d6c1f521d@github.com>
 <EjqSwyshh75YtKji43w2BJQABwZhJfHH03U_eDauvnY=.fb06ab80-69fd-4c1b-88b4-3c1698fd96b4@github.com>
 <4IrMrIGz101qsBIjluHA8uVrsckxMfxDL70NqQpIog8=.9b9c202f-9973-4958-9dd5-91f4aa9f1bb6@github.com>
 <kowFc6D23a5547qelVDqTWo6LrHKS6ynU4-4lsxPZHM=.a24e0770-d74e-4d7b-a7e6-636c45669d2d@github.com>
 <Uz5Q_zmsxgcIBvimEB7eHVmvrvve-2KIMTPnlxqesog=.e5b35f03-d79e-4fe8-a172-e793c9150a26@github.com>
 <CoGNeHzyxu1CYND-HWkTueOsLkPYDCnGhhwGfY7s6zo=.759ef08a-48f4-4b58-bc19-1ee2407ee8dc@github.com>
 <dFY1n2zzS_pwhoDplPeIYajN5BU3A2T8_lFXi9xCEoA=.04b52714-72c8-4d6b-8d75-dae6acc4dbd7@github.com>
 <vh4AHBezdlier713UP4M76M5qXvr3bC_pvK8ozrhKNE=.30a19c38-a188-47b4-a45c-5b1f7ea6be7f@github.com>
Message-ID: <uDTp24Vz2n6H0gekHVb4H2Q9dmav5d6vcfhj-sQ9p3Q=.ef02d338-f9c0-40ad-99b0-6cbb6b91e325@github.com>

On Tue, 6 Sep 2022 12:32:46 GMT, Markus KARG <duke at openjdk.org> wrote:

>> BIS dates from JDK 1.0 and it's not hard to find examples that extend it. The HexPrinter test reminds us that it has been possible for 25+ years to override the read methods and snoop on all bytes that are read. Adding an override of the transferTo method that bypasses the read methods might break these subclasses. So I think Daniel is right that we have to be cautious.
>> 
>> So I think the feedback that you have now is that bypassing the buffer is problematic when using mark, when there are buffered bytes, or when BIS has been extended. It may be that the starting point is something very conservative like this:
>> 
>> 
>>     @Override
>>     public long transferTo(OutputStream out) throws IOException {
>>         if (getClass() == BufferedInputStream.class
>>                 && ((count - pos) <= 0) && (markpos == -1)) {
>>             return getInIfOpen().transferTo(out);
>>         } else {
>>             return super.transferTo(out);
>>         }
>>     }
>> 
>> 
>> There is also the issue of locking and async close to look into.
>
> Thank you for your decision about this issue, so instead of fixing the existing bugs I will implement as you outlined.
> 
> BTW, locking and rebasing is on the way.

Rebased and fixed locking, using your proposed code now.

@AlanBateman  Async close leaves BIS in an invalid state. The JavaDocs say ` The behavior for the case where the inputand/or output stream is asynchronously closed, or the thread interrupted during the transfer, is highly input and output streamspecific, and therefore not specified.`. So there is seems to be no *essential* need to do something *particular* in that case (the caller cannot further use the BIS, just like after an IOE: `It is strongly recommended that both streams be promptly closed if an I/O error occurs.` -- which is what *I personally, as a user of BIS* would do after async close), but if you *want* that we reach a particular outcome, then just tell me what outcome you envision.

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

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

From duke at openjdk.org  Tue Sep  6 13:04:42 2022
From: duke at openjdk.org (Markus KARG)
Date: Tue, 6 Sep 2022 13:04:42 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v7]
In-Reply-To: <uDTp24Vz2n6H0gekHVb4H2Q9dmav5d6vcfhj-sQ9p3Q=.ef02d338-f9c0-40ad-99b0-6cbb6b91e325@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <iQc17-mZLZe0P2Kc41ZYd4vZDjG4CYV-XDORMUpOo1M=.27d01189-50a8-4c32-916f-2e4d6c1f521d@github.com>
 <EjqSwyshh75YtKji43w2BJQABwZhJfHH03U_eDauvnY=.fb06ab80-69fd-4c1b-88b4-3c1698fd96b4@github.com>
 <4IrMrIGz101qsBIjluHA8uVrsckxMfxDL70NqQpIog8=.9b9c202f-9973-4958-9dd5-91f4aa9f1bb6@github.com>
 <kowFc6D23a5547qelVDqTWo6LrHKS6ynU4-4lsxPZHM=.a24e0770-d74e-4d7b-a7e6-636c45669d2d@github.com>
 <Uz5Q_zmsxgcIBvimEB7eHVmvrvve-2KIMTPnlxqesog=.e5b35f03-d79e-4fe8-a172-e793c9150a26@github.com>
 <CoGNeHzyxu1CYND-HWkTueOsLkPYDCnGhhwGfY7s6zo=.759ef08a-48f4-4b58-bc19-1ee2407ee8dc@github.com>
 <dFY1n2zzS_pwhoDplPeIYajN5BU3A2T8_lFXi9xCEoA=.04b52714-72c8-4d6b-8d75-dae6acc4dbd7@github.com>
 <vh4AHBezdlier713UP4M76M5qXvr3bC_pvK8ozrhKNE=.30a19c38-a188-47b4-a45c-5b1f7ea6be7f@github.com>
 <uDTp24Vz2n6H0gekHVb4H2Q9dmav5d6vcfhj-sQ9p3Q=.ef02d338-f9c0-40ad-99b0-6cbb6b91e325@github.com>
Message-ID: <opnnc0yeSVnOhs5DF9-64YUjjUcZh_sEb184fET4x-A=.69f7ea41-b127-42ab-b6e0-cb6b320da694@github.com>

On Tue, 6 Sep 2022 12:56:46 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Thank you for your decision about this issue, so instead of fixing the existing bugs I will implement as you outlined.
>> 
>> BTW, locking and rebasing is on the way.
>
> Rebased and fixed locking, using your proposed code now.
> 
> @AlanBateman  Async close leaves BIS in an invalid state. The JavaDocs say ` The behavior for the case where the inputand/or output stream is asynchronously closed, or the thread interrupted during the transfer, is highly input and output streamspecific, and therefore not specified.`. So there is seems to be no *essential* need to do something *particular* in that case (the caller cannot further use the BIS, just like after an IOE: `It is strongly recommended that both streams be promptly closed if an I/O error occurs.` -- which is what *I personally, as a user of BIS* would do after async close), but if you *want* that we reach a particular outcome, then just tell me what outcome you envision.

> With the changes you proposed a CSR will definitely be needed.

@dfuch Just to learn about OpenJDK rules: Why? I always thought that CSR is only needed when breaking *documented* behavior. Do you have a link to the official rule that proofs your claim in *this* case (i. e. *non-documented* behavior)? Thanks! :-)

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

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

From duke at openjdk.org  Tue Sep  6 14:54:08 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 6 Sep 2022 14:54:08 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v8]
In-Reply-To: <AW23TcDAk3zincTif6LZpUHNqKDsMqdSHGnd071YzYA=.7e44d075-c0d9-48ce-912f-f44008d48551@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <AW23TcDAk3zincTif6LZpUHNqKDsMqdSHGnd071YzYA=.7e44d075-c0d9-48ce-912f-f44008d48551@github.com>
Message-ID: <VnaKBtiipTXJLw6gimv7E2wTsl3XHr3mUoZyM_rfG6o=.428fc2ac-b24a-4429-92f4-51af47875988@github.com>

On Tue, 6 Sep 2022 12:50:50 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Implementation of JDK-8279283
>
> Markus KARG has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - proposal by Alan Bateman
>  - modified locking
>  - HexPrinter::transferTo
>  - using getBufIfOpen() instead of direct buf access
>  - fixed missing BufferedInputStream
>  - removed unused code
>  - test for BufferedInputStream.transferTo
>  - synchronized BufferedInputStream::transferTo
>  - BufferedInputStream::transferTo

src/java.base/share/classes/java/io/BufferedInputStream.java line 608:

> 606:     private long implTransferTo(OutputStream out) throws IOException {
> 607:         if (getClass() == BufferedInputStream.class
> 608:                 && ((count - pos) <= 0) && (markpos == -1)) {

Tiny thing: I think with 3 `&&`s we don't need parenthesis around `((count - pos) <= 0) && (markpos == -1))`. How about to leave leave only the one around `count - pos`?

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

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

From dfuchs at openjdk.org  Tue Sep  6 15:38:45 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 6 Sep 2022 15:38:45 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v7]
In-Reply-To: <opnnc0yeSVnOhs5DF9-64YUjjUcZh_sEb184fET4x-A=.69f7ea41-b127-42ab-b6e0-cb6b320da694@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <iQc17-mZLZe0P2Kc41ZYd4vZDjG4CYV-XDORMUpOo1M=.27d01189-50a8-4c32-916f-2e4d6c1f521d@github.com>
 <EjqSwyshh75YtKji43w2BJQABwZhJfHH03U_eDauvnY=.fb06ab80-69fd-4c1b-88b4-3c1698fd96b4@github.com>
 <4IrMrIGz101qsBIjluHA8uVrsckxMfxDL70NqQpIog8=.9b9c202f-9973-4958-9dd5-91f4aa9f1bb6@github.com>
 <kowFc6D23a5547qelVDqTWo6LrHKS6ynU4-4lsxPZHM=.a24e0770-d74e-4d7b-a7e6-636c45669d2d@github.com>
 <Uz5Q_zmsxgcIBvimEB7eHVmvrvve-2KIMTPnlxqesog=.e5b35f03-d79e-4fe8-a172-e793c9150a26@github.com>
 <CoGNeHzyxu1CYND-HWkTueOsLkPYDCnGhhwGfY7s6zo=.759ef08a-48f4-4b58-bc19-1ee2407ee8dc@github.com>
 <dFY1n2zzS_pwhoDplPeIYajN5BU3A2T8_lFXi9xCEoA=.04b52714-72c8-4d6b-8d75-dae6acc4dbd7@github.com>
 <vh4AHBezdlier713UP4M76M5qXvr3bC_pvK8ozrhKNE=.30a19c38-a188-47b4-a45c-5b1f7ea6be7f@github.com>
 <uDTp24Vz2n6H0gekHVb4H2Q9dmav5d6vcfhj-sQ9p3Q=.ef02d338-f9c0-40ad-99b0-6cbb6b91e325@github.com>
 <opnnc0yeSVnOhs5DF9-64YUjjUcZh_sEb18
 4fET4x-A=.69f7ea41-b127-42ab-b6e0-cb6b320da694@github.com>
Message-ID: <G4Cd7rP5mKb81LArHFB-enBwfoCRcsRB1hQfIyihqEo=.8e4475ed-f197-4776-b899-f37a319705c9@github.com>

On Tue, 6 Sep 2022 13:00:23 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Rebased and fixed locking, using your proposed code now.
>> 
>> @AlanBateman  Async close leaves BIS in an invalid state. The JavaDocs say ` The behavior for the case where the inputand/or output stream is asynchronously closed, or the thread interrupted during the transfer, is highly input and output streamspecific, and therefore not specified.`. So there is seems to be no *essential* need to do something *particular* in that case (the caller cannot further use the BIS, just like after an IOE: `It is strongly recommended that both streams be promptly closed if an I/O error occurs.` -- which is what *I personally, as a user of BIS* would do after async close), but if you *want* that we reach a particular outcome, then just tell me what outcome you envision.
>
>> With the changes you proposed a CSR will definitely be needed.
> 
> @dfuch Just to learn about OpenJDK rules: Why? I always thought that CSR is only needed when breaking *documented* behavior. Do you have a link to the official rule that proofs your claim in *this* case (i. e. *non-documented* behavior)? Thanks! :-)

Hi Markus, It's a good idea to write a CSR if your change modifies an observable behavior that users of the public API (including custom subclasses) might be depending on. This is both to raise the awareness on the impact of the change, document the possible regression risks, and get feedback from the CSR committee who might suggest mitigating actions to reduce the risk (such as e.g: adding a property to make it possible to revert to the old behavior, write a release note, etc...). In the case at hand `BufferedInputStream` is a very old class that has been used and abused all over the board in the java ecosystem. So writing a CSR to document a change in behavior that some subclasses may be depending on would be the proper thing to do, when changing that behaviour. The fact that you have found such a subclass (with a legitimate use case) only strengthen the need for exercising such care.
In retrospect it would have been much better if `BufferedInputStream` had been declared final - but it's much too late for that now. Thanks!

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

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

From ysatowse at openjdk.org  Tue Sep  6 16:09:09 2022
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Tue, 6 Sep 2022 16:09:09 GMT
Subject: Integrated: 8292579: (tz) Update Timezone Data to 2022c
In-Reply-To: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
References: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
Message-ID: <LxIbeC8-1Fw2dEtmteVCuXd3rq0cL438YQ-gVdbLPJE=.7f590598-e12b-4d2b-a154-8253f0b7e081@github.com>

On Thu, 25 Aug 2022 02:26:19 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  The PR adopts the official tzdata2022c as it is.
> It means the pre-1970s data merged in tzdata2022c doesn't exist.
> All tests have been passed with no failures.

This pull request has now been integrated.

Changeset: 98d85e6f
Author:    Yoshiki Sato <ysatowse at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/98d85e6f594bf34b97407c470b14791af0a2bc53
Stats:     1021 lines in 15 files changed: 256 ins; 613 del; 152 mod

8292579: (tz) Update Timezone Data to 2022c

Reviewed-by: naoto, alanb

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

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

From alanb at openjdk.org  Tue Sep  6 16:31:49 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 Sep 2022 16:31:49 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v7]
In-Reply-To: <dFY1n2zzS_pwhoDplPeIYajN5BU3A2T8_lFXi9xCEoA=.04b52714-72c8-4d6b-8d75-dae6acc4dbd7@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <iQc17-mZLZe0P2Kc41ZYd4vZDjG4CYV-XDORMUpOo1M=.27d01189-50a8-4c32-916f-2e4d6c1f521d@github.com>
 <EjqSwyshh75YtKji43w2BJQABwZhJfHH03U_eDauvnY=.fb06ab80-69fd-4c1b-88b4-3c1698fd96b4@github.com>
 <4IrMrIGz101qsBIjluHA8uVrsckxMfxDL70NqQpIog8=.9b9c202f-9973-4958-9dd5-91f4aa9f1bb6@github.com>
 <kowFc6D23a5547qelVDqTWo6LrHKS6ynU4-4lsxPZHM=.a24e0770-d74e-4d7b-a7e6-636c45669d2d@github.com>
 <Uz5Q_zmsxgcIBvimEB7eHVmvrvve-2KIMTPnlxqesog=.e5b35f03-d79e-4fe8-a172-e793c9150a26@github.com>
 <CoGNeHzyxu1CYND-HWkTueOsLkPYDCnGhhwGfY7s6zo=.759ef08a-48f4-4b58-bc19-1ee2407ee8dc@github.com>
 <dFY1n2zzS_pwhoDplPeIYajN5BU3A2T8_lFXi9xCEoA=.04b52714-72c8-4d6b-8d75-dae6acc4dbd7@github.com>
Message-ID: <_nsxM8jRpfTC4Ap2BDnf4qgGj07syWVIrOp5c7UsWFQ=.a982a387-b97f-4020-9c17-da6357c2ab48@github.com>

On Tue, 6 Sep 2022 12:14:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> With the changes you proposed a CSR will definitely be needed.
>
> BIS dates from JDK 1.0 and it's not hard to find examples that extend it. The HexPrinter test reminds us that it has been possible for 25+ years to override the read methods and snoop on all bytes that are read. Adding an override of the transferTo method that bypasses the read methods might break these subclasses. So I think Daniel is right that we have to be cautious.
> 
> So I think the feedback that you have now is that bypassing the buffer is problematic when using mark, when there are buffered bytes, or when BIS has been extended. It may be that the starting point is something very conservative like this:
> 
> 
>     @Override
>     public long transferTo(OutputStream out) throws IOException {
>         if (getClass() == BufferedInputStream.class
>                 && ((count - pos) <= 0) && (markpos == -1)) {
>             return getInIfOpen().transferTo(out);
>         } else {
>             return super.transferTo(out);
>         }
>     }
> 
> 
> There is also the issue of locking and async close to look into.

> @AlanBateman Async close leaves BIS in an invalid state. The JavaDocs say ` The behavior for the case where the input and/or output stream is asynchronously closed, or the thread interrupted during the transfer, is highly input and output stream specific, and therefore not specified.`. 

Yes, I believe I suggested that wording when the method was added. The java.io APIs mostly pre-date deep consideration of those topics.

I've looked at the update change to BIS in f2f9a904 and I think it's okay.

On the CSR topic and your messages with Daniel. On the CSR wiki pages then phrase to look for is "behavioral compatibility".  The "Kinds of Compatibility" has more details on the topic.

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

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

From iklam at openjdk.org  Tue Sep  6 16:50:42 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 6 Sep 2022 16:50:42 GMT
Subject: RFR: JDK-8292914: Introduce a system property that enables stable
 names for lambda classes
In-Reply-To: <pYF675FND8BK8SUHFnvstPMcoKTcW81zs7yGCli5Mxo=.aac8b180-6101-4320-aa73-7e640952afaf@github.com>
References: <pYF675FND8BK8SUHFnvstPMcoKTcW81zs7yGCli5Mxo=.aac8b180-6101-4320-aa73-7e640952afaf@github.com>
Message-ID: <yHc2sx--3vLcANEym5JWSCfHvsiLG1QyPgOoUmMhCgU=.940f943f-adb0-4568-9bde-74faec9c1703@github.com>

On Thu, 25 Aug 2022 14:32:06 GMT, Strahinja Stanojevic <duke at openjdk.org> wrote:

> This PR introduces a system property that creates stable names for the lambda classes in the JDK. Instead of using an atomic counter in the lambda name, we can use a 32-bit hash after `$$Lambda$`. Thus, the name becomes `lambdaCapturingClass$$Lambda$hashValue`.
> Parameters used to create a stable part of the name (hash value) are a superset of the parameters used for lambda class archiving when the CDS dumping option is enabled. During the stable name creation process,
> all the common parameters are in the same form as in the low-level implementation (C part of the code) of the archiving process.
> We concatenate all of those parameters in one string `hashData`. We calculate the long hash value for `hashData` in the same manner as the `java.lang.StringUTF16#hashCode` does, and then we hash that value using `Long.toString(longHashValue, Character.MAX_RADIX)`. The desired length for this hash is equal to the length of the `Long.toString(Long.MAX_VALUE, Character.MAX_RADIX)`.
> Sometimes, the calculated hash value is shorter than the desired length, so we pad it with the character `#` to hit it. Appending `#` only affects the hash length, but not its stability.
> 
> Link to the related issue: https://bugs.openjdk.org/browse/JDK-8292914

Have you tested with method references? Two references to the same method will result in a single `JVM_CONSTANT_InvokeDynamic` constant pool entry in the classfile, but it's invoked by two callsites. As a result, two different lambda proxy classes will be generated, as the JVMS requires the invokedynamic resolution to be per callsite, not per constantpool entry.


public class ShareBSM {
  public static void main(String args[]) {
    doit1(ShareBSM::func);
    doit2(ShareBSM::func);
  }
  static void func() {  Thread.dumpStack();  }
  static void doit1(Runnable r) {  r.run();  }
  static void doit2(Runnable r) {  r.run();  }
}


Here's the output:


$ java -cp . -XX:+UnlockDiagnosticVMOptions -XX:+ShowHiddenFrames ShareBSM
java.lang.Exception: Stack trace
	at java.base/java.lang.Thread.dumpStack(Thread.java:1380)
	at ShareBSM.func(ShareBSM.java:8)
	at ShareBSM$$Lambda$1/0x0000000800c009f0.run(Unknown Source)
	at ShareBSM.doit1(ShareBSM.java:12)
	at ShareBSM.main(ShareBSM.java:3)
java.lang.Exception: Stack trace
	at java.base/java.lang.Thread.dumpStack(Thread.java:1380)
	at ShareBSM.func(ShareBSM.java:8)
	at ShareBSM$$Lambda$2/0x0000000800c00bf8.run(Unknown Source)
	at ShareBSM.doit2(ShareBSM.java:15)
	at ShareBSM.main(ShareBSM.java:4)


Will you patch generate the same name for both callsites? Does this matter for your use case?

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

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

From duke at openjdk.org  Tue Sep  6 16:59:16 2022
From: duke at openjdk.org (Markus KARG)
Date: Tue, 6 Sep 2022 16:59:16 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v8]
In-Reply-To: <VnaKBtiipTXJLw6gimv7E2wTsl3XHr3mUoZyM_rfG6o=.428fc2ac-b24a-4429-92f4-51af47875988@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <AW23TcDAk3zincTif6LZpUHNqKDsMqdSHGnd071YzYA=.7e44d075-c0d9-48ce-912f-f44008d48551@github.com>
 <VnaKBtiipTXJLw6gimv7E2wTsl3XHr3mUoZyM_rfG6o=.428fc2ac-b24a-4429-92f4-51af47875988@github.com>
Message-ID: <rGMhwW6uhKgFpTTwl_FbquLXHEosaC6MKQ4Ng0lL-1s=.f9afe591-af8c-4ea2-b74b-14e6e1c656f3@github.com>

On Tue, 6 Sep 2022 14:51:20 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> Markus KARG has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
>> 
>>  - proposal by Alan Bateman
>>  - modified locking
>>  - HexPrinter::transferTo
>>  - using getBufIfOpen() instead of direct buf access
>>  - fixed missing BufferedInputStream
>>  - removed unused code
>>  - test for BufferedInputStream.transferTo
>>  - synchronized BufferedInputStream::transferTo
>>  - BufferedInputStream::transferTo
>
> src/java.base/share/classes/java/io/BufferedInputStream.java line 608:
> 
>> 606:     private long implTransferTo(OutputStream out) throws IOException {
>> 607:         if (getClass() == BufferedInputStream.class
>> 608:                 && ((count - pos) <= 0) && (markpos == -1)) {
> 
> Tiny thing: I think with 3 `&&`s we don't need parenthesis around `((count - pos) <= 0) && (markpos == -1))`. How about to leave leave only the one around `count - pos`?

I was using the exact code proposed by @AlanBateman and I don't dare to touch it. ;-)

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

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

From duke at openjdk.org  Tue Sep  6 16:59:16 2022
From: duke at openjdk.org (Markus KARG)
Date: Tue, 6 Sep 2022 16:59:16 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v8]
In-Reply-To: <rGMhwW6uhKgFpTTwl_FbquLXHEosaC6MKQ4Ng0lL-1s=.f9afe591-af8c-4ea2-b74b-14e6e1c656f3@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <AW23TcDAk3zincTif6LZpUHNqKDsMqdSHGnd071YzYA=.7e44d075-c0d9-48ce-912f-f44008d48551@github.com>
 <VnaKBtiipTXJLw6gimv7E2wTsl3XHr3mUoZyM_rfG6o=.428fc2ac-b24a-4429-92f4-51af47875988@github.com>
 <rGMhwW6uhKgFpTTwl_FbquLXHEosaC6MKQ4Ng0lL-1s=.f9afe591-af8c-4ea2-b74b-14e6e1c656f3@github.com>
Message-ID: <cDL21EvrdvPN_7od3bu3UcTS1svCDm3Tz-buVRPb53g=.01beeb1c-dd79-46d4-b4c9-6b16889df490@github.com>

On Tue, 6 Sep 2022 16:56:03 GMT, Markus KARG <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/BufferedInputStream.java line 608:
>> 
>>> 606:     private long implTransferTo(OutputStream out) throws IOException {
>>> 607:         if (getClass() == BufferedInputStream.class
>>> 608:                 && ((count - pos) <= 0) && (markpos == -1)) {
>> 
>> Tiny thing: I think with 3 `&&`s we don't need parenthesis around `((count - pos) <= 0) && (markpos == -1))`. How about to leave leave only the one around `count - pos`?
>
> I was using the exact code proposed by @AlanBateman and I don't dare to touch it. ;-)

@AlanBateman Please decide. :-)

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

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

From duke at openjdk.org  Tue Sep  6 17:04:50 2022
From: duke at openjdk.org (Markus KARG)
Date: Tue, 6 Sep 2022 17:04:50 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v7]
In-Reply-To: <_nsxM8jRpfTC4Ap2BDnf4qgGj07syWVIrOp5c7UsWFQ=.a982a387-b97f-4020-9c17-da6357c2ab48@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <iQc17-mZLZe0P2Kc41ZYd4vZDjG4CYV-XDORMUpOo1M=.27d01189-50a8-4c32-916f-2e4d6c1f521d@github.com>
 <EjqSwyshh75YtKji43w2BJQABwZhJfHH03U_eDauvnY=.fb06ab80-69fd-4c1b-88b4-3c1698fd96b4@github.com>
 <4IrMrIGz101qsBIjluHA8uVrsckxMfxDL70NqQpIog8=.9b9c202f-9973-4958-9dd5-91f4aa9f1bb6@github.com>
 <kowFc6D23a5547qelVDqTWo6LrHKS6ynU4-4lsxPZHM=.a24e0770-d74e-4d7b-a7e6-636c45669d2d@github.com>
 <Uz5Q_zmsxgcIBvimEB7eHVmvrvve-2KIMTPnlxqesog=.e5b35f03-d79e-4fe8-a172-e793c9150a26@github.com>
 <CoGNeHzyxu1CYND-HWkTueOsLkPYDCnGhhwGfY7s6zo=.759ef08a-48f4-4b58-bc19-1ee2407ee8dc@github.com>
 <dFY1n2zzS_pwhoDplPeIYajN5BU3A2T8_lFXi9xCEoA=.04b52714-72c8-4d6b-8d75-dae6acc4dbd7@github.com>
 <_nsxM8jRpfTC4Ap2BDnf4qgGj07syWVIrOp5c7UsWFQ=.a982a387-b97f-4020-9c17-da6357c2ab48@github.com>
Message-ID: <voBG4m10RpjAfHA5RC_WSfPr3mkmg5wi2ipgJbI1_NM=.22a63472-c7f8-4237-9787-d84121d0e4a0@github.com>

On Tue, 6 Sep 2022 16:29:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> BIS dates from JDK 1.0 and it's not hard to find examples that extend it. The HexPrinter test reminds us that it has been possible for 25+ years to override the read methods and snoop on all bytes that are read. Adding an override of the transferTo method that bypasses the read methods might break these subclasses. So I think Daniel is right that we have to be cautious.
>> 
>> So I think the feedback that you have now is that bypassing the buffer is problematic when using mark, when there are buffered bytes, or when BIS has been extended. It may be that the starting point is something very conservative like this:
>> 
>> 
>>     @Override
>>     public long transferTo(OutputStream out) throws IOException {
>>         if (getClass() == BufferedInputStream.class
>>                 && ((count - pos) <= 0) && (markpos == -1)) {
>>             return getInIfOpen().transferTo(out);
>>         } else {
>>             return super.transferTo(out);
>>         }
>>     }
>> 
>> 
>> There is also the issue of locking and async close to look into.
>
>> @AlanBateman Async close leaves BIS in an invalid state. The JavaDocs say ` The behavior for the case where the input and/or output stream is asynchronously closed, or the thread interrupted during the transfer, is highly input and output stream specific, and therefore not specified.`. 
> 
> Yes, I believe I suggested that wording when the method was added. The java.io APIs mostly pre-date deep consideration of those topics.
> 
> I've looked at the update change to BIS in f2f9a904 and I think it's okay.
> 
> On the CSR topic and your messages with Daniel. On the CSR wiki pages then phrase to look for is "behavioral compatibility".  The "Kinds of Compatibility" has more details on the topic.

Thank you all for your kind help and feedback.

@AlanBateman So is now the time to switch this PR from Draft to Ready?

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

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

From dfuchs at openjdk.org  Tue Sep  6 17:13:47 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 6 Sep 2022 17:13:47 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v7]
In-Reply-To: <voBG4m10RpjAfHA5RC_WSfPr3mkmg5wi2ipgJbI1_NM=.22a63472-c7f8-4237-9787-d84121d0e4a0@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <iQc17-mZLZe0P2Kc41ZYd4vZDjG4CYV-XDORMUpOo1M=.27d01189-50a8-4c32-916f-2e4d6c1f521d@github.com>
 <EjqSwyshh75YtKji43w2BJQABwZhJfHH03U_eDauvnY=.fb06ab80-69fd-4c1b-88b4-3c1698fd96b4@github.com>
 <4IrMrIGz101qsBIjluHA8uVrsckxMfxDL70NqQpIog8=.9b9c202f-9973-4958-9dd5-91f4aa9f1bb6@github.com>
 <kowFc6D23a5547qelVDqTWo6LrHKS6ynU4-4lsxPZHM=.a24e0770-d74e-4d7b-a7e6-636c45669d2d@github.com>
 <Uz5Q_zmsxgcIBvimEB7eHVmvrvve-2KIMTPnlxqesog=.e5b35f03-d79e-4fe8-a172-e793c9150a26@github.com>
 <CoGNeHzyxu1CYND-HWkTueOsLkPYDCnGhhwGfY7s6zo=.759ef08a-48f4-4b58-bc19-1ee2407ee8dc@github.com>
 <dFY1n2zzS_pwhoDplPeIYajN5BU3A2T8_lFXi9xCEoA=.04b52714-72c8-4d6b-8d75-dae6acc4dbd7@github.com>
 <_nsxM8jRpfTC4Ap2BDnf4qgGj07syWVIrOp5c7UsWFQ=.a982a387-b97f-4020-9c17-da6357c2ab48@github.com>
 <voBG4m10RpjAfHA5RC_WSfPr3mkmg5wi2ipgJbI1_NM=.22a63472-c7f8-4237-9787-d84121d0e4a0@github.com>
Message-ID: <NyMhs43dogu2oFVjCESd8Dy2-zRYD8RvsNyQCgx5-UU=.31d22b3a-3f8c-4f6e-b2d5-c29a6cbbc545@github.com>

On Tue, 6 Sep 2022 17:01:09 GMT, Markus KARG <duke at openjdk.org> wrote:

>>> @AlanBateman Async close leaves BIS in an invalid state. The JavaDocs say ` The behavior for the case where the input and/or output stream is asynchronously closed, or the thread interrupted during the transfer, is highly input and output stream specific, and therefore not specified.`. 
>> 
>> Yes, I believe I suggested that wording when the method was added. The java.io APIs mostly pre-date deep consideration of those topics.
>> 
>> I've looked at the update change to BIS in f2f9a904 and I think it's okay.
>> 
>> On the CSR topic and your messages with Daniel. On the CSR wiki pages then phrase to look for is "behavioral compatibility".  The "Kinds of Compatibility" has more details on the topic.
>
> Thank you all for your kind help and feedback.
> 
> @AlanBateman So is now the time to switch this PR from Draft to Ready?

The source changes LGTM. I suppose you should now revert the changes above (in `HexPrinter.java`), otherwise the bytes will now be counted twice :-).
Which BTW shows that you would be depending on undocumented behavior whatever you do:
`transferTo` is not documented to call `this.read(...)`, but neither is it documented to **not call**  `this.read(...)`...  Hyrum's law wins here ;-)

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

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

From duke at openjdk.org  Tue Sep  6 17:20:22 2022
From: duke at openjdk.org (Markus KARG)
Date: Tue, 6 Sep 2022 17:20:22 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v9]
In-Reply-To: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
Message-ID: <jpjOzk7z0bfD2rIbg_yWGlW3IcaDJqKx2oL8vx9K3K8=.3cc44e7f-babe-46b6-ae6e-7d0581f3c100@github.com>

> Implementation of JDK-8279283

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

  Revert "HexPrinter::transferTo"
  
  This reverts commit 6f0e2a8f7be5706b39a8e9bc88a97f34d2819098.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/6935/files
  - new: https://git.openjdk.org/jdk/pull/6935/files/f2f9a904..b4d5004d

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

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

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

From duke at openjdk.org  Tue Sep  6 17:20:24 2022
From: duke at openjdk.org (Markus KARG)
Date: Tue, 6 Sep 2022 17:20:24 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v7]
In-Reply-To: <NyMhs43dogu2oFVjCESd8Dy2-zRYD8RvsNyQCgx5-UU=.31d22b3a-3f8c-4f6e-b2d5-c29a6cbbc545@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <iQc17-mZLZe0P2Kc41ZYd4vZDjG4CYV-XDORMUpOo1M=.27d01189-50a8-4c32-916f-2e4d6c1f521d@github.com>
 <EjqSwyshh75YtKji43w2BJQABwZhJfHH03U_eDauvnY=.fb06ab80-69fd-4c1b-88b4-3c1698fd96b4@github.com>
 <4IrMrIGz101qsBIjluHA8uVrsckxMfxDL70NqQpIog8=.9b9c202f-9973-4958-9dd5-91f4aa9f1bb6@github.com>
 <kowFc6D23a5547qelVDqTWo6LrHKS6ynU4-4lsxPZHM=.a24e0770-d74e-4d7b-a7e6-636c45669d2d@github.com>
 <Uz5Q_zmsxgcIBvimEB7eHVmvrvve-2KIMTPnlxqesog=.e5b35f03-d79e-4fe8-a172-e793c9150a26@github.com>
 <CoGNeHzyxu1CYND-HWkTueOsLkPYDCnGhhwGfY7s6zo=.759ef08a-48f4-4b58-bc19-1ee2407ee8dc@github.com>
 <dFY1n2zzS_pwhoDplPeIYajN5BU3A2T8_lFXi9xCEoA=.04b52714-72c8-4d6b-8d75-dae6acc4dbd7@github.com>
 <_nsxM8jRpfTC4Ap2BDnf4qgGj07syWVIrOp5c7UsWFQ=.a982a387-b97f-4020-9c17-da6357c2ab48@github.com>
 <voBG4m10RpjAfHA5RC_WSfPr3mkmg5wi2ipgJbI1_NM=.22a63472-c7f8-4237-9787-d84121d0e4a0@github.com>
 <NyMhs43dogu2oFVjCESd8Dy2-zRYD8RvsNy
 QCgx5-UU=.31d22b3a-3f8c-4f6e-b2d5-c29a6cbbc545@github.com>
Message-ID: <wcJtciB8guAN0iI2hxU5GJoKLk2kNjn0YMcDVgPM1XQ=.8ed5ae5e-c200-46e2-a6e6-fe4f4f64a4af@github.com>

On Tue, 6 Sep 2022 17:11:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Thank you all for your kind help and feedback.
>> 
>> @AlanBateman So is now the time to switch this PR from Draft to Ready?
>
> The source changes LGTM. I suppose you should now revert the changes above (in `HexPrinter.java`), otherwise the bytes will now be counted twice :-).
> Which BTW shows that you would be depending on undocumented behavior whatever you do:
> `transferTo` is not documented to call `this.read(...)`, but neither is it documented to **not call**  `this.read(...)`...  Hyrum's law wins here ;-)

https://github.com/openjdk/jdk/pull/6935/commits/b4d5004dd3299d084769309b505b19ed7dd3182e reverts the change, as it is not needed (and wrong) with the check in place. I wonder if in future people will actually understand what actually is going on under the hood here.

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

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

From naoto at openjdk.org  Tue Sep  6 17:36:38 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Sep 2022 17:36:38 GMT
Subject: RFR: 8293146: Strict DateTimeFormatter fails to report an invalid week
 53
Message-ID: <VxElPtTH8m2HoBuHuxIQ7JT-N0jePRGAQTvFkDz5MKI=.bc698e1c-beaa-4d1e-8c82-0caf02bd15c9@github.com>

Fixed the max week number on parsing the week of week-based year field in strict mode. It used to be always returning the largest maximum, which should be adjusted by the actual week-based year.

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

Commit messages:
 - 8293146: Strict DateTimeFormatter fails to report an invalid week 53

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

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

From naoto at openjdk.org  Tue Sep  6 19:06:45 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Sep 2022 19:06:45 GMT
Subject: RFR: 8293146: Strict DateTimeFormatter fails to report an invalid
 week 53 [v2]
In-Reply-To: <VxElPtTH8m2HoBuHuxIQ7JT-N0jePRGAQTvFkDz5MKI=.bc698e1c-beaa-4d1e-8c82-0caf02bd15c9@github.com>
References: <VxElPtTH8m2HoBuHuxIQ7JT-N0jePRGAQTvFkDz5MKI=.bc698e1c-beaa-4d1e-8c82-0caf02bd15c9@github.com>
Message-ID: <p5aZI5V2M65EtDlnIPeG4OiaCPxFehoWkTabex9vPaA=.2e240b4e-fe7e-47f2-b8bd-bf4457415fe2@github.com>

> Fixed the max week number on parsing the week of week-based year field in strict mode. It used to be always returning the largest maximum, which should be adjusted by the actual week-based year.

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

 - Merge branch 'master' into JDK-8293146-StrictDateTimeFormatter
 - Fixed typo
 - 8293146: Strict DateTimeFormatter fails to report an invalid week 53

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10184/files
  - new: https://git.openjdk.org/jdk/pull/10184/files/7c7a532c..be54a7be

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

  Stats: 27962 lines in 532 files changed: 10072 ins; 12327 del; 5563 mod
  Patch: https://git.openjdk.org/jdk/pull/10184.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10184/head:pull/10184

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

From svkamath at openjdk.org  Tue Sep  6 21:09:50 2022
From: svkamath at openjdk.org (Smita Kamath)
Date: Tue, 6 Sep 2022 21:09:50 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v6]
In-Reply-To: <SkGmDPFWhQZGaglHmdt3p72B17yxGc8flLEei7F_H3s=.a6e53ae9-aac9-406a-8b7e-6886572ae3f2@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <0im5_Of4jj3BHOipBt4VkAuX3327nQbKtW_sYnzcVUU=.0153ab0a-aa0c-4c12-a150-407a85cf8d0c@github.com>
 <jp3g1e-Vjzar_GlVAN7CqFoj-EpNAcKwiX-C_HXDEhY=.eb36da15-a147-4730-b0af-da5825b58bb9@github.com>
 <SkGmDPFWhQZGaglHmdt3p72B17yxGc8flLEei7F_H3s=.a6e53ae9-aac9-406a-8b7e-6886572ae3f2@github.com>
Message-ID: <Ww1wlufHuLDadpYkGZHbtwJpzN6I_duM_vhN3ibPWw4=.311c2a6b-19f8-4039-acf4-53883193c7b3@github.com>

On Thu, 1 Sep 2022 21:17:30 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Yes; I removed support for --release 7 in JDK 20 early today.
>> 
>> 
>> On Thu, Sep 1, 2022 at 1:36 PM Paul Sandoz ***@***.***> wrote:
>> 
>>> Likely requires a merge with master.
>>>
>>> ?
>>> Reply to this email directly, view it on GitHub
>>> <https://github.com/openjdk/jdk/pull/9781#issuecomment-1234753280>, or
>>> unsubscribe
>>> <https://github.com/notifications/unsubscribe-auth/AHPLHYCD2RZXG427WU2322DV4EHT3ANCNFSM55WURKVA>
>>> .
>>> You are receiving this because you were mentioned.Message ID:
>>> ***@***.***>
>>>
>
>> Yes; I removed support for --release 7 in JDK 20 early today.
> 
> Yes, I missed that my merge of master did not apply because I modified tests, Joe fixed, to test his changes.
> 
> Resubmitting testing after resolving the issue. Still missed parentheses issue should be fixed.

@vnkozlov Hi Vladimir, thanks for testing the changes. Could you let me know if the tests completed and passed? Thanks once again.

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

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

From alexander.matveev at oracle.com  Tue Sep  6 21:48:36 2022
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Tue, 6 Sep 2022 21:48:36 +0000
Subject: jpackage OS/X --app-image signing 
In-Reply-To: <1A3AD609-41FA-4FC4-B95D-19F3F0FED372@gmail.com>
References: <1A3AD609-41FA-4FC4-B95D-19F3F0FED372@gmail.com>
Message-ID: <505138E4-48B6-4F14-905A-9FEA2F7881EA@oracle.com>

Hi Michael,

Did you generate application image with same JDK version (19+36-2238)? With latest JDK version .jpackage.xml file should be present. We do not support signing of application images generate by another versions of JDK. It should be same JDK.

Thanks,
Alexander

> On Sep 5, 2022, at 4:15 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> The 19 release candidate appears to have new issues on this?
> 
> java --version
> openjdk 19 2022-09-20
> OpenJDK Runtime Environment (build 19+36-2238)
> OpenJDK 64-Bit Server VM (build 19+36-2238, mixed mode, sharing)
> 
> which jpackage
> jpackage: aliased to /Library/Java/JavaVirtualMachines/jdk-19.jdk/Contents/Home/bin/jpackage
> 
> jpackage --version
> 19
> 
> jpackage --type app-image --app-image ~/Blackjack_Blastoff/bjb/bjb_jpkg/BlackJack\ Blastoff_Unsigned.app --mac-sign --mac-signing-key-user-name "Developer ID Application: Michael Hall (5X6BXQB3Q7)"                                  
> Error: app-image dir (/Users/mjh/Blackjack_Blastoff/bjb/bjb_jpkg/BlackJack Blastoff_Unsigned.app) generated by another jpackage version or malformed .jpackage.xml
> 
> ls -l
> total 4224
> drwxr-xr-x  3 mjh  staff       96 Sep  5 17:50 BlackJack Blastoff_Unsigned.app
> ?
> 
> I don?t think any information is included in the Info.plist or anywhere else that indicates which jpackage version was used to build it. (Maybe an idea?)
> But I did recreate with the newly installed 19 release candidate. 
> I?m not sure what the .jpackage.xml is about?
> 
> ls -l .jpackage.xml
> ls: .jpackage.xml: No such file or directory


From mik3hall at gmail.com  Tue Sep  6 21:52:56 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 6 Sep 2022 16:52:56 -0500
Subject: jpackage OS/X --app-image signing
In-Reply-To: <505138E4-48B6-4F14-905A-9FEA2F7881EA@oracle.com>
References: <1A3AD609-41FA-4FC4-B95D-19F3F0FED372@gmail.com>
 <505138E4-48B6-4F14-905A-9FEA2F7881EA@oracle.com>
Message-ID: <3A133DBA-AA83-4824-89AA-DD0C406D86D7@gmail.com>



> On Sep 6, 2022, at 4:48 PM, Alexander Matveev <alexander.matveev at oracle.com> wrote:
> 
> Hi Michael,
> 
> Did you generate application image with same JDK version (19+36-2238)? With latest JDK version .jpackage.xml file should be present. We do not support signing of application images generate by another versions of JDK. It should be same JDK.
> 
> Thanks,
> Alexander
> 

Alexander,

Should of been. I installed the jdk, deleted the app and recreated, then tried to sign.

I?ll repeat to make sure I didn?t mix it up somehow.


From mik3hall at gmail.com  Tue Sep  6 22:29:12 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 6 Sep 2022 17:29:12 -0500
Subject: jpackage OS/X --app-image signing
In-Reply-To: <3A133DBA-AA83-4824-89AA-DD0C406D86D7@gmail.com>
References: <1A3AD609-41FA-4FC4-B95D-19F3F0FED372@gmail.com>
 <505138E4-48B6-4F14-905A-9FEA2F7881EA@oracle.com>
 <3A133DBA-AA83-4824-89AA-DD0C406D86D7@gmail.com>
Message-ID: <A28B7697-6B7A-4496-B055-3AE98F54F5C6@gmail.com>



> On Sep 6, 2022, at 4:52 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> 
>> On Sep 6, 2022, at 4:48 PM, Alexander Matveev <alexander.matveev at oracle.com> wrote:
>> 
>> Hi Michael,
>> 
>> Did you generate application image with same JDK version (19+36-2238)? With latest JDK version .jpackage.xml file should be present. We do not support signing of application images generate by another versions of JDK. It should be same JDK.
>> 
>> Thanks,
>> Alexander
>> 
> 
> Alexander,
> 
> Should of been. I installed the jdk, deleted the app and recreated, then tried to sign.
> 
> I?ll repeat to make sure I didn?t mix it up somehow.
> 

My mistake. I usually always have the jpackage build script set to use the current installed jpackage but I had changed this one to use a built GitHub version which was a jdk 20.

However, there do seem to still be remaining issues. 

The codesign verify still seems to indicate an error.

codesign -v --verbose=4 "/Volumes/BlackJack Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app"
/Volumes/BlackJack Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app: a sealed resource is missing or invalid
file added: /Volumes/BlackJack Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app/Contents/app/.package


Also I didn?t seem to get the expected small icon for the application. I put a screenshot of the window at http://mikehall.pairserver.com/ScreenShot.png <http://mikehall.pairserver.com/ScreenShot.png>
It seems to be correct in the dmg.

And I still don?t see where I have the .jpackage.xml in the current directory.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220906/25b18db2/attachment.htm>

From mik3hall at gmail.com  Wed Sep  7 01:00:05 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 6 Sep 2022 20:00:05 -0500
Subject: jpackage OS/X --app-image signing
In-Reply-To: <3A133DBA-AA83-4824-89AA-DD0C406D86D7@gmail.com>
References: <1A3AD609-41FA-4FC4-B95D-19F3F0FED372@gmail.com>
 <505138E4-48B6-4F14-905A-9FEA2F7881EA@oracle.com>
 <3A133DBA-AA83-4824-89AA-DD0C406D86D7@gmail.com>
Message-ID: <6CBB029A-D807-4E06-B073-2D536C4D25CB@gmail.com>



> On Sep 6, 2022, at 4:52 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> 
>> On Sep 6, 2022, at 4:48 PM, Alexander Matveev <alexander.matveev at oracle.com> wrote:
>> 
>> Hi Michael,
>> 
>> Did you generate application image with same JDK version (19+36-2238)? With latest JDK version .jpackage.xml file should be present. We do not support signing of application images generate by another versions of JDK. It should be same JDK.
>> 
>> Thanks,
>> Alexander
>> 
> 

Found this explains some of it.

Re: [jdk19] RFR: 8289030: [macos] app image signature invalid when creating DMG or PKG [v3]


From cjplummer at openjdk.org  Wed Sep  7 02:12:19 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 7 Sep 2022 02:12:19 GMT
Subject: RFR: 8283224: Remove THREAD_NOT_ALIVE from possible JDWP error codes
Message-ID: <-uXeHdtNBceQvqp-l256Tx1kI80v-tbD8-OMV_oMD7I=.34fbf6f5-2edc-4ed7-87cd-5734064b76c8@github.com>

THREAD_NOT_ALIVE originates from JVMTI. However, the debug agent converts it to INVALID_THREAD before passing it on to the debug agent client (the debugger, usually JDI), so debug agent users (JDI) should never see it. Currently ThreadReference.forceEarlyReturn() is the only API that even bothers to check for it, and it throws com.sun.jdi.IllegalThreadStateException, which is the same thing it already does for INVALID_THREAD.

In the JDWP spec I change the description of THREAD_NOT_ALIVE  to "Not used". If you have a suggestion for better wording, please let me now. (I was thinking maybe "Unused" would be better.

In the JDI ThreadReference.forceEarlyReturn implementation, I removed the code that checks for THREAD_NOT_ALIVE since it should never occur. There is no behavior change associated with this change, and there is no JDI spec update necessary. The spec already says IllegalThreadStateException means "the thread is not suspended", and not being alive implies not suspended.

Note the JDWP spec for ThreadReference.ForceEarlyReturn used to mention THREAD_NOT_ALIVE as a possible error code, but it was removed as part of the loom work.

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

Commit messages:
 - Cleanup THREAD_NOT_ALIVE usage

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

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

From aturbanov at openjdk.org  Wed Sep  7 06:14:44 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 7 Sep 2022 06:14:44 GMT
Subject: Integrated: 8293197: Avoid double racy reads from non-volatile fields
 in SharedSecrets
In-Reply-To: <GvvKthp1tV-BsDwulYsu5nGEYXKnibDPse5MVdQHyyg=.f7ce5178-d88e-44d6-9103-6d94de127cef@github.com>
References: <GvvKthp1tV-BsDwulYsu5nGEYXKnibDPse5MVdQHyyg=.f7ce5178-d88e-44d6-9103-6d94de127cef@github.com>
Message-ID: <EAVsuCQZ0PkCmui5ResmrkoFwiQ_Wj0YDMYVbk16D6M=.ca9b66b0-cd05-4d6e-b62a-0396aeba6c20@github.com>

On Tue, 30 Aug 2022 07:10:36 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> After integration of [JDK-8259021](https://bugs.openjdk.org/browse/JDK-8259021) a few more fields were added to `SharedSecrets` class. It make sense to update their reading code to use the same idiom.

This pull request has now been integrated.

Changeset: 2259e427
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2259e427a53440da948315db2272396294036051
Stats:     16 lines in 1 file changed: 8 ins; 0 del; 8 mod

8293197: Avoid double racy reads from non-volatile fields in SharedSecrets

Reviewed-by: alanb

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

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

From alanb at openjdk.org  Wed Sep  7 08:30:41 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Sep 2022 08:30:41 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v7]
In-Reply-To: <_nsxM8jRpfTC4Ap2BDnf4qgGj07syWVIrOp5c7UsWFQ=.a982a387-b97f-4020-9c17-da6357c2ab48@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <iQc17-mZLZe0P2Kc41ZYd4vZDjG4CYV-XDORMUpOo1M=.27d01189-50a8-4c32-916f-2e4d6c1f521d@github.com>
 <EjqSwyshh75YtKji43w2BJQABwZhJfHH03U_eDauvnY=.fb06ab80-69fd-4c1b-88b4-3c1698fd96b4@github.com>
 <4IrMrIGz101qsBIjluHA8uVrsckxMfxDL70NqQpIog8=.9b9c202f-9973-4958-9dd5-91f4aa9f1bb6@github.com>
 <kowFc6D23a5547qelVDqTWo6LrHKS6ynU4-4lsxPZHM=.a24e0770-d74e-4d7b-a7e6-636c45669d2d@github.com>
 <Uz5Q_zmsxgcIBvimEB7eHVmvrvve-2KIMTPnlxqesog=.e5b35f03-d79e-4fe8-a172-e793c9150a26@github.com>
 <CoGNeHzyxu1CYND-HWkTueOsLkPYDCnGhhwGfY7s6zo=.759ef08a-48f4-4b58-bc19-1ee2407ee8dc@github.com>
 <dFY1n2zzS_pwhoDplPeIYajN5BU3A2T8_lFXi9xCEoA=.04b52714-72c8-4d6b-8d75-dae6acc4dbd7@github.com>
 <_nsxM8jRpfTC4Ap2BDnf4qgGj07syWVIrOp5c7UsWFQ=.a982a387-b97f-4020-9c17-da6357c2ab48@github.com>
Message-ID: <9l_2-AWMVU6Rkb4p5Kgypog-FmVeb134GPsNDecN4bI=.6541d84e-c637-41f2-a226-2ce75d380d94@github.com>

On Tue, 6 Sep 2022 16:29:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> BIS dates from JDK 1.0 and it's not hard to find examples that extend it. The HexPrinter test reminds us that it has been possible for 25+ years to override the read methods and snoop on all bytes that are read. Adding an override of the transferTo method that bypasses the read methods might break these subclasses. So I think Daniel is right that we have to be cautious.
>> 
>> So I think the feedback that you have now is that bypassing the buffer is problematic when using mark, when there are buffered bytes, or when BIS has been extended. It may be that the starting point is something very conservative like this:
>> 
>> 
>>     @Override
>>     public long transferTo(OutputStream out) throws IOException {
>>         if (getClass() == BufferedInputStream.class
>>                 && ((count - pos) <= 0) && (markpos == -1)) {
>>             return getInIfOpen().transferTo(out);
>>         } else {
>>             return super.transferTo(out);
>>         }
>>     }
>> 
>> 
>> There is also the issue of locking and async close to look into.
>
>> @AlanBateman Async close leaves BIS in an invalid state. The JavaDocs say ` The behavior for the case where the input and/or output stream is asynchronously closed, or the thread interrupted during the transfer, is highly input and output stream specific, and therefore not specified.`. 
> 
> Yes, I believe I suggested that wording when the method was added. The java.io APIs mostly pre-date deep consideration of those topics.
> 
> I've looked at the update change to BIS in f2f9a904 and I think it's okay.
> 
> On the CSR topic and your messages with Daniel. On the CSR wiki pages then phrase to look for is "behavioral compatibility".  The "Kinds of Compatibility" has more details on the topic.

> @AlanBateman So is now the time to switch this PR from Draft to Ready?

Yes. From what I can tell, moving to Draft while you worked on it didn't pause the Skara bots, I'm not sure why that is.

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

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

From duke at openjdk.org  Wed Sep  7 08:38:59 2022
From: duke at openjdk.org (Markus KARG)
Date: Wed, 7 Sep 2022 08:38:59 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v9]
In-Reply-To: <jpjOzk7z0bfD2rIbg_yWGlW3IcaDJqKx2oL8vx9K3K8=.3cc44e7f-babe-46b6-ae6e-7d0581f3c100@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <jpjOzk7z0bfD2rIbg_yWGlW3IcaDJqKx2oL8vx9K3K8=.3cc44e7f-babe-46b6-ae6e-7d0581f3c100@github.com>
Message-ID: <LzpKTZFpL0wsWlAfJqMsYo2VupXCVyNDdSJXpwx42Dg=.ae7fcc69-9623-475a-80b9-d7f7b784de40@github.com>

On Tue, 6 Sep 2022 17:20:22 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Implementation of JDK-8279283
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "HexPrinter::transferTo"
>   
>   This reverts commit 6f0e2a8f7be5706b39a8e9bc88a97f34d2819098.

Kindly requesting approval of this PR. :-)

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

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

From duke at openjdk.org  Wed Sep  7 10:45:47 2022
From: duke at openjdk.org (Strahinja Stanojevic)
Date: Wed, 7 Sep 2022 10:45:47 GMT
Subject: RFR: JDK-8292914: Introduce a system property that enables stable
 names for lambda classes [v2]
In-Reply-To: <pYF675FND8BK8SUHFnvstPMcoKTcW81zs7yGCli5Mxo=.aac8b180-6101-4320-aa73-7e640952afaf@github.com>
References: <pYF675FND8BK8SUHFnvstPMcoKTcW81zs7yGCli5Mxo=.aac8b180-6101-4320-aa73-7e640952afaf@github.com>
Message-ID: <LD6Fi65pSyIg2nENBV7mom18fdbvyI74g1-k82Gvzjg=.1c1cbc06-01c7-4be3-b59e-0c380a27bd1b@github.com>

> This PR introduces a system property that creates stable names for the lambda classes in the JDK. Instead of using an atomic counter in the lambda name, we can use a 32-bit hash after `$$Lambda$`. Thus, the name becomes `lambdaCapturingClass$$Lambda$hashValue`.
> Parameters used to create a stable part of the name (hash value) are a superset of the parameters used for lambda class archiving when the CDS dumping option is enabled. During the stable name creation process,
> all the common parameters are in the same form as in the low-level implementation (C part of the code) of the archiving process.
> We concatenate all of those parameters in one string `hashData`. We calculate the long hash value for `hashData` in the same manner as the `java.lang.StringUTF16#hashCode` does, and then we hash that value using `Long.toString(longHashValue, Character.MAX_RADIX)`. The desired length for this hash is equal to the length of the `Long.toString(Long.MAX_VALUE, Character.MAX_RADIX)`.
> Sometimes, the calculated hash value is shorter than the desired length, so we pad it with the character `#` to hit it. Appending `#` only affects the hash length, but not its stability.
> 
> Link to the related issue: https://bugs.openjdk.org/browse/JDK-8292914

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

  Enhance test with lambdas created as method references

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10024/files
  - new: https://git.openjdk.org/jdk/pull/10024/files/1f551d1d..dd268934

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

  Stats: 30 lines in 2 files changed: 12 ins; 16 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10024.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10024/head:pull/10024

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

From duke at openjdk.org  Wed Sep  7 11:09:36 2022
From: duke at openjdk.org (Strahinja Stanojevic)
Date: Wed, 7 Sep 2022 11:09:36 GMT
Subject: RFR: JDK-8292914: Introduce a system property that enables stable
 names for lambda classes
In-Reply-To: <yHc2sx--3vLcANEym5JWSCfHvsiLG1QyPgOoUmMhCgU=.940f943f-adb0-4568-9bde-74faec9c1703@github.com>
References: <pYF675FND8BK8SUHFnvstPMcoKTcW81zs7yGCli5Mxo=.aac8b180-6101-4320-aa73-7e640952afaf@github.com>
 <yHc2sx--3vLcANEym5JWSCfHvsiLG1QyPgOoUmMhCgU=.940f943f-adb0-4568-9bde-74faec9c1703@github.com>
Message-ID: <8MH8sTBRNTHhfjbgJ9T6fBMe9y9c5NBFVATcoy4Et_c=.6aa4250f-d8b5-408f-b7a9-fdfd9a80705b@github.com>

On Tue, 6 Sep 2022 16:47:03 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Have you tested with method references? Two references to the same method will result in a single `JVM_CONSTANT_InvokeDynamic` constant pool entry in the classfile, but it's invoked by two callsites. As a result, two different lambda proxy classes will be generated, as the JVMS requires the invokedynamic resolution to be per callsite, not per constantpool entry.
> 
> ```
> public class ShareBSM {
>   public static void main(String args[]) {
>     doit1(ShareBSM::func);
>     doit2(ShareBSM::func);
>   }
>   static void func() {  Thread.dumpStack();  }
>   static void doit1(Runnable r) {  r.run();  }
>   static void doit2(Runnable r) {  r.run();  }
> }
> ```
> 
> Here's the output:
> 
> ```
> $ java -cp . -XX:+UnlockDiagnosticVMOptions -XX:+ShowHiddenFrames ShareBSM
> java.lang.Exception: Stack trace
> 	at java.base/java.lang.Thread.dumpStack(Thread.java:1380)
> 	at ShareBSM.func(ShareBSM.java:8)
> 	at ShareBSM$$Lambda$1/0x0000000800c009f0.run(Unknown Source)
> 	at ShareBSM.doit1(ShareBSM.java:12)
> 	at ShareBSM.main(ShareBSM.java:3)
> java.lang.Exception: Stack trace
> 	at java.base/java.lang.Thread.dumpStack(Thread.java:1380)
> 	at ShareBSM.func(ShareBSM.java:8)
> 	at ShareBSM$$Lambda$2/0x0000000800c00bf8.run(Unknown Source)
> 	at ShareBSM.doit2(ShareBSM.java:15)
> 	at ShareBSM.main(ShareBSM.java:4)
> ```
> 
> Will you patch generate the same name for both callsites? Does this matter for your use case?

@iklam Yes, I tested it against method references too. The patch produces the same names as it should. I enhanced the test with one additional method that will explicitly use method references. We don't want confusion about this in the future.

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

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

From mik3hall at gmail.com  Wed Sep  7 13:28:11 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 7 Sep 2022 08:28:11 -0500
Subject: jpackage OS/X --app-image signing
In-Reply-To: <6CBB029A-D807-4E06-B073-2D536C4D25CB@gmail.com>
References: <1A3AD609-41FA-4FC4-B95D-19F3F0FED372@gmail.com>
 <505138E4-48B6-4F14-905A-9FEA2F7881EA@oracle.com>
 <3A133DBA-AA83-4824-89AA-DD0C406D86D7@gmail.com>
 <6CBB029A-D807-4E06-B073-2D536C4D25CB@gmail.com>
Message-ID: <D34E9956-5770-461D-B64A-26BDEECDD4DA@gmail.com>



> On Sep 6, 2022, at 8:00 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> 
>> On Sep 6, 2022, at 4:52 PM, Michael Hall <mik3hall at gmail.com> wrote:
>> 
>> 
>> 
>>> On Sep 6, 2022, at 4:48 PM, Alexander Matveev <alexander.matveev at oracle.com> wrote:
>>> 
>>> Hi Michael,
>>> 
>>> Did you generate application image with same JDK version (19+36-2238)? With latest JDK version .jpackage.xml file should be present. We do not support signing of application images generate by another versions of JDK. It should be same JDK.
>>> 
>>> Thanks,
>>> Alexander
>>> 
>> 
> 
> Found this explains some of it.
> 
> Re: [jdk19] RFR: 8289030: [macos] app image signature invalid when creating DMG or PKG [v3]

Added this after my build script jpackage invocation to verify .jpackage.xml and version are correct

cat "BlackJack Blastoff_Unsigned.app/Contents/app/.jpackage.xml" | grep "jpackage-state version=?

Showing 
<jpackage-state version="19" platform="macOS">
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220907/df79d2ba/attachment.htm>

From duke at openjdk.org  Wed Sep  7 13:29:41 2022
From: duke at openjdk.org (Markus KARG)
Date: Wed, 7 Sep 2022 13:29:41 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v9]
In-Reply-To: <jpjOzk7z0bfD2rIbg_yWGlW3IcaDJqKx2oL8vx9K3K8=.3cc44e7f-babe-46b6-ae6e-7d0581f3c100@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <jpjOzk7z0bfD2rIbg_yWGlW3IcaDJqKx2oL8vx9K3K8=.3cc44e7f-babe-46b6-ae6e-7d0581f3c100@github.com>
Message-ID: <tz3BVV2qWWPQrLDNn50A386ikpM52IDSIyQXgd5-z1w=.f94d29f0-4fdd-4b77-9ff9-c2eae1cef8cc@github.com>

On Tue, 6 Sep 2022 17:20:22 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Implementation of JDK-8279283
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "HexPrinter::transferTo"
>   
>   This reverts commit 6f0e2a8f7be5706b39a8e9bc88a97f34d2819098.

Strange. Whenever I click on the "request review" icon, it removes the existing review requests?!

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

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

From cstein at openjdk.org  Wed Sep  7 15:17:53 2022
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 7 Sep 2022 15:17:53 GMT
Subject: Integrated: JDK-8289798: Update to use jtreg 7
In-Reply-To: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
References: <S6z2NnZ2cw_S59_xb1qd8lfnY4n98Yu9hruEWh133wE=.b551011f-1526-4155-a9b8-38cc28b9d106@github.com>
Message-ID: <k1uDsY_ME1eyOmdh6X8FPYC4Gu_VfA7DZh1o1BbPVGU=.dadd0e4b-5982-4786-988c-b2871d04a783@github.com>

On Wed, 6 Jul 2022 08:24:21 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.
> 
> 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 has now been integrated.

Changeset: 1ee59adc
Author:    Christian Stein <cstein at openjdk.org>
Committer: Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1ee59adcfead2128316556121c1711d308c7ea01
Stats:     11 lines in 8 files changed: 0 ins; 0 del; 11 mod

8289798: Update to use jtreg 7

Reviewed-by: ihse, jpai

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

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

From duke at openjdk.org  Wed Sep  7 15:20:31 2022
From: duke at openjdk.org (Weibing Xiao)
Date: Wed, 7 Sep 2022 15:20:31 GMT
Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir
 directory doesn't exist
Message-ID: <rjEWqSaj5cFnFbv-bFsv7Ab1qpwgfoKe9mILyMuXH_M=.b8b570a7-27cf-494a-805b-3e04dd404bc6@github.com>

8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist

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

Commit messages:
 - new approach
 - change based on the review
 - updating according to the comments
 - Merge branch 'master' of https://github.com/openjdk/jdk into improve-directory-not-existing-error-message
 - update error message
 - error message for non-existing directory
 - improve error message when file directory does not exist

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

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

From duke at openjdk.org  Wed Sep  7 15:20:31 2022
From: duke at openjdk.org (Weibing Xiao)
Date: Wed, 7 Sep 2022 15:20:31 GMT
Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir
 directory doesn't exist
In-Reply-To: <rjEWqSaj5cFnFbv-bFsv7Ab1qpwgfoKe9mILyMuXH_M=.b8b570a7-27cf-494a-805b-3e04dd404bc6@github.com>
References: <rjEWqSaj5cFnFbv-bFsv7Ab1qpwgfoKe9mILyMuXH_M=.b8b570a7-27cf-494a-805b-3e04dd404bc6@github.com>
Message-ID: <e01JD2YRq8QWw6bazrCTedSee4VEu0qlCgZwy3_qhic=.c92e83d9-1235-4b24-bbc0-4610145177f3@github.com>

On Tue, 23 Aug 2022 18:32:30 GMT, Weibing Xiao <duke at openjdk.org> wrote:

> 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist

CSR https://bugs.openjdk.org/browse/JDK-8293246

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

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

From duke at openjdk.org  Wed Sep  7 15:20:34 2022
From: duke at openjdk.org (David Schlosnagle)
Date: Wed, 7 Sep 2022 15:20:34 GMT
Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir
 directory doesn't exist
In-Reply-To: <rjEWqSaj5cFnFbv-bFsv7Ab1qpwgfoKe9mILyMuXH_M=.b8b570a7-27cf-494a-805b-3e04dd404bc6@github.com>
References: <rjEWqSaj5cFnFbv-bFsv7Ab1qpwgfoKe9mILyMuXH_M=.b8b570a7-27cf-494a-805b-3e04dd404bc6@github.com>
Message-ID: <CISGTHcmFrrnWlM2V2vGizMf5Ga9mzX5SIDzUpSA72Y=.4114d5d9-de1c-4d23-9965-a15c93919b6a@github.com>

On Tue, 23 Aug 2022 18:32:30 GMT, Weibing Xiao <duke at openjdk.org> wrote:

> 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist

src/java.base/share/classes/java/io/File.java line 2180:

> 2178: 
> 2179: 
> 2180:         if(!tmpdir.exists() || !tmpdir.canWrite()) {

Should this check that `tmpdir.isDirectory()` that will do both existence & directory check? That would catch if java.io.t odor was mistakenly set to an existing (writable) file.

Suggestion:

        if(!tmpdir.isDirectory() || !tmpdir.canWrite()) {

src/java.base/share/classes/java/io/File.java line 2181:

> 2179: 
> 2180:         if(!tmpdir.exists() || !tmpdir.canWrite()) {
> 2181:             throw new IOException("The specified directory does no exist or is not accessible! " +

Spelling nit:

Suggestion:

            throw new IOException("The specified directory does not exist or is not accessible! " +

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

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

From duke at openjdk.org  Wed Sep  7 15:20:34 2022
From: duke at openjdk.org (Weibing Xiao)
Date: Wed, 7 Sep 2022 15:20:34 GMT
Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir
 directory doesn't exist
In-Reply-To: <CISGTHcmFrrnWlM2V2vGizMf5Ga9mzX5SIDzUpSA72Y=.4114d5d9-de1c-4d23-9965-a15c93919b6a@github.com>
References: <rjEWqSaj5cFnFbv-bFsv7Ab1qpwgfoKe9mILyMuXH_M=.b8b570a7-27cf-494a-805b-3e04dd404bc6@github.com>
 <CISGTHcmFrrnWlM2V2vGizMf5Ga9mzX5SIDzUpSA72Y=.4114d5d9-de1c-4d23-9965-a15c93919b6a@github.com>
Message-ID: <baaRLXm6yX_lHvt_rXNFh1dEkUoWcBUeebYO8jWhRjE=.494415cf-8626-4fa3-a159-94c59f395117@github.com>

On Wed, 24 Aug 2022 04:42:54 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist
>
> src/java.base/share/classes/java/io/File.java line 2180:
> 
>> 2178: 
>> 2179: 
>> 2180:         if(!tmpdir.exists() || !tmpdir.canWrite()) {
> 
> Should this check that `tmpdir.isDirectory()` that will do both existence & directory check? That would catch if java.io.t odor was mistakenly set to an existing (writable) file.
> 
> Suggestion:
> 
>         if(!tmpdir.isDirectory() || !tmpdir.canWrite()) {

Using a new approach, please check the new commits. Thanks.

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

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

From dcubed at openjdk.org  Wed Sep  7 15:29:11 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 7 Sep 2022 15:29:11 GMT
Subject: Integrated: 8293496: ProblemList runtime/os/TestTracePageSizes.java on
 linux-x64
In-Reply-To: <tk1Mh79j3E4_goNT0n-inLZUJDrVbzeAi4yw_fznqk4=.6b0f6d6a-fb8e-46e9-b71e-5ca386a02147@github.com>
References: <tk1Mh79j3E4_goNT0n-inLZUJDrVbzeAi4yw_fznqk4=.6b0f6d6a-fb8e-46e9-b71e-5ca386a02147@github.com>
Message-ID: <hd4Rv3iIYNGYPGYb0eTm52MQhQiWXkKeWMrmtnolWQk=.d565cda5-5871-4eaf-be32-636889adef9c@github.com>

On Wed, 7 Sep 2022 15:18:29 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList runtime/os/TestTracePageSizes.java on linux-x64.

This pull request has now been integrated.

Changeset: d36abbe8
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d36abbe8dab3618a08a8a87f53411ed92823d471
Stats:     6 lines in 1 file changed: 0 ins; 0 del; 6 mod

8293496: ProblemList runtime/os/TestTracePageSizes.java on linux-x64

Reviewed-by: alanb, azvegint

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

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

From duke at openjdk.org  Wed Sep  7 15:36:43 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 7 Sep 2022 15:36:43 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v9]
In-Reply-To: <jpjOzk7z0bfD2rIbg_yWGlW3IcaDJqKx2oL8vx9K3K8=.3cc44e7f-babe-46b6-ae6e-7d0581f3c100@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <jpjOzk7z0bfD2rIbg_yWGlW3IcaDJqKx2oL8vx9K3K8=.3cc44e7f-babe-46b6-ae6e-7d0581f3c100@github.com>
Message-ID: <Zj4OYBq7kAPGHS7jIhSmBRDmedb54Uz2_urlMkGvF7k=.cebda9a7-5bcc-41bc-a2c5-7699fdba9c65@github.com>

On Tue, 6 Sep 2022 17:20:22 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Implementation of JDK-8279283
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "HexPrinter::transferTo"
>   
>   This reverts commit 6f0e2a8f7be5706b39a8e9bc88a97f34d2819098.

LGTM

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

Marked as reviewed by stsypanov at github.com (no known OpenJDK username).

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

From alanb at openjdk.org  Wed Sep  7 16:04:59 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Sep 2022 16:04:59 GMT
Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir
 directory doesn't exist
In-Reply-To: <rjEWqSaj5cFnFbv-bFsv7Ab1qpwgfoKe9mILyMuXH_M=.b8b570a7-27cf-494a-805b-3e04dd404bc6@github.com>
References: <rjEWqSaj5cFnFbv-bFsv7Ab1qpwgfoKe9mILyMuXH_M=.b8b570a7-27cf-494a-805b-3e04dd404bc6@github.com>
Message-ID: <Sx7xodx4v0cJM2sl2fFAWKMnO9oQFAdGax8k5megEic=.9e4b176d-7f85-4aff-8807-221f94cf9f37@github.com>

On Tue, 23 Aug 2022 18:32:30 GMT, Weibing Xiao <duke at openjdk.org> wrote:

> 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist

src/java.base/share/classes/java/io/File.java line 1992:

> 1990: 
> 1991:         // print out the error message for java.io.tmpdir setting
> 1992:         static {

This will only run when java.io.File.createTempFile is used. So it work won't work java.nio.files.Files.createTempXXX. Have you looked into testing the value of java.io.tmpdir at startup when it is specified on the command line?

src/java.base/share/classes/java/io/File.java line 1995:

> 1993:             if (tmpdir.isInvalid() || !fs.hasBooleanAttributes(tmpdir, FileSystem.BA_DIRECTORY)) {
> 1994:                 String msg = "WARNING: java.io.tmpdir location does not exist";
> 1995:                 if (SecurityProperties.includedInExceptions("fileInfo")) {

The security property controls is for exception messages, not warnings to System.err.

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

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

From rriggs at openjdk.org  Wed Sep  7 17:46:43 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 7 Sep 2022 17:46:43 GMT
Subject: RFR: 8293146: Strict DateTimeFormatter fails to report an invalid
 week 53 [v2]
In-Reply-To: <p5aZI5V2M65EtDlnIPeG4OiaCPxFehoWkTabex9vPaA=.2e240b4e-fe7e-47f2-b8bd-bf4457415fe2@github.com>
References: <VxElPtTH8m2HoBuHuxIQ7JT-N0jePRGAQTvFkDz5MKI=.bc698e1c-beaa-4d1e-8c82-0caf02bd15c9@github.com>
 <p5aZI5V2M65EtDlnIPeG4OiaCPxFehoWkTabex9vPaA=.2e240b4e-fe7e-47f2-b8bd-bf4457415fe2@github.com>
Message-ID: <Sm4RGS25JMCI4vX2w7NpPsHUJEl8ag2WdU8zhsT1ydE=.ce11cda2-ecd3-479c-9d92-6dff9a70d0c7@github.com>

On Tue, 6 Sep 2022 19:06:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixed the max week number on parsing the week of week-based year field in strict mode. It used to be always returning the largest maximum, which should be adjusted by the actual week-based year.
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8293146-StrictDateTimeFormatter
>  - Fixed typo
>  - 8293146: Strict DateTimeFormatter fails to report an invalid week 53

LGTM

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

Marked as reviewed by rriggs (Reviewer).

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

From alanb at openjdk.org  Wed Sep  7 18:25:43 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Sep 2022 18:25:43 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v4]
In-Reply-To: <xrJWvyFSxCoKKFHL5TunUs-Gdr7cZJqp6zG-6UgyGOA=.61545fcd-8e13-4f31-9d6f-19a783eb4ed5@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
 <xrJWvyFSxCoKKFHL5TunUs-Gdr7cZJqp6zG-6UgyGOA=.61545fcd-8e13-4f31-9d6f-19a783eb4ed5@github.com>
Message-ID: <iefMarU77AZurBI9lsZ_41R22mUMZCx57rRfZ5xWXJw=.0f2c6377-3a6f-410c-bc94-a97a46b38317@github.com>

On Tue, 6 Sep 2022 09:14:47 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.
>> 
>> Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
>> Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.
>> 
>> Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor formating fixes

Would it be possible to summarize how the loader delegate work in jshell? Instrumenting the code to invoke REPL/$Cancel$.stopCheck looks reasonable but I can't immediately see how the generated REPL/$Cancel$ has access to LocalExecutionControl.allStop.

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

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

From jlahoda at openjdk.org  Wed Sep  7 18:33:44 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 7 Sep 2022 18:33:44 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v4]
In-Reply-To: <xrJWvyFSxCoKKFHL5TunUs-Gdr7cZJqp6zG-6UgyGOA=.61545fcd-8e13-4f31-9d6f-19a783eb4ed5@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
 <xrJWvyFSxCoKKFHL5TunUs-Gdr7cZJqp6zG-6UgyGOA=.61545fcd-8e13-4f31-9d6f-19a783eb4ed5@github.com>
Message-ID: <q8DOPk6Ycf_9z5nKNGVEVo8LnDvz2w8ltAPDMQBN75c=.7782cb28-e2ee-468f-b183-3d6270492908@github.com>

On Tue, 6 Sep 2022 09:14:47 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.
>> 
>> Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
>> Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.
>> 
>> Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor formating fixes

Seems reasonable to me.

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

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

From jlahoda at openjdk.org  Wed Sep  7 18:37:43 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 7 Sep 2022 18:37:43 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v4]
In-Reply-To: <iefMarU77AZurBI9lsZ_41R22mUMZCx57rRfZ5xWXJw=.0f2c6377-3a6f-410c-bc94-a97a46b38317@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
 <xrJWvyFSxCoKKFHL5TunUs-Gdr7cZJqp6zG-6UgyGOA=.61545fcd-8e13-4f31-9d6f-19a783eb4ed5@github.com>
 <iefMarU77AZurBI9lsZ_41R22mUMZCx57rRfZ5xWXJw=.0f2c6377-3a6f-410c-bc94-a97a46b38317@github.com>
Message-ID: <AM8OtPmjdxL4Py28hAqWUX-ZCRwFxJdl-Sd-dUSdxS8=.a229f2df-6b95-4ce6-b7e3-9f3014b89097@github.com>

On Wed, 7 Sep 2022 18:22:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Would it be possible to summarize how the loader delegate work in jshell? Instrumenting the code to invoke REPL/$Cancel$.stopCheck looks reasonable but I can't immediately see how the generated REPL/$Cancel$ has access to LocalExecutionControl.allStop.

Not sure what you mean - as far as I can tell, neither the generated class, nor the snippets access `LocalExecutionControl.allStop`. The snippets only access the generated class, and `LocalExecutionControl` sets the cancelled value into the generated class. And there is no problem accessing the generated class, as it is in the unnamed module and public.

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

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

From naoto at openjdk.org  Wed Sep  7 18:37:51 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 7 Sep 2022 18:37:51 GMT
Subject: Integrated: 8293146: Strict DateTimeFormatter fails to report an
 invalid week 53
In-Reply-To: <VxElPtTH8m2HoBuHuxIQ7JT-N0jePRGAQTvFkDz5MKI=.bc698e1c-beaa-4d1e-8c82-0caf02bd15c9@github.com>
References: <VxElPtTH8m2HoBuHuxIQ7JT-N0jePRGAQTvFkDz5MKI=.bc698e1c-beaa-4d1e-8c82-0caf02bd15c9@github.com>
Message-ID: <ZTMWrY_wpL8qy9i-W1vuFWWMDoGIqxJAterSA5j7yPM=.12ad4e1a-94f7-456e-a573-c9524ff1fd46@github.com>

On Tue, 6 Sep 2022 17:30:27 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixed the max week number on parsing the week of week-based year field in strict mode. It used to be always returning the largest maximum, which should be adjusted by the actual week-based year.

This pull request has now been integrated.

Changeset: 32c7b628
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/32c7b6283daf6f3876ff62693d5a0cb7c4af4232
Stats:     65 lines in 2 files changed: 61 ins; 0 del; 4 mod

8293146: Strict DateTimeFormatter fails to report an invalid week 53

Reviewed-by: rriggs

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

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

From alanb at openjdk.org  Wed Sep  7 18:48:43 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Sep 2022 18:48:43 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v4]
In-Reply-To: <AM8OtPmjdxL4Py28hAqWUX-ZCRwFxJdl-Sd-dUSdxS8=.a229f2df-6b95-4ce6-b7e3-9f3014b89097@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
 <xrJWvyFSxCoKKFHL5TunUs-Gdr7cZJqp6zG-6UgyGOA=.61545fcd-8e13-4f31-9d6f-19a783eb4ed5@github.com>
 <iefMarU77AZurBI9lsZ_41R22mUMZCx57rRfZ5xWXJw=.0f2c6377-3a6f-410c-bc94-a97a46b38317@github.com>
 <AM8OtPmjdxL4Py28hAqWUX-ZCRwFxJdl-Sd-dUSdxS8=.a229f2df-6b95-4ce6-b7e3-9f3014b89097@github.com>
Message-ID: <SW37eotjKyFHMChF5bYOn6OKeLbf39-epiZFTgEsej0=.c7eec432-0835-44f3-9f43-8a84162c67f3@github.com>

On Wed, 7 Sep 2022 18:35:37 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Not sure what you mean - as far as I can tell, neither the generated class, nor the snippets access `LocalExecutionControl.allStop`. 

Okay, I see it now. REPL.$Cancel$.allStop is public so there is no issue accessing it from LEC.invoke.

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

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

From alexander.matveev at oracle.com  Wed Sep  7 18:50:58 2022
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Wed, 7 Sep 2022 18:50:58 +0000
Subject: [External] : Re: jpackage OS/X --app-image signing
In-Reply-To: <D34E9956-5770-461D-B64A-26BDEECDD4DA@gmail.com>
References: <1A3AD609-41FA-4FC4-B95D-19F3F0FED372@gmail.com>
 <505138E4-48B6-4F14-905A-9FEA2F7881EA@oracle.com>
 <3A133DBA-AA83-4824-89AA-DD0C406D86D7@gmail.com>
 <6CBB029A-D807-4E06-B073-2D536C4D25CB@gmail.com>
 <D34E9956-5770-461D-B64A-26BDEECDD4DA@gmail.com>
Message-ID: <A0B5CB1E-F55E-4E7B-8125-D4D0C8691F84@oracle.com>

Hi Michael,

I file following issue for this:
https://bugs.openjdk.org/browse/JDK-8293462

Yes, you right it is related to JDK-8289030. I put suggested workaround to https://bugs.openjdk.org/browse/JDK-8293462 in comment section.

There are two possible workarounds:
1) Generate signed application image initially, then post process it and sign again.
2) Generate unsigned application image and change value of <signed> from false to true in "APPNAME.app/Contents/app/.jpackage.xml" and then do post processing and sign it again.

There is a bug in "jpackage --type app-image --app-image APPNAME.app --mac-sign? command which signs app image correctly, but never changes value in ?.jpackage.xml? to mark image as signed. Thus we will treat such images as unsigned even if they signed and as result we adding ?.package? file when generating DMG or PKG from such images.

Thanks,
Alexander

On Sep 7, 2022, at 6:28 AM, Michael Hall <mik3hall at gmail.com<mailto:mik3hall at gmail.com>> wrote:



On Sep 6, 2022, at 8:00 PM, Michael Hall <mik3hall at gmail.com<mailto:mik3hall at gmail.com>> wrote:



On Sep 6, 2022, at 4:52 PM, Michael Hall <mik3hall at gmail.com<mailto:mik3hall at gmail.com>> wrote:



On Sep 6, 2022, at 4:48 PM, Alexander Matveev <alexander.matveev at oracle.com<mailto:alexander.matveev at oracle.com>> wrote:

Hi Michael,

Did you generate application image with same JDK version (19+36-2238)? With latest JDK version .jpackage.xml file should be present. We do not support signing of application images generate by another versions of JDK. It should be same JDK.

Thanks,
Alexander



Found this explains some of it.

Re: [jdk19] RFR: 8289030: [macos] app image signature invalid when creating DMG or PKG [v3]

Added this after my build script jpackage invocation to verify .jpackage.xml and version are correct

cat "BlackJack Blastoff_Unsigned.app/Contents/app/.jpackage.xml" | grep "jpackage-state version=?

Showing
<jpackage-state version="19" platform="macOS">

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

From duke at openjdk.org  Wed Sep  7 18:59:43 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 7 Sep 2022 18:59:43 GMT
Subject: RFR: 8287908: Use non-cloning reflection methods where acceptable
 [v3]
In-Reply-To: <cZlvnhWCtA1QALP8IlPlzH9rkITeK8_hDEpSR1DreW0=.9fe3db1d-d4bc-402e-a70c-2bcfc98531e7@github.com>
References: <BIw7M4O4Qvjd04_wmQBV9uENDGS_sd1uGZPt1cGgOqs=.9d5de4e3-a50c-4b17-8c43-314f76eceed4@github.com>
 <cZlvnhWCtA1QALP8IlPlzH9rkITeK8_hDEpSR1DreW0=.9fe3db1d-d4bc-402e-a70c-2bcfc98531e7@github.com>
Message-ID: <JJGRm6mnSYvOsPMlyX3ZMtbqXqj4lM6vlCWNLfe5bNk=.f3627f74-467a-4731-b3b8-391034394c3a@github.com>

On Tue, 14 Jun 2022 19:36:51 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> Instead of `Executable.getParameterTypes()` we could use `Executable.getSharedParameterTypes()` in trusted code. Same is applicable for `Executable.getExceptionTypes()`.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8287908: Make Executable.getAllGenericParameterTypes() safe

@RogerRiggs is there anything I can do about this in addition to what is already done?

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

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

From rriggs at openjdk.org  Wed Sep  7 19:44:45 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 7 Sep 2022 19:44:45 GMT
Subject: RFR: 8287908: Use non-cloning reflection methods where acceptable
 [v3]
In-Reply-To: <cZlvnhWCtA1QALP8IlPlzH9rkITeK8_hDEpSR1DreW0=.9fe3db1d-d4bc-402e-a70c-2bcfc98531e7@github.com>
References: <BIw7M4O4Qvjd04_wmQBV9uENDGS_sd1uGZPt1cGgOqs=.9d5de4e3-a50c-4b17-8c43-314f76eceed4@github.com>
 <cZlvnhWCtA1QALP8IlPlzH9rkITeK8_hDEpSR1DreW0=.9fe3db1d-d4bc-402e-a70c-2bcfc98531e7@github.com>
Message-ID: <iz0rhVHNndNTJqmavyaroZ8_NSerRO1TPMhLnH9GHYo=.2a9aa937-6840-4a54-8360-39360997efcd@github.com>

On Tue, 14 Jun 2022 19:36:51 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> Instead of `Executable.getParameterTypes()` we could use `Executable.getSharedParameterTypes()` in trusted code. Same is applicable for `Executable.getExceptionTypes()`.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8287908: Make Executable.getAllGenericParameterTypes() safe

Looks ok to me.
I was expecting another reviewer to chime in.
(BTW, the change isn't so interesting that reviewers have jumped on the chance).

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

Marked as reviewed by rriggs (Reviewer).

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

From rriggs at openjdk.org  Wed Sep  7 19:44:47 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 7 Sep 2022 19:44:47 GMT
Subject: RFR: 8287908: Use non-cloning reflection methods where acceptable
 [v2]
In-Reply-To: <KqMAl8iMM8VXaUe19U46ujtlFD40RxX3dTGwsKZntG4=.c732b887-8a3a-4902-b436-458b6ecdd52a@github.com>
References: <BIw7M4O4Qvjd04_wmQBV9uENDGS_sd1uGZPt1cGgOqs=.9d5de4e3-a50c-4b17-8c43-314f76eceed4@github.com>
 <i7ttqg9j_Ma_hFqj-bg-kSvpnm2xbl6fEVC6DTWLSWM=.cd3ad1fe-5e65-4d85-9c55-8866c8ab199b@github.com>
 <8gJqFD2EEy97SaUyg0QPZKNJFboCpB9aVIbE5j4bih4=.5117277c-a410-4010-82da-1f0033c041a6@github.com>
 <K6NK1miU8vi0NzizCugrXlC1XewH1zFTtcA6Zm2WC1Q=.22a6794b-e8d6-41d7-96f2-65e34e607821@github.com>
 <KqMAl8iMM8VXaUe19U46ujtlFD40RxX3dTGwsKZntG4=.c732b887-8a3a-4902-b436-458b6ecdd52a@github.com>
Message-ID: <bQmhT2vlVBmf7RpuhfIf2WYuzL3HLP01GfKqw6wxXPg=.6ef9b7f6-ecc6-4d96-bf1a-484f3aedf1d7@github.com>

On Tue, 14 Jun 2022 19:54:44 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Right, I was looking into usages of `getAllGenericParameterTypes()` and all of them are read-only. However I agree that later it might become an issue, so I'd use `getParameterTypes()` in line 345.
>
> You can probably appreciate how hard it is to keep track of what's a copy (and needs to be copied) and what's not through several levels of APIs. From a security perspective, its better to spend a little extra at runtime, than to run the risk of allowing an internal data structure to be corrupted.

To ensure the shared types are not too easily exposed, move 317: to inside the `if (realParamData)`.
That's also the only scope in which it is used.

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

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

From dcubed at openjdk.org  Wed Sep  7 19:45:49 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 7 Sep 2022 19:45:49 GMT
Subject: RFR: 8293496: ProblemList runtime/os/TestTracePageSizes.java on
 linux-x64
In-Reply-To: <CZ6Nl1MrGirVcBczT1r0QTXFJM3jrp0AAiT3zAzI3Nk=.0604afde-49df-4b1d-89a8-436c17fa807c@github.com>
References: <tk1Mh79j3E4_goNT0n-inLZUJDrVbzeAi4yw_fznqk4=.6b0f6d6a-fb8e-46e9-b71e-5ca386a02147@github.com>
 <CZ6Nl1MrGirVcBczT1r0QTXFJM3jrp0AAiT3zAzI3Nk=.0604afde-49df-4b1d-89a8-436c17fa807c@github.com>
Message-ID: <0C8JzZ2dqps9gGcY9EgMiGavNgSba8XYCwrQur1DNBI=.62149552-cba6-4f6c-b3e2-5044393adf72@github.com>

On Wed, 7 Sep 2022 15:20:54 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> A trivial fix to ProblemList runtime/os/TestTracePageSizes.java on linux-x64.
>
> Marked as reviewed by azvegint (Reviewer).

@azvegint - Thanks for your review also. (Just caught up on the email thread).

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

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

From duke at openjdk.org  Wed Sep  7 19:54:45 2022
From: duke at openjdk.org (ExE Boss)
Date: Wed, 7 Sep 2022 19:54:45 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v4]
In-Reply-To: <xrJWvyFSxCoKKFHL5TunUs-Gdr7cZJqp6zG-6UgyGOA=.61545fcd-8e13-4f31-9d6f-19a783eb4ed5@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
 <xrJWvyFSxCoKKFHL5TunUs-Gdr7cZJqp6zG-6UgyGOA=.61545fcd-8e13-4f31-9d6f-19a783eb4ed5@github.com>
Message-ID: <6WDxkch-eI0hI2WF0ZbWcCrC3E96fZoFKLuye2dGjLk=.bc1c79c3-e7d2-4a1c-9ec1-27285141f806@github.com>

On Tue, 6 Sep 2022 09:14:47 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.
>> 
>> Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
>> Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.
>> 
>> Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor formating fixes

src/jdk.jshell/share/classes/jdk/jshell/execution/LocalExecutionControl.java line 51:

> 49:     private boolean userCodeRunning = false;
> 50:     private ThreadGroup execThreadGroup;
> 51:     private Field allStop = null;

It?might be?better to?use a?`VarHandle` for?this (as?it doesn?t?need?boxing or?access?checks on?every?access).

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

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

From smarks at openjdk.org  Wed Sep  7 23:23:42 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 7 Sep 2022 23:23:42 GMT
Subject: RFR: 8291660: Grapheme support in BreakIterator [v4]
In-Reply-To: <gMCB2FydC8HN9bhgEhD_rgJ8nYsH4jbdrwxBf6nV70I=.6200e629-b5e3-4f53-936d-a2b9669daeb3@github.com>
References: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
 <gMCB2FydC8HN9bhgEhD_rgJ8nYsH4jbdrwxBf6nV70I=.6200e629-b5e3-4f53-936d-a2b9669daeb3@github.com>
Message-ID: <B7pt8BV5F7b0lfXYePq3cRVxri7HE7WJC_AOjUWAi7U=.7ceff804-9a59-4d9d-ba47-e50fbfccc54c@github.com>

On Fri, 26 Aug 2022 21:48:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to enhance the character break analysis in `java.text.BreakIterator` to conform to the extended grapheme cluster boundaries defined in https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A corresponding CSR has also been drafted, as there will be behavioral changes with this modification.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed the paragraph to @implSpec

src/java.base/share/classes/jdk/internal/util/regex/Grapheme.java line 47:

> 45:      */
> 46:     public static int nextBoundary(CharSequence src, int off, int limit) {
> 47:         Objects.checkFromToIndex(0, limit - off, src.length());

Is this right? The old code's use of `checkFromToIndex` method seems to be the right way to check that `off` and `limit` are a valid from-to range within `[0, src.length)`. The new code subtracts `off` from both args but the arithmetic seems to allow for some errors. For example, depending on the value of `limit`, this might permit `off` to be a small negative number.

src/java.base/share/classes/sun/util/locale/provider/BreakIteratorProviderImpl.java line 135:

> 133:     public BreakIterator getCharacterInstance(Locale locale) {
> 134:         return new GraphemeBreakIterator();
> 135:     }

It looks like there is some kind of table Since CHARACTER_INDEX is no longer used, does it mean there is now dead code for the CHARACTER break iterator class, and dead resources for CharacterData and CharacterDictionary? Should this be removed? Or maybe this is all in each locale or something and should be cleaned up later?

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

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

From jpai at openjdk.org  Thu Sep  8 05:09:51 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 8 Sep 2022 05:09:51 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v9]
In-Reply-To: <jpjOzk7z0bfD2rIbg_yWGlW3IcaDJqKx2oL8vx9K3K8=.3cc44e7f-babe-46b6-ae6e-7d0581f3c100@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <jpjOzk7z0bfD2rIbg_yWGlW3IcaDJqKx2oL8vx9K3K8=.3cc44e7f-babe-46b6-ae6e-7d0581f3c100@github.com>
Message-ID: <rUMf62LDvb4QNSzwgVnUnStNpEWe1yoa4X8_ZtDr7mk=.76992d5b-45ed-4258-9ee0-5b3cfcad7065@github.com>

On Tue, 6 Sep 2022 17:20:22 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Implementation of JDK-8279283
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "HexPrinter::transferTo"
>   
>   This reverts commit 6f0e2a8f7be5706b39a8e9bc88a97f34d2819098.

test/jdk/java/io/BufferedInputStream/TransferTo.java line 2:

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

Hello Markus, the copyright year here should be `2022` instead of `2021`

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

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

From jpai at openjdk.org  Thu Sep  8 05:55:48 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 8 Sep 2022 05:55:48 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v9]
In-Reply-To: <jpjOzk7z0bfD2rIbg_yWGlW3IcaDJqKx2oL8vx9K3K8=.3cc44e7f-babe-46b6-ae6e-7d0581f3c100@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <jpjOzk7z0bfD2rIbg_yWGlW3IcaDJqKx2oL8vx9K3K8=.3cc44e7f-babe-46b6-ae6e-7d0581f3c100@github.com>
Message-ID: <b5QCtaoe5GQMJolv-H17_onxNge9uzVhWZG0rjNybac=.ea98e71e-0f8f-41f3-b4c6-bdafb2186b79@github.com>

On Tue, 6 Sep 2022 17:20:22 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Implementation of JDK-8279283
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "HexPrinter::transferTo"
>   
>   This reverts commit 6f0e2a8f7be5706b39a8e9bc88a97f34d2819098.

test/jdk/java/io/BufferedInputStream/TransferTo.java line 105:

> 103:     public void testStreamContents() throws Exception {
> 104:         // factory for incoming data provider
> 105:         InputStreamProvider inputStreamProvider = byteArrayInput();

Given that the implementation in this PR now calls the wrapped `InputStream`'s `transferTo` method, should we also include a test where the wrapped `InputStream` is a `FileInputStream` and the target `OutputStream` is a `FileOutputStream`, so that it exercises the `FileChannel#transferTo` code path and verifies the correct data is transferred?

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

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

From duke at openjdk.org  Thu Sep  8 06:09:48 2022
From: duke at openjdk.org (Markus KARG)
Date: Thu, 8 Sep 2022 06:09:48 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v9]
In-Reply-To: <rUMf62LDvb4QNSzwgVnUnStNpEWe1yoa4X8_ZtDr7mk=.76992d5b-45ed-4258-9ee0-5b3cfcad7065@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <jpjOzk7z0bfD2rIbg_yWGlW3IcaDJqKx2oL8vx9K3K8=.3cc44e7f-babe-46b6-ae6e-7d0581f3c100@github.com>
 <rUMf62LDvb4QNSzwgVnUnStNpEWe1yoa4X8_ZtDr7mk=.76992d5b-45ed-4258-9ee0-5b3cfcad7065@github.com>
Message-ID: <_qH7Tpud0TI2H2Jv_maCLJuzVxod3NlbbAU2nq4Vjk4=.9817a70f-2b8e-45b1-a00d-2ce14146f473@github.com>

On Thu, 8 Sep 2022 05:07:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert "HexPrinter::transferTo"
>>   
>>   This reverts commit 6f0e2a8f7be5706b39a8e9bc88a97f34d2819098.
>
> test/jdk/java/io/BufferedInputStream/TransferTo.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.
> 
> Hello Markus, the copyright year here should be `2022` instead of `2021`

Actually I wrote this code in 2021.

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

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

From duke at openjdk.org  Thu Sep  8 06:22:09 2022
From: duke at openjdk.org (Markus KARG)
Date: Thu, 8 Sep 2022 06:22:09 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v9]
In-Reply-To: <b5QCtaoe5GQMJolv-H17_onxNge9uzVhWZG0rjNybac=.ea98e71e-0f8f-41f3-b4c6-bdafb2186b79@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <jpjOzk7z0bfD2rIbg_yWGlW3IcaDJqKx2oL8vx9K3K8=.3cc44e7f-babe-46b6-ae6e-7d0581f3c100@github.com>
 <b5QCtaoe5GQMJolv-H17_onxNge9uzVhWZG0rjNybac=.ea98e71e-0f8f-41f3-b4c6-bdafb2186b79@github.com>
Message-ID: <OcIzi6kemkv0Xfa7CSbQrTNQLGuuywSjRAHUwFssVpg=.6b1aa0e7-78e3-4208-b008-d69f41b52594@github.com>

On Thu, 8 Sep 2022 05:53:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert "HexPrinter::transferTo"
>>   
>>   This reverts commit 6f0e2a8f7be5706b39a8e9bc88a97f34d2819098.
>
> test/jdk/java/io/BufferedInputStream/TransferTo.java line 105:
> 
>> 103:     public void testStreamContents() throws Exception {
>> 104:         // factory for incoming data provider
>> 105:         InputStreamProvider inputStreamProvider = byteArrayInput();
> 
> Given that the implementation in this PR now calls the wrapped `InputStream`'s `transferTo` method, should we also include a test where the wrapped `InputStream` is a `FileInputStream` and the target `OutputStream` is a `FileOutputStream`, so that it exercises the `FileChannel#transferTo` code path and verifies the correct data is transferred?

The correctness of the actually written data is already checked in `checkTransferredContents`. I do not see what you win by replacing `ByteArrayInputStream` by `FileInputStream`. What additional risks do you cover, and what is so special about `FileInputStream` compared to any other `InputStream`? `FileInputStream::transferTo` is already checked by its own unit test.

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

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

From alanb at openjdk.org  Thu Sep  8 06:36:48 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Sep 2022 06:36:48 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v9]
In-Reply-To: <OcIzi6kemkv0Xfa7CSbQrTNQLGuuywSjRAHUwFssVpg=.6b1aa0e7-78e3-4208-b008-d69f41b52594@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <jpjOzk7z0bfD2rIbg_yWGlW3IcaDJqKx2oL8vx9K3K8=.3cc44e7f-babe-46b6-ae6e-7d0581f3c100@github.com>
 <b5QCtaoe5GQMJolv-H17_onxNge9uzVhWZG0rjNybac=.ea98e71e-0f8f-41f3-b4c6-bdafb2186b79@github.com>
 <OcIzi6kemkv0Xfa7CSbQrTNQLGuuywSjRAHUwFssVpg=.6b1aa0e7-78e3-4208-b008-d69f41b52594@github.com>
Message-ID: <ZPkUJ23Vcp0IB_pXE0of7uDFCW-vsa3ezojUfYGmHso=.0e6c88a5-fbd3-42ef-9190-3f7c557d6311@github.com>

On Thu, 8 Sep 2022 06:19:22 GMT, Markus KARG <duke at openjdk.org> wrote:

>> test/jdk/java/io/BufferedInputStream/TransferTo.java line 105:
>> 
>>> 103:     public void testStreamContents() throws Exception {
>>> 104:         // factory for incoming data provider
>>> 105:         InputStreamProvider inputStreamProvider = byteArrayInput();
>> 
>> Given that the implementation in this PR now calls the wrapped `InputStream`'s `transferTo` method, should we also include a test where the wrapped `InputStream` is a `FileInputStream` and the target `OutputStream` is a `FileOutputStream`, so that it exercises the `FileChannel#transferTo` code path and verifies the correct data is transferred?
>
> The correctness of the actually written data is already checked in `checkTransferredContents`. I do not see what you win by replacing `ByteArrayInputStream` by `FileInputStream`. What additional risks do you cover, and what is so special about `FileInputStream` compared to any other `InputStream`? `FileInputStream::transferTo` is already checked by its own unit test.

> Given that the implementation in this PR now calls the wrapped `InputStream`'s `transferTo` method, should we also include a test where the wrapped `InputStream` is a `FileInputStream` and the target `OutputStream` is a `FileOutputStream`, so that it exercises the `FileChannel#transferTo` code path and verifies the correct data is transferred?

Right, the implementation change means that the transferTo implementation of the wrapped input stream is used, or the base InputStream.transferTo is used. We should expect there is good test coverage of these implementations already but checking into that might find opportunities to expand those tests (not this PR of course).

For the new test to exercise the BIS.transferTo then I think it will need to test with a mark set, test when there are buffered bytes (read before transferTo), or when BIS has been extended.

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

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

From duke at openjdk.org  Thu Sep  8 06:43:51 2022
From: duke at openjdk.org (Markus KARG)
Date: Thu, 8 Sep 2022 06:43:51 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v9]
In-Reply-To: <ZPkUJ23Vcp0IB_pXE0of7uDFCW-vsa3ezojUfYGmHso=.0e6c88a5-fbd3-42ef-9190-3f7c557d6311@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <jpjOzk7z0bfD2rIbg_yWGlW3IcaDJqKx2oL8vx9K3K8=.3cc44e7f-babe-46b6-ae6e-7d0581f3c100@github.com>
 <b5QCtaoe5GQMJolv-H17_onxNge9uzVhWZG0rjNybac=.ea98e71e-0f8f-41f3-b4c6-bdafb2186b79@github.com>
 <OcIzi6kemkv0Xfa7CSbQrTNQLGuuywSjRAHUwFssVpg=.6b1aa0e7-78e3-4208-b008-d69f41b52594@github.com>
 <ZPkUJ23Vcp0IB_pXE0of7uDFCW-vsa3ezojUfYGmHso=.0e6c88a5-fbd3-42ef-9190-3f7c557d6311@github.com>
Message-ID: <0RLLED6GtHRlfEiP0etija1-1sYD7AmeuvRiQ_l9vyk=.47d4e178-aa73-4f70-b732-13a9fc76ffef@github.com>

On Thu, 8 Sep 2022 06:32:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The correctness of the actually written data is already checked in `checkTransferredContents`. I do not see what you win by replacing `ByteArrayInputStream` by `FileInputStream`. What additional risks do you cover, and what is so special about `FileInputStream` compared to any other `InputStream`? `FileInputStream::transferTo` is already checked by its own unit test.
>
>> Given that the implementation in this PR now calls the wrapped `InputStream`'s `transferTo` method, should we also include a test where the wrapped `InputStream` is a `FileInputStream` and the target `OutputStream` is a `FileOutputStream`, so that it exercises the `FileChannel#transferTo` code path and verifies the correct data is transferred?
> 
> Right, the implementation change means that the transferTo implementation of the wrapped input stream is used, or the base InputStream.transferTo is used. We should expect there is good test coverage of these implementations already but checking into that might find opportunities to expand those tests (not this PR of course).
> 
> For the new test to exercise the BIS.transferTo then I think it will need to test with a mark set, test when there are buffered bytes (read before transferTo), or when BIS has been extended.

Agreed that testing the non-empty-buffer (read-before-transferTo) and the mark-set cases (mark-before-transferTo), but still I do not see any need to take particularly `FileInputStream` into the boat; files only make the test run slower.

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

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

From duke at openjdk.org  Thu Sep  8 06:56:47 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 8 Sep 2022 06:56:47 GMT
Subject: RFR: 8287908: Use non-cloning reflection methods where acceptable
 [v2]
In-Reply-To: <bQmhT2vlVBmf7RpuhfIf2WYuzL3HLP01GfKqw6wxXPg=.6ef9b7f6-ecc6-4d96-bf1a-484f3aedf1d7@github.com>
References: <BIw7M4O4Qvjd04_wmQBV9uENDGS_sd1uGZPt1cGgOqs=.9d5de4e3-a50c-4b17-8c43-314f76eceed4@github.com>
 <i7ttqg9j_Ma_hFqj-bg-kSvpnm2xbl6fEVC6DTWLSWM=.cd3ad1fe-5e65-4d85-9c55-8866c8ab199b@github.com>
 <8gJqFD2EEy97SaUyg0QPZKNJFboCpB9aVIbE5j4bih4=.5117277c-a410-4010-82da-1f0033c041a6@github.com>
 <K6NK1miU8vi0NzizCugrXlC1XewH1zFTtcA6Zm2WC1Q=.22a6794b-e8d6-41d7-96f2-65e34e607821@github.com>
 <KqMAl8iMM8VXaUe19U46ujtlFD40RxX3dTGwsKZntG4=.c732b887-8a3a-4902-b436-458b6ecdd52a@github.com>
 <bQmhT2vlVBmf7RpuhfIf2WYuzL3HLP01GfKqw6wxXPg=.6ef9b7f6-ecc6-4d96-bf1a-484f3aedf1d7@github.com>
Message-ID: <zOkZnoS1YRjeWiQnxC0tpx3-fyZfV5JuOuNUeb41iq0=.35408d03-4c88-4185-998d-f51d927dee07@github.com>

On Wed, 7 Sep 2022 19:33:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> You can probably appreciate how hard it is to keep track of what's a copy (and needs to be copied) and what's not through several levels of APIs. From a security perspective, its better to spend a little extra at runtime, than to run the risk of allowing an internal data structure to be corrupted.
>
> To ensure the shared types are not too easily exposed, move 317: to inside the `if (realParamData)`.
> That's also the only scope in which it is used.

But `nonGenericParamTypes` is used in `else` block as well, so should I call `getSharedParameterTypes()` twice?

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

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

From shade at openjdk.org  Thu Sep  8 08:04:23 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 8 Sep 2022 08:04:23 GMT
Subject: RFR: 8293499: Provide jmod compression level option
Message-ID: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>

I have been looking into `make clean-images images` performance, and realized jmod keeps compressing files with default compression level. Tuning that toward lighter compression levels improves build performance considerably, without a heavy loss in *.jmod sizes. 

This PR allows JMOD to select the compression level. Follow-ups would use this in the build system.

This change nominally requires CSR, but I would like to gauge the reaction to this patch first, before submitting a formal CSR. The interesting asymmetry against `jlink` is: `jlink` provides `--compress` option that only takes `2` for "ZIP compression". I would argue it would be beneficial to add `--compression-level` to `jlink` as well, so to select the compression level there too.

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

Commit messages:
 - Fix

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

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

From duke at openjdk.org  Thu Sep  8 08:26:43 2022
From: duke at openjdk.org (Markus KARG)
Date: Thu, 8 Sep 2022 08:26:43 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo
 [v10]
In-Reply-To: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
Message-ID: <nkoRspmTOHaEze-cxLxu2N1On3FMeOMT4rpJE_Hx9J0=.b056ebea-c23a-496d-9199-3e005964da01@github.com>

> Implementation of JDK-8279283

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

 - testing transferTo() when mark was set
 - testing transferTo() when buffer is non-empty

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/6935/files
  - new: https://git.openjdk.org/jdk/pull/6935/files/b4d5004d..ab7c170b

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

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

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

From duke at openjdk.org  Thu Sep  8 08:26:44 2022
From: duke at openjdk.org (Markus KARG)
Date: Thu, 8 Sep 2022 08:26:44 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v9]
In-Reply-To: <0RLLED6GtHRlfEiP0etija1-1sYD7AmeuvRiQ_l9vyk=.47d4e178-aa73-4f70-b732-13a9fc76ffef@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <jpjOzk7z0bfD2rIbg_yWGlW3IcaDJqKx2oL8vx9K3K8=.3cc44e7f-babe-46b6-ae6e-7d0581f3c100@github.com>
 <b5QCtaoe5GQMJolv-H17_onxNge9uzVhWZG0rjNybac=.ea98e71e-0f8f-41f3-b4c6-bdafb2186b79@github.com>
 <OcIzi6kemkv0Xfa7CSbQrTNQLGuuywSjRAHUwFssVpg=.6b1aa0e7-78e3-4208-b008-d69f41b52594@github.com>
 <ZPkUJ23Vcp0IB_pXE0of7uDFCW-vsa3ezojUfYGmHso=.0e6c88a5-fbd3-42ef-9190-3f7c557d6311@github.com>
 <0RLLED6GtHRlfEiP0etija1-1sYD7AmeuvRiQ_l9vyk=.47d4e178-aa73-4f70-b732-13a9fc76ffef@github.com>
Message-ID: <9QPnmPJ33rtWrz_YFm3nDucySHcRiDMyXuPfx1t3xBE=.1351c7a5-35df-45ee-8d26-98551fbe7941@github.com>

On Thu, 8 Sep 2022 06:39:58 GMT, Markus KARG <duke at openjdk.org> wrote:

>>> Given that the implementation in this PR now calls the wrapped `InputStream`'s `transferTo` method, should we also include a test where the wrapped `InputStream` is a `FileInputStream` and the target `OutputStream` is a `FileOutputStream`, so that it exercises the `FileChannel#transferTo` code path and verifies the correct data is transferred?
>> 
>> Right, the implementation change means that the transferTo implementation of the wrapped input stream is used, or the base InputStream.transferTo is used. We should expect there is good test coverage of these implementations already but checking into that might find opportunities to expand those tests (not this PR of course).
>> 
>> For the new test to exercise the BIS.transferTo then I think it will need to test with a mark set, test when there are buffered bytes (read before transferTo), or when BIS has been extended.
>
> Agreed that testing the non-empty-buffer (read-before-transferTo) and the mark-set cases (mark-before-transferTo), but still I do not see any need to take particularly `FileInputStream` into the boat; files only make the test run slower.

I have just added testing `transferTo` with non-empty buffer and mark set as part of the already existing *randomized* test steps. I think that should be sufficient to detect problems if they really would exist, so there should not be a real need to run *explicit and separate* test cases for the combinations of "buffered with mark" / "buffered without mark" / "unbuffered with mark" / "unbuffered without mark" as that would not provide any improved coverage or detection rate IMHO.

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

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

From asotona at openjdk.org  Thu Sep  8 08:40:00 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 8 Sep 2022 08:40:00 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v4]
In-Reply-To: <6WDxkch-eI0hI2WF0ZbWcCrC3E96fZoFKLuye2dGjLk=.bc1c79c3-e7d2-4a1c-9ec1-27285141f806@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
 <xrJWvyFSxCoKKFHL5TunUs-Gdr7cZJqp6zG-6UgyGOA=.61545fcd-8e13-4f31-9d6f-19a783eb4ed5@github.com>
 <6WDxkch-eI0hI2WF0ZbWcCrC3E96fZoFKLuye2dGjLk=.bc1c79c3-e7d2-4a1c-9ec1-27285141f806@github.com>
Message-ID: <VO8VdoA35Yy2fWDDMRhf9aJVCrj0yRn8ByMchEX_jHc=.31517850-2a93-4aa2-9d75-bf2de3a76cc0@github.com>

On Wed, 7 Sep 2022 19:48:56 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor formating fixes
>
> src/jdk.jshell/share/classes/jdk/jshell/execution/LocalExecutionControl.java line 51:
> 
>> 49:     private boolean userCodeRunning = false;
>> 50:     private ThreadGroup execThreadGroup;
>> 51:     private Field allStop = null;
> 
> It?might be?better to?use a?`VarHandle` for?this (as?it doesn?t?need?boxing or?access?checks on?every?access).

According to javadoc VarHandle of static field "effectively ignore the volatile declaration".
Volatility of REPL.$Cancel.allStop field is critical for this use case.

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

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

From asotona at openjdk.org  Thu Sep  8 08:40:00 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 8 Sep 2022 08:40:00 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v3]
In-Reply-To: <eqNFeas5FsuQxyjzY2s30KyP33G_0qrhHoy57sxgpX4=.4fb677ec-34c0-49c8-821a-1412bf816f8c@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
 <nVWcamwX-PTcahYaIcHpHGoo2a5ItBrVNW9ImSd5RvM=.214ebaf8-ad2d-4348-8acc-b74d4e03f175@github.com>
 <MHUPVdtqnKJo50BP3ByLUKLPHa49SbTt8lkZjrmtvHM=.35ee2523-330a-4747-925a-c79117d5adef@github.com>
 <eqNFeas5FsuQxyjzY2s30KyP33G_0qrhHoy57sxgpX4=.4fb677ec-34c0-49c8-821a-1412bf816f8c@github.com>
Message-ID: <c-KjQfLp_Vn_r2kK-D7RKWpbWuN8CnHQkast3TXChsA=.a0f28368-0568-4be4-89b8-e33ad38bebfa@github.com>

On Tue, 6 Sep 2022 09:05:53 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/jdk.jshell/share/classes/jdk/jshell/execution/LocalExecutionControl.java line 200:
>> 
>>> 198:                 allStop.set(null, true);
>>> 199:             } catch (IllegalArgumentException| IllegalAccessException ex) {
>>> 200:                 throw new InternalException(ex.getMessage());
>> 
>> to avoid to drop the stack trace of the original exception, it's better to chain the exceptions,
>> 
>>   throw (InternalException) new InternalException().initCause(ex);
>
> I just followed similar pattern as in other 9 cases of throwing new InternalException in idk.jshell.

Adjusted exception message construction to exactly match other cases.

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

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

From jpai at openjdk.org  Thu Sep  8 08:42:44 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 8 Sep 2022 08:42:44 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v9]
In-Reply-To: <_qH7Tpud0TI2H2Jv_maCLJuzVxod3NlbbAU2nq4Vjk4=.9817a70f-2b8e-45b1-a00d-2ce14146f473@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <jpjOzk7z0bfD2rIbg_yWGlW3IcaDJqKx2oL8vx9K3K8=.3cc44e7f-babe-46b6-ae6e-7d0581f3c100@github.com>
 <rUMf62LDvb4QNSzwgVnUnStNpEWe1yoa4X8_ZtDr7mk=.76992d5b-45ed-4258-9ee0-5b3cfcad7065@github.com>
 <_qH7Tpud0TI2H2Jv_maCLJuzVxod3NlbbAU2nq4Vjk4=.9817a70f-2b8e-45b1-a00d-2ce14146f473@github.com>
Message-ID: <gQUwyL4NKd-T4DAcDou688_fXhbr93CR2KuVKOVN5Hw=.d98693f7-ef4a-4e93-80c9-39028ff08119@github.com>

On Thu, 8 Sep 2022 06:05:51 GMT, Markus KARG <duke at openjdk.org> wrote:

> Actually I wrote this code in 2021. What are the official rules here, do I have to use the original date or the latest change date?

I remember reading it somewhere but I can't seem  to locate the text right now and it isn't mentioned in the OpenJDK developer's guide either https://openjdk.org/guide/.
>From what I remember, the copyright year is of the form `year1, [year2]` where `year1` is the year the file was first added to the project (so in this case it would be `2022`) and `year2` is the year it was last updated. That's my understanding of the guidelines. Others can correct me if that isn't accurate.

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

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

From alanb at openjdk.org  Thu Sep  8 08:51:53 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Sep 2022 08:51:53 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v4]
In-Reply-To: <VO8VdoA35Yy2fWDDMRhf9aJVCrj0yRn8ByMchEX_jHc=.31517850-2a93-4aa2-9d75-bf2de3a76cc0@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
 <xrJWvyFSxCoKKFHL5TunUs-Gdr7cZJqp6zG-6UgyGOA=.61545fcd-8e13-4f31-9d6f-19a783eb4ed5@github.com>
 <6WDxkch-eI0hI2WF0ZbWcCrC3E96fZoFKLuye2dGjLk=.bc1c79c3-e7d2-4a1c-9ec1-27285141f806@github.com>
 <VO8VdoA35Yy2fWDDMRhf9aJVCrj0yRn8ByMchEX_jHc=.31517850-2a93-4aa2-9d75-bf2de3a76cc0@github.com>
Message-ID: <O3BQ14WJo_eD5koxEhIis-MY4ri9P6BpV9HfdfSOpBI=.20b41057-0373-4a58-a2ec-2aa17b80100c@github.com>

On Thu, 8 Sep 2022 08:34:59 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> According to javadoc VarHandle of static field "effectively ignore the volatile declaration".
> Volatility of REPL.$Cancel.allStop field is critical for this use case.

VarHandles defines xxxVolatile so it would be feasible but I don't see a strong need to change it as the reflective op is only done at the start to reset "stop" and when control-C/stop is done.

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

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

From jlahoda at openjdk.org  Thu Sep  8 09:53:34 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 8 Sep 2022 09:53:34 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v4]
In-Reply-To: <xrJWvyFSxCoKKFHL5TunUs-Gdr7cZJqp6zG-6UgyGOA=.61545fcd-8e13-4f31-9d6f-19a783eb4ed5@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
 <xrJWvyFSxCoKKFHL5TunUs-Gdr7cZJqp6zG-6UgyGOA=.61545fcd-8e13-4f31-9d6f-19a783eb4ed5@github.com>
Message-ID: <Ybp8lCA2bBRkAy786RW9bJNXhuzu7w4YHnGre2x_3RA=.1cd00c92-458d-4ca2-b2a9-1e476de391b3@github.com>

On Tue, 6 Sep 2022 09:14:47 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.
>> 
>> Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
>> Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.
>> 
>> Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor formating fixes

Marked as reviewed by jlahoda (Reviewer).

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

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

From asotona at openjdk.org  Thu Sep  8 10:06:47 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 8 Sep 2022 10:06:47 GMT
Subject: Integrated: 8289613: Drop use of Thread.stop in jshell
In-Reply-To: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
Message-ID: <9SQ5u6EHSaEdUMrd0_i598-6OcfrKuhT-DbJgfbASek=.88fa004f-d99e-4f1b-947a-3e9635a0e6e3@github.com>

On Mon, 5 Sep 2022 12:39:41 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.
> 
> Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
> Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.
> 
> Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: ffc249ae
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ffc249ae2120752a9c0e9de18167b0c16f2de410
Stats:     71 lines in 2 files changed: 67 ins; 1 del; 3 mod

8289613: Drop use of Thread.stop in jshell

Reviewed-by: jlahoda

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

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

From jpai at openjdk.org  Thu Sep  8 10:24:35 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 8 Sep 2022 10:24:35 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v9]
In-Reply-To: <9QPnmPJ33rtWrz_YFm3nDucySHcRiDMyXuPfx1t3xBE=.1351c7a5-35df-45ee-8d26-98551fbe7941@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <jpjOzk7z0bfD2rIbg_yWGlW3IcaDJqKx2oL8vx9K3K8=.3cc44e7f-babe-46b6-ae6e-7d0581f3c100@github.com>
 <b5QCtaoe5GQMJolv-H17_onxNge9uzVhWZG0rjNybac=.ea98e71e-0f8f-41f3-b4c6-bdafb2186b79@github.com>
 <OcIzi6kemkv0Xfa7CSbQrTNQLGuuywSjRAHUwFssVpg=.6b1aa0e7-78e3-4208-b008-d69f41b52594@github.com>
 <ZPkUJ23Vcp0IB_pXE0of7uDFCW-vsa3ezojUfYGmHso=.0e6c88a5-fbd3-42ef-9190-3f7c557d6311@github.com>
 <0RLLED6GtHRlfEiP0etija1-1sYD7AmeuvRiQ_l9vyk=.47d4e178-aa73-4f70-b732-13a9fc76ffef@github.com>
 <9QPnmPJ33rtWrz_YFm3nDucySHcRiDMyXuPfx1t3xBE=.1351c7a5-35df-45ee-8d26-98551fbe7941@github.com>
Message-ID: <7j_VoKwXD1ZRL6BHybuOhyw97Zd5htRn_HdRF2eF6JE=.c1088a2d-f461-471d-9ebd-7372e9f3ac20@github.com>

On Thu, 8 Sep 2022 08:22:14 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Agreed that testing the non-empty-buffer (read-before-transferTo) and the mark-set cases (mark-before-transferTo), but still I do not see any need to take particularly `FileInputStream` into the boat; files only make the test run slower.
>
> I have just added testing `transferTo` with non-empty buffer and mark set as part of the already existing *randomized* test steps. I think that should be sufficient to detect problems if they really would exist, so there should not be a real need to run *explicit and separate* test cases for the combinations of "buffered with mark" / "buffered without mark" / "unbuffered with mark" / "unbuffered without mark" as that would not provide any improved coverage or detection rate IMHO.

My intention of suggesting a test where it uses something like a FileInputStream was to trigger the code path that would invoke the `FileChannel#transferTo` when such an `InputStream` was wrapped in a `BufferedInputStream`. The `FileChannel#transferTo` in its javadoc states that it can throw exceptions that aren't `IOException` (for example `NonReadableChannelException` which is a `IllegalStateException`). So it was just an attempt to see if such a testing uncovers something that might make us consider catching those exceptions in this new implementation of `BufferedInputStream#transferTo` and rethrow it as an `IOException`.

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

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

From duke at openjdk.org  Thu Sep  8 10:24:35 2022
From: duke at openjdk.org (Markus KARG)
Date: Thu, 8 Sep 2022 10:24:35 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v9]
In-Reply-To: <7j_VoKwXD1ZRL6BHybuOhyw97Zd5htRn_HdRF2eF6JE=.c1088a2d-f461-471d-9ebd-7372e9f3ac20@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <jpjOzk7z0bfD2rIbg_yWGlW3IcaDJqKx2oL8vx9K3K8=.3cc44e7f-babe-46b6-ae6e-7d0581f3c100@github.com>
 <b5QCtaoe5GQMJolv-H17_onxNge9uzVhWZG0rjNybac=.ea98e71e-0f8f-41f3-b4c6-bdafb2186b79@github.com>
 <OcIzi6kemkv0Xfa7CSbQrTNQLGuuywSjRAHUwFssVpg=.6b1aa0e7-78e3-4208-b008-d69f41b52594@github.com>
 <ZPkUJ23Vcp0IB_pXE0of7uDFCW-vsa3ezojUfYGmHso=.0e6c88a5-fbd3-42ef-9190-3f7c557d6311@github.com>
 <0RLLED6GtHRlfEiP0etija1-1sYD7AmeuvRiQ_l9vyk=.47d4e178-aa73-4f70-b732-13a9fc76ffef@github.com>
 <9QPnmPJ33rtWrz_YFm3nDucySHcRiDMyXuPfx1t3xBE=.1351c7a5-35df-45ee-8d26-98551fbe7941@github.com>
 <7j_VoKwXD1ZRL6BHybuOhyw97Zd5htRn_HdRF2eF6JE=.c1088a2d-f461-471d-9ebd-7372e9f3ac20@github.com>
Message-ID: <z1TFWcXrdJoJyvYZ-4YuWa9uGEh1_n2f7BOS0HmuFX8=.c805d58c-aad1-4571-a286-6b7fd7bd075c@github.com>

On Thu, 8 Sep 2022 08:45:02 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> I have just added testing `transferTo` with non-empty buffer and mark set as part of the already existing *randomized* test steps. I think that should be sufficient to detect problems if they really would exist, so there should not be a real need to run *explicit and separate* test cases for the combinations of "buffered with mark" / "buffered without mark" / "unbuffered with mark" / "unbuffered without mark" as that would not provide any improved coverage or detection rate IMHO.
>
> My intention of suggesting a test where it uses something like a FileInputStream was to trigger the code path that would invoke the `FileChannel#transferTo` when such an `InputStream` was wrapped in a `BufferedInputStream`. The `FileChannel#transferTo` in its javadoc states that it can throw exceptions that aren't `IOException` (for example `NonReadableChannelException` which is a `IllegalStateException`). So it was just an attempt to see if such a testing uncovers something that might make us consider catching those exceptions in this new implementation of `BufferedInputStream#transferTo` and rethrow it as an `IOException`.

The original implementation of `InputStream::transferTo()` doesn't do that either, so if you think `transferTo()` must do that, that has to go into the *original* implementation, not only into the one of BIS in particular. To keep things simple, I'd propose that we do not mix ideas and you file a new issue / PR for that.

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

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

From duke at openjdk.org  Thu Sep  8 12:24:59 2022
From: duke at openjdk.org (Markus KARG)
Date: Thu, 8 Sep 2022 12:24:59 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v9]
In-Reply-To: <gQUwyL4NKd-T4DAcDou688_fXhbr93CR2KuVKOVN5Hw=.d98693f7-ef4a-4e93-80c9-39028ff08119@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <jpjOzk7z0bfD2rIbg_yWGlW3IcaDJqKx2oL8vx9K3K8=.3cc44e7f-babe-46b6-ae6e-7d0581f3c100@github.com>
 <rUMf62LDvb4QNSzwgVnUnStNpEWe1yoa4X8_ZtDr7mk=.76992d5b-45ed-4258-9ee0-5b3cfcad7065@github.com>
 <_qH7Tpud0TI2H2Jv_maCLJuzVxod3NlbbAU2nq4Vjk4=.9817a70f-2b8e-45b1-a00d-2ce14146f473@github.com>
 <gQUwyL4NKd-T4DAcDou688_fXhbr93CR2KuVKOVN5Hw=.d98693f7-ef4a-4e93-80c9-39028ff08119@github.com>
Message-ID: <uH-1RNihIinJKFqtqE-R1flb8-3qNIgy_u9uiPkPH1Q=.6d36a0cc-3cf6-42d9-86b9-287a6414ab9b@github.com>

On Thu, 8 Sep 2022 08:39:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Actually I wrote this code in 2021. What are the official rules here, do I have to use the original date or the latest change date?
>
>> Actually I wrote this code in 2021. What are the official rules here, do I have to use the original date or the latest change date?
> 
> I remember reading it somewhere but I can't seem  to locate the text right now and it isn't mentioned in the OpenJDK developer's guide either https://openjdk.org/guide/.
> From what I remember, the copyright year is of the form `year1, [year2]` where `year1` is the year the file was first added to the project (so in this case it would be `2022`) and `year2` is the year it was last updated. That's my understanding of the guidelines. Others can correct me if that isn't accurate.

Correct, but **2021** is right here, as the second date (last change) is *optional*, and I interpret "added" as "opened pr".

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

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

From alanb at openjdk.org  Thu Sep  8 13:38:40 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Sep 2022 13:38:40 GMT
Subject: RFR: 8293499: Provide jmod compression level option
In-Reply-To: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
Message-ID: <GclIe6dfd6sfc5KP1sDNM198cvrw16vOHOHbquG90do=.ee720293-7071-4b58-bfce-7eea0375ed80@github.com>

On Thu, 8 Sep 2022 07:57:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have been looking into `make clean-images images` performance, and realized jmod keeps compressing files with default compression level. Tuning that toward lighter compression levels improves build performance considerably, without a heavy loss in *.jmod sizes. 
> 
> This PR allows JMOD to select the compression level. Follow-ups would use this in the build system, see #10214.
> 
> This change nominally requires CSR, but I would like to gauge the reaction to this patch first, before submitting a formal CSR. The interesting asymmetry against `jlink` is: `jlink` provides `--compress` option that only takes `2` for "ZIP compression". I would argue it would be beneficial to add `--compression-level` to `jlink` as well, so to select the compression level there too.

I don't have time to look at this closely today but I think an option to configure the compression level wouldn't look out of place on the jmod tool.

Doing the equivalent with jlink would require more thought to see if it makes sense or is really needed. The jimage format is for execution, not a packaging format like jmod that is primarily consumed at link-time. I agree the  jlink --compress option is a bit overloaded where --compress=0 and --compress=2 are more like jar --no-compress or its default to deflate. The jar tool doesn't have an option to set the compression level.

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

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

From rriggs at openjdk.org  Thu Sep  8 14:25:05 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 8 Sep 2022 14:25:05 GMT
Subject: RFR: 8287908: Use non-cloning reflection methods where acceptable
 [v2]
In-Reply-To: <zOkZnoS1YRjeWiQnxC0tpx3-fyZfV5JuOuNUeb41iq0=.35408d03-4c88-4185-998d-f51d927dee07@github.com>
References: <BIw7M4O4Qvjd04_wmQBV9uENDGS_sd1uGZPt1cGgOqs=.9d5de4e3-a50c-4b17-8c43-314f76eceed4@github.com>
 <i7ttqg9j_Ma_hFqj-bg-kSvpnm2xbl6fEVC6DTWLSWM=.cd3ad1fe-5e65-4d85-9c55-8866c8ab199b@github.com>
 <8gJqFD2EEy97SaUyg0QPZKNJFboCpB9aVIbE5j4bih4=.5117277c-a410-4010-82da-1f0033c041a6@github.com>
 <K6NK1miU8vi0NzizCugrXlC1XewH1zFTtcA6Zm2WC1Q=.22a6794b-e8d6-41d7-96f2-65e34e607821@github.com>
 <KqMAl8iMM8VXaUe19U46ujtlFD40RxX3dTGwsKZntG4=.c732b887-8a3a-4902-b436-458b6ecdd52a@github.com>
 <bQmhT2vlVBmf7RpuhfIf2WYuzL3HLP01GfKqw6wxXPg=.6ef9b7f6-ecc6-4d96-bf1a-484f3aedf1d7@github.com>
 <zOkZnoS1YRjeWiQnxC0tpx3-fyZfV5JuOuNUeb41iq0=.35408d03-4c88-4185-998d-f51d927dee07@github.com>
Message-ID: <ICXBAka_5uTlmVQpnAqn7LUffFaH4EUgdzljYWx9eoE=.4f505319-1c08-47f6-a178-b0e5cb1cc6f5@github.com>

On Thu, 8 Sep 2022 06:54:45 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> To ensure the shared types are not too easily exposed, move 317: to inside the `if (realParamData)`.
>> That's also the only scope in which it is used.
>
> But `nonGenericParamTypes` is used in `else` block as well, so should I call `getSharedParameterTypes()` twice?

My mistake, its ok as is.  tnx.

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

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

From naoto at openjdk.org  Thu Sep  8 16:11:57 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 8 Sep 2022 16:11:57 GMT
Subject: RFR: 8291660: Grapheme support in BreakIterator [v5]
In-Reply-To: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
References: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
Message-ID: <1FaPRQjWWE3I3jAyr2vyRnecYFIve45caRkDzNRLr1g=.fa0237b6-2793-49a1-8349-ab09371bf151@github.com>

> This is to enhance the character break analysis in `java.text.BreakIterator` to conform to the extended grapheme cluster boundaries defined in https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A corresponding CSR has also been drafted, as there will be behavioral changes with this modification.

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

 - Reverted the index checking fix
 - Removed character break data which is no longer needed
 - Merge branch 'master' into JDK-8291660-graphemes
 - Changed the paragraph to @implSpec
 - Reverting the fix to BreakIterator.isBoundary()
 - Fixing JCK failures
 - Addressing review comments
 - 8291660: Grapheme support in BreakIterator
 - 8291660: Add a method to stream extended grapheme clusters in a String

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9991/files
  - new: https://git.openjdk.org/jdk/pull/9991/files/06cfc222..2f31d417

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

  Stats: 74365 lines in 1082 files changed: 32063 ins; 34006 del; 8296 mod
  Patch: https://git.openjdk.org/jdk/pull/9991.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9991/head:pull/9991

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

From naoto at openjdk.org  Thu Sep  8 16:14:30 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 8 Sep 2022 16:14:30 GMT
Subject: RFR: 8291660: Grapheme support in BreakIterator [v4]
In-Reply-To: <B7pt8BV5F7b0lfXYePq3cRVxri7HE7WJC_AOjUWAi7U=.7ceff804-9a59-4d9d-ba47-e50fbfccc54c@github.com>
References: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
 <gMCB2FydC8HN9bhgEhD_rgJ8nYsH4jbdrwxBf6nV70I=.6200e629-b5e3-4f53-936d-a2b9669daeb3@github.com>
 <B7pt8BV5F7b0lfXYePq3cRVxri7HE7WJC_AOjUWAi7U=.7ceff804-9a59-4d9d-ba47-e50fbfccc54c@github.com>
Message-ID: <_ROpfVbWGm458N8rQ6gUOmfUArxrl7Ufm3slZUwjX5A=.06e59d20-50c8-4d03-a16f-4fdc7fdcd85c@github.com>

On Wed, 7 Sep 2022 21:27:10 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changed the paragraph to @implSpec
>
> src/java.base/share/classes/jdk/internal/util/regex/Grapheme.java line 47:
> 
>> 45:      */
>> 46:     public static int nextBoundary(CharSequence src, int off, int limit) {
>> 47:         Objects.checkFromToIndex(0, limit - off, src.length());
> 
> Is this right? The old code's use of `checkFromToIndex` method seems to be the right way to check that `off` and `limit` are a valid from-to range within `[0, src.length)`. The new code subtracts `off` from both args but the arithmetic seems to allow for some errors. For example, depending on the value of `limit`, this might permit `off` to be a small negative number.

Thanks for the catch! Yes, this was a leftover before I fixed a couple of JCK failures which correctly fixed edge cases. Reverted the change.

> src/java.base/share/classes/sun/util/locale/provider/BreakIteratorProviderImpl.java line 135:
> 
>> 133:     public BreakIterator getCharacterInstance(Locale locale) {
>> 134:         return new GraphemeBreakIterator();
>> 135:     }
> 
> It looks like there is some kind of table Since CHARACTER_INDEX is no longer used, does it mean there is now dead code for the CHARACTER break iterator class, and dead resources for CharacterData and CharacterDictionary? Should this be removed? Or maybe this is all in each locale or something and should be cleaned up later?

Right. Removed the now-dead code.

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

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

From naoto at openjdk.org  Thu Sep  8 18:32:56 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 8 Sep 2022 18:32:56 GMT
Subject: RFR: 8291660: Grapheme support in BreakIterator [v6]
In-Reply-To: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
References: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
Message-ID: <-vMSsSpfdN9yInhc30W0R3MNURpC7WuLr0xehsufqxs=.479c0683-e3c3-47cb-b83e-e83108077094@github.com>

> This is to enhance the character break analysis in `java.text.BreakIterator` to conform to the extended grapheme cluster boundaries defined in https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A corresponding CSR has also been drafted, as there will be behavioral changes with this modification.

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

  Removed unnecessary comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9991/files
  - new: https://git.openjdk.org/jdk/pull/9991/files/2f31d417..e8e037c2

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

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

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

From duke at openjdk.org  Thu Sep  8 19:22:37 2022
From: duke at openjdk.org (Weibing Xiao)
Date: Thu, 8 Sep 2022 19:22:37 GMT
Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir
 directory doesn't exist [v2]
In-Reply-To: <rjEWqSaj5cFnFbv-bFsv7Ab1qpwgfoKe9mILyMuXH_M=.b8b570a7-27cf-494a-805b-3e04dd404bc6@github.com>
References: <rjEWqSaj5cFnFbv-bFsv7Ab1qpwgfoKe9mILyMuXH_M=.b8b570a7-27cf-494a-805b-3e04dd404bc6@github.com>
Message-ID: <MlgCrMDsYqv2oqdmK3ZLqeWSjLHgQhcTkSZ-36bkrAY=.824b6879-b0be-4e00-9f29-3f7dbdb60e74@github.com>

> 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist

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

  add the change for nio and update the code according to the comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9989/files
  - new: https://git.openjdk.org/jdk/pull/9989/files/9f5a2983..cacf41d6

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

  Stats: 90 lines in 6 files changed: 69 ins; 12 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/9989.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9989/head:pull/9989

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

From duke at openjdk.org  Thu Sep  8 19:25:16 2022
From: duke at openjdk.org (Weibing Xiao)
Date: Thu, 8 Sep 2022 19:25:16 GMT
Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir
 directory doesn't exist
In-Reply-To: <rjEWqSaj5cFnFbv-bFsv7Ab1qpwgfoKe9mILyMuXH_M=.b8b570a7-27cf-494a-805b-3e04dd404bc6@github.com>
References: <rjEWqSaj5cFnFbv-bFsv7Ab1qpwgfoKe9mILyMuXH_M=.b8b570a7-27cf-494a-805b-3e04dd404bc6@github.com>
Message-ID: <gVJUtb-6_8NjeJQHOAAyrZdJLqLssse3DfjisZAcwKY=.a08a79ca-382d-4cf4-a0e2-7faf0dcfc447@github.com>

On Tue, 23 Aug 2022 18:32:30 GMT, Weibing Xiao <duke at openjdk.org> wrote:

> 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist

1) Remove the setting in java.security, not displaying the folder name of java.io.tmpdir
2) Add the change for NIO
3) Update the testing files.
4) In testing files, java.io.tmpdir is added as the option of command line

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

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

From rriggs at openjdk.org  Thu Sep  8 20:34:31 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 8 Sep 2022 20:34:31 GMT
Subject: RFR: 8293282: LoadLibraryUnloadTest.java fails with
 "Too few cleared WeakReferences"
Message-ID: <O7RYAAkE9CHAAzWdTLQBCaaEns3vK6c896tmx8Ul0rM=.bccf6768-e5b1-4bd3-85f7-4dfd27277bfb@github.com>

Modify the LoadLibraryUnload test to call gc() more a few times, allowing multiple gc cycles to queue the expected refs.
Short the timeout on each cycle to 10 sec.

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

Commit messages:
 - Add bugid to LoadLibraryUnloadTest
 - Modify the wait loop to repeat the System.gc and count queued refs.

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

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

From mchung at openjdk.org  Thu Sep  8 20:56:46 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 8 Sep 2022 20:56:46 GMT
Subject: RFR: 8293282: LoadLibraryUnloadTest.java fails with
 "Too few cleared WeakReferences"
In-Reply-To: <O7RYAAkE9CHAAzWdTLQBCaaEns3vK6c896tmx8Ul0rM=.bccf6768-e5b1-4bd3-85f7-4dfd27277bfb@github.com>
References: <O7RYAAkE9CHAAzWdTLQBCaaEns3vK6c896tmx8Ul0rM=.bccf6768-e5b1-4bd3-85f7-4dfd27277bfb@github.com>
Message-ID: <1Rr-_8-7Und4z_ivbHwgwSLCY-gYuRZApv0vGe_xU0E=.b1ca81d5-90d0-47ff-ab43-051f47d0c70b@github.com>

On Thu, 8 Sep 2022 20:26:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Modify the LoadLibraryUnload test to call gc() more a few times, allowing multiple gc cycles to queue the expected refs.
> Short the timeout on each cycle to 10 sec.

test/jdk/java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnload.java line 171:

> 169:                 dequeueCount++;
> 170:         }
> 171:         Asserts.assertEquals(dequeueCount, LOADER_COUNT, "Too few cleared WeakReferences");

This only invokes GC `LOADER_COUNT` times.  I think you may want something like what ForceGC does:


        int retries = (int)(Math.round(1000L * TIMEOUT_FACTOR) / 200);
        for (; retries >= 0; retries--) {
            if (dequeueCount == LOADER_COUNT) return;
            
            System.gc();
            refQueue.remove(200L);
        }

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

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

From duke at openjdk.org  Thu Sep  8 21:28:33 2022
From: duke at openjdk.org (Rahul Prabhu)
Date: Thu, 8 Sep 2022 21:28:33 GMT
Subject: RFR: 8289508: Improve test coverage for XPath Axes: ancestor,
 ancestor-or-self, preceding, and preceding-sibling
Message-ID: <xn1BRpM7AtPakAYm2AdbtoddvmCNqP3wBPwjMGUPx8w=.4aaac0f2-1383-4e45-b49e-d1da3cfbdf43@github.com>

Created two files for testing XPath Axes: XPathAncestors.java tests the ancestor and ancestor-or-self axes, while XPathPrecedingTest.java tests the preceding and preceding-sibling axes.

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

Commit messages:
 - Update XPathAncestorsTest.java to remove whitespace
 - 8289508: Update PrecedingTest to remove whitespace
 - 8289508: update to remove whitespaces in XPathAncestorsTest.java
 - Delete XPathAncestorsPrecedingTest.java
 - 8289508: Improve test coverage for XPath Axes: ancestor, ancestor-or-self, preceding, and preceding-sibling, separated tests and labeled testing between ancestor and preceding
 - 8289508: Improve test coverage for XPath Axes: ancestor, ancestor-or-self, preceding, and preceding-sibling
 - Merge branch '8289508' of github.com:Ruprabhu25/jdk into 8289508
 - added test for ancestor/preceding and related axes
 - 8289508 Improve test coverage for XPath Axes: ancestor, ancestor-or-self, preceding, and preceding-sibling

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

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

From rhalade at openjdk.org  Thu Sep  8 21:28:34 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 8 Sep 2022 21:28:34 GMT
Subject: RFR: 8289508: Improve test coverage for XPath Axes: ancestor,
 ancestor-or-self, preceding, and preceding-sibling
In-Reply-To: <xn1BRpM7AtPakAYm2AdbtoddvmCNqP3wBPwjMGUPx8w=.4aaac0f2-1383-4e45-b49e-d1da3cfbdf43@github.com>
References: <xn1BRpM7AtPakAYm2AdbtoddvmCNqP3wBPwjMGUPx8w=.4aaac0f2-1383-4e45-b49e-d1da3cfbdf43@github.com>
Message-ID: <A34UIWos48mBbQ9PtXW_Bdlxx7hBQK4UeqLKmHCOHu0=.f24e912b-88ed-4336-97b2-b8f69d06bd59@github.com>

On Thu, 8 Sep 2022 06:19:10 GMT, Rahul Prabhu <duke at openjdk.org> wrote:

> Created two files for testing XPath Axes: XPathAncestors.java tests the ancestor and ancestor-or-self axes, while XPathPrecedingTest.java tests the preceding and preceding-sibling axes.

Please fix jcheck issues. Code has trailing whitespaces on several lines.

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

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

From duke at openjdk.org  Thu Sep  8 21:28:35 2022
From: duke at openjdk.org (Rahul Prabhu)
Date: Thu, 8 Sep 2022 21:28:35 GMT
Subject: RFR: 8289508: Improve test coverage for XPath Axes: ancestor,
 ancestor-or-self, preceding, and preceding-sibling
In-Reply-To: <A34UIWos48mBbQ9PtXW_Bdlxx7hBQK4UeqLKmHCOHu0=.f24e912b-88ed-4336-97b2-b8f69d06bd59@github.com>
References: <xn1BRpM7AtPakAYm2AdbtoddvmCNqP3wBPwjMGUPx8w=.4aaac0f2-1383-4e45-b49e-d1da3cfbdf43@github.com>
 <A34UIWos48mBbQ9PtXW_Bdlxx7hBQK4UeqLKmHCOHu0=.f24e912b-88ed-4336-97b2-b8f69d06bd59@github.com>
Message-ID: <V1OzbTD0NZRQYBrN5SRwADBWYBpyAeOsj1dTNdULoqI=.93ce9efa-f72c-4856-82cb-0fb405386be7@github.com>

On Thu, 8 Sep 2022 15:54:03 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> Created two files for testing XPath Axes: XPathAncestors.java tests the ancestor and ancestor-or-self axes, while XPathPrecedingTest.java tests the preceding and preceding-sibling axes.
>
> Please fix jcheck issues. Code has trailing whitespaces on several lines.

@rhalade should be good for review now.

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

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

From mchung at openjdk.org  Fri Sep  9 02:02:45 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 9 Sep 2022 02:02:45 GMT
Subject: RFR: 8293499: Provide jmod compression level option
In-Reply-To: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
Message-ID: <YM26uQJWU4QDo_TWPF0N6gBGPeqr44FQr1kN3U26A_k=.fe4134c7-c2c1-47c5-900f-9bf152abc5c0@github.com>

On Thu, 8 Sep 2022 07:57:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have been looking into `make clean-images images` performance, and realized jmod keeps compressing files with default compression level. Tuning that toward lighter compression levels improves build performance considerably, without a heavy loss in *.jmod sizes. 
> 
> This PR allows JMOD to select the compression level. Follow-ups would use this in the build system, see #10214.
> 
> This change nominally requires CSR, but I would like to gauge the reaction to this patch first, before submitting a formal CSR. The interesting asymmetry against `jlink` is: `jlink` provides `--compress` option that only takes `2` for "ZIP compression". I would argue it would be beneficial to add `--compression-level` to `jlink` as well, so to select the compression level there too.

It's reasonable for jmod tool to support `--compress-level` option to specify the compression level.   The JMOD file format is not specified but the implementation uses ZIP.  Compression level from 0-9 makes sense for ZIP but may not be applicable if the JMOD file format is changed.   But it may be okay to worry about that when the file format is changed.

For jlink, when resources are compressed in writing to jimage, there would be performance overhead in reading and decompressing the resources at runtime.   I'd be interested in knowing the tradeoff between the smaller jimage vs the runtime overhead in decompressing the resources.   I'd advice to separate the jmod compression level change from jlink compression level discussion.

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

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

From jpai at openjdk.org  Fri Sep  9 03:40:38 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 9 Sep 2022 03:40:38 GMT
Subject: RFR: 8293282: LoadLibraryUnloadTest.java fails with
 "Too few cleared WeakReferences"
In-Reply-To: <O7RYAAkE9CHAAzWdTLQBCaaEns3vK6c896tmx8Ul0rM=.bccf6768-e5b1-4bd3-85f7-4dfd27277bfb@github.com>
References: <O7RYAAkE9CHAAzWdTLQBCaaEns3vK6c896tmx8Ul0rM=.bccf6768-e5b1-4bd3-85f7-4dfd27277bfb@github.com>
Message-ID: <fX9LMqzWyBclf-6wmcEJj8ZAkioWh9d5-jI8KsrUVBs=.87d2c4ab-947d-41fc-a518-3c06c78d703b@github.com>

On Thu, 8 Sep 2022 20:26:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Modify the LoadLibraryUnload test to call gc() more a few times, allowing multiple gc cycles to queue the expected refs.
> Short the timeout on each cycle to 10 sec.

Hello Roger, just a few additional points that I noticed about this test. I haven't fully investigated to see if they play any role at all, but I thought I will note them here:

- The `LoadLibraryUnloadTest` which acts as a driver, launches the `LoadLibraryUnload` as a Java program. There's no specific memory settings passed when that program is launched (line 82 of `LoadLibraryUnloadTest`). I did a quick test a few days back where I updated the process builder launch command to use `-XshowSettings:all` to see what the inferred memory setting would be for this program on our CI systems and I could see that in many cases the estimated max heap size was as big as 7G:

[0.001s][trace][gc] MarkStackSize: 4096k  MarkStackSizeMax: 524288k
[0.002s][info ][gc] Using G1
[0.002s][debug][gc] ConcGCThreads: 2 offset 16
[0.002s][debug][gc] ParallelGCThreads: 8
[0.002s][debug][gc] Initialize mark stack with 4096 chunks, maximum 524288
VM settings:
    Max. Heap Size (Estimated): 7.75G
    Using VM: Java HotSpot(TM) 64-Bit Server VM

So, would it be relevant/useful if the driver launched the `LoadLibraryUnload` with a more specific/lesser value of max heap size?

- The driver `LoadLibraryUnloadTest` is launched using `-Xcheck:jni` in its test definition. Looking at the code of `LoadLibraryUnloadTest`, I'm unsure why that would be needed on the test definition. I am wondering whether that `-Xcheck:jni` should have instead been passed to the process builder launched `LoadLibraryUnload` process, which is where the actual JNI usage is taking place. Of course this isn't what is causing the test failures.

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

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

From alanb at openjdk.org  Fri Sep  9 06:18:09 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 Sep 2022 06:18:09 GMT
Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir
 directory doesn't exist [v2]
In-Reply-To: <MlgCrMDsYqv2oqdmK3ZLqeWSjLHgQhcTkSZ-36bkrAY=.824b6879-b0be-4e00-9f29-3f7dbdb60e74@github.com>
References: <rjEWqSaj5cFnFbv-bFsv7Ab1qpwgfoKe9mILyMuXH_M=.b8b570a7-27cf-494a-805b-3e04dd404bc6@github.com>
 <MlgCrMDsYqv2oqdmK3ZLqeWSjLHgQhcTkSZ-36bkrAY=.824b6879-b0be-4e00-9f29-3f7dbdb60e74@github.com>
Message-ID: <USHWDQgxuoF9_duskV7fm4ejwWH_2-aj4hru4W2pfEE=.d6c11aff-f4c8-4cc8-bf3e-7f7a3ab4d91c@github.com>

On Thu, 8 Sep 2022 19:22:37 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add the change for nio and update the code according to the comments

Is the primary motive to catch scenarios where someone provides -Djava.io.tmpdir=<baddir> on the command line? I asked this via a comment in the JBS issue last month and it would be useful to know if this is the scenario that you are interested in. If it is, then I think we should look at a warning at startup rather than delayed warning (or two warnings with the current patch).

src/java.base/share/classes/java/nio/file/TempFileHelper.java line 53:

> 51:     // print out the error message for java.io.tmpdir setting
> 52:     static {
> 53:         if (!Files.isDirectory(tmpdir)) {

This won't work with a security manager set.

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

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

From alanb at openjdk.org  Fri Sep  9 06:23:43 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 Sep 2022 06:23:43 GMT
Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir
 directory doesn't exist [v2]
In-Reply-To: <MlgCrMDsYqv2oqdmK3ZLqeWSjLHgQhcTkSZ-36bkrAY=.824b6879-b0be-4e00-9f29-3f7dbdb60e74@github.com>
References: <rjEWqSaj5cFnFbv-bFsv7Ab1qpwgfoKe9mILyMuXH_M=.b8b570a7-27cf-494a-805b-3e04dd404bc6@github.com>
 <MlgCrMDsYqv2oqdmK3ZLqeWSjLHgQhcTkSZ-36bkrAY=.824b6879-b0be-4e00-9f29-3f7dbdb60e74@github.com>
Message-ID: <QxcHKOfx3m9RFBdMbg1vKZRgXEmwEC3j8Ge6iJlVzfI=.14a7208f-e8fa-499d-8538-2a492de96e71@github.com>

On Thu, 8 Sep 2022 19:22:37 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add the change for nio and update the code according to the comments

test/jdk/java/io/File/TempDirectoryNotExistingErrorMessage.java line 34:

> 32: import java.io.File;
> 33: 
> 34: public class TempDirectoryNotExistingErrorMessage {

The tests look the same and maybe we can get away with one in java/io/File. Renaming it something like The TempDirectoryDoesNotExist would make it a bit more consistent with the tests in the Files test directory.

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

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

From itakiguchi at openjdk.org  Fri Sep  9 06:29:44 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Fri, 9 Sep 2022 06:29:44 GMT
Subject: RFR: 8291916: Unexpected output on Windows command prompt
In-Reply-To: <xvXRAlkC7Q81fP5b63cOVROBypIqiYPPuS_OY19qWkA=.3ac6b47a-0a97-45ba-88d5-5b13836f7c06@github.com>
References: <kCEIAwQZuJQRpQB-usp-YiUpUyULY1gzf6Bcf-6ZAtU=.e592478d-a7da-4220-84df-914a02dbe1a2@github.com>
 <xvXRAlkC7Q81fP5b63cOVROBypIqiYPPuS_OY19qWkA=.3ac6b47a-0a97-45ba-88d5-5b13836f7c06@github.com>
Message-ID: <EP299LVn48-t5mVWSu7N7SoN5S7HGConRvSRHQOsU_k=.0a50e6d3-65a9-4001-a7a0-bb1714b83201@github.com>

On Tue, 9 Aug 2022 20:38:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> To support Windows command prompt's codepage, following charsets should be moved from jdk.charsets module to java.base module.
>> 
>> - IBM860
>> - IBM861
>> - IBM863
>> - IBM864
>> - IBM865
>> - IBM869
>
> I looked at this issue a bit more. It looks to me that the issue is caused by the fact that the encoding of `System.out` falls back to the default encoding, as `IBM864` is not in `java.base`. This issue seems not new and reproducible with the releases since JDK9 where modularization has been introduced. Also, I think other encodings than those `IBM*` listed here, can possibly cause this issue. In order to fix this completely, those obscure encodings also have to be in `java.base` which I don't think we would want to do.

Hello @naotoj .
Sorry for my bad reaction.

I checked these charsets with IBM CDRA definitions.
These are also same, but some round-trip definitions are not same, like #9661 .
I think there come from files under https://unicode.org/Public/MAPPINGS/VENDORS/MICSFT/PC/ .
As you know, `CP860/CP861/CP863/CP864/CP865/CP869` are defined into [IANA Character Sets](https://www.iana.org/assignments/character-sets/character-sets.xhtml) as an alias.
Even if the registered names are `IBM*`, these charset implementations are from Microsoft.
I think these charset should be usable as default charset on Windows command prompt.
Please reconsider current Java implementation.

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

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

From alanb at openjdk.org  Fri Sep  9 06:39:51 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 Sep 2022 06:39:51 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo
 [v10]
In-Reply-To: <nkoRspmTOHaEze-cxLxu2N1On3FMeOMT4rpJE_Hx9J0=.b056ebea-c23a-496d-9199-3e005964da01@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <nkoRspmTOHaEze-cxLxu2N1On3FMeOMT4rpJE_Hx9J0=.b056ebea-c23a-496d-9199-3e005964da01@github.com>
Message-ID: <rjpq6J49ANcpxwc4cV1xB4JzHl6uPp96DEuwMpUhq94=.2aff360c-d9a7-4cf0-9d08-c7877f75de42@github.com>

On Thu, 8 Sep 2022 08:26:43 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Implementation of JDK-8279283
>
> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - testing transferTo() when mark was set
>  - testing transferTo() when buffer is non-empty

test/jdk/java/io/BufferedInputStream/TransferTo.java line 170:

> 168:             if (mark) {
> 169:               in.mark(1);
> 170:             }

This just tests transferTo with a mark set, it doesn't appear to check that mark is respected. To test mark/reset then I think it will need to call mark with a largish readLimit, transferTo to drain the input to EOF, reset, and then read or transferTo again to check that the bytes from the mark are replayed.

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

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

From duke at openjdk.org  Fri Sep  9 06:48:46 2022
From: duke at openjdk.org (Markus KARG)
Date: Fri, 9 Sep 2022 06:48:46 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo
 [v10]
In-Reply-To: <rjpq6J49ANcpxwc4cV1xB4JzHl6uPp96DEuwMpUhq94=.2aff360c-d9a7-4cf0-9d08-c7877f75de42@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <nkoRspmTOHaEze-cxLxu2N1On3FMeOMT4rpJE_Hx9J0=.b056ebea-c23a-496d-9199-3e005964da01@github.com>
 <rjpq6J49ANcpxwc4cV1xB4JzHl6uPp96DEuwMpUhq94=.2aff360c-d9a7-4cf0-9d08-c7877f75de42@github.com>
Message-ID: <Rs-kU9u4tIqv_PuC6hwmeVB-qIoTIux8m4KRe5XjKm0=.0d074549-3a77-4424-b9ca-6bac87dfd072@github.com>

On Fri, 9 Sep 2022 06:36:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - testing transferTo() when mark was set
>>  - testing transferTo() when buffer is non-empty
>
> test/jdk/java/io/BufferedInputStream/TransferTo.java line 170:
> 
>> 168:             if (mark) {
>> 169:               in.mark(1);
>> 170:             }
> 
> This just tests transferTo with a mark set, it doesn't appear to check that mark is respected. To test mark/reset then I think it will need to call mark with a largish readLimit, transferTo to drain the input to EOF, reset, and then read or transferTo again to check that the bytes from the mark are replayed.

I did not do that so far, as we agreed to check the *new* code path, which is only executed when noting was marked (so reset plays no role). Certainly I will be happy to add another test for the use case you describe (i. e. the *old* code path), even if we all know -thanks to our knowledge of the existence of the two code paths-, that it will surely pass even with my PR in place, unless there is a bug in the *old* code path... ;-)

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

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

From duke at openjdk.org  Fri Sep  9 08:38:16 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Fri, 9 Sep 2022 08:38:16 GMT
Subject: RFR: 8293579:
 tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese
 Windows platform
Message-ID: <ROgI801Y_MVdXiCKPYVtwN9C5kDZTT3gdAo4pnCACbs=.618721ad-4cc5-4db7-a923-3bf740e35181@github.com>

Could you please review the JDK-8293579 bug fixes?

tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java attempts to give 
the launcher the character which is encoded by Windows API WideCharToMultiByte() 
from UNICODE "?"(0x00e9) as an argument. However, this test fails because the 
code point "?"(0x00e9) cannot be treated on Japanese Windows.

WideCharToMultiByte() encodes characters as Shift-JIS on Japanese Windows, but 
the code point "?"(0x00e9) does not exist in Shift-JIS, and it is replaced with 
"e"(0x0065) as substitute. Therefore, "?"(0x00e9) and "e"(0x0065) are compared 
in this test and judged to be different characters, and return as failed.

So, in the Japanese encoding("MS932", "SJIS"), the test should be modified to 
give a character such as "?"(0x3042) as the launcher's argument instead of 
"?"(0x00e9).

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

Commit messages:
 - 8293579: tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese Windows platform

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

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

From dfuchs at openjdk.org  Fri Sep  9 08:52:51 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 Sep 2022 08:52:51 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo
 [v10]
In-Reply-To: <Rs-kU9u4tIqv_PuC6hwmeVB-qIoTIux8m4KRe5XjKm0=.0d074549-3a77-4424-b9ca-6bac87dfd072@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <nkoRspmTOHaEze-cxLxu2N1On3FMeOMT4rpJE_Hx9J0=.b056ebea-c23a-496d-9199-3e005964da01@github.com>
 <rjpq6J49ANcpxwc4cV1xB4JzHl6uPp96DEuwMpUhq94=.2aff360c-d9a7-4cf0-9d08-c7877f75de42@github.com>
 <Rs-kU9u4tIqv_PuC6hwmeVB-qIoTIux8m4KRe5XjKm0=.0d074549-3a77-4424-b9ca-6bac87dfd072@github.com>
Message-ID: <Gd1CwIApU_6VRRlvCODREI21WaIP4_pC-xqYiSe4tj8=.9976ead1-170f-4de3-a988-20d44a6e2e33@github.com>

On Fri, 9 Sep 2022 06:45:04 GMT, Markus KARG <duke at openjdk.org> wrote:

>> test/jdk/java/io/BufferedInputStream/TransferTo.java line 170:
>> 
>>> 168:             if (mark) {
>>> 169:               in.mark(1);
>>> 170:             }
>> 
>> This just tests transferTo with a mark set, it doesn't appear to check that mark is respected. To test mark/reset then I think it will need to call mark with a largish readLimit, transferTo to drain the input to EOF, reset, and then read or transferTo again to check that the bytes from the mark are replayed.
>
> I did not do that so far, as we agreed to check the *new* code path, which is only executed when noting was marked (so reset plays no role). Certainly I will be happy to add another test for the use case you describe (i. e. the *old* code path), even if we all know -thanks to our knowledge of the existence of the two code paths-, that it will surely pass even with my PR in place, unless there is a bug in the *old* code path... ;-)

Unless there's a bug and the new code path is triggered when there's a mark ;-) . Maybe we can convince ourselves that this can't happen now (by reading the code), but if someone modifies this code 2 years from now and introduces a bug that changes that it would be good to have a test to catch it.

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

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

From duke at openjdk.org  Fri Sep  9 10:06:56 2022
From: duke at openjdk.org (Markus KARG)
Date: Fri, 9 Sep 2022 10:06:56 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo
 [v10]
In-Reply-To: <Gd1CwIApU_6VRRlvCODREI21WaIP4_pC-xqYiSe4tj8=.9976ead1-170f-4de3-a988-20d44a6e2e33@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <nkoRspmTOHaEze-cxLxu2N1On3FMeOMT4rpJE_Hx9J0=.b056ebea-c23a-496d-9199-3e005964da01@github.com>
 <rjpq6J49ANcpxwc4cV1xB4JzHl6uPp96DEuwMpUhq94=.2aff360c-d9a7-4cf0-9d08-c7877f75de42@github.com>
 <Rs-kU9u4tIqv_PuC6hwmeVB-qIoTIux8m4KRe5XjKm0=.0d074549-3a77-4424-b9ca-6bac87dfd072@github.com>
 <Gd1CwIApU_6VRRlvCODREI21WaIP4_pC-xqYiSe4tj8=.9976ead1-170f-4de3-a988-20d44a6e2e33@github.com>
Message-ID: <r8gyw7xkSfdjlPnRZ_9RGR5-TvWKWauQsvJ-Ud-iPdY=.60595a13-a651-4e52-b6e9-f040b7fc5883@github.com>

On Fri, 9 Sep 2022 08:49:07 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I did not do that so far, as we agreed to check the *new* code path, which is only executed when noting was marked (so reset plays no role). Certainly I will be happy to add another test for the use case you describe (i. e. the *old* code path), even if we all know -thanks to our knowledge of the existence of the two code paths-, that it will surely pass even with my PR in place, unless there is a bug in the *old* code path... ;-)
>
> Unless there's a bug and the new code path is triggered when there's a mark ;-) . Maybe we can convince ourselves that this can't happen now (by reading the code), but if someone modifies this code 2 years from now and introduces a bug that changes that it would be good to have a test to catch it.

It depends on the target of a test, but I am fine with adding such a test, as I alrready wrote.

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

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

From aefimov at openjdk.org  Fri Sep  9 11:12:45 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Fri, 9 Sep 2022 11:12:45 GMT
Subject: RFR: 8290367: Update default value and extend the scope of
 com.sun.jndi.ldap.object.trustSerialData system property
Message-ID: <T8JiNCNUKjV5bue6Bd8MjtatKCd9yik8cYMw2NIGTps=.02763149-a450-4e04-99b5-748d92b35714@github.com>

### Summary of the change

The LDAP Naming Service Provider implementation's default settings are changed to disallow deserialization and reconstruction of Java objects from different LDAP attributes (RFC 2713). Currently, only the deserialization is controlled by the `com.sun.jndi.ldap.object.trustSerialData` system property, and it is allowed by default.
The change proposed here switches the default value of the` com.sun.jndi.ldap.object.trustSerialData `system property to `"false"`, and also extends its scope to cover the reconstruction of RMI remote objects from the `javaRemoteLocation` LDAP attribute.

CSR for this change can be viewed [here](https://bugs.openjdk.org/browse/JDK-8290369).

### List of code changes
- Switch the default value of the 'com.sun.jndi.ldap.object.trustSerialData' system property to "false".

- Extend the scope of the property to also cover the reconstruction of RMI remote objects from the deprecated 'javaRemoteLocation' LDAP attribute.

- Document the support for `javaRemoteLocation` and the `javaReferenceAddress` LDAP attributes in `java.naming`'s module-info.

### Test changes
- New `test/jdk/com/sun/jndi/ldap/objects/RemoteLocationAttributeTest.java` test has been added to test that `com.sun.jndi.ldap.object.trustSerialData` system property can be used to control reconstruction of RMI objects from the `javaRemoteLocation` LDAP attribute.

-  `test/jdk/javax/naming/module/RunBasic.java` was modified to pass `com.sun.jndi.ldap.object.trustSerialData=true` to the sub-tests that rely on reconstruction/deserialization from LDAP attributes. 

- During the update for `test/jdk/javax/naming/module/RunBasic.java`, it was spotted that sub-tests apps launched in separate processes were returning the '0' exit value irrelevant to their execution status. All these sub-tests were modified to throw an exception when failure is observed. It helps to ensure that the exit value of launched process is not '0' for failed sub-tests.

### Testing

`tier1`-`tier3` and JNDI regression/JCK tests not showing any failures related to this change.
No failures observed for the modified regression tests.

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

Commit messages:
 - Update storeFruit sub-test parameters
 - Move and modify the SP description in module-info
 - Update trustSerialData description in java.naming module-info
 - Update and move trustSerialData description
 - 8290367: Update default value and extend the scope of com.sun.jndi.ldap.object.trustSerialData system property

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

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

From duke at openjdk.org  Fri Sep  9 12:19:54 2022
From: duke at openjdk.org (Markus KARG)
Date: Fri, 9 Sep 2022 12:19:54 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo
 [v11]
In-Reply-To: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
Message-ID: <_la5Co3yx5ik1wt7Y6Bi7MDC3MCVUxIKxz_iQQp2TT8=.1023ef6d-266f-45f5-aa93-7218d0d89c10@github.com>

> Implementation of JDK-8279283

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

 - corrected copyright
 - testing transferTo() after reset()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/6935/files
  - new: https://git.openjdk.org/jdk/pull/6935/files/ab7c170b..a4b6f913

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

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

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

From duke at openjdk.org  Fri Sep  9 12:19:55 2022
From: duke at openjdk.org (Markus KARG)
Date: Fri, 9 Sep 2022 12:19:55 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v9]
In-Reply-To: <uH-1RNihIinJKFqtqE-R1flb8-3qNIgy_u9uiPkPH1Q=.6d36a0cc-3cf6-42d9-86b9-287a6414ab9b@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <jpjOzk7z0bfD2rIbg_yWGlW3IcaDJqKx2oL8vx9K3K8=.3cc44e7f-babe-46b6-ae6e-7d0581f3c100@github.com>
 <rUMf62LDvb4QNSzwgVnUnStNpEWe1yoa4X8_ZtDr7mk=.76992d5b-45ed-4258-9ee0-5b3cfcad7065@github.com>
 <_qH7Tpud0TI2H2Jv_maCLJuzVxod3NlbbAU2nq4Vjk4=.9817a70f-2b8e-45b1-a00d-2ce14146f473@github.com>
 <gQUwyL4NKd-T4DAcDou688_fXhbr93CR2KuVKOVN5Hw=.d98693f7-ef4a-4e93-80c9-39028ff08119@github.com>
 <uH-1RNihIinJKFqtqE-R1flb8-3qNIgy_u9uiPkPH1Q=.6d36a0cc-3cf6-42d9-86b9-287a6414ab9b@github.com>
Message-ID: <nrs1e1_b6_Qrmxs26n1LkHLYpP6rdna5Fs-G-X8899k=.b0f0ca73-d5cd-4946-a7e5-b882fc96275e@github.com>

On Thu, 8 Sep 2022 12:18:35 GMT, Markus KARG <duke at openjdk.org> wrote:

>>> Actually I wrote this code in 2021. What are the official rules here, do I have to use the original date or the latest change date?
>> 
>> I remember reading it somewhere but I can't seem  to locate the text right now and it isn't mentioned in the OpenJDK developer's guide either https://openjdk.org/guide/.
>> From what I remember, the copyright year is of the form `year1, [year2]` where `year1` is the year the file was first added to the project (so in this case it would be `2022`) and `year2` is the year it was last updated. That's my understanding of the guidelines. Others can correct me if that isn't accurate.
>
> Correct, but **2021** is right here, as the second date (last change) is *optional*, and I interpret "added" as "opened pr".

Updated copyright to 2022 in https://github.com/openjdk/jdk/pull/6935/commits/a4b6f9130a045064370e49c0678429b26616fc3d as per your request.

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

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

From duke at openjdk.org  Fri Sep  9 12:19:55 2022
From: duke at openjdk.org (Markus KARG)
Date: Fri, 9 Sep 2022 12:19:55 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo
 [v10]
In-Reply-To: <r8gyw7xkSfdjlPnRZ_9RGR5-TvWKWauQsvJ-Ud-iPdY=.60595a13-a651-4e52-b6e9-f040b7fc5883@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <nkoRspmTOHaEze-cxLxu2N1On3FMeOMT4rpJE_Hx9J0=.b056ebea-c23a-496d-9199-3e005964da01@github.com>
 <rjpq6J49ANcpxwc4cV1xB4JzHl6uPp96DEuwMpUhq94=.2aff360c-d9a7-4cf0-9d08-c7877f75de42@github.com>
 <Rs-kU9u4tIqv_PuC6hwmeVB-qIoTIux8m4KRe5XjKm0=.0d074549-3a77-4424-b9ca-6bac87dfd072@github.com>
 <Gd1CwIApU_6VRRlvCODREI21WaIP4_pC-xqYiSe4tj8=.9976ead1-170f-4de3-a988-20d44a6e2e33@github.com>
 <r8gyw7xkSfdjlPnRZ_9RGR5-TvWKWauQsvJ-Ud-iPdY=.60595a13-a651-4e52-b6e9-f040b7fc5883@github.com>
Message-ID: <2moaYigxrzUi-Hgb_9TpPT15_sI_0MMoneAV6JJbtIg=.17fc069d-6e57-43cc-a4a6-e6b370cb60de@github.com>

On Fri, 9 Sep 2022 10:03:11 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Unless there's a bug and the new code path is triggered when there's a mark ;-) . Maybe we can convince ourselves that this can't happen now (by reading the code), but if someone modifies this code 2 years from now and introduces a bug that changes that it would be good to have a test to catch it.
>
> It depends on the target of a test, but I am fine with adding such a test, as I alrready wrote.

Since https://github.com/openjdk/jdk/pull/6935/commits/5d24268a807faa4535ea66f7e40ca6e4b983ce51 the test now proofs that mark/reset is respected by subsequent transferTo.

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

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

From alanb at openjdk.org  Fri Sep  9 12:57:16 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 Sep 2022 12:57:16 GMT
Subject: RFR: 8292240: CarrierThread.blocking not reset when spare not
 activated
Message-ID: <-zN5ga4az_E-S4fJDNkLRaB2SG8nHTuyeAo7ZgSVDBY=.af009574-532f-4078-a934-9f18a0996e7c@github.com>

Some blocking operations that pin a virtual thread to its carrier will compensate by activating a spare carrier (essentially managed blocker). This is done by wrapping the operation in a Blocker begin/end. This code is not correct for the case that a spare cannot be activated (e.g. already at the max of 256 carrier threads). When that happens, the carrier thread's "blocking" flag, used to detect reentrancy, is not reset when the blocking operation is done. The result is that subsequent blocking operations by virtual threads on this carrier thread will not attempt to activate a spare.

The test runs with parallelism=1 and maxPoolSize=2 in order to make it easier to create the conditions for this bug.

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

Commit messages:
 - Adjust comments
 - Merge
 - Merge
 - Merge
 - Initial commit

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

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

From alanb at openjdk.org  Fri Sep  9 13:06:46 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 Sep 2022 13:06:46 GMT
Subject: RFR: 8293499: Provide jmod compression level option
In-Reply-To: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
Message-ID: <4Xc1dfNNw7yvhEVG-XYcwYEjOk2xeoxuCx334iwHKcs=.1a7237a4-a592-447c-8e50-fad534106057@github.com>

On Thu, 8 Sep 2022 07:57:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have been looking into `make clean-images images` performance, and realized jmod keeps compressing files with default compression level. Tuning that toward lighter compression levels improves build performance considerably, without a heavy loss in *.jmod sizes. 
> 
> This PR allows JMOD to select the compression level. Follow-ups would use this in the build system, see #10214.
> 
> This change nominally requires CSR, but I would like to gauge the reaction to this patch first, before submitting a formal CSR. The interesting asymmetry against `jlink` is: `jlink` provides `--compress` option that only takes `2` for "ZIP compression". I would argue it would be beneficial to add `--compression-level` to `jlink` as well, so to select the compression level there too.

I went through the changes and I don't see anything obviously wrong. The command line option doesn't look out of place although as Mandy points us, the format is not documented so there is flexibility to change it in the future. If some future format doesn't support something like compression level then that option could just emit a warning and do nothing.

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

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

From redestad at openjdk.org  Fri Sep  9 13:16:44 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 9 Sep 2022 13:16:44 GMT
Subject: RFR: 8288933: Improve the implementation of
 Double/Float.isInfinite
In-Reply-To: <GeqTxOCKCJsEeh6FJ8VeIKtRxpihPbn7PyGIftfqbDw=.aa9aa68d-7d03-4d2b-8abb-d18ec4c7f765@github.com>
References: <GeqTxOCKCJsEeh6FJ8VeIKtRxpihPbn7PyGIftfqbDw=.aa9aa68d-7d03-4d2b-8abb-d18ec4c7f765@github.com>
Message-ID: <cSFgIE_BwzEX-z1A1-eb26QTXnA1aGkj3alUrV38PGg=.1ddeb207-89d5-41da-a20c-e0217d421877@github.com>

On Wed, 22 Jun 2022 12:43:53 GMT, Quan Anh Mai <duke at openjdk.org> wrote:

> Improve the implementation of `Double/Float.isInfinite` to reduce branching. Using `>` comparison with `MAX_VALUE` instead of `==` with `POSITIVE_INFINITY` improves code emission on x86 and produces similar code for arm. This is also the way gcc implements `std::isinf` on x86 and arm (clang uses the pattern `Math.abs(v) == POSITIVE_INFINITY` on arm).
> 
> `test/micro/org/openjdk/bench/java/lang/FPComparison.java` has been added in #8525, the results are reshown here:
> 
>     Benchmark                      Mode  Cnt     Score     Error    Score     Error   Unit   Ratio
>     FPComparison.isInfiniteDouble  avgt    5  1232.800 ?  31.677  621.185 ?  11.935  ns/op    1.98
>     FPComparison.isInfiniteFloat   avgt    5  1234.708 ?  70.239  623.566 ?  15.206  ns/op    1.98
> 
> Thank you very much.

Looks good to me!

(Sorry for the long delay, I've been out for a while and forgot to formally review this.)

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

Marked as reviewed by redestad (Reviewer).

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

From jwaters at openjdk.org  Fri Sep  9 13:48:45 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 9 Sep 2022 13:48:45 GMT
Subject: RFR: 8293595: tstrings::any() is missing an overload
Message-ID: <0tqqa1avFzs-MV0Veo0QnpBG1-0b1djoKap5D_vF62U=.4fed5b83-dfc2-4661-a031-f3d1b64eeca9@github.com>

tstrings::any() has an overload for std::wstring (if required) but is missing the corresponding operator overload for std::string, leaving only the templated one as a fallback, which will expand into a std::wostringstream << std::string operation. This isn't particularly safe on Windows, considering that JDK-8292008 and JDK-8247283 have been recently merged, and can sporadically cause build failures. This change simply adds the missing overload with the appropriate format handling that jpackage expects from std::string. Also contains minor name changes to fit the rest of the parameter names in the other overloads.

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

Commit messages:
 - Rename remaining parameters
 - Missing overload in any()

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

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

From ethan at mccue.dev  Fri Sep  9 13:59:36 2022
From: ethan at mccue.dev (Ethan McCue)
Date: Fri, 9 Sep 2022 09:59:36 -0400
Subject: Standard Artifact Resolution API
Message-ID: <CA+NR86hkudszN74xwOYDh2N3LGB+4KCzUbO_cJ8vFnTa7xCTjQ@mail.gmail.com>

This email is mostly to test the waters, I expect some hostility.

Say, as a premise, that an API for resolving external dependencies was
something that the JDK concerned itself with providing.

I think the foundation for that is there - the POM v4 format is more or
less around forever, maven style repositories aren't going anywhere, and
it's nearly impossible to write a modern application without some degree of
dependence on code that was written by other people.

What properties would folks want from such an API? What blockers would
there be (technical/social)? Any other initial thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220909/cceb77ec/attachment-0001.htm>

From dfuchs at openjdk.org  Fri Sep  9 14:10:41 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 Sep 2022 14:10:41 GMT
Subject: RFR: 8292240: CarrierThread.blocking not reset when spare not
 activated
In-Reply-To: <-zN5ga4az_E-S4fJDNkLRaB2SG8nHTuyeAo7ZgSVDBY=.af009574-532f-4078-a934-9f18a0996e7c@github.com>
References: <-zN5ga4az_E-S4fJDNkLRaB2SG8nHTuyeAo7ZgSVDBY=.af009574-532f-4078-a934-9f18a0996e7c@github.com>
Message-ID: <wHn1OizvQr_dkvGtaHHc0MLJVDnN8ynsB0PgcJqRUJ0=.85a91d10-305b-4eef-9d05-07ed47e5ec03@github.com>

On Thu, 11 Aug 2022 16:11:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Some blocking operations that pin a virtual thread to its carrier will compensate by activating a spare carrier (essentially managed blocker). This is done by wrapping the operation in a Blocker begin/end. This code is not correct for the case that a spare cannot be activated (e.g. already at the max of 256 carrier threads). When that happens, the carrier thread's "blocking" flag, used to detect reentrancy, is not reset when the blocking operation is done. The result is that subsequent blocking operations by virtual threads on this carrier thread will not attempt to activate a spare.
> 
> The test runs with parallelism=1 and maxPoolSize=2 in order to make it easier to create the conditions for this bug.

It took me some time to figure out why -1 was different than 0 but now I see it. If `FJP.beginCompensatedBlock()` returned 0 then `ct.beginBlocking()` would have been called, but `ct.endBlocking()` would not be called.
LGTM

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

Marked as reviewed by dfuchs (Reviewer).

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

From alanb at openjdk.org  Fri Sep  9 14:16:43 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 Sep 2022 14:16:43 GMT
Subject: RFR: 8290367: Update default value and extend the scope of
 com.sun.jndi.ldap.object.trustSerialData system property
In-Reply-To: <T8JiNCNUKjV5bue6Bd8MjtatKCd9yik8cYMw2NIGTps=.02763149-a450-4e04-99b5-748d92b35714@github.com>
References: <T8JiNCNUKjV5bue6Bd8MjtatKCd9yik8cYMw2NIGTps=.02763149-a450-4e04-99b5-748d92b35714@github.com>
Message-ID: <CMlpUh0Hw-i1gLYF9ZijUCWnHDr2JixCStqGLYndMcU=.20d5fd81-58d8-4bcb-b253-3fba9cd1cba0@github.com>

On Fri, 9 Sep 2022 11:03:14 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> ### Summary of the change
> 
> The LDAP Naming Service Provider implementation's default settings are changed to disallow deserialization and reconstruction of Java objects from different LDAP attributes (RFC 2713). Currently, only the deserialization is controlled by the `com.sun.jndi.ldap.object.trustSerialData` system property, and it is allowed by default.
> The change proposed here switches the default value of the` com.sun.jndi.ldap.object.trustSerialData `system property to `"false"`, and also extends its scope to cover the reconstruction of RMI remote objects from the `javaRemoteLocation` LDAP attribute.
> 
> CSR for this change can be viewed [here](https://bugs.openjdk.org/browse/JDK-8290369).
> 
> ### List of code changes
> - Switch the default value of the 'com.sun.jndi.ldap.object.trustSerialData' system property to "false".
> 
> - Extend the scope of the property to also cover the reconstruction of RMI remote objects from the deprecated 'javaRemoteLocation' LDAP attribute.
> 
> - Document the support for `javaRemoteLocation` and the `javaReferenceAddress` LDAP attributes in `java.naming`'s module-info.
> 
> ### Test changes
> - New `test/jdk/com/sun/jndi/ldap/objects/RemoteLocationAttributeTest.java` test has been added to test that `com.sun.jndi.ldap.object.trustSerialData` system property can be used to control reconstruction of RMI objects from the `javaRemoteLocation` LDAP attribute.
> 
> -  `test/jdk/javax/naming/module/RunBasic.java` was modified to pass `com.sun.jndi.ldap.object.trustSerialData=true` to the sub-tests that rely on reconstruction/deserialization from LDAP attributes. 
> 
> - During the update for `test/jdk/javax/naming/module/RunBasic.java`, it was spotted that sub-tests apps launched in separate processes were returning the '0' exit value irrelevant to their execution status. All these sub-tests were modified to throw an exception when failure is observed. It helps to ensure that the exit value of launched process is not '0' for failed sub-tests.
> 
> ### Testing
> 
> `tier1`-`tier3` and JNDI regression/JCK tests not showing any failures related to this change.
> No failures observed for the modified regression tests.

src/java.naming/share/classes/module-info.java line 82:

> 80:  *     <li>{@systemProperty com.sun.jndi.ldap.object.trustSerialData}:
> 81:  *          <br>The value of this system property is the string representation of a boolean value
> 82:  *          which allows to control the deserialization of java objects from the {@code javaSerializedData} LDAP

"allows to control"? Maybe this should be "that controls".

Is there anywhere that "javaRemoveLocation", and "javaReferenceAddress" could link to?

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

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

From dfuchs at openjdk.org  Fri Sep  9 14:45:48 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 Sep 2022 14:45:48 GMT
Subject: RFR: 8290367: Update default value and extend the scope of
 com.sun.jndi.ldap.object.trustSerialData system property
In-Reply-To: <CMlpUh0Hw-i1gLYF9ZijUCWnHDr2JixCStqGLYndMcU=.20d5fd81-58d8-4bcb-b253-3fba9cd1cba0@github.com>
References: <T8JiNCNUKjV5bue6Bd8MjtatKCd9yik8cYMw2NIGTps=.02763149-a450-4e04-99b5-748d92b35714@github.com>
 <CMlpUh0Hw-i1gLYF9ZijUCWnHDr2JixCStqGLYndMcU=.20d5fd81-58d8-4bcb-b253-3fba9cd1cba0@github.com>
Message-ID: <iwGVIU49MP88C_HvprvhHk9nTjt0TVSZFe4icsUqwXU=.4f113497-3539-4a3c-9340-d46f3b4526b6@github.com>

On Fri, 9 Sep 2022 14:13:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> ### Summary of the change
>> 
>> The LDAP Naming Service Provider implementation's default settings are changed to disallow deserialization and reconstruction of Java objects from different LDAP attributes (RFC 2713). Currently, only the deserialization is controlled by the `com.sun.jndi.ldap.object.trustSerialData` system property, and it is allowed by default.
>> The change proposed here switches the default value of the` com.sun.jndi.ldap.object.trustSerialData `system property to `"false"`, and also extends its scope to cover the reconstruction of RMI remote objects from the `javaRemoteLocation` LDAP attribute.
>> 
>> CSR for this change can be viewed [here](https://bugs.openjdk.org/browse/JDK-8290369).
>> 
>> ### List of code changes
>> - Switch the default value of the 'com.sun.jndi.ldap.object.trustSerialData' system property to "false".
>> 
>> - Extend the scope of the property to also cover the reconstruction of RMI remote objects from the deprecated 'javaRemoteLocation' LDAP attribute.
>> 
>> - Document the support for `javaRemoteLocation` and the `javaReferenceAddress` LDAP attributes in `java.naming`'s module-info.
>> 
>> ### Test changes
>> - New `test/jdk/com/sun/jndi/ldap/objects/RemoteLocationAttributeTest.java` test has been added to test that `com.sun.jndi.ldap.object.trustSerialData` system property can be used to control reconstruction of RMI objects from the `javaRemoteLocation` LDAP attribute.
>> 
>> -  `test/jdk/javax/naming/module/RunBasic.java` was modified to pass `com.sun.jndi.ldap.object.trustSerialData=true` to the sub-tests that rely on reconstruction/deserialization from LDAP attributes. 
>> 
>> - During the update for `test/jdk/javax/naming/module/RunBasic.java`, it was spotted that sub-tests apps launched in separate processes were returning the '0' exit value irrelevant to their execution status. All these sub-tests were modified to throw an exception when failure is observed. It helps to ensure that the exit value of launched process is not '0' for failed sub-tests.
>> 
>> ### Testing
>> 
>> `tier1`-`tier3` and JNDI regression/JCK tests not showing any failures related to this change.
>> No failures observed for the modified regression tests.
>
> src/java.naming/share/classes/module-info.java line 82:
> 
>> 80:  *     <li>{@systemProperty com.sun.jndi.ldap.object.trustSerialData}:
>> 81:  *          <br>The value of this system property is the string representation of a boolean value
>> 82:  *          which allows to control the deserialization of java objects from the {@code javaSerializedData} LDAP
> 
> "allows to control"? Maybe this should be "that controls".
> 
> Is there anywhere that "javaRemoveLocation", and "javaReferenceAddress" could link to?

`javaReferenceAddress` is defined in RFC 2713, section 3.6 - but `javaRemoteLocation` is not - it's marked deprecated in our code base so maybe it came from some early draft of this representation.

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

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

From alanb at openjdk.org  Fri Sep  9 14:58:44 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 Sep 2022 14:58:44 GMT
Subject: RFR: 8293499: Provide jmod compression level option
In-Reply-To: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
Message-ID: <M3-rObmkZwQ3kYWUiRZST5sexge4W8cMmNy07OO_2nA=.08f94f08-169d-454f-8751-2f81ebe7f584@github.com>

On Thu, 8 Sep 2022 07:57:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have been looking into `make clean-images images` performance, and realized jmod keeps compressing files with default compression level. Tuning that toward lighter compression levels improves build performance considerably, without a heavy loss in *.jmod sizes. 
> 
> This PR allows JMOD to select the compression level. Follow-ups would use this in the build system, see #10214.
> 
> This change nominally requires CSR, but I would like to gauge the reaction to this patch first, before submitting a formal CSR. The interesting asymmetry against `jlink` is: `jlink` provides `--compress` option that only takes `2` for "ZIP compression". I would argue it would be beneficial to add `--compression-level` to `jlink` as well, so to select the compression level there too.

Marked as reviewed by alanb (Reviewer).

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

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

From rriggs at openjdk.org  Fri Sep  9 15:06:50 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 9 Sep 2022 15:06:50 GMT
Subject: RFR: 8293282: LoadLibraryUnloadTest.java fails with
 "Too few cleared WeakReferences"
In-Reply-To: <1Rr-_8-7Und4z_ivbHwgwSLCY-gYuRZApv0vGe_xU0E=.b1ca81d5-90d0-47ff-ab43-051f47d0c70b@github.com>
References: <O7RYAAkE9CHAAzWdTLQBCaaEns3vK6c896tmx8Ul0rM=.bccf6768-e5b1-4bd3-85f7-4dfd27277bfb@github.com>
 <1Rr-_8-7Und4z_ivbHwgwSLCY-gYuRZApv0vGe_xU0E=.b1ca81d5-90d0-47ff-ab43-051f47d0c70b@github.com>
Message-ID: <B4pwA-A_Sw51H3E1gDuaktWkB6eb5x7XVvUkUBlkjFs=.2e12745e-15f0-4c62-8c2c-903b5875407f@github.com>

On Thu, 8 Sep 2022 20:54:28 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Modify the LoadLibraryUnload test to call gc() more a few times, allowing multiple gc cycles to queue the expected refs.
>> Short the timeout on each cycle to 10 sec.
>
> test/jdk/java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnload.java line 171:
> 
>> 169:                 dequeueCount++;
>> 170:         }
>> 171:         Asserts.assertEquals(dequeueCount, LOADER_COUNT, "Too few cleared WeakReferences");
> 
> This only invokes GC `LOADER_COUNT` times.  I think you may want something like what ForceGC does:
> 
> 
>         int retries = (int)(Math.round(1000L * TIMEOUT_FACTOR) / 200);
>         for (; retries >= 0; retries--) {
>             if (dequeueCount == LOADER_COUNT) return;
>             
>             System.gc();
>             refQueue.remove(200L);
>         }

I'll switch to using ForceGC.wait to wait for all the WeakReferences to be cleared.
Using existing logic for the gc and timing.

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

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

From rriggs at openjdk.org  Fri Sep  9 15:15:39 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 9 Sep 2022 15:15:39 GMT
Subject: RFR: 8293282: LoadLibraryUnloadTest.java fails with
 "Too few cleared WeakReferences"
In-Reply-To: <O7RYAAkE9CHAAzWdTLQBCaaEns3vK6c896tmx8Ul0rM=.bccf6768-e5b1-4bd3-85f7-4dfd27277bfb@github.com>
References: <O7RYAAkE9CHAAzWdTLQBCaaEns3vK6c896tmx8Ul0rM=.bccf6768-e5b1-4bd3-85f7-4dfd27277bfb@github.com>
Message-ID: <4CYua7qRlVq_H7vkCqV-t7FM74A28dfi2uB8mhHc1i4=.c619c6e9-909c-45f4-bd0f-ad4ad002e3e9@github.com>

On Thu, 8 Sep 2022 20:26:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Modify the LoadLibraryUnload test to call gc() more a few times, allowing multiple gc cycles to queue the expected refs.
> Short the timeout on each cycle to 10 sec.

Hi Jai, I don't think the memory size comes into play, the GC is invoked directly and WeakReferences should be cleared independently from memory pressure.  Adding a memory max might be harmless, but it would not be clear whether it was really a factor.

As for the -Xcheck:jni, it's a left over from when the test was constructed and run as a single main.
There is no explicit JNI usage in the test and the test logic does not depend on that setting.
It should be removed to avoid future confusion.  Thanks for the observations.

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

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

From rriggs at openjdk.org  Fri Sep  9 15:22:01 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 9 Sep 2022 15:22:01 GMT
Subject: RFR: 8293282: LoadLibraryUnloadTest.java fails with
 "Too few cleared WeakReferences" [v2]
In-Reply-To: <O7RYAAkE9CHAAzWdTLQBCaaEns3vK6c896tmx8Ul0rM=.bccf6768-e5b1-4bd3-85f7-4dfd27277bfb@github.com>
References: <O7RYAAkE9CHAAzWdTLQBCaaEns3vK6c896tmx8Ul0rM=.bccf6768-e5b1-4bd3-85f7-4dfd27277bfb@github.com>
Message-ID: <ge797GUgta3v48xl6KgOd8VWRmuQgg-vtfa7UGn9OCk=.282683d9-8c0b-48c8-9f4c-d3a30119eb0e@github.com>

> Modify the LoadLibraryUnload test to call gc() more a few times, allowing multiple gc cycles to queue the expected refs.
> Short the timeout on each cycle to 10 sec.

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

  Refactored to use test library ForceGC.wait waiting for all WeakReferences to be cleared.
  Cleanup/remove unnecessary LoadLibraryUnloadTest imports and -Xcheck:jni

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10223/files
  - new: https://git.openjdk.org/jdk/pull/10223/files/fe704b58..498273d9

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

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

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

From aefimov at openjdk.org  Fri Sep  9 15:22:46 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Fri, 9 Sep 2022 15:22:46 GMT
Subject: RFR: 8290367: Update default value and extend the scope of
 com.sun.jndi.ldap.object.trustSerialData system property
In-Reply-To: <iwGVIU49MP88C_HvprvhHk9nTjt0TVSZFe4icsUqwXU=.4f113497-3539-4a3c-9340-d46f3b4526b6@github.com>
References: <T8JiNCNUKjV5bue6Bd8MjtatKCd9yik8cYMw2NIGTps=.02763149-a450-4e04-99b5-748d92b35714@github.com>
 <CMlpUh0Hw-i1gLYF9ZijUCWnHDr2JixCStqGLYndMcU=.20d5fd81-58d8-4bcb-b253-3fba9cd1cba0@github.com>
 <iwGVIU49MP88C_HvprvhHk9nTjt0TVSZFe4icsUqwXU=.4f113497-3539-4a3c-9340-d46f3b4526b6@github.com>
Message-ID: <sOCmI9NmDENiLXuY4hvA8F1PfCN_NTI-2TH7n9SCqsA=.9cba0c2c-533a-4216-aa86-2b54f4f03691@github.com>

On Fri, 9 Sep 2022 14:42:20 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> `javaReferenceAddress` is defined in RFC 2713, section 3.6 - but `javaRemoteLocation` is not - it's marked deprecated in our code base so maybe it came from some early draft of this representation.

Correct, and since these attributes are not documented it would be great to at least mention them in `java.naming` module javadoc.

> "allows to control"? Maybe this should be "that controls".

Thanks, will change that

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

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

From duke at openjdk.org  Fri Sep  9 15:39:53 2022
From: duke at openjdk.org (duke)
Date: Fri, 9 Sep 2022 15:39:53 GMT
Subject: Withdrawn: 8286849: Use @Stable for generic repositories
In-Reply-To: <3-iOiv3PbymtBaPWZyXn8J9zCQxrJRvfsNlQLCWea6Y=.1259786c-f2b3-4b99-8fd5-861cc7e2325a@github.com>
References: <3-iOiv3PbymtBaPWZyXn8J9zCQxrJRvfsNlQLCWea6Y=.1259786c-f2b3-4b99-8fd5-861cc7e2325a@github.com>
Message-ID: <qtNhJ2z86lv4IrviY7huiRbKivTxqficrXvtWfnghYA=.a1766a71-8787-401a-ab2b-ab968e34c699@github.com>

On Tue, 17 May 2022 04:40:50 GMT, liach <duke at openjdk.org> wrote:

> Generic repositories, the implementation detail for generic information in core reflection, can be updated to use the `@Stable` annotation to replace their `volatile` access. Their existing accessor code is already safe, reading the cache fields only once.
> 
> In addition, fixed potentially non-thread-safe `genericInfo` access in `Method`, `Field`, and `RecordComponent`.

This pull request has been closed without being integrated.

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

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

From rriggs at openjdk.org  Fri Sep  9 15:41:42 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 9 Sep 2022 15:41:42 GMT
Subject: RFR: 8290367: Update default value and extend the scope of
 com.sun.jndi.ldap.object.trustSerialData system property
In-Reply-To: <T8JiNCNUKjV5bue6Bd8MjtatKCd9yik8cYMw2NIGTps=.02763149-a450-4e04-99b5-748d92b35714@github.com>
References: <T8JiNCNUKjV5bue6Bd8MjtatKCd9yik8cYMw2NIGTps=.02763149-a450-4e04-99b5-748d92b35714@github.com>
Message-ID: <YEUHmqJDibwSrBd6Q4fmZqfnlSkCUNAFoxrO28mIAFM=.6454657c-fc37-4e73-8e7d-f6f583e77df3@github.com>

On Fri, 9 Sep 2022 11:03:14 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> ### Summary of the change
> 
> The LDAP Naming Service Provider implementation's default settings are changed to disallow deserialization and reconstruction of Java objects from different LDAP attributes (RFC 2713). Currently, only the deserialization is controlled by the `com.sun.jndi.ldap.object.trustSerialData` system property, and it is allowed by default.
> The change proposed here switches the default value of the` com.sun.jndi.ldap.object.trustSerialData `system property to `"false"`, and also extends its scope to cover the reconstruction of RMI remote objects from the `javaRemoteLocation` LDAP attribute.
> 
> CSR for this change can be viewed [here](https://bugs.openjdk.org/browse/JDK-8290369).
> 
> ### List of code changes
> - Switch the default value of the 'com.sun.jndi.ldap.object.trustSerialData' system property to "false".
> 
> - Extend the scope of the property to also cover the reconstruction of RMI remote objects from the deprecated 'javaRemoteLocation' LDAP attribute.
> 
> - Document the support for `javaRemoteLocation` and the `javaReferenceAddress` LDAP attributes in `java.naming`'s module-info.
> 
> ### Test changes
> - New `test/jdk/com/sun/jndi/ldap/objects/RemoteLocationAttributeTest.java` test has been added to test that `com.sun.jndi.ldap.object.trustSerialData` system property can be used to control reconstruction of RMI objects from the `javaRemoteLocation` LDAP attribute.
> 
> -  `test/jdk/javax/naming/module/RunBasic.java` was modified to pass `com.sun.jndi.ldap.object.trustSerialData=true` to the sub-tests that rely on reconstruction/deserialization from LDAP attributes. 
> 
> - During the update for `test/jdk/javax/naming/module/RunBasic.java`, it was spotted that sub-tests apps launched in separate processes were returning the '0' exit value irrelevant to their execution status. All these sub-tests were modified to throw an exception when failure is observed. It helps to ensure that the exit value of launched process is not '0' for failed sub-tests.
> 
> ### Testing
> 
> `tier1`-`tier3` and JNDI regression/JCK tests not showing any failures related to this change.
> No failures observed for the modified regression tests.

test/jdk/com/sun/jndi/ldap/objects/RemoteLocationAttributeTest.java line 50:

> 48:  * RemoteLocationAttributeTest
> 49:  * @run main/othervm -Dcom.sun.jndi.ldap.object.trustSerialData=true
> 50:  * RemoteLocationAttributeTest

Please indent the continued lines.

Is the case of -Dcom.sun.jndi.ldap.object.trustSerialData (w/o a value) well defined.  Does it need a test.

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

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

From rriggs at openjdk.org  Fri Sep  9 15:48:41 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 9 Sep 2022 15:48:41 GMT
Subject: RFR: 8293282: LoadLibraryUnloadTest.java fails with
 "Too few cleared WeakReferences" [v3]
In-Reply-To: <O7RYAAkE9CHAAzWdTLQBCaaEns3vK6c896tmx8Ul0rM=.bccf6768-e5b1-4bd3-85f7-4dfd27277bfb@github.com>
References: <O7RYAAkE9CHAAzWdTLQBCaaEns3vK6c896tmx8Ul0rM=.bccf6768-e5b1-4bd3-85f7-4dfd27277bfb@github.com>
Message-ID: <jDgkLmJEqnxMDhGUCVAt3f7ssqnOhJnyPUWhXV7xYnY=.0c8a1bfa-9b85-4813-bff6-f4c21fdfd154@github.com>

> Modify the LoadLibraryUnload test to call gc() more a few times, allowing multiple gc cycles to queue the expected refs.
> Short the timeout on each cycle to 10 sec.

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

  Remove unused ReferenceQueue for canary WeakReferences.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10223/files
  - new: https://git.openjdk.org/jdk/pull/10223/files/498273d9..27a28ed2

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

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

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

From duke at openjdk.org  Fri Sep  9 15:51:46 2022
From: duke at openjdk.org (Quan Anh Mai)
Date: Fri, 9 Sep 2022 15:51:46 GMT
Subject: RFR: 8288933: Improve the implementation of
 Double/Float.isInfinite
In-Reply-To: <Iv3Cw6MZICDgF-4STDIH4Gd4Anclk3Nf5Gpx3enKRhM=.14ab7742-a484-4f38-880a-4dd6badb210a@github.com>
References: <GeqTxOCKCJsEeh6FJ8VeIKtRxpihPbn7PyGIftfqbDw=.aa9aa68d-7d03-4d2b-8abb-d18ec4c7f765@github.com>
 <3ACF4446eOlmU4fy37s0ethO60isKd4Gd_Wtr18k-MA=.069bece8-1b36-4f40-9a79-16efb018762d@github.com>
 <Iv3Cw6MZICDgF-4STDIH4Gd4Anclk3Nf5Gpx3enKRhM=.14ab7742-a484-4f38-880a-4dd6badb210a@github.com>
Message-ID: <LD4ESHmYm8jtUSOTMvno3AV8v7RR0jJHvefW5kJEW-A=.fdb30327-b429-438b-9699-fcb04a073462@github.com>

On Sun, 17 Jul 2022 10:58:45 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> @merykitty, the proposed change is functionally correct.
>> 
>> @cl4es, what set of platforms do we usually consider for evaluating performance changes like this?
>
>> @cl4es, what set of platforms do we usually consider for evaluating performance changes like 
> 
> A mix of x86 and aarch64 systems, some old, some new. We could run the microbenchmark on our internal performance system to verify the reported performance gain. I assume the first score column is the baseline and the second the patched version, so a 2x gain on x86, right @merykitty?

@cl4es Thanks very much for your review, I believe this change is trivial, right?

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

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

From aefimov at openjdk.org  Fri Sep  9 16:55:44 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Fri, 9 Sep 2022 16:55:44 GMT
Subject: RFR: 8290367: Update default value and extend the scope of
 com.sun.jndi.ldap.object.trustSerialData system property [v2]
In-Reply-To: <T8JiNCNUKjV5bue6Bd8MjtatKCd9yik8cYMw2NIGTps=.02763149-a450-4e04-99b5-748d92b35714@github.com>
References: <T8JiNCNUKjV5bue6Bd8MjtatKCd9yik8cYMw2NIGTps=.02763149-a450-4e04-99b5-748d92b35714@github.com>
Message-ID: <IPAtsqgCk-KnjZ6saGmBMb3VHvm7DWCkT2uu_S27acI=.50ee2564-080c-4f0d-af55-35608e966179@github.com>

> ### Summary of the change
> 
> The LDAP Naming Service Provider implementation's default settings are changed to disallow deserialization and reconstruction of Java objects from different LDAP attributes (RFC 2713). Currently, only the deserialization is controlled by the `com.sun.jndi.ldap.object.trustSerialData` system property, and it is allowed by default.
> The change proposed here switches the default value of the` com.sun.jndi.ldap.object.trustSerialData `system property to `"false"`, and also extends its scope to cover the reconstruction of RMI remote objects from the `javaRemoteLocation` LDAP attribute.
> 
> CSR for this change can be viewed [here](https://bugs.openjdk.org/browse/JDK-8290369).
> 
> ### List of code changes
> - Switch the default value of the 'com.sun.jndi.ldap.object.trustSerialData' system property to "false".
> 
> - Extend the scope of the property to also cover the reconstruction of RMI remote objects from the deprecated 'javaRemoteLocation' LDAP attribute.
> 
> - Document the support for `javaRemoteLocation` and the `javaReferenceAddress` LDAP attributes in `java.naming`'s module-info.
> 
> ### Test changes
> - New `test/jdk/com/sun/jndi/ldap/objects/RemoteLocationAttributeTest.java` test has been added to test that `com.sun.jndi.ldap.object.trustSerialData` system property can be used to control reconstruction of RMI objects from the `javaRemoteLocation` LDAP attribute.
> 
> -  `test/jdk/javax/naming/module/RunBasic.java` was modified to pass `com.sun.jndi.ldap.object.trustSerialData=true` to the sub-tests that rely on reconstruction/deserialization from LDAP attributes. 
> 
> - During the update for `test/jdk/javax/naming/module/RunBasic.java`, it was spotted that sub-tests apps launched in separate processes were returning the '0' exit value irrelevant to their execution status. All these sub-tests were modified to throw an exception when failure is observed. It helps to ensure that the exit value of launched process is not '0' for failed sub-tests.
> 
> ### Testing
> 
> `tier1`-`tier3` and JNDI regression/JCK tests not showing any failures related to this change.
> No failures observed for the modified regression tests.

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

  Add run for the SP w/o value, formatting/wording updates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10228/files
  - new: https://git.openjdk.org/jdk/pull/10228/files/40868838..faec04e6

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

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

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

From aefimov at openjdk.org  Fri Sep  9 16:55:46 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Fri, 9 Sep 2022 16:55:46 GMT
Subject: RFR: 8290367: Update default value and extend the scope of
 com.sun.jndi.ldap.object.trustSerialData system property [v2]
In-Reply-To: <YEUHmqJDibwSrBd6Q4fmZqfnlSkCUNAFoxrO28mIAFM=.6454657c-fc37-4e73-8e7d-f6f583e77df3@github.com>
References: <T8JiNCNUKjV5bue6Bd8MjtatKCd9yik8cYMw2NIGTps=.02763149-a450-4e04-99b5-748d92b35714@github.com>
 <YEUHmqJDibwSrBd6Q4fmZqfnlSkCUNAFoxrO28mIAFM=.6454657c-fc37-4e73-8e7d-f6f583e77df3@github.com>
Message-ID: <-4-ilt3LtDPIMs9fee3OQSdiG5WlQJpgueAUhAy7WM0=.9a4e6427-3c4e-4216-9634-e884e033d98f@github.com>

On Fri, 9 Sep 2022 15:29:22 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Is the case of -Dcom.sun.jndi.ldap.object.trustSerialData (w/o a value) well defined.

Deserialization and reconstruction of Java objects are only allowed when the system property is set to "true". That's how its defined in `java.naming` module info:

> "To allow the deserialization or reconstruction of java objects from {@code javaSerializedData},
> {@code javaRemoteLocation} or {@code javaReferenceAddress} attributes,
> the system property value can be set to {@code true}"
> 

Other values and no value do not allow deserialization and reconstruction.

> Does it need a test.

Yes - I've updated the test with additional `run` tag with no value set for `com.sun.jndi.ldap.object.trustSerialData`, also fixed the indentation in jtreg header.

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

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

From darcy at openjdk.org  Fri Sep  9 17:02:03 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 9 Sep 2022 17:02:03 GMT
Subject: RFR: 8288933: Improve the implementation of
 Double/Float.isInfinite
In-Reply-To: <GeqTxOCKCJsEeh6FJ8VeIKtRxpihPbn7PyGIftfqbDw=.aa9aa68d-7d03-4d2b-8abb-d18ec4c7f765@github.com>
References: <GeqTxOCKCJsEeh6FJ8VeIKtRxpihPbn7PyGIftfqbDw=.aa9aa68d-7d03-4d2b-8abb-d18ec4c7f765@github.com>
Message-ID: <wUBcUnTz52_0f4jOU2KsLHxC0zys2dItqbvPTWb-VtU=.5900b23e-cbcd-4988-8116-33e0400bbfc6@github.com>

On Wed, 22 Jun 2022 12:43:53 GMT, Quan Anh Mai <duke at openjdk.org> wrote:

> Improve the implementation of `Double/Float.isInfinite` to reduce branching. Using `>` comparison with `MAX_VALUE` instead of `==` with `POSITIVE_INFINITY` improves code emission on x86 and produces similar code for arm. This is also the way gcc implements `std::isinf` on x86 and arm (clang uses the pattern `Math.abs(v) == POSITIVE_INFINITY` on arm).
> 
> `test/micro/org/openjdk/bench/java/lang/FPComparison.java` has been added in #8525, the results are reshown here:
> 
>     Benchmark                      Mode  Cnt     Score     Error    Score     Error   Unit   Ratio
>     FPComparison.isInfiniteDouble  avgt    5  1232.800 ?  31.677  621.185 ?  11.935  ns/op    1.98
>     FPComparison.isInfiniteFloat   avgt    5  1234.708 ?  70.239  623.566 ?  15.206  ns/op    1.98
> 
> Thank you very much.

Marked as reviewed by darcy (Reviewer).

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

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

From duke at openjdk.org  Fri Sep  9 17:04:34 2022
From: duke at openjdk.org (Quan Anh Mai)
Date: Fri, 9 Sep 2022 17:04:34 GMT
Subject: Integrated: 8288933: Improve the implementation of
 Double/Float.isInfinite
In-Reply-To: <GeqTxOCKCJsEeh6FJ8VeIKtRxpihPbn7PyGIftfqbDw=.aa9aa68d-7d03-4d2b-8abb-d18ec4c7f765@github.com>
References: <GeqTxOCKCJsEeh6FJ8VeIKtRxpihPbn7PyGIftfqbDw=.aa9aa68d-7d03-4d2b-8abb-d18ec4c7f765@github.com>
Message-ID: <7_8grwA-KBKP_d6ObFULYT5OSkphScGEaO37aQu5Hes=.c0f0e957-1ae0-49e5-9563-bde57d4f329d@github.com>

On Wed, 22 Jun 2022 12:43:53 GMT, Quan Anh Mai <duke at openjdk.org> wrote:

> Improve the implementation of `Double/Float.isInfinite` to reduce branching. Using `>` comparison with `MAX_VALUE` instead of `==` with `POSITIVE_INFINITY` improves code emission on x86 and produces similar code for arm. This is also the way gcc implements `std::isinf` on x86 and arm (clang uses the pattern `Math.abs(v) == POSITIVE_INFINITY` on arm).
> 
> `test/micro/org/openjdk/bench/java/lang/FPComparison.java` has been added in #8525, the results are reshown here:
> 
>     Benchmark                      Mode  Cnt     Score     Error    Score     Error   Unit   Ratio
>     FPComparison.isInfiniteDouble  avgt    5  1232.800 ?  31.677  621.185 ?  11.935  ns/op    1.98
>     FPComparison.isInfiniteFloat   avgt    5  1234.708 ?  70.239  623.566 ?  15.206  ns/op    1.98
> 
> Thank you very much.

This pull request has now been integrated.

Changeset: a14c3a49
Author:    Quan Anh Mai <anhmdq99 at gmail.com>
Committer: Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a14c3a493a98792a61de253920bb177a5c35fd8e
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8288933: Improve the implementation of Double/Float.isInfinite

Reviewed-by: redestad, darcy

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

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

From smarks at openjdk.org  Fri Sep  9 17:07:42 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 9 Sep 2022 17:07:42 GMT
Subject: RFR: 8291660: Grapheme support in BreakIterator [v6]
In-Reply-To: <-vMSsSpfdN9yInhc30W0R3MNURpC7WuLr0xehsufqxs=.479c0683-e3c3-47cb-b83e-e83108077094@github.com>
References: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
 <-vMSsSpfdN9yInhc30W0R3MNURpC7WuLr0xehsufqxs=.479c0683-e3c3-47cb-b83e-e83108077094@github.com>
Message-ID: <UVNyv7_-VHGVutCdBIH2wWSQcT9lkPPAk01sCM6KibA=.78652eb9-4727-401c-80ce-d62bd7a00106@github.com>

On Thu, 8 Sep 2022 18:32:56 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to enhance the character break analysis in `java.text.BreakIterator` to conform to the extended grapheme cluster boundaries defined in https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A corresponding CSR has also been drafted, as there will be behavioral changes with this modification.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unnecessary comments

Updates look good, assuming all the tests pass.

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

Marked as reviewed by smarks (Reviewer).

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

From naoto at openjdk.org  Fri Sep  9 17:17:49 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 Sep 2022 17:17:49 GMT
Subject: Integrated: 8291660: Grapheme support in BreakIterator
In-Reply-To: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
References: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
Message-ID: <GyZI7XYjr-LusgzJFOQUCey0_TdWYRg7acOJaJ4B3gc=.3bcd5089-2a9e-49cb-94d1-ffcde1a1b298@github.com>

On Tue, 23 Aug 2022 22:44:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to enhance the character break analysis in `java.text.BreakIterator` to conform to the extended grapheme cluster boundaries defined in https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A corresponding CSR has also been drafted, as there will be behavioral changes with this modification.

This pull request has now been integrated.

Changeset: b8598b02
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b8598b02979dff8a947a523a6d76768a1bfe594b
Stats:     348 lines in 15 files changed: 199 ins; 103 del; 46 mod

8291660: Grapheme support in BreakIterator

Reviewed-by: smarks

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

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

From ethan at mccue.dev  Fri Sep  9 17:31:27 2022
From: ethan at mccue.dev (Ethan McCue)
Date: Fri, 9 Sep 2022 13:31:27 -0400
Subject: Standard Artifact Resolution API
In-Reply-To: <E3A0AB1E-4FAC-4ED3-A3EE-647B74258C60@gmail.com>
References: <CA+NR86hkudszN74xwOYDh2N3LGB+4KCzUbO_cJ8vFnTa7xCTjQ@mail.gmail.com>
 <E3A0AB1E-4FAC-4ED3-A3EE-647B74258C60@gmail.com>
Message-ID: <CA+NR86g8Gd3gWpvO51=SbbWhLH6DFWw+ZStU78_o7xJrkeVEPw@mail.gmail.com>

> We already have Ant+Ivy, Maven, Gradle and they have significantly
different philosophies such that agreeing on a single dependency management
tool may be too ambitious.

Maybe it would be useful to dig into what those different philosophies are?

> I suggest looking at what Gradle has done in this area.
> It would be a reasonable goal for Java to have a canonical format (like
Rust?s ?cargo? format) for external dependencies that addressed all the
issues and tools could use it and benefit from the potential cross-tool
compatibility.

I don't disagree per-se, but without an actual tool the JDK doesn't exactly
have much leverage to drive adoption of whatever
dependency-metadata.[xml|json|toml|tar.gz] would address all the issues. It
also would still need to handle "the world as is" for published artifacts.

> agreeing on a single dependency management tool may be too ambitious.

Maybe, but an uncharitable combination of accepting both the statements

"it's nearly impossible to write a modern application without external
dependencies"

and

"the jdk does not provide the ability to resolve external dependencies"

is

"it's nearly impossible to write a modern application with just the jdk"

Which is at least a tad unfortunate.

On Fri, Sep 9, 2022 at 12:22 PM Scott Palmer <swpalmer at gmail.com> wrote:

> I suggest looking at what Gradle has done in this area.  For example they
> found that the POM format didn?t have information required to properly
> identify variants so they added additional metadata.  (See:
> https://docs.gradle.org/current/userguide/variant_model.html)
>
> It would be a reasonable goal for Java to have a canonical format (like
> Rust?s ?cargo? format) for external dependencies that addressed all the
> issues and tools could use it and benefit from from the potential
> cross-tool compatibility.  I think however that the focus would be on the
> repository format & metadata, not the tool.  We already have Ant+Ivy,
> Maven, Gradle and they have significantly different philosophies such that
> agreeing on a single dependency management tool may be too ambitious.
>
> Scott
>
>
> On Sep 9, 2022, at 9:59 AM, Ethan McCue <ethan at mccue.dev> wrote:
>
> This email is mostly to test the waters, I expect some hostility.
>
> Say, as a premise, that an API for resolving external dependencies was
> something that the JDK concerned itself with providing.
>
> I think the foundation for that is there - the POM v4 format is more or
> less around forever, maven style repositories aren't going anywhere, and
> it's nearly impossible to write a modern application without some degree of
> dependence on code that was written by other people.
>
> What properties would folks want from such an API? What blockers would
> there be (technical/social)? Any other initial thoughts?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220909/d9a9de64/attachment.htm>

From mchung at openjdk.org  Fri Sep  9 18:23:52 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 9 Sep 2022 18:23:52 GMT
Subject: RFR: 8293282: LoadLibraryUnloadTest.java fails with
 "Too few cleared WeakReferences" [v3]
In-Reply-To: <jDgkLmJEqnxMDhGUCVAt3f7ssqnOhJnyPUWhXV7xYnY=.0c8a1bfa-9b85-4813-bff6-f4c21fdfd154@github.com>
References: <O7RYAAkE9CHAAzWdTLQBCaaEns3vK6c896tmx8Ul0rM=.bccf6768-e5b1-4bd3-85f7-4dfd27277bfb@github.com>
 <jDgkLmJEqnxMDhGUCVAt3f7ssqnOhJnyPUWhXV7xYnY=.0c8a1bfa-9b85-4813-bff6-f4c21fdfd154@github.com>
Message-ID: <9NyEJVcSwgAp8z7A-J3W7Zh1V9Ov0mlbyqB30-uJrKY=.bdbb40d4-14f8-414b-ab66-16ad15f387cb@github.com>

On Fri, 9 Sep 2022 15:48:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Modify the LoadLibraryUnload test to call gc() more a few times, allowing multiple gc cycles to queue the expected refs.
>> Short the timeout on each cycle to 10 sec.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused ReferenceQueue for canary WeakReferences.

Jai has a good observation and setting -Xmx to a smaller heap size while I agree that is orthogonal to this change.   Less work for GC may shorten the test execution time as it was suspected that this takes more than one GCs to clear the weak reference.

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

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

From mchung at openjdk.org  Fri Sep  9 22:03:34 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 9 Sep 2022 22:03:34 GMT
Subject: RFR: 8293282: LoadLibraryUnloadTest.java fails with
 "Too few cleared WeakReferences" [v3]
In-Reply-To: <jDgkLmJEqnxMDhGUCVAt3f7ssqnOhJnyPUWhXV7xYnY=.0c8a1bfa-9b85-4813-bff6-f4c21fdfd154@github.com>
References: <O7RYAAkE9CHAAzWdTLQBCaaEns3vK6c896tmx8Ul0rM=.bccf6768-e5b1-4bd3-85f7-4dfd27277bfb@github.com>
 <jDgkLmJEqnxMDhGUCVAt3f7ssqnOhJnyPUWhXV7xYnY=.0c8a1bfa-9b85-4813-bff6-f4c21fdfd154@github.com>
Message-ID: <N_deN7QICsqMqLgr8GudVQMlS5yLv6si5xFmcVooVLU=.1b3c6037-9ad8-4840-8d5a-b950ff92a537@github.com>

On Fri, 9 Sep 2022 15:48:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Modify the LoadLibraryUnload test to call gc() more a few times, allowing multiple gc cycles to queue the expected refs.
>> Short the timeout on each cycle to 10 sec.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused ReferenceQueue for canary WeakReferences.

Looks good.

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

Marked as reviewed by mchung (Reviewer).

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

From naoto at openjdk.org  Fri Sep  9 22:30:41 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 Sep 2022 22:30:41 GMT
Subject: RFR: 8291916: Unexpected output on Windows command prompt
In-Reply-To: <kCEIAwQZuJQRpQB-usp-YiUpUyULY1gzf6Bcf-6ZAtU=.e592478d-a7da-4220-84df-914a02dbe1a2@github.com>
References: <kCEIAwQZuJQRpQB-usp-YiUpUyULY1gzf6Bcf-6ZAtU=.e592478d-a7da-4220-84df-914a02dbe1a2@github.com>
Message-ID: <wUsVvxt2BvERyA9ogVz9rgrWSXESTlkYfU1ro8pAMFM=.7b3a48f3-ea75-4bb2-aa7a-c2de2cea3975@github.com>

On Fri, 5 Aug 2022 02:15:21 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> To support Windows command prompt's codepage, following charsets should be moved from jdk.charsets module to java.base module.
> 
> - IBM860
> - IBM861
> - IBM863
> - IBM864
> - IBM865
> - IBM869

Considering those code page encodings are legacy ones (Microsoft now endorses UTF-8 (cp65001) as the default encoding), I still don't think moving those charsets into java.base module is a good idea. Keeping the base module small is more important IMO.

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

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

From naoto at openjdk.org  Fri Sep  9 23:26:22 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 Sep 2022 23:26:22 GMT
Subject: RFR: 8293579:
 tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese
 Windows platform
In-Reply-To: <ROgI801Y_MVdXiCKPYVtwN9C5kDZTT3gdAo4pnCACbs=.618721ad-4cc5-4db7-a923-3bf740e35181@github.com>
References: <ROgI801Y_MVdXiCKPYVtwN9C5kDZTT3gdAo4pnCACbs=.618721ad-4cc5-4db7-a923-3bf740e35181@github.com>
Message-ID: <xVnuvImRWDHz9kwNg2tjUsvu9BySBFkeyiAQfy3D_K4=.6e1b5e5a-962a-4789-b26f-f96591a597d1@github.com>

On Fri, 9 Sep 2022 08:30:55 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

> Could you please review the JDK-8293579 bug fixes?
> 
> tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java attempts to give 
> the launcher the character which is encoded by Windows API WideCharToMultiByte() 
> from UNICODE "?"(0x00e9) as an argument. However, this test fails because the 
> code point "?"(0x00e9) cannot be treated on Japanese Windows.
> 
> WideCharToMultiByte() encodes characters as Shift-JIS on Japanese Windows, but 
> the code point "?"(0x00e9) does not exist in Shift-JIS, and it is replaced with 
> "e"(0x0065) as substitute. Therefore, "?"(0x00e9) and "e"(0x0065) are compared 
> in this test and judged to be different characters, and return as failed.
> 
> So, in the Japanese encoding("MS932", "SJIS"), the test should be modified to 
> give a character such as "?"(0x3042) as the launcher's argument instead of 
> "?"(0x00e9).

I just wonder if the fix is working as intended... Since JDK18, `file.encoding` is always `UTF-8` with JEP 400, so the switch expression seems to fall into the `default` clause?

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

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

From alanb at openjdk.org  Sat Sep 10 06:19:09 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 10 Sep 2022 06:19:09 GMT
Subject: Integrated: 8292240: CarrierThread.blocking not reset when spare not
 activated
In-Reply-To: <-zN5ga4az_E-S4fJDNkLRaB2SG8nHTuyeAo7ZgSVDBY=.af009574-532f-4078-a934-9f18a0996e7c@github.com>
References: <-zN5ga4az_E-S4fJDNkLRaB2SG8nHTuyeAo7ZgSVDBY=.af009574-532f-4078-a934-9f18a0996e7c@github.com>
Message-ID: <7KrPNQaRfht6c_rDkbEWnDMaXq4C673alFrLjcFSH5s=.b1f1e2af-007d-4df8-a50e-70de0884cdbb@github.com>

On Thu, 11 Aug 2022 16:11:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Some blocking operations that pin a virtual thread to its carrier will compensate by activating a spare carrier (essentially managed blocker). This is done by wrapping the operation in a Blocker begin/end. This code is not correct for the case that a spare cannot be activated (e.g. already at the max of 256 carrier threads). When that happens, the carrier thread's "blocking" flag, used to detect reentrancy, is not reset when the blocking operation is done. The result is that subsequent blocking operations by virtual threads on this carrier thread will not attempt to activate a spare.
> 
> The test runs with parallelism=1 and maxPoolSize=2 in order to make it easier to create the conditions for this bug.

This pull request has now been integrated.

Changeset: 68da02c7
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/68da02c7b536799ccca49e889c22f3e9a2691fb7
Stats:     154 lines in 2 files changed: 148 ins; 0 del; 6 mod

8292240: CarrierThread.blocking not reset when spare not activated

Reviewed-by: dfuchs

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

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

From stuefe at openjdk.org  Sat Sep 10 06:56:20 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 10 Sep 2022 06:56:20 GMT
Subject: RFR: JDK-8293466: libjsig should ignore non-modifying sigaction calls
Message-ID: <0dJOnUfBGdMTkrt-Dq8pXJVapUswB2Sq7bI2PSfJY7A=.04f45a7c-bac1-4771-9cc3-33b5af888d56@github.com>

Found during code review of [JDK-8292695](https://bugs.openjdk.org/browse/JDK-8292695).

We have two bugs in libjsig when we install hotspot signal handlers. Relevant code in libjsig:


int sigaction(int sig, const struct sigaction *act, struct sigaction *oact) {
<snip>

  sigused = sigismember(&jvmsigs, sig);
  if (jvm_signal_installed && sigused) {
    /* jvm has installed its signal handler for this signal. */
    /* Save the handler. Don't really install it. */
    if (oact != NULL) {
      *oact = sact[sig];
    }
    if (act != NULL) {
      sact[sig] = *act;
    }

    signal_unlock();
    return 0;
  } else if (jvm_signal_installing) {
    /* jvm is installing its signal handlers. Install the new
     * handlers and save the old ones. */
    res = call_os_sigaction(sig, act, &oldAct);
    sact[sig] = oldAct;
    if (oact != NULL) {
      *oact = oldAct;
    }

    /* Record the signals used by jvm. */
    sigaddset(&jvmsigs, sig);

    signal_unlock();
    return res;
  }
<snip>
}


Bug 1: we change state even if the sigaction call failed
Bug 2: we change state even if the sigaction call was a non-modifying one (act == NULL)

The latter is usually no problem since hotspot always calls `sigaction()` in pairs when installing a signal: first with NULL to get the old handler, then with the real handler. But this is not always true. If `AllowUserSignalHandlers` is set, and we find a custom handler is present, we will not override it:


void set_signal_handler(int sig, bool do_check = true) {
  // Check for overwrite.
  struct sigaction oldAct;
  sigaction(sig, (struct sigaction*)NULL, &oldAct); <<<<< first sigaction call, libjsig now remembers signal as set

  // Query the current signal handler. Needs to be a separate operation
  // from installing a new handler since we need to honor AllowUserSignalHandlers.
  void* oldhand = get_signal_handler(&oldAct);
  if (!HANDLER_IS_IGN_OR_DFL(oldhand) &&
      !HANDLER_IS(oldhand, javaSignalHandler)) {
    if (AllowUserSignalHandlers) {
      // Do not overwrite; user takes responsibility to forward to us.
      return;


That means:
- we still have the original custom handler in place
- but we already called sigaction, albeit with NULL, but libjsig now assumes that hotspot installed a handler itself.

The result is that any further attempts to change the signal handler, whether by hotspot or by user code, will be prevented by libjsig. Any further non-modifying sigaction calls will return the original - still installed - custom handler.

Admittedly, the error is very exotic. Users would have to set AllowUserSignalHandlers and preload libjsig, and *then* attempt to modify signal handlers after JVM initialization. But it is confusing, and a potential source for other errors. In hotspot, nobody counts on a non-modifying sigaction query changing program state somewhere.

This seems to be an old bug, I see it in at least JDK 8. Did not look further into the past

---

Tests: Ran the runtime/jsig and the runtime/Thread tests manually.

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

Commit messages:
 - JDK-8293466-libjsig-should-ignore-non-modifying-sigaction-calls
 - JDK-8293466-libjsig-should-ignore-non-modifying-sigaction-calls

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

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

From duke at openjdk.org  Sat Sep 10 12:41:44 2022
From: duke at openjdk.org (Markus KARG)
Date: Sat, 10 Sep 2022 12:41:44 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v7]
In-Reply-To: <bSbC1oyhu41M8dzeZHhVSI08UOFj9cVnB-Zs3oW4Sy8=.7e1f43d7-50c5-4bd7-ba2a-a9ad965981ce@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <iQc17-mZLZe0P2Kc41ZYd4vZDjG4CYV-XDORMUpOo1M=.27d01189-50a8-4c32-916f-2e4d6c1f521d@github.com>
 <bSbC1oyhu41M8dzeZHhVSI08UOFj9cVnB-Zs3oW4Sy8=.7e1f43d7-50c5-4bd7-ba2a-a9ad965981ce@github.com>
Message-ID: <chZgwgh5JI1vDseIRMMYaJCAfF_wMK6gOOxLfFy_Q9A=.f23633d7-6ac7-4cb4-a247-986364ff067e@github.com>

On Mon, 5 Sep 2022 18:33:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   HexPrinter::transferTo
>
> It looks like this patch is against a repository that hasn't been sync'ed up since late 2021. BIS has changed, esp. the locking, so this is why you get the merge-conflict label. Look at the implXXX methods to see how the existing methods do the locking.
> 
> I think I pointed out in one of the early rounds that you'll have to take the mark (if set) into account. It may be that you just call super.transferTo when markpos == -1.
> 
> The other issue that needs consideration is that the draining of the buffered bytes will leak the underlying input stream to the target output stream. It may be safer to also call super.transferTo when (count - pos) > 0.

@AlanBateman I do not quite understand what would be wrong with the code below instead of falling back to the super implementation *in case of non-empty buffer*?

private long implTransferTo(OutputStream out) throws IOException {
    if (getClass() == BufferedInputStream.class && markpos < 0) {
        int avail = count - pos;
        if (avail > 0) {
            out.write(getBufIfOpen(), pos, avail);
            pos = count;
        }
        return avail + getInIfOpen().transferTo(out);
    } else {
        return super.transferTo(out);
    }
}

Can you please explain why you proposed to use the super implementation for non-empty buffer? Just for my understanding. Thanks!

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

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

From ethan at mccue.dev  Sat Sep 10 16:49:55 2022
From: ethan at mccue.dev (Ethan McCue)
Date: Sat, 10 Sep 2022 12:49:55 -0400
Subject: Standard Artifact Resolution API
In-Reply-To: <EFD85D67-C546-4D93-96EF-844B7A3E0801@gmail.com>
References: <CA+NR86hkudszN74xwOYDh2N3LGB+4KCzUbO_cJ8vFnTa7xCTjQ@mail.gmail.com>
 <E3A0AB1E-4FAC-4ED3-A3EE-647B74258C60@gmail.com>
 <CA+NR86g8Gd3gWpvO51=SbbWhLH6DFWw+ZStU78_o7xJrkeVEPw@mail.gmail.com>
 <EFD85D67-C546-4D93-96EF-844B7A3E0801@gmail.com>
Message-ID: <CA+NR86j2xXnxO40mcBuTPzWM5b+x7JY80dK=-wdco5t=edhnqA@mail.gmail.com>

Okay so from what I can parse there are different streams of work here

1. The JDK could be well served by a "standard" build tool.

I don't think this is controversial, but I'm nowhere near qualified enough
to say what the "right" choice is. Maybe it is just taking gradle, who
knows.

What I do posit, though, is that the problem space is underexplored. I will
claim this is partially because things like dependency resolution have been
out of reach of the kinds of low stakes amateur exploration that drives
innovation. The Node ecosystem churns through a build system a season, but
they are at least actively exploring options - y'know?

Let's call this hypothetical tool "jproject".

2. The JDK has the power to standardize improvements to dependency metadata
and resolution

The gradle team has done what they think is a good extension of the
classifier system. There is some other analogous work in the rust ecosystem
around features that could be interesting to incorporate. Maybe even
ABI-level tool enforced minimum semver bumps like Elm, where we make
something similar to Scala's Tasty metadata.

Of all the players in the ecosystem, the JDK probably has the most power to
make a given answer "happen", and being comfortable that the right answer
has been reached may or may not be a blocker for "jproject" being real.

3. A standard dependency resolution api

In order to successfully drive improvements to dependency resolution the
JDK needs a tool, but I don't think that needs to be dependent on either
knowing the "best-path-forward" metadata or deciding on a JDK build tool.

There is enough prior work in tools like coursier (https://get-coursier.io/),
shrinkwrap resolver (https://github.com/shrinkwrap/resolver), maven aether (
https://maven.apache.org/aether.html), and tools deps (
https://github.com/clojure/tools.deps.alpha) to at least start to talk
about what a "jresolve" cli tool or "java.util.resolve"' api could look
like.

(apologies if that is only mildly coherent)

On Sat, Sep 10, 2022 at 12:19 PM Scott Palmer <swpalmer at gmail.com> wrote:

> After thinking about it a bit more, I agree that a canonical dependency
> format wouldn?t be much good without the tool to go with it.  In my
> particular case, I have builds that incorporate native code and Java.  I
> use Gradle partly because it handles both (though it could do a better job
> with C and cross-compiling), and also because it can handle complex build
> logic for putting the pieces together.  One thing I dislike about tools
> such as Rusts? cargo or Node?s npm, is that they seem to make the
> assumption that my project is based on a single language. That?s one reason
> I don?t use Maven - it assumes you have a vanilla Java project and is
> painful to use for anything beyond that.  Any tool integrated into the JDK
> should be able to build the JDK itself, including all the native bits, and
> dealing with the multiple platforms and conditions.  There should be no
> need for external scripts to hack it together and very few external tools.
> E.g. a C/C++ compiler would be needed to b build the JDK, but not
> bash/Cygwin.
>
> I?ve often thought, why don?t they just use Gradle for building the JDK?
> It seems to me that it would be so much simpler (and faster), but I can
> imagine the mess of build-logic history that would need to be untangled.
> I haven?t looked into alternatives like Bazel, as Gradle is working well
> for me, but in the design of any tool for the JDK all of these other tools
> should be looked at.  Perhaps in the end the JDK could simply settle on one
> of the modern tools already available and integrate or endorse it?  That to
> me would make more sense than building yet another tool (
> https://xkcd.com/927/). For example, if the JDK were to adopt Gradle as
> the tool to use to build the JDK, it could de-facto become the ?JDK build
> tool?.   Other projects formerly part of the JDK, like JavaFX, are already
> using Gradle (though not as effectively as they could).
>
> Anyway, that?s just my 2 cents on the subject.
>
> Regards,
>
> Scott
>
>
> On Sep 9, 2022, at 1:31 PM, Ethan McCue <ethan at mccue.dev> wrote:
>
> > We already have Ant+Ivy, Maven, Gradle and they have significantly
> different philosophies such that agreeing on a single dependency management
> tool may be too ambitious.
>
> Maybe it would be useful to dig into what those different philosophies are?
>
> > I suggest looking at what Gradle has done in this area.
> > It would be a reasonable goal for Java to have a canonical format (like
> Rust?s ?cargo? format) for external dependencies that addressed all the
> issues and tools could use it and benefit from the potential cross-tool
> compatibility.
>
> I don't disagree per-se, but without an actual tool the JDK doesn't
> exactly have much leverage to drive adoption of whatever
> dependency-metadata.[xml|json|toml|tar.gz] would address all the issues. It
> also would still need to handle "the world as is" for published artifacts.
>
> > agreeing on a single dependency management tool may be too ambitious.
>
> Maybe, but an uncharitable combination of accepting both the statements
>
> "it's nearly impossible to write a modern application without external
> dependencies"
>
> and
>
> "the jdk does not provide the ability to resolve external dependencies"
>
> is
>
> "it's nearly impossible to write a modern application with just the jdk"
>
> Which is at least a tad unfortunate.
>
> On Fri, Sep 9, 2022 at 12:22 PM Scott Palmer <swpalmer at gmail.com> wrote:
>
>> I suggest looking at what Gradle has done in this area.  For example they
>> found that the POM format didn?t have information required to properly
>> identify variants so they added additional metadata.  (See:
>> https://docs.gradle.org/current/userguide/variant_model.html)
>>
>> It would be a reasonable goal for Java to have a canonical format (like
>> Rust?s ?cargo? format) for external dependencies that addressed all the
>> issues and tools could use it and benefit from from the potential
>> cross-tool compatibility.  I think however that the focus would be on the
>> repository format & metadata, not the tool.  We already have Ant+Ivy,
>> Maven, Gradle and they have significantly different philosophies such that
>> agreeing on a single dependency management tool may be too ambitious.
>>
>> Scott
>>
>>
>> On Sep 9, 2022, at 9:59 AM, Ethan McCue <ethan at mccue.dev> wrote:
>>
>> This email is mostly to test the waters, I expect some hostility.
>>
>> Say, as a premise, that an API for resolving external dependencies was
>> something that the JDK concerned itself with providing.
>>
>> I think the foundation for that is there - the POM v4 format is more or
>> less around forever, maven style repositories aren't going anywhere, and
>> it's nearly impossible to write a modern application without some degree of
>> dependence on code that was written by other people.
>>
>> What properties would folks want from such an API? What blockers would
>> there be (technical/social)? Any other initial thoughts?
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220910/a468a50d/attachment.htm>

From manc at openjdk.org  Sun Sep 11 05:11:38 2022
From: manc at openjdk.org (Man Cao)
Date: Sun, 11 Sep 2022 05:11:38 GMT
Subject: RFR: JDK-8293466: libjsig should ignore non-modifying sigaction
 calls
In-Reply-To: <0dJOnUfBGdMTkrt-Dq8pXJVapUswB2Sq7bI2PSfJY7A=.04f45a7c-bac1-4771-9cc3-33b5af888d56@github.com>
References: <0dJOnUfBGdMTkrt-Dq8pXJVapUswB2Sq7bI2PSfJY7A=.04f45a7c-bac1-4771-9cc3-33b5af888d56@github.com>
Message-ID: <saaVWptFE8hmbmy8BgS4nvw41eETOuxKP53N0Bn2WRs=.6e285a0b-924d-4e59-a25e-8a7a341fecd3@github.com>

On Sat, 10 Sep 2022 06:15:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Found during code review of [JDK-8292695](https://bugs.openjdk.org/browse/JDK-8292695).
> 
> We have two bugs in libjsig when we install hotspot signal handlers. Relevant code in libjsig:
> 
> 
> int sigaction(int sig, const struct sigaction *act, struct sigaction *oact) {
> <snip>
> 
>   sigused = sigismember(&jvmsigs, sig);
>   if (jvm_signal_installed && sigused) {
>     /* jvm has installed its signal handler for this signal. */
>     /* Save the handler. Don't really install it. */
>     if (oact != NULL) {
>       *oact = sact[sig];
>     }
>     if (act != NULL) {
>       sact[sig] = *act;
>     }
> 
>     signal_unlock();
>     return 0;
>   } else if (jvm_signal_installing) {
>     /* jvm is installing its signal handlers. Install the new
>      * handlers and save the old ones. */
>     res = call_os_sigaction(sig, act, &oldAct);
>     sact[sig] = oldAct;
>     if (oact != NULL) {
>       *oact = oldAct;
>     }
> 
>     /* Record the signals used by jvm. */
>     sigaddset(&jvmsigs, sig);
> 
>     signal_unlock();
>     return res;
>   }
> <snip>
> }
> 
> 
> Bug 1: we change state even if the sigaction call failed
> Bug 2: we change state even if the sigaction call was a non-modifying one (act == NULL)
> 
> The latter is usually no problem since hotspot always calls `sigaction()` in pairs when installing a signal: first with NULL to get the old handler, then with the real handler. But this is not always true. If `AllowUserSignalHandlers` is set, and we find a custom handler is present, we will not override it:
> 
> 
> void set_signal_handler(int sig, bool do_check = true) {
>   // Check for overwrite.
>   struct sigaction oldAct;
>   sigaction(sig, (struct sigaction*)NULL, &oldAct); <<<<< first sigaction call, libjsig now remembers signal as set
> 
>   // Query the current signal handler. Needs to be a separate operation
>   // from installing a new handler since we need to honor AllowUserSignalHandlers.
>   void* oldhand = get_signal_handler(&oldAct);
>   if (!HANDLER_IS_IGN_OR_DFL(oldhand) &&
>       !HANDLER_IS(oldhand, javaSignalHandler)) {
>     if (AllowUserSignalHandlers) {
>       // Do not overwrite; user takes responsibility to forward to us.
>       return;
> 
> 
> That means:
> - we still have the original custom handler in place
> - but we already called sigaction, albeit with NULL, but libjsig now assumes that hotspot installed a handler itself.
> 
> The result is that any further attempts to change the signal handler, whether by hotspot or by user code, will be prevented by libjsig. Any further non-modifying sigaction calls will return the original - still installed - custom handler.
> 
> Admittedly, the error is very exotic. Users would have to set AllowUserSignalHandlers and preload libjsig, and *then* attempt to modify signal handlers after JVM initialization. But it is confusing, and a potential source for other errors. In hotspot, nobody counts on a non-modifying sigaction query changing program state somewhere.
> 
> This seems to be an old bug, I see it in at least JDK 8. Did not look further into the past
> 
> ---
> 
> Tests: Ran the runtime/jsig and the runtime/Thread tests manually.

LGTM. Not an official OpenJDK Reviewer though.

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

Marked as reviewed by manc (Committer).

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

From alanb at openjdk.org  Sun Sep 11 07:46:45 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 11 Sep 2022 07:46:45 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo
 [v11]
In-Reply-To: <_la5Co3yx5ik1wt7Y6Bi7MDC3MCVUxIKxz_iQQp2TT8=.1023ef6d-266f-45f5-aa93-7218d0d89c10@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <_la5Co3yx5ik1wt7Y6Bi7MDC3MCVUxIKxz_iQQp2TT8=.1023ef6d-266f-45f5-aa93-7218d0d89c10@github.com>
Message-ID: <34XpvO2kWiaGOek0LRM_ZW5Wlkbp1pW5NzDaKZc3N1I=.93222a1d-3ed7-4700-9115-8bc47a077bbd@github.com>

On Fri, 9 Sep 2022 12:19:54 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Implementation of JDK-8279283
>
> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - corrected copyright
>  - testing transferTo() after reset()

> I do not quite understand what would be wrong with the code below instead of falling back to the super implementation _in case of non-empty buffer_?

I think you are asking if is safe to leak a reference to the internal buffer. If there is no mark then it might be okay because there is no replay for an evil output stream to attack. However, I think it would require wider review to be confident that there aren't other interesting ways to break it; hence the suggestion in one of the earlier comments to keep it simple and limit it when there is no subclassing, no mark, and no bytes buffered. This does not prevent widening the conditions in the future.

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

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

From duke at openjdk.org  Sun Sep 11 08:06:54 2022
From: duke at openjdk.org (Markus KARG)
Date: Sun, 11 Sep 2022 08:06:54 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo
 [v11]
In-Reply-To: <34XpvO2kWiaGOek0LRM_ZW5Wlkbp1pW5NzDaKZc3N1I=.93222a1d-3ed7-4700-9115-8bc47a077bbd@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <_la5Co3yx5ik1wt7Y6Bi7MDC3MCVUxIKxz_iQQp2TT8=.1023ef6d-266f-45f5-aa93-7218d0d89c10@github.com>
 <34XpvO2kWiaGOek0LRM_ZW5Wlkbp1pW5NzDaKZc3N1I=.93222a1d-3ed7-4700-9115-8bc47a077bbd@github.com>
Message-ID: <Krgv8GySho1g_UyeDrJa-4sc5HkbtPizXBCC3yk097k=.e6832aef-173d-4bde-a754-dd52cc3b0cb8@github.com>

On Sun, 11 Sep 2022 07:44:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > I do not quite understand what would be wrong with the code below instead of falling back to the super implementation _in case of non-empty buffer_?
> 
> I think you are asking if is safe to leak a reference to the internal buffer. If there is no mark then it might be okay because there is no replay for an evil output stream to attack. However, I think it would require wider review to be confident that there aren't other interesting ways to break it; hence the suggestion in one of the earlier comments to keep it simple and limit it when there is no subclassing, no mark, and no bytes buffered. This does not prevent widening the conditions in the future.

Thank you. So I will file another PR for such a further discussion once we merged the current one.

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

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

From dfuchs at openjdk.org  Mon Sep 12 09:34:43 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 12 Sep 2022 09:34:43 GMT
Subject: RFR: 8290367: Update default value and extend the scope of
 com.sun.jndi.ldap.object.trustSerialData system property [v2]
In-Reply-To: <IPAtsqgCk-KnjZ6saGmBMb3VHvm7DWCkT2uu_S27acI=.50ee2564-080c-4f0d-af55-35608e966179@github.com>
References: <T8JiNCNUKjV5bue6Bd8MjtatKCd9yik8cYMw2NIGTps=.02763149-a450-4e04-99b5-748d92b35714@github.com>
 <IPAtsqgCk-KnjZ6saGmBMb3VHvm7DWCkT2uu_S27acI=.50ee2564-080c-4f0d-af55-35608e966179@github.com>
Message-ID: <YxxGu_abm2gc2WngGjKlM8ZUHSO2P9MLO2MrN4Wgqcw=.dbe07dd3-0e9a-4590-8856-a987e80bd095@github.com>

On Fri, 9 Sep 2022 16:55:44 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary of the change
>> 
>> The LDAP Naming Service Provider implementation's default settings are changed to disallow deserialization and reconstruction of Java objects from different LDAP attributes (RFC 2713). Currently, only the deserialization is controlled by the `com.sun.jndi.ldap.object.trustSerialData` system property, and it is allowed by default.
>> The change proposed here switches the default value of the` com.sun.jndi.ldap.object.trustSerialData `system property to `"false"`, and also extends its scope to cover the reconstruction of RMI remote objects from the `javaRemoteLocation` LDAP attribute.
>> 
>> CSR for this change can be viewed [here](https://bugs.openjdk.org/browse/JDK-8290369).
>> 
>> ### List of code changes
>> - Switch the default value of the 'com.sun.jndi.ldap.object.trustSerialData' system property to "false".
>> 
>> - Extend the scope of the property to also cover the reconstruction of RMI remote objects from the deprecated 'javaRemoteLocation' LDAP attribute.
>> 
>> - Document the support for `javaRemoteLocation` and the `javaReferenceAddress` LDAP attributes in `java.naming`'s module-info.
>> 
>> ### Test changes
>> - New `test/jdk/com/sun/jndi/ldap/objects/RemoteLocationAttributeTest.java` test has been added to test that `com.sun.jndi.ldap.object.trustSerialData` system property can be used to control reconstruction of RMI objects from the `javaRemoteLocation` LDAP attribute.
>> 
>> -  `test/jdk/javax/naming/module/RunBasic.java` was modified to pass `com.sun.jndi.ldap.object.trustSerialData=true` to the sub-tests that rely on reconstruction/deserialization from LDAP attributes. 
>> 
>> - During the update for `test/jdk/javax/naming/module/RunBasic.java`, it was spotted that sub-tests apps launched in separate processes were returning the '0' exit value irrelevant to their execution status. All these sub-tests were modified to throw an exception when failure is observed. It helps to ensure that the exit value of launched process is not '0' for failed sub-tests.
>> 
>> ### Testing
>> 
>> `tier1`-`tier3` and JNDI regression/JCK tests not showing any failures related to this change.
>> No failures observed for the modified regression tests.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add run for the SP w/o value, formatting/wording updates

@AlekseiEfimov The CSR is well written, and the update to the module-info.java look good to me. The code changes and tests changes look good. I'm glad to see this change.

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

Marked as reviewed by dfuchs (Reviewer).

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

From duke at openjdk.org  Mon Sep 12 09:40:18 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 12 Sep 2022 09:40:18 GMT
Subject: RFR: 8293630: Simplify TreeMap.get() with Comparator.naturalOrder()
Message-ID: <gV_EahOUQIDq-71mp4aC8bFtrZyw_oKe9m9RuFP-0Uo=.f6bfbdc1-cc7d-43b6-8595-82f26be793ee@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?

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

Commit messages:
 - 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: https://git.openjdk.org/jdk/pull/9901/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9901&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293630
  Stats: 45 lines in 1 file changed: 6 ins; 22 del; 17 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 duke at openjdk.org  Mon Sep 12 09:40:19 2022
From: duke at openjdk.org (liach)
Date: Mon, 12 Sep 2022 09:40:19 GMT
Subject: RFR: 8293630: Simplify TreeMap.get() with
 Comparator.naturalOrder()
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: <0k3bK-V3WVOGjeoVQLdqCTL5NjaXcH5paqcR14qs58I=.0c35ac24-b79b-4428-92de-3a3770294939@github.com>

On Wed, 17 Aug 2022 11:23:57 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> 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?

src/java.base/share/classes/java/util/TreeMap.java line 3318:

> 3316:             // Adapt or create a key-based comparator
> 3317:             Comparator<? super K> treeComparator = tree.comparator;
> 3318:             return Map.Entry.comparingByKey(treeComparator == null ? natural() : treeComparator);

You can probably have:

return treeComparator == nul ?
        Map.Entry.comparingByKey() :
        Map.Entry.comparingByKey(treeComparator);

instead.

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

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

From duke at openjdk.org  Mon Sep 12 09:40:19 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 12 Sep 2022 09:40:19 GMT
Subject: RFR: 8293630: Simplify TreeMap.get() with
 Comparator.naturalOrder()
In-Reply-To: <0k3bK-V3WVOGjeoVQLdqCTL5NjaXcH5paqcR14qs58I=.0c35ac24-b79b-4428-92de-3a3770294939@github.com>
References: <gV_EahOUQIDq-71mp4aC8bFtrZyw_oKe9m9RuFP-0Uo=.f6bfbdc1-cc7d-43b6-8595-82f26be793ee@github.com>
 <0k3bK-V3WVOGjeoVQLdqCTL5NjaXcH5paqcR14qs58I=.0c35ac24-b79b-4428-92de-3a3770294939@github.com>
Message-ID: <lkOBF5TWrSZ2oI639Ak3qKiKHvS9e1JTeCZwlVWmFvE=.cd97b61c-937a-4855-97c8-1e7c7eba0123@github.com>

On Sat, 20 Aug 2022 16:37:29 GMT, liach <duke at openjdk.org> wrote:

>> 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?
>
> src/java.base/share/classes/java/util/TreeMap.java line 3318:
> 
>> 3316:             // Adapt or create a key-based comparator
>> 3317:             Comparator<? super K> treeComparator = tree.comparator;
>> 3318:             return Map.Entry.comparingByKey(treeComparator == null ? natural() : treeComparator);
> 
> You can probably have:
> 
> return treeComparator == nul ?
>         Map.Entry.comparingByKey() :
>         Map.Entry.comparingByKey(treeComparator);
> 
> instead.

Nope, there'd be a compilation error

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

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

From shade at openjdk.org  Mon Sep 12 09:43:16 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 12 Sep 2022 09:43:16 GMT
Subject: RFR: 8293499: Provide jmod compression level option
In-Reply-To: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
Message-ID: <WXjeLN6TUKdTtRScgDsP0zZOTPQGVI3WYtmxiF11M-4=.0027db0d-e6b9-4edc-ae53-1ae30461bfba@github.com>

On Thu, 8 Sep 2022 07:57:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have been looking into `make clean-images images` performance, and realized jmod keeps compressing files with default compression level. Tuning that toward lighter compression levels improves build performance considerably, without a heavy loss in *.jmod sizes. 
> 
> This PR allows JMOD to select the compression level. Follow-ups would use this in the build system, see #10214.
> 
> This change nominally requires CSR, but I would like to gauge the reaction to this patch first, before submitting a formal CSR. The interesting asymmetry against `jlink` is: `jlink` provides `--compress` option that only takes `2` for "ZIP compression". I would argue it would be beneficial to add `--compression-level` to `jlink` as well, so to select the compression level there too.

I submitted the CSR request for this change: https://bugs.openjdk.org/browse/JDK-8293629

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

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

From duke at openjdk.org  Mon Sep 12 10:11:43 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 12 Sep 2022 10:11:43 GMT
Subject: RFR: 8292698: Improve performance of DataInputStream [v3]
In-Reply-To: <e4eIcbtpEZdZdn5KvOHjd3zrI8voMlr1aMuURWTJRN0=.7834a1a2-287a-4b3c-80bd-0918c7a04ae7@github.com>
References: <MXdBQj8qYqvvImT-MaBpf8mAm3b1tbNiPS93syrjfqg=.3ebdd952-f9d7-4ec9-9655-a63829828c67@github.com>
 <5v8lej62KNGYz6FTjQ6FyABbMfJxwLUSNCa6Z3DXZGQ=.1b35ef41-3b59-4b78-b035-6d1838eaebbd@github.com>
 <KIfIm02U3CPC53gSjSpi68Jk7BcoMgcmwHe3SDGVFSw=.0dc503c6-937b-4c7f-a05a-6ac7655f019e@github.com>
 <e4eIcbtpEZdZdn5KvOHjd3zrI8voMlr1aMuURWTJRN0=.7834a1a2-287a-4b3c-80bd-0918c7a04ae7@github.com>
Message-ID: <9envbhhc21YONg335lelECu8h4u_5QAlegJV9w_fCts=.097c4a7f-45c6-42bd-ad52-f6e6a519d411@github.com>

On Thu, 25 Aug 2022 09:25:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Btw, I've tried to reimplement `readInt()` in a way similar to `readLong()`:
>> 
>> public final int readInt() throws IOException {
>>     readFully(readBuffer, 0, 4);
>>     return (readBuffer[0] & 0xff) << 24
>>          + (readBuffer[1] & 0xff) << 16
>>          + (readBuffer[2] & 0xff) << 8
>>          + (readBuffer[3] & 0xff);
>> }
>> 
>> but with this change the build fails with
>> 
>> Building target 'test' in configuration 'macosx-x86_64-server-release'
>> Compiling 3158 files for java.base
>> Updating support/src.zip
>> Optimizing the exploded image
>> Error occurred during initialization of boot layer
>> java.lang.module.FindException: Error reading module: /Users/stsypanov/IdeaProjects/jdk/build/macosx-x86_64-server-release/jdk/modules/java.management.rmi
>> Caused by: java.lang.module.InvalidModuleDescriptorException: Bad magic number
>> make[3]: *** [/Users/stsypanov/IdeaProjects/jdk/build/macosx-x86_64-server-release/jdk/_optimize_image_exec.marker] Error 1
>> make[2]: *** [exploded-image-optimize] Error 2
>> 
>> ERROR: Build failed for target 'test' in configuration 'macosx-x86_64-server-release' (exit code 2) 
>> Stopping sjavac server
>> 
>> === Output from failing command(s) repeated here ===
>> * For target jdk__optimize_image_exec:
>> Error occurred during initialization of boot layer
>> java.lang.module.FindException: Error reading module: /Users/stsypanov/IdeaProjects/jdk/build/macosx-x86_64-server-release/jdk/modules/java.management.rmi
>> Caused by: java.lang.module.InvalidModuleDescriptorException: Bad magic number
>> 
>> * All command lines available in /Users/stsypanov/IdeaProjects/jdk/build/macosx-x86_64-server-release/make-support/failure-logs.
>> === End of repeated output ===
>> 
>> What is wrong with the change?
>
>> What is wrong with the change?
> 
> You'll need parentheses to make that work, changing it to use '|' would work too.

@AlanBateman @dfuch is there anything I can do about this PR?

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

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

From redestad at openjdk.org  Mon Sep 12 10:18:01 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 12 Sep 2022 10:18:01 GMT
Subject: RFR: 8293499: Provide jmod compression level option
In-Reply-To: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
Message-ID: <KuAHZ29TsraSfrcieRHDzMYbhzh0wAimt0H0mU5zmZg=.e9db65a1-627e-4d1e-9b1d-a303deaf15cd@github.com>

On Thu, 8 Sep 2022 07:57:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have been looking into `make clean-images images` performance, and realized jmod keeps compressing files with default compression level. Tuning that toward lighter compression levels improves build performance considerably, without a heavy loss in *.jmod sizes. 
> 
> This PR allows JMOD to select the compression level. Follow-ups would use this in the build system, see #10214.
> 
> This change nominally requires CSR, but I would like to gauge the reaction to this patch first, before submitting a formal CSR. The interesting asymmetry against `jlink` is: `jlink` provides `--compress` option that only takes `2` for "ZIP compression". I would argue it would be beneficial to add `--compression-level` to `jlink` as well, so to select the compression level there too.

Could we word this so that the accepted values is compression-dependent? The value appears to be ignored for `--compress=0|1` (should it throw if specified or not specified to, say, 0?). We might also add other compressions in the future which allows a wider or narrower range of compression levels (zstd uses 0 - 22).

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

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

From jpai at openjdk.org  Mon Sep 12 10:18:01 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 12 Sep 2022 10:18:01 GMT
Subject: RFR: 8293499: Provide jmod compression level option
In-Reply-To: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
Message-ID: <hKuncm4kge-aXUpk2NrnOI4DRgP7Tf_6X9j-ditVAnU=.4439f647-2f6e-4670-9275-2750ee508b3b@github.com>

On Thu, 8 Sep 2022 07:57:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have been looking into `make clean-images images` performance, and realized jmod keeps compressing files with default compression level. Tuning that toward lighter compression levels improves build performance considerably, without a heavy loss in *.jmod sizes. 
> 
> This PR allows JMOD to select the compression level. Follow-ups would use this in the build system, see #10214.
> 
> This change nominally requires CSR, but I would like to gauge the reaction to this patch first, before submitting a formal CSR. The interesting asymmetry against `jlink` is: `jlink` provides `--compress` option that only takes `2` for "ZIP compression". I would argue it would be beneficial to add `--compression-level` to `jlink` as well, so to select the compression level there too.

src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties line 85:

> 83: main.opt.cmdfile=Read options from the specified file
> 84: 
> 85: main.opt.compression-level=Compression level to use when compressing the JMOD archive.\

Hello Aleksey, should this instead say "Compression level to use when creating the JMOD archive."?

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

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

From jpai at openjdk.org  Mon Sep 12 10:21:05 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 12 Sep 2022 10:21:05 GMT
Subject: RFR: 8293499: Provide jmod compression level option
In-Reply-To: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
Message-ID: <RQnHc9nYL1IX9v1Ml4VNoZqmRPcEvPf8-SG8yZqwt74=.f5cb18f9-9018-4426-8562-c8cf7b433b15@github.com>

On Thu, 8 Sep 2022 07:57:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have been looking into `make clean-images images` performance, and realized jmod keeps compressing files with default compression level. Tuning that toward lighter compression levels improves build performance considerably, without a heavy loss in *.jmod sizes. 
> 
> This PR allows JMOD to select the compression level. Follow-ups would use this in the build system, see #10214.
> 
> This change nominally requires CSR, but I would like to gauge the reaction to this patch first, before submitting a formal CSR. The interesting asymmetry against `jlink` is: `jlink` provides `--compress` option that only takes `2` for "ZIP compression". I would argue it would be beneficial to add `--compression-level` to `jlink` as well, so to select the compression level there too.

I gave this a try locally. It's my understanding that this new option is only relevant when creating the `jmod` archive. However, right now, in its current form, I can pass this option to commands like `jmod extract` and `jmod list` without those commands complaining about that option. For example, this following command doesn't complain about the `--compression-level` being passed to it:


jmod extract --compression-level=9 jdk/jmods/java.base.jmod

Should we instead complain/fail when this option is used for anything other than `create`?

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

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

From shade at openjdk.org  Mon Sep 12 10:30:44 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 12 Sep 2022 10:30:44 GMT
Subject: RFR: 8293499: Provide jmod compression level option
In-Reply-To: <KuAHZ29TsraSfrcieRHDzMYbhzh0wAimt0H0mU5zmZg=.e9db65a1-627e-4d1e-9b1d-a303deaf15cd@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
 <KuAHZ29TsraSfrcieRHDzMYbhzh0wAimt0H0mU5zmZg=.e9db65a1-627e-4d1e-9b1d-a303deaf15cd@github.com>
Message-ID: <xl524uxRBH8lKO7UxqYBkXwCgJMZXKc0hCjQKk7O7x0=.dc7fc4a6-5f70-48d6-95d1-e6f221fd00c8@github.com>

On Mon, 12 Sep 2022 10:13:12 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Could we word this so that the accepted values is compression-dependent? The value appears to be ignored for `--compress=0|1` (should it throw if specified or not specified to, say, 0?). We might also add other compressions in the future which allows a wider or narrower range of compression levels (zstd uses 0 - 22).

Um, this is `jmod`, it does not have `--compress=...` option? `jlink` does. So, I don't quite understand this comment :)

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

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

From shade at openjdk.org  Mon Sep 12 10:42:45 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 12 Sep 2022 10:42:45 GMT
Subject: RFR: 8293499: Provide jmod compression level option
In-Reply-To: <hKuncm4kge-aXUpk2NrnOI4DRgP7Tf_6X9j-ditVAnU=.4439f647-2f6e-4670-9275-2750ee508b3b@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
 <hKuncm4kge-aXUpk2NrnOI4DRgP7Tf_6X9j-ditVAnU=.4439f647-2f6e-4670-9275-2750ee508b3b@github.com>
Message-ID: <4syldT1P2uktq1FL4eZuxDcjY89LyH11CuijQ-PppUE=.dd47b9ec-13cf-4eca-86ac-01a4d16dacb7@github.com>

On Mon, 12 Sep 2022 10:15:26 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> I have been looking into `make clean-images images` performance, and realized jmod keeps compressing files with default compression level. Tuning that toward lighter compression levels improves build performance considerably, without a heavy loss in *.jmod sizes. 
>> 
>> This PR allows JMOD to select the compression level. Follow-ups would use this in the build system, see #10214.
>> 
>> This change nominally requires CSR, but I would like to gauge the reaction to this patch first, before submitting a formal CSR. The interesting asymmetry against `jlink` is: `jlink` provides `--compress` option that only takes `2` for "ZIP compression". (Separately, we could argue if it would be beneficial to add `--compression-level` to `jlink` as well, so to select the compression level there too.)
>
> src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties line 85:
> 
>> 83: main.opt.cmdfile=Read options from the specified file
>> 84: 
>> 85: main.opt.compression-level=Compression level to use when compressing the JMOD archive.\
> 
> Hello Aleksey, should this instead say "Compression level to use when creating the JMOD archive."?

Right. Done in new commit (to be published soon).

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

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

From shade at openjdk.org  Mon Sep 12 10:48:16 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 12 Sep 2022 10:48:16 GMT
Subject: RFR: 8293499: Provide jmod compression level option [v2]
In-Reply-To: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
Message-ID: <vsdqwfOrBiSgHwM22RoQHNyepexZYvAzyvObzwMxE3k=.5c344518-a3a2-4b98-b64d-4f2242caf397@github.com>

> I have been looking into `make clean-images images` performance, and realized jmod keeps compressing files with default compression level. Tuning that toward lighter compression levels improves build performance considerably, without a heavy loss in *.jmod sizes. 
> 
> This PR allows JMOD to select the compression level. Follow-ups would use this in the build system, see #10214.
> 
> This change nominally requires CSR, but I would like to gauge the reaction to this patch first, before submitting a formal CSR. The interesting asymmetry against `jlink` is: `jlink` provides `--compress` option that only takes `2` for "ZIP compression". (Separately, we could argue if it would be beneficial to add `--compression-level` to `jlink` as well, so to select the compression level there too.)

Aleksey Shipilev 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:

 - Only accept --compression-level when creating the archive
 - Merge branch 'master' into JDK-8293499-jmod-compression-level
 - Fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10213/files
  - new: https://git.openjdk.org/jdk/pull/10213/files/8f1dc761..c44ecf01

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

  Stats: 45099 lines in 404 files changed: 23431 ins; 20112 del; 1556 mod
  Patch: https://git.openjdk.org/jdk/pull/10213.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10213/head:pull/10213

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

From shade at openjdk.org  Mon Sep 12 10:48:16 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 12 Sep 2022 10:48:16 GMT
Subject: RFR: 8293499: Provide jmod compression level option
In-Reply-To: <RQnHc9nYL1IX9v1Ml4VNoZqmRPcEvPf8-SG8yZqwt74=.f5cb18f9-9018-4426-8562-c8cf7b433b15@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
 <RQnHc9nYL1IX9v1Ml4VNoZqmRPcEvPf8-SG8yZqwt74=.f5cb18f9-9018-4426-8562-c8cf7b433b15@github.com>
Message-ID: <b-Ve9LIsaM0QTDJIpTsK3uut5yWVh55vd2u7lNMJFR4=.df408024-0412-4237-8a33-d29755d059dc@github.com>

On Mon, 12 Sep 2022 10:18:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Should we instead complain/fail when this option is used for anything other than `create`?

Good idea, see new commit.

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

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

From redestad at openjdk.org  Mon Sep 12 10:51:08 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 12 Sep 2022 10:51:08 GMT
Subject: RFR: 8293499: Provide jmod compression level option
In-Reply-To: <xl524uxRBH8lKO7UxqYBkXwCgJMZXKc0hCjQKk7O7x0=.dc7fc4a6-5f70-48d6-95d1-e6f221fd00c8@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
 <KuAHZ29TsraSfrcieRHDzMYbhzh0wAimt0H0mU5zmZg=.e9db65a1-627e-4d1e-9b1d-a303deaf15cd@github.com>
 <xl524uxRBH8lKO7UxqYBkXwCgJMZXKc0hCjQKk7O7x0=.dc7fc4a6-5f70-48d6-95d1-e6f221fd00c8@github.com>
Message-ID: <jA3I2nMyPkpZpEXvM-HMJxvyF9d3EyrtUuRX_I3orBI=.c31fc6ae-e5e9-4f5c-acc7-56cdf94b8042@github.com>

On Mon, 12 Sep 2022 10:26:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Um, this is `jmod`, it does not have `--compress=...` option? `jlink` does. So, I don't quite understand this comment :)

Doh! Yes, I mixed up the two and assumed you'd be considering this for `jlink` as well. The part about being open-ended about alternate compression algorithms still applies, but since the compression for `jmod` is currently always zip we can defer such wording for if/when that day comes.

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

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

From jpai at openjdk.org  Mon Sep 12 10:51:46 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 12 Sep 2022 10:51:46 GMT
Subject: RFR: 8290367: Update default value and extend the scope of
 com.sun.jndi.ldap.object.trustSerialData system property [v2]
In-Reply-To: <IPAtsqgCk-KnjZ6saGmBMb3VHvm7DWCkT2uu_S27acI=.50ee2564-080c-4f0d-af55-35608e966179@github.com>
References: <T8JiNCNUKjV5bue6Bd8MjtatKCd9yik8cYMw2NIGTps=.02763149-a450-4e04-99b5-748d92b35714@github.com>
 <IPAtsqgCk-KnjZ6saGmBMb3VHvm7DWCkT2uu_S27acI=.50ee2564-080c-4f0d-af55-35608e966179@github.com>
Message-ID: <VNU0tb0KhttcT3L-biWhO0TXLAaaR3UQI1qpxxxlGdo=.8bb7827d-d773-4b6d-9a0e-c2ac5671cf93@github.com>

On Fri, 9 Sep 2022 16:55:44 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary of the change
>> 
>> The LDAP Naming Service Provider implementation's default settings are changed to disallow deserialization and reconstruction of Java objects from different LDAP attributes (RFC 2713). Currently, only the deserialization is controlled by the `com.sun.jndi.ldap.object.trustSerialData` system property, and it is allowed by default.
>> The change proposed here switches the default value of the` com.sun.jndi.ldap.object.trustSerialData `system property to `"false"`, and also extends its scope to cover the reconstruction of RMI remote objects from the `javaRemoteLocation` LDAP attribute.
>> 
>> CSR for this change can be viewed [here](https://bugs.openjdk.org/browse/JDK-8290369).
>> 
>> ### List of code changes
>> - Switch the default value of the 'com.sun.jndi.ldap.object.trustSerialData' system property to "false".
>> 
>> - Extend the scope of the property to also cover the reconstruction of RMI remote objects from the deprecated 'javaRemoteLocation' LDAP attribute.
>> 
>> - Document the support for `javaRemoteLocation` and the `javaReferenceAddress` LDAP attributes in `java.naming`'s module-info.
>> 
>> ### Test changes
>> - New `test/jdk/com/sun/jndi/ldap/objects/RemoteLocationAttributeTest.java` test has been added to test that `com.sun.jndi.ldap.object.trustSerialData` system property can be used to control reconstruction of RMI objects from the `javaRemoteLocation` LDAP attribute.
>> 
>> -  `test/jdk/javax/naming/module/RunBasic.java` was modified to pass `com.sun.jndi.ldap.object.trustSerialData=true` to the sub-tests that rely on reconstruction/deserialization from LDAP attributes. 
>> 
>> - During the update for `test/jdk/javax/naming/module/RunBasic.java`, it was spotted that sub-tests apps launched in separate processes were returning the '0' exit value irrelevant to their execution status. All these sub-tests were modified to throw an exception when failure is observed. It helps to ensure that the exit value of launched process is not '0' for failed sub-tests.
>> 
>> ### Testing
>> 
>> `tier1`-`tier3` and JNDI regression/JCK tests not showing any failures related to this change.
>> No failures observed for the modified regression tests.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add run for the SP w/o value, formatting/wording updates

src/java.naming/share/classes/com/sun/jndi/ldap/VersionHelper.java line 60:

> 58: 
> 59:         // System property to control whether classes is allowed to be loaded from
> 60:         // 'javaSerializedData' attribute

Hello Aleksei, should we also update this code comment to make a mention of the additional attributes this system property now controls?

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

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

From jpai at openjdk.org  Mon Sep 12 10:56:43 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 12 Sep 2022 10:56:43 GMT
Subject: RFR: 8290367: Update default value and extend the scope of
 com.sun.jndi.ldap.object.trustSerialData system property [v2]
In-Reply-To: <IPAtsqgCk-KnjZ6saGmBMb3VHvm7DWCkT2uu_S27acI=.50ee2564-080c-4f0d-af55-35608e966179@github.com>
References: <T8JiNCNUKjV5bue6Bd8MjtatKCd9yik8cYMw2NIGTps=.02763149-a450-4e04-99b5-748d92b35714@github.com>
 <IPAtsqgCk-KnjZ6saGmBMb3VHvm7DWCkT2uu_S27acI=.50ee2564-080c-4f0d-af55-35608e966179@github.com>
Message-ID: <SvdV_zgyWVAFN6O01IQVMA--4rSGMK4eop-64OAtv2o=.5d776678-f8e8-4d69-9556-9279d5e36978@github.com>

On Fri, 9 Sep 2022 16:55:44 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary of the change
>> 
>> The LDAP Naming Service Provider implementation's default settings are changed to disallow deserialization and reconstruction of Java objects from different LDAP attributes (RFC 2713). Currently, only the deserialization is controlled by the `com.sun.jndi.ldap.object.trustSerialData` system property, and it is allowed by default.
>> The change proposed here switches the default value of the` com.sun.jndi.ldap.object.trustSerialData `system property to `"false"`, and also extends its scope to cover the reconstruction of RMI remote objects from the `javaRemoteLocation` LDAP attribute.
>> 
>> CSR for this change can be viewed [here](https://bugs.openjdk.org/browse/JDK-8290369).
>> 
>> ### List of code changes
>> - Switch the default value of the 'com.sun.jndi.ldap.object.trustSerialData' system property to "false".
>> 
>> - Extend the scope of the property to also cover the reconstruction of RMI remote objects from the deprecated 'javaRemoteLocation' LDAP attribute.
>> 
>> - Document the support for `javaRemoteLocation` and the `javaReferenceAddress` LDAP attributes in `java.naming`'s module-info.
>> 
>> ### Test changes
>> - New `test/jdk/com/sun/jndi/ldap/objects/RemoteLocationAttributeTest.java` test has been added to test that `com.sun.jndi.ldap.object.trustSerialData` system property can be used to control reconstruction of RMI objects from the `javaRemoteLocation` LDAP attribute.
>> 
>> -  `test/jdk/javax/naming/module/RunBasic.java` was modified to pass `com.sun.jndi.ldap.object.trustSerialData=true` to the sub-tests that rely on reconstruction/deserialization from LDAP attributes. 
>> 
>> - During the update for `test/jdk/javax/naming/module/RunBasic.java`, it was spotted that sub-tests apps launched in separate processes were returning the '0' exit value irrelevant to their execution status. All these sub-tests were modified to throw an exception when failure is observed. It helps to ensure that the exit value of launched process is not '0' for failed sub-tests.
>> 
>> ### Testing
>> 
>> `tier1`-`tier3` and JNDI regression/JCK tests not showing any failures related to this change.
>> No failures observed for the modified regression tests.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add run for the SP w/o value, formatting/wording updates

src/java.naming/share/classes/com/sun/jndi/ldap/VersionHelper.java line 63:

> 61:         String trustSerialDataSp = getPrivilegedProperty(
> 62:                 "com.sun.jndi.ldap.object.trustSerialData", "false");
> 63:         trustSerialData = "true".equalsIgnoreCase(trustSerialDataSp);

More of a question - is there a convention in our documentation where we state that the value is case insensitive? Right now, the `module-info.java` uses the literals `false` and `true` and doesn't talk about case insensitivity. Should it?

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

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

From jpai at openjdk.org  Mon Sep 12 11:00:50 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 12 Sep 2022 11:00:50 GMT
Subject: RFR: 8293499: Provide jmod compression level option [v2]
In-Reply-To: <vsdqwfOrBiSgHwM22RoQHNyepexZYvAzyvObzwMxE3k=.5c344518-a3a2-4b98-b64d-4f2242caf397@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
 <vsdqwfOrBiSgHwM22RoQHNyepexZYvAzyvObzwMxE3k=.5c344518-a3a2-4b98-b64d-4f2242caf397@github.com>
Message-ID: <xD6-WUYYIHO0uBX7_-_VnFYfxzD4aHmVpVkeMocNdeE=.18c58acf-831a-4dd8-9610-4c7b9fcaf5cf@github.com>

On Mon, 12 Sep 2022 10:48:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I have been looking into `make clean-images images` performance, and realized jmod keeps compressing files with default compression level. Tuning that toward lighter compression levels improves build performance considerably, without a heavy loss in *.jmod sizes. 
>> 
>> This PR allows JMOD to select the compression level. Follow-ups would use this in the build system, see #10214.
>> 
>> This change nominally requires CSR, but I would like to gauge the reaction to this patch first, before submitting a formal CSR. The interesting asymmetry against `jlink` is: `jlink` provides `--compress` option that only takes `2` for "ZIP compression". (Separately, we could argue if it would be beneficial to add `--compression-level` to `jlink` as well, so to select the compression level there too.)
>
> Aleksey Shipilev 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:
> 
>  - Only accept --compression-level when creating the archive
>  - Merge branch 'master' into JDK-8293499-jmod-compression-level
>  - Fix

src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties line 120:

> 118: err.date.out.of.range=--date {0} is out of the valid range 1980-01-01T00:00:02Z to 2099-12-31T23:59:59Z
> 119: err.compression.level.out.of.range=--compression-level {0} is out of the valid range: 0-9
> 120: err.compression.level.wrong.mode=--compression-level {0} is only accepted with create mode

Hello Aleksey, the place where this error message gets used doesn't right now pass the compression-level value to the constructor of `CommandException`. So I guess this usage of `{0}` here is unintentional?

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

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

From dfuchs at openjdk.org  Mon Sep 12 11:02:09 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 12 Sep 2022 11:02:09 GMT
Subject: RFR: 8292698: Improve performance of DataInputStream [v4]
In-Reply-To: <8Rm-eVp7g0Z5PojiU5DwSU2Cuej9zlFtDdKBkUljazo=.0a1c4182-3ade-4da4-b235-f7412bee3140@github.com>
References: <MXdBQj8qYqvvImT-MaBpf8mAm3b1tbNiPS93syrjfqg=.3ebdd952-f9d7-4ec9-9655-a63829828c67@github.com>
 <8Rm-eVp7g0Z5PojiU5DwSU2Cuej9zlFtDdKBkUljazo=.0a1c4182-3ade-4da4-b235-f7412bee3140@github.com>
Message-ID: <69nPqF3s3KbaAGxJ2xBMbeYlGMtpXorK1vMM2Y1Vyg8=.94d51482-e948-4a4c-b074-eea93ea030e9@github.com>

On Mon, 29 Aug 2022 08:46:20 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> I found out that reading from `DataInputStream` wrapping `ByteArrayInputStream` (as well as `BufferedInputStream` or any `InputStream` relying on `byte[]`) can be significantly improved by accessing volatile `in` field only once per operation.
>> 
>> Current implementation does it for each call of `in.read()`, i.e. in `readInt()` method we do it 4 times:
>> 
>> public final int readInt() throws IOException {
>>     int ch1 = in.read();
>>     int ch2 = in.read();
>>     int ch3 = in.read();
>>     int ch4 = in.read();
>>     if ((ch1 | ch2 | ch3 | ch4) < 0)
>>         throw new EOFException();
>>     return ((ch1 << 24) + (ch2 << 16) + (ch3 << 8) + (ch4 << 0));
>> }
>> 
>> Apparently accessing volatile reference with underlying `byte[]` prevents runtime from doing some optimizations, so dereferencing local variable should be more efficient.
>> 
>> Benchmarking:
>> 
>> baseline:
>> 
>> Benchmark                     Mode  Cnt   Score   Error  Units
>> DataInputStreamTest.readChar  avgt   20  22,889 ? 0,648  us/op
>> DataInputStreamTest.readInt   avgt   20  21,804 ? 0,197  us/op
>> 
>> patch:
>> 
>> Benchmark                     Mode  Cnt   Score   Error  Units
>> DataInputStreamTest.readChar  avgt   20  11,018 ? 0,089  us/op
>> DataInputStreamTest.readInt   avgt   20   5,608 ? 0,087  us/op
>
> ?????? ??????? 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:
> 
>  - 8292698: Reuse existing code
>  - Merge branch 'master' into 8292698
>  - 8292698: Fix copyright year
>  - 8292698: Revert dubious changes
>  - 8292698: Improve performance of reading from DataInputStream

This looks reasonable to me, but please get @AlanBateman's approval before integrating.

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

Marked as reviewed by dfuchs (Reviewer).

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

From jpai at openjdk.org  Mon Sep 12 11:05:00 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 12 Sep 2022 11:05:00 GMT
Subject: RFR: 8293499: Provide jmod compression level option [v2]
In-Reply-To: <vsdqwfOrBiSgHwM22RoQHNyepexZYvAzyvObzwMxE3k=.5c344518-a3a2-4b98-b64d-4f2242caf397@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
 <vsdqwfOrBiSgHwM22RoQHNyepexZYvAzyvObzwMxE3k=.5c344518-a3a2-4b98-b64d-4f2242caf397@github.com>
Message-ID: <7fbdzDxQcirUHBoITyrYBT2GhmPGY2v3Vcdsd9sUzTU=.59fde7a2-4fa4-4dee-8680-2f02f754a236@github.com>

On Mon, 12 Sep 2022 10:48:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I have been looking into `make clean-images images` performance, and realized jmod keeps compressing files with default compression level. Tuning that toward lighter compression levels improves build performance considerably, without a heavy loss in *.jmod sizes. 
>> 
>> This PR allows JMOD to select the compression level. Follow-ups would use this in the build system, see #10214.
>> 
>> This change nominally requires CSR, but I would like to gauge the reaction to this patch first, before submitting a formal CSR. The interesting asymmetry against `jlink` is: `jlink` provides `--compress` option that only takes `2` for "ZIP compression". (Separately, we could argue if it would be beneficial to add `--compression-level` to `jlink` as well, so to select the compression level there too.)
>
> Aleksey Shipilev 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:
> 
>  - Only accept --compression-level when creating the archive
>  - Merge branch 'master' into JDK-8293499-jmod-compression-level
>  - Fix

Thank you for the changes Aleksey. They look fine to me (except for that one minor error message related issue which I added a comment for). I haven't given the latest changes a try, but the new test you added to verify that the command fails in other modes when `--compression-level` will cover it.

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

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

From aefimov at openjdk.org  Mon Sep 12 11:23:52 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 12 Sep 2022 11:23:52 GMT
Subject: RFR: 8290367: Update default value and extend the scope of
 com.sun.jndi.ldap.object.trustSerialData system property [v2]
In-Reply-To: <VNU0tb0KhttcT3L-biWhO0TXLAaaR3UQI1qpxxxlGdo=.8bb7827d-d773-4b6d-9a0e-c2ac5671cf93@github.com>
References: <T8JiNCNUKjV5bue6Bd8MjtatKCd9yik8cYMw2NIGTps=.02763149-a450-4e04-99b5-748d92b35714@github.com>
 <IPAtsqgCk-KnjZ6saGmBMb3VHvm7DWCkT2uu_S27acI=.50ee2564-080c-4f0d-af55-35608e966179@github.com>
 <VNU0tb0KhttcT3L-biWhO0TXLAaaR3UQI1qpxxxlGdo=.8bb7827d-d773-4b6d-9a0e-c2ac5671cf93@github.com>
Message-ID: <_Q8r6pk7Optlc33nwyQy5r2RCjWhNiV7t-xcBYlA5XA=.fedc659f-4a68-4c1b-befc-a2e214e66fa3@github.com>

On Mon, 12 Sep 2022 10:48:01 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add run for the SP w/o value, formatting/wording updates
>
> src/java.naming/share/classes/com/sun/jndi/ldap/VersionHelper.java line 60:
> 
>> 58: 
>> 59:         // System property to control whether classes is allowed to be loaded from
>> 60:         // 'javaSerializedData' attribute
> 
> Hello Aleksei, should we also update this code comment to make a mention of the additional attributes this system property now controls?

Hi Jai,
Thanks for spotting that - will update this and other code comments in the `VersionHelper` class.

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

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

From shade at openjdk.org  Mon Sep 12 11:23:55 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 12 Sep 2022 11:23:55 GMT
Subject: RFR: 8293499: Provide jmod compression level option
In-Reply-To: <jA3I2nMyPkpZpEXvM-HMJxvyF9d3EyrtUuRX_I3orBI=.c31fc6ae-e5e9-4f5c-acc7-56cdf94b8042@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
 <KuAHZ29TsraSfrcieRHDzMYbhzh0wAimt0H0mU5zmZg=.e9db65a1-627e-4d1e-9b1d-a303deaf15cd@github.com>
 <xl524uxRBH8lKO7UxqYBkXwCgJMZXKc0hCjQKk7O7x0=.dc7fc4a6-5f70-48d6-95d1-e6f221fd00c8@github.com>
 <jA3I2nMyPkpZpEXvM-HMJxvyF9d3EyrtUuRX_I3orBI=.c31fc6ae-e5e9-4f5c-acc7-56cdf94b8042@github.com>
Message-ID: <hyIQdQe0FrVD-F8Mf4GBJBB7VS0AtjmfDPnmfINVfok=.5e5e36e5-af70-4488-a1dd-17efec5c72a6@github.com>

On Mon, 12 Sep 2022 10:48:53 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> The part about being open-ended about alternate compression algorithms still applies, but since the compression for `jmod` is currently always zip we can defer such wording for if/when that day comes.

Well, we can future-proof it by doing what e.g. ZFS does:


$ zfs set compression
...
	compression     YES      YES   on | off | lzjb | gzip | gzip-[1-9] | zle | lz4 | zstd | zstd-[1-19] | zstd-fast-[1-10,20,30,40,50,60,70,80,90,100,500,1000]
...


Meaning, we allow `--compress=zip-[0..9]` and default to `zip-6`. This has the added benefit of clearly stating that `zip-0` is still ZIP, but without the compression applied. This is a bit ambiguous with `--compression-level=0`.

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

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

From redestad at openjdk.org  Mon Sep 12 11:52:43 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 12 Sep 2022 11:52:43 GMT
Subject: RFR: 8293499: Provide jmod compression level option
In-Reply-To: <hyIQdQe0FrVD-F8Mf4GBJBB7VS0AtjmfDPnmfINVfok=.5e5e36e5-af70-4488-a1dd-17efec5c72a6@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
 <KuAHZ29TsraSfrcieRHDzMYbhzh0wAimt0H0mU5zmZg=.e9db65a1-627e-4d1e-9b1d-a303deaf15cd@github.com>
 <xl524uxRBH8lKO7UxqYBkXwCgJMZXKc0hCjQKk7O7x0=.dc7fc4a6-5f70-48d6-95d1-e6f221fd00c8@github.com>
 <jA3I2nMyPkpZpEXvM-HMJxvyF9d3EyrtUuRX_I3orBI=.c31fc6ae-e5e9-4f5c-acc7-56cdf94b8042@github.com>
 <hyIQdQe0FrVD-F8Mf4GBJBB7VS0AtjmfDPnmfINVfok=.5e5e36e5-af70-4488-a1dd-17efec5c72a6@github.com>
Message-ID: <h396zUQFP_URr-2lLId0Q-is28839c7uQ8FjMQJgBx0=.c1b277dd-b696-48cb-9a61-8e2ea3fd041a@github.com>

On Mon, 12 Sep 2022 11:20:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Meaning, we allow `--compress=zip-[0..9]` and default to `zip-6`. This has the added benefit of clearly stating that `zip-0` is still ZIP, but without the compression applied. This is a bit ambiguous with `--compression-level=0`.

I like this scheme. It's a good thing there's prior art, too.

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

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

From jpai at openjdk.org  Mon Sep 12 12:09:47 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 12 Sep 2022 12:09:47 GMT
Subject: RFR: 8290367: Update default value and extend the scope of
 com.sun.jndi.ldap.object.trustSerialData system property [v2]
In-Reply-To: <IPAtsqgCk-KnjZ6saGmBMb3VHvm7DWCkT2uu_S27acI=.50ee2564-080c-4f0d-af55-35608e966179@github.com>
References: <T8JiNCNUKjV5bue6Bd8MjtatKCd9yik8cYMw2NIGTps=.02763149-a450-4e04-99b5-748d92b35714@github.com>
 <IPAtsqgCk-KnjZ6saGmBMb3VHvm7DWCkT2uu_S27acI=.50ee2564-080c-4f0d-af55-35608e966179@github.com>
Message-ID: <MTXIDbf4pT5NCuuN5E71Xl5gkpxZlYUj9SlxA7hdF0Q=.2a4e8f0b-1a22-4a8f-8b1f-e3ceca1ee3c2@github.com>

On Fri, 9 Sep 2022 16:55:44 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary of the change
>> 
>> The LDAP Naming Service Provider implementation's default settings are changed to disallow deserialization and reconstruction of Java objects from different LDAP attributes (RFC 2713). Currently, only the deserialization is controlled by the `com.sun.jndi.ldap.object.trustSerialData` system property, and it is allowed by default.
>> The change proposed here switches the default value of the` com.sun.jndi.ldap.object.trustSerialData `system property to `"false"`, and also extends its scope to cover the reconstruction of RMI remote objects from the `javaRemoteLocation` LDAP attribute.
>> 
>> CSR for this change can be viewed [here](https://bugs.openjdk.org/browse/JDK-8290369).
>> 
>> ### List of code changes
>> - Switch the default value of the 'com.sun.jndi.ldap.object.trustSerialData' system property to "false".
>> 
>> - Extend the scope of the property to also cover the reconstruction of RMI remote objects from the deprecated 'javaRemoteLocation' LDAP attribute.
>> 
>> - Document the support for `javaRemoteLocation` and the `javaReferenceAddress` LDAP attributes in `java.naming`'s module-info.
>> 
>> ### Test changes
>> - New `test/jdk/com/sun/jndi/ldap/objects/RemoteLocationAttributeTest.java` test has been added to test that `com.sun.jndi.ldap.object.trustSerialData` system property can be used to control reconstruction of RMI objects from the `javaRemoteLocation` LDAP attribute.
>> 
>> -  `test/jdk/javax/naming/module/RunBasic.java` was modified to pass `com.sun.jndi.ldap.object.trustSerialData=true` to the sub-tests that rely on reconstruction/deserialization from LDAP attributes. 
>> 
>> - During the update for `test/jdk/javax/naming/module/RunBasic.java`, it was spotted that sub-tests apps launched in separate processes were returning the '0' exit value irrelevant to their execution status. All these sub-tests were modified to throw an exception when failure is observed. It helps to ensure that the exit value of launched process is not '0' for failed sub-tests.
>> 
>> ### Testing
>> 
>> `tier1`-`tier3` and JNDI regression/JCK tests not showing any failures related to this change.
>> No failures observed for the modified regression tests.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add run for the SP w/o value, formatting/wording updates

test/jdk/com/sun/jndi/ldap/objects/RemoteLocationAttributeTest.java line 64:

> 62:         SocketAddress sockAddr = new InetSocketAddress(
> 63:                 InetAddress.getLoopbackAddress(), 0);
> 64:         serverSocket.bind(sockAddr);

Perhaps we should `close()` this `serverSocket` in a finally block to cleanly shutdown?

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

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

From aefimov at openjdk.org  Mon Sep 12 12:31:43 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 12 Sep 2022 12:31:43 GMT
Subject: RFR: 8290367: Update default value and extend the scope of
 com.sun.jndi.ldap.object.trustSerialData system property [v2]
In-Reply-To: <MTXIDbf4pT5NCuuN5E71Xl5gkpxZlYUj9SlxA7hdF0Q=.2a4e8f0b-1a22-4a8f-8b1f-e3ceca1ee3c2@github.com>
References: <T8JiNCNUKjV5bue6Bd8MjtatKCd9yik8cYMw2NIGTps=.02763149-a450-4e04-99b5-748d92b35714@github.com>
 <IPAtsqgCk-KnjZ6saGmBMb3VHvm7DWCkT2uu_S27acI=.50ee2564-080c-4f0d-af55-35608e966179@github.com>
 <MTXIDbf4pT5NCuuN5E71Xl5gkpxZlYUj9SlxA7hdF0Q=.2a4e8f0b-1a22-4a8f-8b1f-e3ceca1ee3c2@github.com>
Message-ID: <lypzPb1DF84TRlLbeJ31E-JMzj9pF7bnNvMAnAS3w7E=.c89f6c61-e6b4-445d-b06b-8f4940c9bedb@github.com>

On Mon, 12 Sep 2022 12:06:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add run for the SP w/o value, formatting/wording updates
>
> test/jdk/com/sun/jndi/ldap/objects/RemoteLocationAttributeTest.java line 64:
> 
>> 62:         SocketAddress sockAddr = new InetSocketAddress(
>> 63:                 InetAddress.getLoopbackAddress(), 0);
>> 64:         serverSocket.bind(sockAddr);
> 
> Perhaps we should `close()` this `serverSocket` in a finally block to cleanly shutdown?

Good idea, thanks. Will add it to try-with-resources statement, like:
`try (serverSocket) {
`

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

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

From aefimov at openjdk.org  Mon Sep 12 12:41:42 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 12 Sep 2022 12:41:42 GMT
Subject: RFR: 8290367: Update default value and extend the scope of
 com.sun.jndi.ldap.object.trustSerialData system property [v2]
In-Reply-To: <SvdV_zgyWVAFN6O01IQVMA--4rSGMK4eop-64OAtv2o=.5d776678-f8e8-4d69-9556-9279d5e36978@github.com>
References: <T8JiNCNUKjV5bue6Bd8MjtatKCd9yik8cYMw2NIGTps=.02763149-a450-4e04-99b5-748d92b35714@github.com>
 <IPAtsqgCk-KnjZ6saGmBMb3VHvm7DWCkT2uu_S27acI=.50ee2564-080c-4f0d-af55-35608e966179@github.com>
 <SvdV_zgyWVAFN6O01IQVMA--4rSGMK4eop-64OAtv2o=.5d776678-f8e8-4d69-9556-9279d5e36978@github.com>
Message-ID: <shEr58HMqp4GgPRnKgZBz9IEfNMMB9bdBOtiBxt9OyA=.2697064f-ead9-4f69-8a49-b6aea308c180@github.com>

On Mon, 12 Sep 2022 10:53:10 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> is there a convention in our documentation where we state that the value is case insensitive?

I think there isn't. Therefore, it will be cleaner to update the property description in `module-info.java` to something like: `"the system property value can be set to {@code true} (case insensitive)"`

And to update the test to check the `case insensitive` clause:


* @run main/othervm -Dcom.sun.jndi.ldap.object.trustSerialData=TrUe
*                   RemoteLocationAttributeTest


Thanks

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

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

From jpai at openjdk.org  Mon Sep 12 13:00:43 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 12 Sep 2022 13:00:43 GMT
Subject: RFR: 8293282: LoadLibraryUnloadTest.java fails with
 "Too few cleared WeakReferences" [v3]
In-Reply-To: <jDgkLmJEqnxMDhGUCVAt3f7ssqnOhJnyPUWhXV7xYnY=.0c8a1bfa-9b85-4813-bff6-f4c21fdfd154@github.com>
References: <O7RYAAkE9CHAAzWdTLQBCaaEns3vK6c896tmx8Ul0rM=.bccf6768-e5b1-4bd3-85f7-4dfd27277bfb@github.com>
 <jDgkLmJEqnxMDhGUCVAt3f7ssqnOhJnyPUWhXV7xYnY=.0c8a1bfa-9b85-4813-bff6-f4c21fdfd154@github.com>
Message-ID: <y1ViUfSzn6gJdD10cTDLhKzT3P0RlFTYFeCnYyEM3UE=.fd55f425-4194-4486-aca5-28ebf7facdc0@github.com>

On Fri, 9 Sep 2022 15:48:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Modify the LoadLibraryUnload test to call gc() more a few times, allowing multiple gc cycles to queue the expected refs.
>> Short the timeout on each cycle to 10 sec.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused ReferenceQueue for canary WeakReferences.

Thank you for the explanation and the changes, Roger.

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

Marked as reviewed by jpai (Reviewer).

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

From rriggs at openjdk.org  Mon Sep 12 13:28:52 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 12 Sep 2022 13:28:52 GMT
Subject: Integrated: 8293282: LoadLibraryUnloadTest.java fails with
 "Too few cleared WeakReferences"
In-Reply-To: <O7RYAAkE9CHAAzWdTLQBCaaEns3vK6c896tmx8Ul0rM=.bccf6768-e5b1-4bd3-85f7-4dfd27277bfb@github.com>
References: <O7RYAAkE9CHAAzWdTLQBCaaEns3vK6c896tmx8Ul0rM=.bccf6768-e5b1-4bd3-85f7-4dfd27277bfb@github.com>
Message-ID: <i_l_JhldtZjctYAmzWREfzozkQZMou8DXix6xqG0dQQ=.70b61f5c-a08a-4cde-9770-45f287574fe1@github.com>

On Thu, 8 Sep 2022 20:26:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Modify the LoadLibraryUnload test to call gc() more a few times, allowing multiple gc cycles to queue the expected refs.
> Short the timeout on each cycle to 10 sec.

This pull request has now been integrated.

Changeset: 0c61bf10
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0c61bf109f162621490df423c33f1bbc2c1524a0
Stats:     21 lines in 2 files changed: 5 ins; 3 del; 13 mod

8293282: LoadLibraryUnloadTest.java fails with "Too few cleared WeakReferences"

Reviewed-by: mchung, jpai

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

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

From duke at openjdk.org  Mon Sep 12 13:35:49 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 12 Sep 2022 13:35:49 GMT
Subject: Integrated: 8287908: Use non-cloning reflection methods where
 acceptable
In-Reply-To: <BIw7M4O4Qvjd04_wmQBV9uENDGS_sd1uGZPt1cGgOqs=.9d5de4e3-a50c-4b17-8c43-314f76eceed4@github.com>
References: <BIw7M4O4Qvjd04_wmQBV9uENDGS_sd1uGZPt1cGgOqs=.9d5de4e3-a50c-4b17-8c43-314f76eceed4@github.com>
Message-ID: <6xk7mB2AT-h4SJbGPag7acJT_Wt20y_eQ1aOsc6z-6k=.53ee367b-922f-481e-9eed-5a78fbc28f23@github.com>

On Tue, 7 Jun 2022 13:45:06 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> Instead of `Executable.getParameterTypes()` we could use `Executable.getSharedParameterTypes()` in trusted code. Same is applicable for `Executable.getExceptionTypes()`.

This pull request has now been integrated.

Changeset: 9ef6c092
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9ef6c0925ae5a0ca774b23f6318551417a53e6c6
Stats:     9 lines in 4 files changed: 0 ins; 0 del; 9 mod

8287908: Use non-cloning reflection methods where acceptable

Reviewed-by: rriggs

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

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

From aefimov at openjdk.org  Mon Sep 12 14:29:56 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 12 Sep 2022 14:29:56 GMT
Subject: RFR: 8290367: Update default value and extend the scope of
 com.sun.jndi.ldap.object.trustSerialData system property [v3]
In-Reply-To: <T8JiNCNUKjV5bue6Bd8MjtatKCd9yik8cYMw2NIGTps=.02763149-a450-4e04-99b5-748d92b35714@github.com>
References: <T8JiNCNUKjV5bue6Bd8MjtatKCd9yik8cYMw2NIGTps=.02763149-a450-4e04-99b5-748d92b35714@github.com>
Message-ID: <VVAGqPtP0lnuo6DOgtsmnWE55ZD7jEfHa5j4CfxGy68=.4a81b5f1-af2f-4f87-8725-60a507ee0600@github.com>

> ### Summary of the change
> 
> The LDAP Naming Service Provider implementation's default settings are changed to disallow deserialization and reconstruction of Java objects from different LDAP attributes (RFC 2713). Currently, only the deserialization is controlled by the `com.sun.jndi.ldap.object.trustSerialData` system property, and it is allowed by default.
> The change proposed here switches the default value of the` com.sun.jndi.ldap.object.trustSerialData `system property to `"false"`, and also extends its scope to cover the reconstruction of RMI remote objects from the `javaRemoteLocation` LDAP attribute.
> 
> CSR for this change can be viewed [here](https://bugs.openjdk.org/browse/JDK-8290369).
> 
> ### List of code changes
> - Switch the default value of the 'com.sun.jndi.ldap.object.trustSerialData' system property to "false".
> 
> - Extend the scope of the property to also cover the reconstruction of RMI remote objects from the deprecated 'javaRemoteLocation' LDAP attribute.
> 
> - Document the support for `javaRemoteLocation` and the `javaReferenceAddress` LDAP attributes in `java.naming`'s module-info.
> 
> ### Test changes
> - New `test/jdk/com/sun/jndi/ldap/objects/RemoteLocationAttributeTest.java` test has been added to test that `com.sun.jndi.ldap.object.trustSerialData` system property can be used to control reconstruction of RMI objects from the `javaRemoteLocation` LDAP attribute.
> 
> -  `test/jdk/javax/naming/module/RunBasic.java` was modified to pass `com.sun.jndi.ldap.object.trustSerialData=true` to the sub-tests that rely on reconstruction/deserialization from LDAP attributes. 
> 
> - During the update for `test/jdk/javax/naming/module/RunBasic.java`, it was spotted that sub-tests apps launched in separate processes were returning the '0' exit value irrelevant to their execution status. All these sub-tests were modified to throw an exception when failure is observed. It helps to ensure that the exit value of launched process is not '0' for failed sub-tests.
> 
> ### Testing
> 
> `tier1`-`tier3` and JNDI regression/JCK tests not showing any failures related to this change.
> No failures observed for the modified regression tests.

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

  Update src comments/update module-info (case insensitive)/close test socket

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10228/files
  - new: https://git.openjdk.org/jdk/pull/10228/files/faec04e6..7f16da07

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

  Stats: 12 lines in 3 files changed: 3 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/10228.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10228/head:pull/10228

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

From mr at openjdk.org  Mon Sep 12 15:53:48 2022
From: mr at openjdk.org (Mark Reinhold)
Date: Mon, 12 Sep 2022 15:53:48 GMT
Subject: RFR: 8293499: Provide jmod compression level option
In-Reply-To: <h396zUQFP_URr-2lLId0Q-is28839c7uQ8FjMQJgBx0=.c1b277dd-b696-48cb-9a61-8e2ea3fd041a@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
 <KuAHZ29TsraSfrcieRHDzMYbhzh0wAimt0H0mU5zmZg=.e9db65a1-627e-4d1e-9b1d-a303deaf15cd@github.com>
 <xl524uxRBH8lKO7UxqYBkXwCgJMZXKc0hCjQKk7O7x0=.dc7fc4a6-5f70-48d6-95d1-e6f221fd00c8@github.com>
 <jA3I2nMyPkpZpEXvM-HMJxvyF9d3EyrtUuRX_I3orBI=.c31fc6ae-e5e9-4f5c-acc7-56cdf94b8042@github.com>
 <hyIQdQe0FrVD-F8Mf4GBJBB7VS0AtjmfDPnmfINVfok=.5e5e36e5-af70-4488-a1dd-17efec5c72a6@github.com>
 <h396zUQFP_URr-2lLId0Q-is28839c7uQ8FjMQJgBx0=.c1b277dd-b696-48cb-9a61-8e2ea3fd041a@github.com>
Message-ID: <Qcuu_ZccHG-1fTew_a4GnfgpE_JqUmvYvl7oF7TkZl8=.ac6bfe5e-fb9b-4c3c-96cd-477201c2da17@github.com>

On Mon, 12 Sep 2022 11:48:50 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> > Meaning, we allow `--compress=zip-[0..9]` and default to `zip-6`. This has the added benefit of clearly stating that `zip-0` is still ZIP, but without the compression applied. This is a bit ambiguous with `--compression-level=0`.
> 
> I like this scheme. It's a good thing there's prior art, too.

Agreed. With this approach we can also revise `jlink --compress` to take the same arguments, keeping `[012]` for compatibility. We can also name this option `--compress` for `jmod`, rather than `--compression-level`, for consistency.

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

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

From rhalade at openjdk.org  Mon Sep 12 17:15:40 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Mon, 12 Sep 2022 17:15:40 GMT
Subject: RFR: 8289508: Improve test coverage for XPath Axes: ancestor,
 ancestor-or-self, preceding, and preceding-sibling
In-Reply-To: <A34UIWos48mBbQ9PtXW_Bdlxx7hBQK4UeqLKmHCOHu0=.f24e912b-88ed-4336-97b2-b8f69d06bd59@github.com>
References: <xn1BRpM7AtPakAYm2AdbtoddvmCNqP3wBPwjMGUPx8w=.4aaac0f2-1383-4e45-b49e-d1da3cfbdf43@github.com>
 <A34UIWos48mBbQ9PtXW_Bdlxx7hBQK4UeqLKmHCOHu0=.f24e912b-88ed-4336-97b2-b8f69d06bd59@github.com>
Message-ID: <nrcDal1Q3UUF8r9e4un08P9bsDV-kSnlQ1h-iNi28mY=.68cbc96c-46c7-4055-9f5d-4829a540113d@github.com>

On Thu, 8 Sep 2022 15:54:03 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> Created two files for testing XPath Axes: XPathAncestors.java tests the ancestor and ancestor-or-self axes, while XPathPrecedingTest.java tests the preceding and preceding-sibling axes.
>
> Please fix jcheck issues. Code has trailing whitespaces on several lines.

> @rhalade should be good for review now.

Thanks! Someone in core-libs team should do the final review and approval.

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

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

From darcy at openjdk.org  Mon Sep 12 18:21:17 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 12 Sep 2022 18:21:17 GMT
Subject: RFR: JDK-8293626: AccessFlag::locations(ClassFileFormatVersion cffv)
 does not throw NPEx when parameter is null
Message-ID: <5heYYRiOGfJKMFhyp2PU4W2xERzsMXeVRWxG1Dpy1K4=.98b3534c-d27a-4fb9-ab93-01a238db7919@github.com>

Small fixes to AccessFlag implementation.

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

Commit messages:
 - JDK-8293626: AccessFlag::locations(ClassFileFormatVersion cffv) does not throw NPEx when parameter is null

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

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

From mchung at openjdk.org  Mon Sep 12 18:31:57 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 12 Sep 2022 18:31:57 GMT
Subject: RFR: JDK-8293626: AccessFlag::locations(ClassFileFormatVersion
 cffv) does not throw NPEx when parameter is null
In-Reply-To: <5heYYRiOGfJKMFhyp2PU4W2xERzsMXeVRWxG1Dpy1K4=.98b3534c-d27a-4fb9-ab93-01a238db7919@github.com>
References: <5heYYRiOGfJKMFhyp2PU4W2xERzsMXeVRWxG1Dpy1K4=.98b3534c-d27a-4fb9-ab93-01a238db7919@github.com>
Message-ID: <tEg-N5c2ISg2ox2eazty9HiqYR8o0YSAVBVbK2dkzIM=.ca9f828e-0129-43b7-a2ad-691196d1eaff@github.com>

On Mon, 12 Sep 2022 18:14:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Small fixes to AccessFlag implementation.

LGTM

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

Marked as reviewed by mchung (Reviewer).

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

From shade at openjdk.org  Mon Sep 12 18:34:12 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 12 Sep 2022 18:34:12 GMT
Subject: RFR: 8293499: Provide jmod --compress option [v3]
In-Reply-To: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
Message-ID: <pVNrjHI89V0JEnYVqOnSqFUZLan_DF6lvpnyi7-1ASI=.a26bcfd5-5b3b-4393-bcf9-f54efdfc9895@github.com>

> I have been looking into `make clean-images images` performance, and realized jmod keeps compressing files with default compression level. Tuning that toward lighter compression levels improves build performance considerably, without a heavy loss in *.jmod sizes. 
> 
> This PR allows JMOD to select the compression level. Follow-ups would use this in the build system, see #10214.
> 
> The interesting asymmetry against `jlink` is: `jlink` provides `--compress` option that only takes `2` for "ZIP compression". (Separately, we could argue if it would be beneficial to extend `--compress` to `jlink` as well, so to select the compression level there too.)

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

  Adopt "--compress zip-[0-9]" as option format

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10213/files
  - new: https://git.openjdk.org/jdk/pull/10213/files/c44ecf01..59eec8c2

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

  Stats: 40 lines in 3 files changed: 16 ins; 0 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/10213.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10213/head:pull/10213

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

From shade at openjdk.org  Mon Sep 12 18:36:54 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 12 Sep 2022 18:36:54 GMT
Subject: RFR: 8293499: Provide jmod --compress option
In-Reply-To: <Qcuu_ZccHG-1fTew_a4GnfgpE_JqUmvYvl7oF7TkZl8=.ac6bfe5e-fb9b-4c3c-96cd-477201c2da17@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
 <KuAHZ29TsraSfrcieRHDzMYbhzh0wAimt0H0mU5zmZg=.e9db65a1-627e-4d1e-9b1d-a303deaf15cd@github.com>
 <xl524uxRBH8lKO7UxqYBkXwCgJMZXKc0hCjQKk7O7x0=.dc7fc4a6-5f70-48d6-95d1-e6f221fd00c8@github.com>
 <jA3I2nMyPkpZpEXvM-HMJxvyF9d3EyrtUuRX_I3orBI=.c31fc6ae-e5e9-4f5c-acc7-56cdf94b8042@github.com>
 <hyIQdQe0FrVD-F8Mf4GBJBB7VS0AtjmfDPnmfINVfok=.5e5e36e5-af70-4488-a1dd-17efec5c72a6@github.com>
 <h396zUQFP_URr-2lLId0Q-is28839c7uQ8FjMQJgBx0=.c1b277dd-b696-48cb-9a61-8e2ea3fd041a@github.com>
 <Qcuu_ZccHG-1fTew_a4GnfgpE_JqUmvYvl7oF7TkZl8=.ac6bfe5e-fb9b-4c3c-96cd-477201c2da17@github.com>
Message-ID: <O-om0n3nRM2UkQnxRfb-PM2uuKPF_iDbqCsSjFs1Gag=.e018d190-09aa-4db3-b405-12e39e5a1275@github.com>

On Mon, 12 Sep 2022 15:51:25 GMT, Mark Reinhold <mr at openjdk.org> wrote:

> Agreed. With this approach we can also revise `jlink --compress` to take the same arguments, keeping `[012]` for compatibility. We can also name this option `--compress` for `jmod`, rather than `--compression-level`, for consistency.

I updated this PR and related CSR with this new option format.

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

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

From shade at openjdk.org  Mon Sep 12 18:50:53 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 12 Sep 2022 18:50:53 GMT
Subject: RFR: 8293499: Provide jmod --compress option [v2]
In-Reply-To: <xD6-WUYYIHO0uBX7_-_VnFYfxzD4aHmVpVkeMocNdeE=.18c58acf-831a-4dd8-9610-4c7b9fcaf5cf@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
 <vsdqwfOrBiSgHwM22RoQHNyepexZYvAzyvObzwMxE3k=.5c344518-a3a2-4b98-b64d-4f2242caf397@github.com>
 <xD6-WUYYIHO0uBX7_-_VnFYfxzD4aHmVpVkeMocNdeE=.18c58acf-831a-4dd8-9610-4c7b9fcaf5cf@github.com>
Message-ID: <At8sQ4VV-BAgGFI5oJ1MFo16c82NL4gwVGn4acjaLJY=.33f64d1e-3523-4a6c-8e7a-ec863b6bc669@github.com>

On Mon, 12 Sep 2022 10:58:41 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Aleksey Shipilev 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:
>> 
>>  - Only accept --compression-level when creating the archive
>>  - Merge branch 'master' into JDK-8293499-jmod-compression-level
>>  - Fix
>
> src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties line 120:
> 
>> 118: err.date.out.of.range=--date {0} is out of the valid range 1980-01-01T00:00:02Z to 2099-12-31T23:59:59Z
>> 119: err.compression.level.out.of.range=--compression-level {0} is out of the valid range: 0-9
>> 120: err.compression.level.wrong.mode=--compression-level {0} is only accepted with create mode
> 
> Hello Aleksey, the place where this error message gets used doesn't right now pass the compression-level value to the constructor of `CommandException`. So I guess this usage of `{0}` here is unintentional?

Yes, this should be fixed in new commits.

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

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

From mchung at openjdk.org  Mon Sep 12 19:00:57 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 12 Sep 2022 19:00:57 GMT
Subject: RFR: 8293499: Provide jmod --compress option [v3]
In-Reply-To: <pVNrjHI89V0JEnYVqOnSqFUZLan_DF6lvpnyi7-1ASI=.a26bcfd5-5b3b-4393-bcf9-f54efdfc9895@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
 <pVNrjHI89V0JEnYVqOnSqFUZLan_DF6lvpnyi7-1ASI=.a26bcfd5-5b3b-4393-bcf9-f54efdfc9895@github.com>
Message-ID: <AbVWidDWi_rJePOSoBuyy-Gw84LJAUPZPd5-S7HuciQ=.32b5c714-a1c5-4056-aa74-25ecdd08ff8d@github.com>

On Mon, 12 Sep 2022 18:34:12 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I have been looking into `make clean-images images` performance, and realized jmod keeps compressing files with default compression level. Tuning that toward lighter compression levels improves build performance considerably, without a heavy loss in *.jmod sizes. 
>> 
>> This PR allows JMOD to select the compression level. Follow-ups would use this in the build system, see #10214.
>> 
>> The interesting asymmetry against `jlink` is: `jlink` provides `--compress` option that only takes `2` for "ZIP compression". (Separately, we could argue if it would be beneficial to extend `--compress` to `jlink` as well, so to select the compression level there too.)
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adopt "--compress zip-[0-9]" as option format

I also like the new `--compress` option taking  `zip-0, zip-1,... zip-9` values.

src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java line 58:

> 56:      * returning the output stream to write to the JMOD file.
> 57:      */
> 58:     static JmodOutputStream newOutputStream(Path file, LocalDateTime date, int compLevel) throws IOException {

Suggest to name this parameter  `compressLevel` to make it clear.

src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java line 171:

> 169:         Path extractDir;
> 170:         LocalDateTime date;
> 171:         int compLevel;

s/compLevel/compressLevel/

src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java line 1191:

> 1189:             if (idx != lastIdx) {
> 1190:                 throw new CommandException("err.compress.incorrect", value);
> 1191:             }

what about checking `value.substring(0, idx)` is "zip"?

test/jdk/tools/jmod/JmodTest.java line 807:

> 805:         jmod("create",
> 806:              "--class-path", cp,
> 807:              "--compress", "test",

good to have a test case verifying "test-0" value.

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

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

From mik3hall at gmail.com  Tue Sep 13 00:14:58 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 12 Sep 2022 19:14:58 -0500
Subject: [External] : Re: jpackage OS/X --app-image signing
In-Reply-To: <A0B5CB1E-F55E-4E7B-8125-D4D0C8691F84@oracle.com>
References: <1A3AD609-41FA-4FC4-B95D-19F3F0FED372@gmail.com>
 <505138E4-48B6-4F14-905A-9FEA2F7881EA@oracle.com>
 <3A133DBA-AA83-4824-89AA-DD0C406D86D7@gmail.com>
 <6CBB029A-D807-4E06-B073-2D536C4D25CB@gmail.com>
 <D34E9956-5770-461D-B64A-26BDEECDD4DA@gmail.com>
 <A0B5CB1E-F55E-4E7B-8125-D4D0C8691F84@oracle.com>
Message-ID: <8F460E9F-6864-42BF-A69A-3B87C600CCFC@gmail.com>



> On Sep 7, 2022, at 1:50 PM, Alexander Matveev <alexander.matveev at oracle.com> wrote:
> 
> Hi Michael,
> 
> I file following issue for this:
> https://bugs.openjdk.org/browse/JDK-8293462 <https://bugs.openjdk.org/browse/JDK-8293462>
> 
> Yes, you right it is related to JDK-8289030. I put suggested workaround to https://bugs.openjdk.org/browse/JDK-8293462 <https://bugs.openjdk.org/browse/JDK-8293462> in comment section.
> 
> There are two possible workarounds:
> 1) Generate signed application image initially, then post process it and sign again.
> 2) Generate unsigned application image and change value of <signed> from false to true in "APPNAME.app/Contents/app/.jpackage.xml" and then do post processing and sign it again.
> 
> There is a bug in "jpackage --type app-image --app-image APPNAME.app --mac-sign? command which signs app image correctly, but never changes value in ?.jpackage.xml? to mark image as signed. Thus we will treat such images as unsigned even if they signed and as result we adding ?.package? file when generating DMG or PKG from such images.
> 
> Thanks,
> Alexander
> 

Alexander,

Thanks for the reply. I hadn?t seen this.
I have no immediate need for a work around. I will try to track the issue and wait on the fix before doing anything related.
I saw you had filed a new one. I was just going to find that again when I saw this.
Including the path to the .jpackage.xml file might be an idea if you are going to reference it in an error message. I hadn?t noticed mention of it before.

Thanks,
Mike

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

From joehw at openjdk.org  Tue Sep 13 05:26:48 2022
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 13 Sep 2022 05:26:48 GMT
Subject: RFR: 8289508: Improve test coverage for XPath Axes: ancestor,
 ancestor-or-self, preceding, and preceding-sibling
In-Reply-To: <xn1BRpM7AtPakAYm2AdbtoddvmCNqP3wBPwjMGUPx8w=.4aaac0f2-1383-4e45-b49e-d1da3cfbdf43@github.com>
References: <xn1BRpM7AtPakAYm2AdbtoddvmCNqP3wBPwjMGUPx8w=.4aaac0f2-1383-4e45-b49e-d1da3cfbdf43@github.com>
Message-ID: <c-9Cw8545qISG2K8aloCbyaE1N-WOpL-XO5DBsXMcUQ=.cb4420cc-1d4f-43cb-9be9-fdbbd32927c8@github.com>

On Thu, 8 Sep 2022 06:19:10 GMT, Rahul Prabhu <duke at openjdk.org> wrote:

> Created two files for testing XPath Axes: XPathAncestors.java tests the ancestor and ancestor-or-self axes, while XPathPrecedingTest.java tests the preceding and preceding-sibling axes.

It would be nice to cover some of the assertions made in the spec, e.g.:
2.2 Axes
      ... if the context node is an attribute node or namespace node, the preceding-sibling axis is empty
      
3.3 Node-sets
            ...
            NOTE: The meaning of a Predicate depends crucially on which axis applies. 
            For example, preceding::foo[1] returns the first foo element in reverse document order, because the axis that applies to the [1] predicate is the preceding axis; by contrast, (preceding::foo)[1] returns the first foo element in document order, because the axis that applies to the [1] predicate is the child axis.
            
5.7 Text Nodes
      ... a text node never has an immediately following or preceding sibling that is a text node

test/jaxp/javax/xml/jaxp/unittest/xpath/XPathAncestorsTest.java line 79:

> 77: 
> 78:     /*
> 79:      * DataProvider:provides XPath expression using ancestor/ancestor-or-self and the expected node(s) from the expression

We still like to limit to about 80 characters (slightly longer is ok), easier for people who like the Sdiffs.

test/jaxp/javax/xml/jaxp/unittest/xpath/XPathPrecedingTest.java line 90:

> 88: 
> 89:                 // abbreviated text
> 90:                 {"//author/preceding::title", "//title"},

Note that both expressions return nodeset while the test calls for the 1st node. When performing node comparison, it would be good to select unique node.

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

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

From shade at openjdk.org  Tue Sep 13 07:42:33 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 13 Sep 2022 07:42:33 GMT
Subject: RFR: 8293499: Provide jmod --compress option [v4]
In-Reply-To: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
Message-ID: <d8H489ORu-8V4SuB1GnjL_dQGRYpqp_wJTjY8QqNW7M=.2e9bd46c-4108-427e-aeb1-d41f7beca807@github.com>

> I have been looking into `make clean-images images` performance, and realized jmod keeps compressing files with default compression level. Tuning that toward lighter compression levels improves build performance considerably, without a heavy loss in *.jmod sizes. 
> 
> This PR allows JMOD to select the compression level. Follow-ups would use this in the build system, see #10214.
> 
> The interesting asymmetry against `jlink` is: `jlink` provides `--compress` option that only takes `2` for "ZIP compression". (Separately, we could argue if it would be beneficial to extend `--compress` to `jlink` as well, so to select the compression level there too.)

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

  More review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10213/files
  - new: https://git.openjdk.org/jdk/pull/10213/files/59eec8c2..44b64021

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

  Stats: 22 lines in 3 files changed: 14 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/10213.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10213/head:pull/10213

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

From shade at openjdk.org  Tue Sep 13 07:42:39 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 13 Sep 2022 07:42:39 GMT
Subject: RFR: 8293499: Provide jmod --compress option [v3]
In-Reply-To: <AbVWidDWi_rJePOSoBuyy-Gw84LJAUPZPd5-S7HuciQ=.32b5c714-a1c5-4056-aa74-25ecdd08ff8d@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
 <pVNrjHI89V0JEnYVqOnSqFUZLan_DF6lvpnyi7-1ASI=.a26bcfd5-5b3b-4393-bcf9-f54efdfc9895@github.com>
 <AbVWidDWi_rJePOSoBuyy-Gw84LJAUPZPd5-S7HuciQ=.32b5c714-a1c5-4056-aa74-25ecdd08ff8d@github.com>
Message-ID: <h-QDuSeysGL1ehYyqTKi--mQLlewGeyH2dQ5zC8xDc4=.6d87d55d-2aee-413b-99c5-52095d865ef8@github.com>

On Mon, 12 Sep 2022 18:51:28 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adopt "--compress zip-[0-9]" as option format
>
> src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java line 58:
> 
>> 56:      * returning the output stream to write to the JMOD file.
>> 57:      */
>> 58:     static JmodOutputStream newOutputStream(Path file, LocalDateTime date, int compLevel) throws IOException {
> 
> Suggest to name this parameter  `compressLevel` to make it clear.

Sure, renamed.

> src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java line 171:
> 
>> 169:         Path extractDir;
>> 170:         LocalDateTime date;
>> 171:         int compLevel;
> 
> s/compLevel/compressLevel/

Renamed.

> src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java line 1191:
> 
>> 1189:             if (idx != lastIdx) {
>> 1190:                 throw new CommandException("err.compress.incorrect", value);
>> 1191:             }
> 
> what about checking `value.substring(0, idx)` is "zip"?

Right, missed that! Fixed in new commit.

> test/jdk/tools/jmod/JmodTest.java line 807:
> 
>> 805:         jmod("create",
>> 806:              "--class-path", cp,
>> 807:              "--compress", "test",
> 
> good to have a test case verifying "test-0" value.

Yes, added.

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

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

From jpai at openjdk.org  Tue Sep 13 08:09:47 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 13 Sep 2022 08:09:47 GMT
Subject: RFR: 8290367: Update default value and extend the scope of
 com.sun.jndi.ldap.object.trustSerialData system property [v3]
In-Reply-To: <VVAGqPtP0lnuo6DOgtsmnWE55ZD7jEfHa5j4CfxGy68=.4a81b5f1-af2f-4f87-8725-60a507ee0600@github.com>
References: <T8JiNCNUKjV5bue6Bd8MjtatKCd9yik8cYMw2NIGTps=.02763149-a450-4e04-99b5-748d92b35714@github.com>
 <VVAGqPtP0lnuo6DOgtsmnWE55ZD7jEfHa5j4CfxGy68=.4a81b5f1-af2f-4f87-8725-60a507ee0600@github.com>
Message-ID: <cVTOEfw9H22UlbOL0D4jwKzMDPLoKEAqwL7Uh7tFGlU=.10d2cc36-ef1d-4ff4-b6ea-a8708f6c9d61@github.com>

On Mon, 12 Sep 2022 14:29:56 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary of the change
>> 
>> The LDAP Naming Service Provider implementation's default settings are changed to disallow deserialization and reconstruction of Java objects from different LDAP attributes (RFC 2713). Currently, only the deserialization is controlled by the `com.sun.jndi.ldap.object.trustSerialData` system property, and it is allowed by default.
>> The change proposed here switches the default value of the` com.sun.jndi.ldap.object.trustSerialData `system property to `"false"`, and also extends its scope to cover the reconstruction of RMI remote objects from the `javaRemoteLocation` LDAP attribute.
>> 
>> CSR for this change can be viewed [here](https://bugs.openjdk.org/browse/JDK-8290369).
>> 
>> ### List of code changes
>> - Switch the default value of the 'com.sun.jndi.ldap.object.trustSerialData' system property to "false".
>> 
>> - Extend the scope of the property to also cover the reconstruction of RMI remote objects from the deprecated 'javaRemoteLocation' LDAP attribute.
>> 
>> - Document the support for `javaRemoteLocation` and the `javaReferenceAddress` LDAP attributes in `java.naming`'s module-info.
>> 
>> ### Test changes
>> - New `test/jdk/com/sun/jndi/ldap/objects/RemoteLocationAttributeTest.java` test has been added to test that `com.sun.jndi.ldap.object.trustSerialData` system property can be used to control reconstruction of RMI objects from the `javaRemoteLocation` LDAP attribute.
>> 
>> -  `test/jdk/javax/naming/module/RunBasic.java` was modified to pass `com.sun.jndi.ldap.object.trustSerialData=true` to the sub-tests that rely on reconstruction/deserialization from LDAP attributes. 
>> 
>> - During the update for `test/jdk/javax/naming/module/RunBasic.java`, it was spotted that sub-tests apps launched in separate processes were returning the '0' exit value irrelevant to their execution status. All these sub-tests were modified to throw an exception when failure is observed. It helps to ensure that the exit value of launched process is not '0' for failed sub-tests.
>> 
>> ### Testing
>> 
>> `tier1`-`tier3` and JNDI regression/JCK tests not showing any failures related to this change.
>> No failures observed for the modified regression tests.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src comments/update module-info (case insensitive)/close test socket

Thank you for the changes, Aleksei. They look fine to me.

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

Marked as reviewed by jpai (Reviewer).

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

From jpai at openjdk.org  Tue Sep 13 08:14:01 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 13 Sep 2022 08:14:01 GMT
Subject: RFR: 8293499: Provide jmod --compress option [v4]
In-Reply-To: <d8H489ORu-8V4SuB1GnjL_dQGRYpqp_wJTjY8QqNW7M=.2e9bd46c-4108-427e-aeb1-d41f7beca807@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
 <d8H489ORu-8V4SuB1GnjL_dQGRYpqp_wJTjY8QqNW7M=.2e9bd46c-4108-427e-aeb1-d41f7beca807@github.com>
Message-ID: <sYCy-VrntBAFB-J3b3JwrYW34W9uV8pwqiBFtSvL1B4=.b8997035-f6ab-478c-9857-a18619b95d79@github.com>

On Tue, 13 Sep 2022 07:42:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I have been looking into `make clean-images images` performance, and realized jmod keeps compressing files with default compression level. Tuning that toward lighter compression levels improves build performance considerably, without a heavy loss in *.jmod sizes. 
>> 
>> This PR allows JMOD to select the compression level. Follow-ups would use this in the build system, see #10214.
>> 
>> The interesting asymmetry against `jlink` is: `jlink` provides `--compress` option that only takes `2` for "ZIP compression". (Separately, we could argue if it would be beneficial to extend `--compress` to `jlink` as well, so to select the compression level there too.)
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More review comments

src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java line 66:

> 64:     private final ZipOutputStream zos;
> 65:     private final LocalDateTime date;
> 66:     private JmodOutputStream(OutputStream out, LocalDateTime date, int compLevel) {

Nit - I think this should be `compressLevel` just like the param name to the static method.

src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java line 1196:

> 1194:             }
> 1195:             try {
> 1196:                 int level = Integer.parseInt(value.substring(idx + 1));

If I'm reading this code correctly, then this call to `substring` can potentially end in a `IndexOutOfBoundsException` if the value is `zip-`. Perhaps add a check above to verify that `idx != value.length()`?

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

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

From shade at openjdk.org  Tue Sep 13 09:31:49 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 13 Sep 2022 09:31:49 GMT
Subject: RFR: 8293499: Provide jmod --compress option [v5]
In-Reply-To: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
Message-ID: <qzRBM-V4f6cLNymJm6tOP6CdI4R-XQcoYVIikzEB4QQ=.09380090-bf57-4539-ae1f-e01e32784f73@github.com>

> I have been looking into `make clean-images images` performance, and realized jmod keeps compressing files with default compression level. Tuning that toward lighter compression levels improves build performance considerably, without a heavy loss in *.jmod sizes. 
> 
> This PR allows JMOD to select the compression level. Follow-ups would use this in the build system, see #10214.
> 
> The interesting asymmetry against `jlink` is: `jlink` provides `--compress` option that only takes `2` for "ZIP compression". (Separately, we could argue if it would be beneficial to extend `--compress` to `jlink` as well, so to select the compression level there too.)

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

  More review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10213/files
  - new: https://git.openjdk.org/jdk/pull/10213/files/44b64021..092b0ffa

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

  Stats: 13 lines in 2 files changed: 11 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10213.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10213/head:pull/10213

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

From shade at openjdk.org  Tue Sep 13 09:31:50 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 13 Sep 2022 09:31:50 GMT
Subject: RFR: 8293499: Provide jmod --compress option [v4]
In-Reply-To: <sYCy-VrntBAFB-J3b3JwrYW34W9uV8pwqiBFtSvL1B4=.b8997035-f6ab-478c-9857-a18619b95d79@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
 <d8H489ORu-8V4SuB1GnjL_dQGRYpqp_wJTjY8QqNW7M=.2e9bd46c-4108-427e-aeb1-d41f7beca807@github.com>
 <sYCy-VrntBAFB-J3b3JwrYW34W9uV8pwqiBFtSvL1B4=.b8997035-f6ab-478c-9857-a18619b95d79@github.com>
Message-ID: <FXc-hPu7naQdFF-LMqPB17uBYlhLhYgtdP2HDovIbh0=.ec7fc33d-87db-4bee-acca-c97ca33b8379@github.com>

On Tue, 13 Sep 2022 08:10:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More review comments
>
> src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java line 66:
> 
>> 64:     private final ZipOutputStream zos;
>> 65:     private final LocalDateTime date;
>> 66:     private JmodOutputStream(OutputStream out, LocalDateTime date, int compLevel) {
> 
> Nit - I think this should be `compressLevel` just like the param name to the static method.

Right, done so.

> src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java line 1196:
> 
>> 1194:             }
>> 1195:             try {
>> 1196:                 int level = Integer.parseInt(value.substring(idx + 1));
> 
> If I'm reading this code correctly, then this call to `substring` can potentially end in a `IndexOutOfBoundsException` if the value is `zip-`. Perhaps add a check above to verify that `idx != value.length()`?

`String.substring` does the right thing when `idx == length()` -- it returns the empty string, which would fail to parse. Anyway, I added the test for "zip-" to verify this.

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

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

From jpai at openjdk.org  Tue Sep 13 09:58:33 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 13 Sep 2022 09:58:33 GMT
Subject: RFR: 8293499: Provide jmod --compress option [v5]
In-Reply-To: <qzRBM-V4f6cLNymJm6tOP6CdI4R-XQcoYVIikzEB4QQ=.09380090-bf57-4539-ae1f-e01e32784f73@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
 <qzRBM-V4f6cLNymJm6tOP6CdI4R-XQcoYVIikzEB4QQ=.09380090-bf57-4539-ae1f-e01e32784f73@github.com>
Message-ID: <MzDBtCmAnya7PJ1kw5X6vqfGNFh6UJ1QExHIfzfU2WY=.529da56b-d0cb-48f6-891b-361dcc1427c2@github.com>

On Tue, 13 Sep 2022 09:31:49 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I have been looking into `make clean-images images` performance, and realized jmod keeps compressing files with default compression level. Tuning that toward lighter compression levels improves build performance considerably, without a heavy loss in *.jmod sizes. 
>> 
>> This PR allows JMOD to select the compression level. Follow-ups would use this in the build system, see #10214.
>> 
>> The interesting asymmetry against `jlink` is: `jlink` provides `--compress` option that only takes `2` for "ZIP compression". (Separately, we could argue if it would be beneficial to extend `--compress` to `jlink` as well, so to select the compression level there too.)
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More review comments

The latest state of this PR looks fine to me.

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

Marked as reviewed by jpai (Reviewer).

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

From jpai at openjdk.org  Tue Sep 13 09:58:35 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 13 Sep 2022 09:58:35 GMT
Subject: RFR: 8293499: Provide jmod --compress option [v4]
In-Reply-To: <FXc-hPu7naQdFF-LMqPB17uBYlhLhYgtdP2HDovIbh0=.ec7fc33d-87db-4bee-acca-c97ca33b8379@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
 <d8H489ORu-8V4SuB1GnjL_dQGRYpqp_wJTjY8QqNW7M=.2e9bd46c-4108-427e-aeb1-d41f7beca807@github.com>
 <sYCy-VrntBAFB-J3b3JwrYW34W9uV8pwqiBFtSvL1B4=.b8997035-f6ab-478c-9857-a18619b95d79@github.com>
 <FXc-hPu7naQdFF-LMqPB17uBYlhLhYgtdP2HDovIbh0=.ec7fc33d-87db-4bee-acca-c97ca33b8379@github.com>
Message-ID: <iq9UhbBcOGtJFNDrUlgpdy5oEDioZ91QkKnjlZEBDXY=.181539b3-10d5-4345-8e37-b639f4592123@github.com>

On Tue, 13 Sep 2022 09:28:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java line 1196:
>> 
>>> 1194:             }
>>> 1195:             try {
>>> 1196:                 int level = Integer.parseInt(value.substring(idx + 1));
>> 
>> If I'm reading this code correctly, then this call to `substring` can potentially end in a `IndexOutOfBoundsException` if the value is `zip-`. Perhaps add a check above to verify that `idx != value.length()`?
>
> `String.substring` does the right thing when `idx == length()` -- it returns the empty string, which would fail to parse. Anyway, I added the test for "zip-" to verify this.

You are right indeed. All these days I had in my mind that the `String.subString` will throw the `IndexOutOfBoundsException` if the passed integer isn't a valid "index". I had that perception due to the javadoc which says:


The substring begins with the character at the specified index

I hadn't paid attention to the later part of that same javadoc which says, along with an example, that the returned value is an empty string if the index == length() and will only throw `IndexOutOfBoundsException` if the passed value is greater than `length()`.

So what you have here is fine, of course. Thank you for updating the test.

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

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

From duke at openjdk.org  Tue Sep 13 12:47:47 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 13 Sep 2022 12:47:47 GMT
Subject: RFR: 8292698: Improve performance of DataInputStream [v3]
In-Reply-To: <e4eIcbtpEZdZdn5KvOHjd3zrI8voMlr1aMuURWTJRN0=.7834a1a2-287a-4b3c-80bd-0918c7a04ae7@github.com>
References: <MXdBQj8qYqvvImT-MaBpf8mAm3b1tbNiPS93syrjfqg=.3ebdd952-f9d7-4ec9-9655-a63829828c67@github.com>
 <5v8lej62KNGYz6FTjQ6FyABbMfJxwLUSNCa6Z3DXZGQ=.1b35ef41-3b59-4b78-b035-6d1838eaebbd@github.com>
 <KIfIm02U3CPC53gSjSpi68Jk7BcoMgcmwHe3SDGVFSw=.0dc503c6-937b-4c7f-a05a-6ac7655f019e@github.com>
 <e4eIcbtpEZdZdn5KvOHjd3zrI8voMlr1aMuURWTJRN0=.7834a1a2-287a-4b3c-80bd-0918c7a04ae7@github.com>
Message-ID: <FNFJb_aFepTRPqmMljvqTk2om3AJaj-milgnVa_ujk8=.b0d39f60-e1c7-4f07-94e7-a29f92a142a8@github.com>

On Thu, 25 Aug 2022 09:25:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Btw, I've tried to reimplement `readInt()` in a way similar to `readLong()`:
>> 
>> public final int readInt() throws IOException {
>>     readFully(readBuffer, 0, 4);
>>     return (readBuffer[0] & 0xff) << 24
>>          + (readBuffer[1] & 0xff) << 16
>>          + (readBuffer[2] & 0xff) << 8
>>          + (readBuffer[3] & 0xff);
>> }
>> 
>> but with this change the build fails with
>> 
>> Building target 'test' in configuration 'macosx-x86_64-server-release'
>> Compiling 3158 files for java.base
>> Updating support/src.zip
>> Optimizing the exploded image
>> Error occurred during initialization of boot layer
>> java.lang.module.FindException: Error reading module: /Users/stsypanov/IdeaProjects/jdk/build/macosx-x86_64-server-release/jdk/modules/java.management.rmi
>> Caused by: java.lang.module.InvalidModuleDescriptorException: Bad magic number
>> make[3]: *** [/Users/stsypanov/IdeaProjects/jdk/build/macosx-x86_64-server-release/jdk/_optimize_image_exec.marker] Error 1
>> make[2]: *** [exploded-image-optimize] Error 2
>> 
>> ERROR: Build failed for target 'test' in configuration 'macosx-x86_64-server-release' (exit code 2) 
>> Stopping sjavac server
>> 
>> === Output from failing command(s) repeated here ===
>> * For target jdk__optimize_image_exec:
>> Error occurred during initialization of boot layer
>> java.lang.module.FindException: Error reading module: /Users/stsypanov/IdeaProjects/jdk/build/macosx-x86_64-server-release/jdk/modules/java.management.rmi
>> Caused by: java.lang.module.InvalidModuleDescriptorException: Bad magic number
>> 
>> * All command lines available in /Users/stsypanov/IdeaProjects/jdk/build/macosx-x86_64-server-release/make-support/failure-logs.
>> === End of repeated output ===
>> 
>> What is wrong with the change?
>
>> What is wrong with the change?
> 
> You'll need parentheses to make that work, changing it to use '|' would work too.

@AlanBateman what do you think?

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

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

From alanb at openjdk.org  Tue Sep 13 13:10:52 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 Sep 2022 13:10:52 GMT
Subject: RFR: 8292698: Improve performance of DataInputStream [v3]
In-Reply-To: <e4eIcbtpEZdZdn5KvOHjd3zrI8voMlr1aMuURWTJRN0=.7834a1a2-287a-4b3c-80bd-0918c7a04ae7@github.com>
References: <MXdBQj8qYqvvImT-MaBpf8mAm3b1tbNiPS93syrjfqg=.3ebdd952-f9d7-4ec9-9655-a63829828c67@github.com>
 <5v8lej62KNGYz6FTjQ6FyABbMfJxwLUSNCa6Z3DXZGQ=.1b35ef41-3b59-4b78-b035-6d1838eaebbd@github.com>
 <KIfIm02U3CPC53gSjSpi68Jk7BcoMgcmwHe3SDGVFSw=.0dc503c6-937b-4c7f-a05a-6ac7655f019e@github.com>
 <e4eIcbtpEZdZdn5KvOHjd3zrI8voMlr1aMuURWTJRN0=.7834a1a2-287a-4b3c-80bd-0918c7a04ae7@github.com>
Message-ID: <FILqy9UnL1GA-SlIVW4w8CGTZobXWIthVseAnVtyAko=.165adc5e-9c02-46fb-bd22-e60acc2b0389@github.com>

On Thu, 25 Aug 2022 09:25:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Btw, I've tried to reimplement `readInt()` in a way similar to `readLong()`:
>> 
>> public final int readInt() throws IOException {
>>     readFully(readBuffer, 0, 4);
>>     return (readBuffer[0] & 0xff) << 24
>>          + (readBuffer[1] & 0xff) << 16
>>          + (readBuffer[2] & 0xff) << 8
>>          + (readBuffer[3] & 0xff);
>> }
>> 
>> but with this change the build fails with
>> 
>> Building target 'test' in configuration 'macosx-x86_64-server-release'
>> Compiling 3158 files for java.base
>> Updating support/src.zip
>> Optimizing the exploded image
>> Error occurred during initialization of boot layer
>> java.lang.module.FindException: Error reading module: /Users/stsypanov/IdeaProjects/jdk/build/macosx-x86_64-server-release/jdk/modules/java.management.rmi
>> Caused by: java.lang.module.InvalidModuleDescriptorException: Bad magic number
>> make[3]: *** [/Users/stsypanov/IdeaProjects/jdk/build/macosx-x86_64-server-release/jdk/_optimize_image_exec.marker] Error 1
>> make[2]: *** [exploded-image-optimize] Error 2
>> 
>> ERROR: Build failed for target 'test' in configuration 'macosx-x86_64-server-release' (exit code 2) 
>> Stopping sjavac server
>> 
>> === Output from failing command(s) repeated here ===
>> * For target jdk__optimize_image_exec:
>> Error occurred during initialization of boot layer
>> java.lang.module.FindException: Error reading module: /Users/stsypanov/IdeaProjects/jdk/build/macosx-x86_64-server-release/jdk/modules/java.management.rmi
>> Caused by: java.lang.module.InvalidModuleDescriptorException: Bad magic number
>> 
>> * All command lines available in /Users/stsypanov/IdeaProjects/jdk/build/macosx-x86_64-server-release/make-support/failure-logs.
>> === End of repeated output ===
>> 
>> What is wrong with the change?
>
>> What is wrong with the change?
> 
> You'll need parentheses to make that work, changing it to use '|' would work too.

> @AlanBateman what do you think?

The latest (3ea66641) looks okay.

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

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

From alanb at openjdk.org  Tue Sep 13 13:17:34 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 Sep 2022 13:17:34 GMT
Subject: RFR: 8289610: Degrade Thread.stop
Message-ID: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>

Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.

Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.

To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.

The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.

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

Commit messages:
 - Deprecate for removal
 - Next iteration, update dates in headers
 - Merge
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/10230/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10230&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289610
  Stats: 311 lines in 23 files changed: 114 ins; 147 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/10230.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10230/head:pull/10230

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

From duke at openjdk.org  Tue Sep 13 13:17:35 2022
From: duke at openjdk.org (ExE Boss)
Date: Tue, 13 Sep 2022 13:17:35 GMT
Subject: RFR: 8289610: Degrade Thread.stop
In-Reply-To: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
Message-ID: <R3vbwdphf7LyGlOStrdg-vizkYQ6WooThta7Utu_ntE=.39121758-eff2-4992-aaad-875e1fdfcfae@github.com>

On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
> 
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
> 
> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
> 
> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.

src/java.base/share/classes/java/lang/ThreadDeath.java line 42:

> 40:  */
> 41: @Deprecated(since="20")
> 42: public class ThreadDeath extends Error {

Actually, `ThreadDeath` is?thrown?manually by?**JShell** instrumentation?code since?[JDK?8289613] ([GH?10166])[^1].

[JDK?8289613]: https://bugs.openjdk.org/browse/JDK-8289613
[GH?10166]: https://github.com/openjdk/jdk/pull/10166
[^1]: https://github.com/openjdk/jdk/blob/00befddd7ce97d324250807824469daaa9434eef/src/jdk.jshell/share/classes/jdk/jshell/execution/LocalExecutionControl.java#L104-L107

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

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

From rriggs at openjdk.org  Tue Sep 13 14:12:48 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 13 Sep 2022 14:12:48 GMT
Subject: RFR: 8289610: Degrade Thread.stop
In-Reply-To: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
Message-ID: <aJKDQu_rOWDcc8-F2LXmygH9d-QBKSd5NOEAlUVI7lQ=.6235cad5-1193-4bc6-89ff-edbf75be21db@github.com>

On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
> 
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
> 
> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
> 
> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.

core-libs parts look fine.

src/java.base/share/classes/java/lang/Thread.java line 1635:

> 1633:      *
> 1634:      * @throws  UnsupportedOperationException
> 1635:      *          always

fold with previous line.

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

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

From darcy at openjdk.org  Tue Sep 13 16:54:18 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 13 Sep 2022 16:54:18 GMT
Subject: Integrated: JDK-8293626: AccessFlag::locations(ClassFileFormatVersion
 cffv) does not throw NPEx when parameter is null
In-Reply-To: <5heYYRiOGfJKMFhyp2PU4W2xERzsMXeVRWxG1Dpy1K4=.98b3534c-d27a-4fb9-ab93-01a238db7919@github.com>
References: <5heYYRiOGfJKMFhyp2PU4W2xERzsMXeVRWxG1Dpy1K4=.98b3534c-d27a-4fb9-ab93-01a238db7919@github.com>
Message-ID: <e7VcSki2HA1zwzz-L-UZODuXSHWMyiIO6pIcUlEwHfU=.8d41c0ba-d7fa-4448-87aa-2c9c7ebe50ae@github.com>

On Mon, 12 Sep 2022 18:14:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Small fixes to AccessFlag implementation.

This pull request has now been integrated.

Changeset: 1dc5039f
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1dc5039fed9494f4d9b6c7002d28da9bc466fb10
Stats:     33 lines in 3 files changed: 30 ins; 0 del; 3 mod

8293626: AccessFlag::locations(ClassFileFormatVersion cffv) does not throw NPEx when parameter is null
8293627: AccessFlag::locations(ClassFileFormatVersion cffv) and locations() results are inconsistent

Reviewed-by: mchung

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

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

From mchung at openjdk.org  Tue Sep 13 16:56:43 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 13 Sep 2022 16:56:43 GMT
Subject: RFR: 8293499: Provide jmod --compress option [v5]
In-Reply-To: <qzRBM-V4f6cLNymJm6tOP6CdI4R-XQcoYVIikzEB4QQ=.09380090-bf57-4539-ae1f-e01e32784f73@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
 <qzRBM-V4f6cLNymJm6tOP6CdI4R-XQcoYVIikzEB4QQ=.09380090-bf57-4539-ae1f-e01e32784f73@github.com>
Message-ID: <PLxSpqwyZOckAhoIjxohreORPnySGmfzrg72d4OASfU=.bf4da65e-9d97-4aa5-9113-17af5b60b7cd@github.com>

On Tue, 13 Sep 2022 09:31:49 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I have been looking into `make clean-images images` performance, and realized jmod keeps compressing files with default compression level. Tuning that toward lighter compression levels improves build performance considerably, without a heavy loss in *.jmod sizes. 
>> 
>> This PR allows JMOD to select the compression level. Follow-ups would use this in the build system, see #10214.
>> 
>> The interesting asymmetry against `jlink` is: `jlink` provides `--compress` option that only takes `2` for "ZIP compression". (Separately, we could argue if it would be beneficial to extend `--compress` to `jlink` as well, so to select the compression level there too.)
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More review comments

Looks good.  The jmod usage should specify the default.

src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties line 87:

> 85: main.opt.compress=Compression to use when creating the JMOD archive.\
> 86: \ Accepted values are: zip-[0-9], where zip-0 provides no compression, and zip-9\
> 87: \ provides the best compression.

Should specify the default if not set.

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

Marked as reviewed by mchung (Reviewer).

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

From lancea at openjdk.org  Tue Sep 13 17:24:40 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 13 Sep 2022 17:24:40 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access
Message-ID: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>

Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.

It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2


Best,
Lance

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

Commit messages:
 - switch linkePlain to code tag
 - Addressed 3rd draft comments
 - Merge branch 'master' into JDK-8215788
 - Third draft of the class description
 - Minor update to the wording for signature entries
 - Inital draft to clarify Manifest access

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

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

From weijun at openjdk.org  Tue Sep 13 17:24:44 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 Sep 2022 17:24:44 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access
In-Reply-To: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
Message-ID: <_ZgZ3CoGb_Z-1pQTC1Q3Gvby_4JVoY3ZY_5qFxcg5v4=.b6336d35-3270-420f-a73e-03437f82b4c5@github.com>

On Fri, 26 Aug 2022 15:48:55 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
> 
> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
> 
> 
> Best,
> Lance

src/java.base/share/classes/java/util/jar/JarInputStream.java line 38:

> 36:  * It provides support for reading an optional {@linkplain JarFile#MANIFEST_NAME Manifest}
> 37:  * entry. The {@linkplain JarFile#MANIFEST_NAME Manifest} can be used to store
> 38:  * meta-information about the JAR file and its entries.

No need to linkplain twice.

src/java.base/share/classes/java/util/jar/JarInputStream.java line 62:

> 60:  *         is the second jar entry
> 61:  *      </li>
> 62:  * </ul>

I wonder if it's necessary to duplicate these lines. How about something like "If ...., then getManifest() returns the manifest and the first call to getNextEntry() returns the entry after it".

src/java.base/share/classes/java/util/jar/JarInputStream.java line 74:

> 72:  *  {@linkplain  JarEntry#getCertificates()} may be called to obtain the certificates
> 73:  *  for this entry and {@linkplain JarEntry#getCodeSigners()} may be called to obtain
> 74:  *  the verified signers.

Either say "verified" for both methods or none. Otherwise, it sounds like `getCertificates` might return unverified ones.

Also, you might want to mention:
1. If the content of an entry is modified after the file is signed, reading the entry will throw a SecurityException.
2. These two methods return null if the file is not signed or the signature is not parseable.

src/java.base/share/classes/java/util/jar/JarInputStream.java line 75:

> 73:  *      </li>
> 74:  *      <li>
> 75:  *         All signature entries must immediately follow the {@code manifest}

We normally say "signature-related entries", which contains both the signature files (.SF) and the signature block files (.DSA/.RSA/.EC) files.

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

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

From lancea at openjdk.org  Tue Sep 13 17:24:45 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 13 Sep 2022 17:24:45 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access
In-Reply-To: <_ZgZ3CoGb_Z-1pQTC1Q3Gvby_4JVoY3ZY_5qFxcg5v4=.b6336d35-3270-420f-a73e-03437f82b4c5@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <_ZgZ3CoGb_Z-1pQTC1Q3Gvby_4JVoY3ZY_5qFxcg5v4=.b6336d35-3270-420f-a73e-03437f82b4c5@github.com>
Message-ID: <-1cQYcaU0Kz7Weg1X6ZQfAjm6n4a_qt7B6-cqPLrkZM=.70ded8f3-2d39-4ccc-812a-07596f463466@github.com>

On Tue, 30 Aug 2022 21:47:03 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
>> 
>> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
>> 
>> 
>> Best,
>> Lance
>
> src/java.base/share/classes/java/util/jar/JarInputStream.java line 62:
> 
>> 60:  *         is the second jar entry
>> 61:  *      </li>
>> 62:  * </ul>
> 
> I wonder if it's necessary to duplicate these lines. How about something like "If ...., then getManifest() returns the manifest and the first call to getNextEntry() returns the entry after it".

The challenge I had with the wording is due to the fact that if "META-INF/" is the first entry in the Zip file, it will not be returned regardless of whether there is a manifest.  So open to suggestions.

> Either say "verified" for both methods or none. Otherwise, it sounds like `getCertificates` might return unverified ones.
> 

Fixed
> Also, you might want to mention:
> 
>     1. If the content of an entry is modified after the file is signed, reading the entry will throw a SecurityException.
> 
Added a note
>     2. These two methods return null if the file is not signed or the signature is not parseable.
Given I link to the javadoc for these methods, this I hope is enough as my goal was not to replace the javadoc for the JarEntry methods.  If you feel the methods should be clarified, happy to work on that next

> src/java.base/share/classes/java/util/jar/JarInputStream.java line 75:
> 
>> 73:  *      </li>
>> 74:  *      <li>
>> 75:  *         All signature entries must immediately follow the {@code manifest}
> 
> We normally say "signature-related entries", which contains both the signature files (.SF) and the signature block files (.DSA/.RSA/.EC) files.

Updated in the next push

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

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

From weijun at openjdk.org  Tue Sep 13 17:24:46 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 Sep 2022 17:24:46 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access
In-Reply-To: <-1cQYcaU0Kz7Weg1X6ZQfAjm6n4a_qt7B6-cqPLrkZM=.70ded8f3-2d39-4ccc-812a-07596f463466@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <_ZgZ3CoGb_Z-1pQTC1Q3Gvby_4JVoY3ZY_5qFxcg5v4=.b6336d35-3270-420f-a73e-03437f82b4c5@github.com>
 <-1cQYcaU0Kz7Weg1X6ZQfAjm6n4a_qt7B6-cqPLrkZM=.70ded8f3-2d39-4ccc-812a-07596f463466@github.com>
Message-ID: <clUkOtLxRTm0Z-OU51o027Bzzf4cUSWk7w0zQKxqAuI=.eef7df1b-3646-463a-87c1-8dd48ed75138@github.com>

On Wed, 31 Aug 2022 18:31:13 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/jar/JarInputStream.java line 62:
>> 
>>> 60:  *         is the second jar entry
>>> 61:  *      </li>
>>> 62:  * </ul>
>> 
>> I wonder if it's necessary to duplicate these lines. How about something like "If ...., then getManifest() returns the manifest and the first call to getNextEntry() returns the entry after it".
>
> The challenge I had with the wording is due to the fact that if "META-INF/" is the first entry in the Zip file, it will not be returned regardless of whether there is a manifest.  So open to suggestions.

That's right. But I think we care about the MANIFEST more. It's not that important whether META-INF is there.

>> src/java.base/share/classes/java/util/jar/JarInputStream.java line 74:
>> 
>>> 72:  *  {@linkplain  JarEntry#getCertificates()} may be called to obtain the certificates
>>> 73:  *  for this entry and {@linkplain JarEntry#getCodeSigners()} may be called to obtain
>>> 74:  *  the verified signers.
>> 
>> Either say "verified" for both methods or none. Otherwise, it sounds like `getCertificates` might return unverified ones.
>> 
>> Also, you might want to mention:
>> 1. If the content of an entry is modified after the file is signed, reading the entry will throw a SecurityException.
>> 2. These two methods return null if the file is not signed or the signature is not parseable.
>
>> Either say "verified" for both methods or none. Otherwise, it sounds like `getCertificates` might return unverified ones.
>> 
> 
> Fixed
>> Also, you might want to mention:
>> 
>>     1. If the content of an entry is modified after the file is signed, reading the entry will throw a SecurityException.
>> 
> Added a note
>>     2. These two methods return null if the file is not signed or the signature is not parseable.
> Given I link to the javadoc for these methods, this I hope is enough as my goal was not to replace the javadoc for the JarEntry methods.  If you feel the methods should be clarified, happy to work on that next

Fair enough.

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

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

From lancea at openjdk.org  Tue Sep 13 17:24:47 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 13 Sep 2022 17:24:47 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access
In-Reply-To: <clUkOtLxRTm0Z-OU51o027Bzzf4cUSWk7w0zQKxqAuI=.eef7df1b-3646-463a-87c1-8dd48ed75138@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <_ZgZ3CoGb_Z-1pQTC1Q3Gvby_4JVoY3ZY_5qFxcg5v4=.b6336d35-3270-420f-a73e-03437f82b4c5@github.com>
 <-1cQYcaU0Kz7Weg1X6ZQfAjm6n4a_qt7B6-cqPLrkZM=.70ded8f3-2d39-4ccc-812a-07596f463466@github.com>
 <clUkOtLxRTm0Z-OU51o027Bzzf4cUSWk7w0zQKxqAuI=.eef7df1b-3646-463a-87c1-8dd48ed75138@github.com>
Message-ID: <M0H1v11ToRj4HozskgItKighzge7-NJoSCFeL8QrhjA=.44e4888f-69c1-4264-958a-03b80fe02939@github.com>

On Wed, 31 Aug 2022 19:13:05 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The challenge I had with the wording is due to the fact that if "META-INF/" is the first entry in the Zip file, it will not be returned regardless of whether there is a manifest.  So open to suggestions.
>
> That's right. But I think we care about the MANIFEST more. It's not that important whether META-INF is there.

True we do care more about the manifest, but was also trying to address the difference between ZipInputStream which will always return both entries regardless of location

We also have the case such where you the 1st entry in the jar is a normal file and the 2nd entry is the manifest.,  getManifest() will return null.

I guess I could say:

 _"getManifest will return the Manifest if it is the first entry or META-INF/ is  the first entry and the Manifest is the second entry within the Jar file. For all cases, getManifest will return null."

Is the above any better?

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

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

From weijun at openjdk.org  Tue Sep 13 17:24:47 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 Sep 2022 17:24:47 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access
In-Reply-To: <M0H1v11ToRj4HozskgItKighzge7-NJoSCFeL8QrhjA=.44e4888f-69c1-4264-958a-03b80fe02939@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <_ZgZ3CoGb_Z-1pQTC1Q3Gvby_4JVoY3ZY_5qFxcg5v4=.b6336d35-3270-420f-a73e-03437f82b4c5@github.com>
 <-1cQYcaU0Kz7Weg1X6ZQfAjm6n4a_qt7B6-cqPLrkZM=.70ded8f3-2d39-4ccc-812a-07596f463466@github.com>
 <clUkOtLxRTm0Z-OU51o027Bzzf4cUSWk7w0zQKxqAuI=.eef7df1b-3646-463a-87c1-8dd48ed75138@github.com>
 <M0H1v11ToRj4HozskgItKighzge7-NJoSCFeL8QrhjA=.44e4888f-69c1-4264-958a-03b80fe02939@github.com>
Message-ID: <huAGEA16B8mM9xdQFaWypWuYB8NeqU_ktPJj0kqH-QA=.c0e5f0f7-319f-4001-91f3-174e7334735f@github.com>

On Thu, 1 Sep 2022 11:06:41 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> That's right. But I think we care about the MANIFEST more. It's not that important whether META-INF is there.
>
> True we do care more about the manifest, but was also trying to address the difference between ZipInputStream which will always return both entries regardless of location
> 
> We also have the case such where you the 1st entry in the jar is a normal file and the 2nd entry is the manifest.,  getManifest() will return null.
> 
> I guess I could say:
> 
>  _"getManifest will return the Manifest if it is the first entry or META-INF/ is  the first entry and the Manifest is the second entry within the Jar file. For all cases, getManifest will return null."
> 
> Is the above any better?

It's better. Do you need to explicitly say "For all other cases"?

My original comment was more about explaining `getManifest()` and `getNextEntry()` in the same if. It's still doable.

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

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

From lancea at openjdk.org  Tue Sep 13 17:24:48 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 13 Sep 2022 17:24:48 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access
In-Reply-To: <huAGEA16B8mM9xdQFaWypWuYB8NeqU_ktPJj0kqH-QA=.c0e5f0f7-319f-4001-91f3-174e7334735f@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <_ZgZ3CoGb_Z-1pQTC1Q3Gvby_4JVoY3ZY_5qFxcg5v4=.b6336d35-3270-420f-a73e-03437f82b4c5@github.com>
 <-1cQYcaU0Kz7Weg1X6ZQfAjm6n4a_qt7B6-cqPLrkZM=.70ded8f3-2d39-4ccc-812a-07596f463466@github.com>
 <clUkOtLxRTm0Z-OU51o027Bzzf4cUSWk7w0zQKxqAuI=.eef7df1b-3646-463a-87c1-8dd48ed75138@github.com>
 <M0H1v11ToRj4HozskgItKighzge7-NJoSCFeL8QrhjA=.44e4888f-69c1-4264-958a-03b80fe02939@github.com>
 <huAGEA16B8mM9xdQFaWypWuYB8NeqU_ktPJj0kqH-QA=.c0e5f0f7-319f-4001-91f3-174e7334735f@github.com>
Message-ID: <QI4qnEF_EAQHycoatIdLkeF-9CBPzL_HBPfuy8jC1PE=.b38162c6-4b00-4349-80a9-5e5efe2cbbb8@github.com>

On Thu, 1 Sep 2022 13:53:05 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> It's better. Do you need to explicitly say "For all other cases"?

I thought it is worth being specific,  but happy to leave it out if you and others prefer
> 
> My original comment was more about explaining `getManifest()` and `getNextEntry()` in the same if. It's still doable.

I think the challenge is there is not an exact match to the behavior between `getManifest()` and `getNext[Jar]Entry()`.    We also have the case if the manifest is the first entry and META-INF/ is the 2nd or later entry, then  META-INF/ will be returned by `JarInputStream`.  ` ZipInputStream` will return all entries which differs from `JarInputStream` so thought it made sense to be specific but perhaps I am overthinking it.

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

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

From lancea at openjdk.org  Tue Sep 13 17:24:49 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 13 Sep 2022 17:24:49 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access
In-Reply-To: <QI4qnEF_EAQHycoatIdLkeF-9CBPzL_HBPfuy8jC1PE=.b38162c6-4b00-4349-80a9-5e5efe2cbbb8@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <_ZgZ3CoGb_Z-1pQTC1Q3Gvby_4JVoY3ZY_5qFxcg5v4=.b6336d35-3270-420f-a73e-03437f82b4c5@github.com>
 <-1cQYcaU0Kz7Weg1X6ZQfAjm6n4a_qt7B6-cqPLrkZM=.70ded8f3-2d39-4ccc-812a-07596f463466@github.com>
 <clUkOtLxRTm0Z-OU51o027Bzzf4cUSWk7w0zQKxqAuI=.eef7df1b-3646-463a-87c1-8dd48ed75138@github.com>
 <M0H1v11ToRj4HozskgItKighzge7-NJoSCFeL8QrhjA=.44e4888f-69c1-4264-958a-03b80fe02939@github.com>
 <huAGEA16B8mM9xdQFaWypWuYB8NeqU_ktPJj0kqH-QA=.c0e5f0f7-319f-4001-91f3-174e7334735f@github.com>
 <QI4qnEF_EAQHycoatIdLkeF-9CBPzL_HBPfuy8jC1PE=.b38162c6-4b00-4349-80a9-5e5efe2cbbb8@github.com>
Message-ID: <2KDL0w92apI-iKU7nfSuunn-kEAXfQbRKLkl9IN2hec=.0b4cfb69-ce9d-4314-8c8f-2b10564bdace@github.com>

On Thu, 1 Sep 2022 17:27:23 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> It's better. Do you need to explicitly say "For all other cases"?
>> 
>> My original comment was more about explaining `getManifest()` and `getNextEntry()` in the same if. It's still doable.
>
>> It's better. Do you need to explicitly say "For all other cases"?
> 
> I thought it is worth being specific,  but happy to leave it out if you and others prefer
>> 
>> My original comment was more about explaining `getManifest()` and `getNextEntry()` in the same if. It's still doable.
> 
> I think the challenge is there is not an exact match to the behavior between `getManifest()` and `getNext[Jar]Entry()`.    We also have the case if the manifest is the first entry and META-INF/ is the 2nd or later entry, then  META-INF/ will be returned by `JarInputStream`.  ` ZipInputStream` will return all entries which differs from `JarInputStream` so thought it made sense to be specific but perhaps I am overthinking it.

I could do tweak further to say:

_`getManifest()` will return the Manifest if it is the first entry or META-INF/ is the first entry and the Manifest is the second entry within the Jar file.   When the Manifest is returned by `getManifest()`,  the `getNextEntry()` and `getNextJarEntry()` methods will not return the Manifest_

Is that more what you were thinking?

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

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

From alanb at openjdk.org  Tue Sep 13 17:24:49 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 Sep 2022 17:24:49 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access
In-Reply-To: <2KDL0w92apI-iKU7nfSuunn-kEAXfQbRKLkl9IN2hec=.0b4cfb69-ce9d-4314-8c8f-2b10564bdace@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <_ZgZ3CoGb_Z-1pQTC1Q3Gvby_4JVoY3ZY_5qFxcg5v4=.b6336d35-3270-420f-a73e-03437f82b4c5@github.com>
 <-1cQYcaU0Kz7Weg1X6ZQfAjm6n4a_qt7B6-cqPLrkZM=.70ded8f3-2d39-4ccc-812a-07596f463466@github.com>
 <clUkOtLxRTm0Z-OU51o027Bzzf4cUSWk7w0zQKxqAuI=.eef7df1b-3646-463a-87c1-8dd48ed75138@github.com>
 <M0H1v11ToRj4HozskgItKighzge7-NJoSCFeL8QrhjA=.44e4888f-69c1-4264-958a-03b80fe02939@github.com>
 <huAGEA16B8mM9xdQFaWypWuYB8NeqU_ktPJj0kqH-QA=.c0e5f0f7-319f-4001-91f3-174e7334735f@github.com>
 <QI4qnEF_EAQHycoatIdLkeF-9CBPzL_HBPfuy8jC1PE=.b38162c6-4b00-4349-80a9-5e5efe2cbbb8@github.com>
 <2KDL0w92apI-iKU7nfSuunn-kEAXfQbRKLkl9IN2hec=.0b4cfb69-ce9d-4314-8c8f-2b10564bdace@github.com>
Message-ID: <Q-0JnUgZm8McmL9RoBEzjddBq-L6sPP1pXyAVS_eoTo=.3bdeeb79-c0dd-4933-8b72-376a1195f1dc@github.com>

On Thu, 1 Sep 2022 17:56:03 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>>> It's better. Do you need to explicitly say "For all other cases"?
>> 
>> I thought it is worth being specific,  but happy to leave it out if you and others prefer
>>> 
>>> My original comment was more about explaining `getManifest()` and `getNextEntry()` in the same if. It's still doable.
>> 
>> I think the challenge is there is not an exact match to the behavior between `getManifest()` and `getNext[Jar]Entry()`.    We also have the case if the manifest is the first entry and META-INF/ is the 2nd or later entry, then  META-INF/ will be returned by `JarInputStream`.  ` ZipInputStream` will return all entries which differs from `JarInputStream` so thought it made sense to be specific but perhaps I am overthinking it.
>
> I could do tweak further to say:
> 
> _`getManifest()` will return the Manifest if it is the first entry or META-INF/ is the first entry and the Manifest is the second entry within the Jar file.   When the Manifest is returned by `getManifest()`,  the `getNextEntry()` and `getNextJarEntry()` methods will not return the Manifest_
> 
> Is that more what you were thinking?

I read the current draft and it makes we wonder if it would be simpler to just replace the class description with something like this:


 * The JarInputStream class is used to read the contents of a JAR file from
 * an input stream. It extends ZipInputStream with support for reading an optional
 * manifest named "META-INF/MANIFEST.MF" when it is found at as the first entry in
 * the stream. If the first entry in the stream is "META-INF/" then it is skipped,
 * in which case the manifest is found if it is the second entry in the stream.
 *
 * JarInputStream defines the getNextJarEntry() method to iterate through the
 * JAR file entries in the stream. The method reads the metadata for the next JAR
 * file entry in the stream and positions the input stream to read the entry's
 * file data. The first entry found by getNextJarEntry() (or getNextEntry())
 * will follow the manifest when the manifest is the first entry in the JAR
 * file (or the second entry when the first entry is "META-INF/").

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

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

From lancea at openjdk.org  Tue Sep 13 17:24:50 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 13 Sep 2022 17:24:50 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access
In-Reply-To: <Q-0JnUgZm8McmL9RoBEzjddBq-L6sPP1pXyAVS_eoTo=.3bdeeb79-c0dd-4933-8b72-376a1195f1dc@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <_ZgZ3CoGb_Z-1pQTC1Q3Gvby_4JVoY3ZY_5qFxcg5v4=.b6336d35-3270-420f-a73e-03437f82b4c5@github.com>
 <-1cQYcaU0Kz7Weg1X6ZQfAjm6n4a_qt7B6-cqPLrkZM=.70ded8f3-2d39-4ccc-812a-07596f463466@github.com>
 <clUkOtLxRTm0Z-OU51o027Bzzf4cUSWk7w0zQKxqAuI=.eef7df1b-3646-463a-87c1-8dd48ed75138@github.com>
 <M0H1v11ToRj4HozskgItKighzge7-NJoSCFeL8QrhjA=.44e4888f-69c1-4264-958a-03b80fe02939@github.com>
 <huAGEA16B8mM9xdQFaWypWuYB8NeqU_ktPJj0kqH-QA=.c0e5f0f7-319f-4001-91f3-174e7334735f@github.com>
 <QI4qnEF_EAQHycoatIdLkeF-9CBPzL_HBPfuy8jC1PE=.b38162c6-4b00-4349-80a9-5e5efe2cbbb8@github.com>
 <2KDL0w92apI-iKU7nfSuunn-kEAXfQbRKLkl9IN2hec=.0b4cfb69-ce9d-4314-8c8f-2b10564bdace@github.com>
 <Q-0JnUgZm8McmL9RoBEzjddBq-L6sPP1pXyAVS_eoTo=.3bdeeb79-c0dd-4933-8b72-376a1195f1dc@github.com>
Message-ID: <442Fu17tGdi8NaT6Xf78IPWFB2UOAAujeoOzFe0N00U=.3eece7e9-f1f6-4087-a6a7-18753f4483d0@github.com>

On Fri, 2 Sep 2022 14:50:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I could do tweak further to say:
>> 
>> _`getManifest()` will return the Manifest if it is the first entry or META-INF/ is the first entry and the Manifest is the second entry within the Jar file.   When the Manifest is returned by `getManifest()`,  the `getNextEntry()` and `getNextJarEntry()` methods will not return the Manifest_
>> 
>> Is that more what you were thinking?
>
> I read the current draft and it makes we wonder if it would be simpler to just replace the class description with something like this:
> 
> 
>  * The JarInputStream class is used to read the contents of a JAR file from
>  * an input stream. It extends ZipInputStream with support for reading an optional
>  * manifest named "META-INF/MANIFEST.MF" when it is found at as the first entry in
>  * the stream. If the first entry in the stream is "META-INF/" then it is skipped,
>  * in which case the manifest is found if it is the second entry in the stream.
>  *
>  * JarInputStream defines the getNextJarEntry() method to iterate through the
>  * JAR file entries in the stream. The method reads the metadata for the next JAR
>  * file entry in the stream and positions the input stream to read the entry's
>  * file data. The first entry found by getNextJarEntry() (or getNextEntry())
>  * will follow the manifest when the manifest is the first entry in the JAR
>  * file (or the second entry when the first entry is "META-INF/").

Thank you for the suggestions.  I just updated the the description leveraging your feedback.  Please let me know if this is better

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

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

From shade at openjdk.org  Tue Sep 13 17:25:48 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 13 Sep 2022 17:25:48 GMT
Subject: RFR: 8293499: Provide jmod --compress option [v5]
In-Reply-To: <PLxSpqwyZOckAhoIjxohreORPnySGmfzrg72d4OASfU=.bf4da65e-9d97-4aa5-9113-17af5b60b7cd@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
 <qzRBM-V4f6cLNymJm6tOP6CdI4R-XQcoYVIikzEB4QQ=.09380090-bf57-4539-ae1f-e01e32784f73@github.com>
 <PLxSpqwyZOckAhoIjxohreORPnySGmfzrg72d4OASfU=.bf4da65e-9d97-4aa5-9113-17af5b60b7cd@github.com>
Message-ID: <80VLHIhczjJN4kDTAGvvlqlNIPFLzya68P5Nnc6uO1U=.be667b63-a28e-4f62-88da-3d461e7522b3@github.com>

On Tue, 13 Sep 2022 16:51:52 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More review comments
>
> src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties line 87:
> 
>> 85: main.opt.compress=Compression to use when creating the JMOD archive.\
>> 86: \ Accepted values are: zip-[0-9], where zip-0 provides no compression, and zip-9\
>> 87: \ provides the best compression.
> 
> Should specify the default if not set.

Here is where we get into a minor pickle. We currently default to `Deflater.DEFAULT_COMPRESSION`, which is `-1`, and which is handled inside `zlib` as `6`. We can say `zip-6` here is the default, but that would be stale if zlib ever updates its default. Still fair to say `zip-6` here, or?

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

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

From lancea at openjdk.org  Tue Sep 13 17:29:57 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 13 Sep 2022 17:29:57 GMT
Subject: RFR: 8278165: Clarify that ZipInputStream does not access the CEN
 fields for a ZipEntry
Message-ID: <5xFWPl4un_Ymri2We2utzNAj9UuqMqzIzF8yex4thFg=.c3d990c5-8765-452b-9775-08071d0576b5@github.com>

Hi,

Please review this update to the ZipInputStream class description to clarify that ZipInputStream walks sequentially through each Zip Entry contained within the Zip File.  As a result, the CEN header for the Zip file entries are not read resulting in ZipInputStream not having access to information that is stored within the CEN Header fields such the as the external file attributes which can be used to store optional data such as Posix Permissions.

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

Commit messages:
 - Merge branch 'JDK-8278165' of https://github.com/LanceAndersen/jdk into JDK-8278165
 - Merge branch 'openjdk:master' into JDK-8278165
 - add extra space
 - removed extra space
 - Minor updates to the LOC description
 - Merge branch 'master' into JDK-8278165
 - Second pass at updating the class description
 - Minor update to the wording
 - Inital draft to clarify ZipInputStream does not access the CEN fields

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

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

From shade at openjdk.org  Tue Sep 13 17:41:04 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 13 Sep 2022 17:41:04 GMT
Subject: RFR: 8293499: Provide jmod --compress option [v6]
In-Reply-To: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
Message-ID: <7mps9AwYW2ZWKhN_3LAeh247LIBuxz9VURde2qxoDxU=.32f31014-5c78-45e0-a511-dd4fbef466de@github.com>

> I have been looking into `make clean-images images` performance, and realized jmod keeps compressing files with default compression level. Tuning that toward lighter compression levels improves build performance considerably, without a heavy loss in *.jmod sizes. 
> 
> This PR allows JMOD to select the compression level. Follow-ups would use this in the build system, see #10214.
> 
> The interesting asymmetry against `jlink` is: `jlink` provides `--compress` option that only takes `2` for "ZIP compression". (Separately, we could argue if it would be beneficial to extend `--compress` to `jlink` as well, so to select the compression level there too.)

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

  Mention the default level

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10213/files
  - new: https://git.openjdk.org/jdk/pull/10213/files/092b0ffa..2729dfb4

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

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

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

From shade at openjdk.org  Tue Sep 13 17:41:04 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 13 Sep 2022 17:41:04 GMT
Subject: RFR: 8293499: Provide jmod --compress option [v5]
In-Reply-To: <80VLHIhczjJN4kDTAGvvlqlNIPFLzya68P5Nnc6uO1U=.be667b63-a28e-4f62-88da-3d461e7522b3@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
 <qzRBM-V4f6cLNymJm6tOP6CdI4R-XQcoYVIikzEB4QQ=.09380090-bf57-4539-ae1f-e01e32784f73@github.com>
 <PLxSpqwyZOckAhoIjxohreORPnySGmfzrg72d4OASfU=.bf4da65e-9d97-4aa5-9113-17af5b60b7cd@github.com>
 <80VLHIhczjJN4kDTAGvvlqlNIPFLzya68P5Nnc6uO1U=.be667b63-a28e-4f62-88da-3d461e7522b3@github.com>
Message-ID: <7MYuZ-KVp5pAUIyXE3X9usY3BuNIAb5rcHjgJzW8HXA=.998db1c3-b5bc-4d4e-9dec-4c532102c9a0@github.com>

On Tue, 13 Sep 2022 17:21:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties line 87:
>> 
>>> 85: main.opt.compress=Compression to use when creating the JMOD archive.\
>>> 86: \ Accepted values are: zip-[0-9], where zip-0 provides no compression, and zip-9\
>>> 87: \ provides the best compression.
>> 
>> Should specify the default if not set.
>
> Here is where we get into a minor pickle. We currently default to `Deflater.DEFAULT_COMPRESSION`, which is `-1`, and which is handled inside `zlib` as `6`. We can say `zip-6` here is the default, but that would be stale if zlib ever updates its default. Still fair to say `zip-6` here, or?

Actually, nevermind. Let's just put the defacto `6` into `jmod` defaults, and use it. See new commit.

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

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

From bpb at openjdk.org  Tue Sep 13 17:42:21 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 13 Sep 2022 17:42:21 GMT
Subject: RFR: 8278165: Clarify that ZipInputStream does not access the CEN
 fields for a ZipEntry
In-Reply-To: <5xFWPl4un_Ymri2We2utzNAj9UuqMqzIzF8yex4thFg=.c3d990c5-8765-452b-9775-08071d0576b5@github.com>
References: <5xFWPl4un_Ymri2We2utzNAj9UuqMqzIzF8yex4thFg=.c3d990c5-8765-452b-9775-08071d0576b5@github.com>
Message-ID: <zR3acqOGGiYataMNkC18tTiArvM-2uTh53ZYWfU0Ayg=.fe10c7d1-c062-4610-a9eb-f4ae358467e7@github.com>

On Wed, 31 Aug 2022 16:06:57 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi,
> 
> Please review this update to the ZipInputStream class description to clarify that ZipInputStream walks sequentially through each Zip Entry contained within the Zip File.  As a result, the CEN header for the Zip file entries are not read resulting in ZipInputStream not having access to information that is stored within the CEN Header fields such the as the external file attributes which can be used to store optional data such as Posix Permissions.

src/java.base/share/classes/java/util/zip/ZipInputStream.java line 49:

> 47:  * The {@link #getNextEntry()} method is used to read the next ZIP file entry
> 48:  * (Local file (LOC) header record in the ZIP format) and position the stream at
> 49:  * the entry's file data. The file data may read using one of

of -> of the?

src/java.base/share/classes/java/util/zip/ZipInputStream.java line 56:

> 54:  *     {@code
> 55:  *      try (FileInputStream fis = new FileInputStream(jar.toFile());
> 56:  *              ZipInputStream zis = new ZipInputStream(fis)) {

The indentation seems weird in this code sample.

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

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

From cjplummer at openjdk.org  Tue Sep 13 17:50:55 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 13 Sep 2022 17:50:55 GMT
Subject: RFR: 8289610: Degrade Thread.stop
In-Reply-To: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
Message-ID: <8ZLJ1_MCq61Of0Jb2zUNFDskX7BYN1LFwGQ3JGSPcUQ=.f971b32e-491d-400d-bced-c13aabc30a0f@github.com>

On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
> 
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
> 
> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
> 
> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.

serviceability changes look good

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

Marked as reviewed by cjplummer (Reviewer).

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

From mchung at openjdk.org  Tue Sep 13 18:04:44 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 13 Sep 2022 18:04:44 GMT
Subject: RFR: 8293499: Provide jmod --compress option [v5]
In-Reply-To: <7MYuZ-KVp5pAUIyXE3X9usY3BuNIAb5rcHjgJzW8HXA=.998db1c3-b5bc-4d4e-9dec-4c532102c9a0@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
 <qzRBM-V4f6cLNymJm6tOP6CdI4R-XQcoYVIikzEB4QQ=.09380090-bf57-4539-ae1f-e01e32784f73@github.com>
 <PLxSpqwyZOckAhoIjxohreORPnySGmfzrg72d4OASfU=.bf4da65e-9d97-4aa5-9113-17af5b60b7cd@github.com>
 <80VLHIhczjJN4kDTAGvvlqlNIPFLzya68P5Nnc6uO1U=.be667b63-a28e-4f62-88da-3d461e7522b3@github.com>
 <7MYuZ-KVp5pAUIyXE3X9usY3BuNIAb5rcHjgJzW8HXA=.998db1c3-b5bc-4d4e-9dec-4c532102c9a0@github.com>
Message-ID: <mv53LyJaOatFlJzuMT9UaYp_CvDVW-EUTFawcUIU4nM=.573d3a13-070d-48d9-8771-a7eaf1c29d31@github.com>

On Tue, 13 Sep 2022 17:35:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Here is where we get into a minor pickle. We currently default to `Deflater.DEFAULT_COMPRESSION`, which is `-1`, and which is handled inside `zlib` as `6`. We can say `zip-6` here is the default, but that would be stale if zlib ever updates its default. Still fair to say `zip-6` here, or?
>
> Actually, nevermind. Let's just put the defacto `6` into `jmod` defaults, and use it. See new commit.

Sounds good as the implementation sets 6 as the default.  The new commit looks good.

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

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

From lancea at openjdk.org  Tue Sep 13 18:12:44 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 13 Sep 2022 18:12:44 GMT
Subject: RFR: 8278165: Clarify that ZipInputStream does not access the CEN
 fields for a ZipEntry [v2]
In-Reply-To: <5xFWPl4un_Ymri2We2utzNAj9UuqMqzIzF8yex4thFg=.c3d990c5-8765-452b-9775-08071d0576b5@github.com>
References: <5xFWPl4un_Ymri2We2utzNAj9UuqMqzIzF8yex4thFg=.c3d990c5-8765-452b-9775-08071d0576b5@github.com>
Message-ID: <FiHbR5gj-gUpsK2IjaL-nuzPRNPn8gpvZqaiW55E-Ao=.92fea959-bdc4-46ef-9c63-14b9a433b9a3@github.com>

> Hi,
> 
> Please review this update to the ZipInputStream class description to clarify that ZipInputStream walks sequentially through each Zip Entry contained within the Zip File.  As a result, the CEN header for the Zip file entries are not read resulting in ZipInputStream not having access to information that is stored within the CEN Header fields such the as the external file attributes which can be used to store optional data such as Posix Permissions.

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

  Address sample indentation and typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10102/files
  - new: https://git.openjdk.org/jdk/pull/10102/files/51ddd8bd..fe462d7f

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

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

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

From lancea at openjdk.org  Tue Sep 13 18:12:48 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 13 Sep 2022 18:12:48 GMT
Subject: RFR: 8278165: Clarify that ZipInputStream does not access the CEN
 fields for a ZipEntry [v2]
In-Reply-To: <zR3acqOGGiYataMNkC18tTiArvM-2uTh53ZYWfU0Ayg=.fe10c7d1-c062-4610-a9eb-f4ae358467e7@github.com>
References: <5xFWPl4un_Ymri2We2utzNAj9UuqMqzIzF8yex4thFg=.c3d990c5-8765-452b-9775-08071d0576b5@github.com>
 <zR3acqOGGiYataMNkC18tTiArvM-2uTh53ZYWfU0Ayg=.fe10c7d1-c062-4610-a9eb-f4ae358467e7@github.com>
Message-ID: <81Db19Qni_8avXqcKxSmKuJ5ytyS3cqqESlm9oTRwiA=.454ad9e1-1f25-4e5e-94e0-a97f5d83328d@github.com>

On Tue, 13 Sep 2022 17:38:29 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address sample indentation and typo
>
> src/java.base/share/classes/java/util/zip/ZipInputStream.java line 49:
> 
>> 47:  * The {@link #getNextEntry()} method is used to read the next ZIP file entry
>> 48:  * (Local file (LOC) header record in the ZIP format) and position the stream at
>> 49:  * the entry's file data. The file data may read using one of
> 
> of -> of the?

fixed

> src/java.base/share/classes/java/util/zip/ZipInputStream.java line 56:
> 
>> 54:  *     {@code
>> 55:  *      try (FileInputStream fis = new FileInputStream(jar.toFile());
>> 56:  *              ZipInputStream zis = new ZipInputStream(fis)) {
> 
> The indentation seems weird in this code sample.

Reformatted

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

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

From bpb at openjdk.org  Tue Sep 13 18:28:41 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 13 Sep 2022 18:28:41 GMT
Subject: RFR: 8278165: Clarify that ZipInputStream does not access the CEN
 fields for a ZipEntry [v2]
In-Reply-To: <FiHbR5gj-gUpsK2IjaL-nuzPRNPn8gpvZqaiW55E-Ao=.92fea959-bdc4-46ef-9c63-14b9a433b9a3@github.com>
References: <5xFWPl4un_Ymri2We2utzNAj9UuqMqzIzF8yex4thFg=.c3d990c5-8765-452b-9775-08071d0576b5@github.com>
 <FiHbR5gj-gUpsK2IjaL-nuzPRNPn8gpvZqaiW55E-Ao=.92fea959-bdc4-46ef-9c63-14b9a433b9a3@github.com>
Message-ID: <qSqq3E5IvDF6nvRpGcZ8TObmQxs3tAjQLpXe171EYYo=.7ddaffa3-507a-45d9-a04c-5baf151f01ef@github.com>

On Tue, 13 Sep 2022 18:12:44 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Hi,
>> 
>> Please review this update to the ZipInputStream class description to clarify that ZipInputStream walks sequentially through each Zip Entry contained within the Zip File.  As a result, the CEN header for the Zip file entries are not read resulting in ZipInputStream not having access to information that is stored within the CEN Header fields such the as the external file attributes which can be used to store optional data such as Posix Permissions.
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address sample indentation and typo

Looks fine.

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

Marked as reviewed by bpb (Reviewer).

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

From mullan at openjdk.org  Tue Sep 13 19:01:51 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 13 Sep 2022 19:01:51 GMT
Subject: RFR: 8289610: Degrade Thread.stop
In-Reply-To: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
Message-ID: <FccBcuRP60nXHjvizhgiU_wr0QoD7vP6ZsJJYsdheLU=.0a392f5f-f3d7-4a28-9183-d1f6a8bfc29f@github.com>

On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
> 
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
> 
> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
> 
> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.

What about also removing and undocumenting `RuntimePermission("stopThread")` as part of this change?

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

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

From eosterlund at openjdk.org  Tue Sep 13 19:09:42 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 13 Sep 2022 19:09:42 GMT
Subject: RFR: 8289610: Degrade Thread.stop
In-Reply-To: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
Message-ID: <NvkrIiKWBp863qr4zH4amdPEXgnWp64PdDnOjoab5Bs=.ac39b71a-f73b-442b-ad1e-978c186aa77f@github.com>

On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
> 
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
> 
> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
> 
> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.

There is a bunch of VM code for this too. Should we clean that up separately?

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

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

From alanb at openjdk.org  Tue Sep 13 19:17:45 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 Sep 2022 19:17:45 GMT
Subject: RFR: 8289610: Degrade Thread.stop
In-Reply-To: <NvkrIiKWBp863qr4zH4amdPEXgnWp64PdDnOjoab5Bs=.ac39b71a-f73b-442b-ad1e-978c186aa77f@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <NvkrIiKWBp863qr4zH4amdPEXgnWp64PdDnOjoab5Bs=.ac39b71a-f73b-442b-ad1e-978c186aa77f@github.com>
Message-ID: <yNN_3wT_cFTtm-ZmdtbtxVE0HiHT9HKcdVYe6eV_Gn4=.f5b40a33-284f-4577-bfa3-bf9ceaaa0ef4@github.com>

On Tue, 13 Sep 2022 19:06:14 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> There is a bunch of VM code for this too. Should we clean that up separately?

Yes chatted with @dholmes-ora about this recently and he suggested separating out so there is a follow-on JBS issue created for that. Aside from JVM_StopThread, I suspect code that deals with pending exceptions before a thread start can go away as the JVM TI StopThread can't cause an async exception on an unstarted thread. I'm hoping Thread.stillborn can go away too.

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

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

From eosterlund at openjdk.org  Tue Sep 13 19:17:46 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 13 Sep 2022 19:17:46 GMT
Subject: RFR: 8289610: Degrade Thread.stop
In-Reply-To: <yNN_3wT_cFTtm-ZmdtbtxVE0HiHT9HKcdVYe6eV_Gn4=.f5b40a33-284f-4577-bfa3-bf9ceaaa0ef4@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <NvkrIiKWBp863qr4zH4amdPEXgnWp64PdDnOjoab5Bs=.ac39b71a-f73b-442b-ad1e-978c186aa77f@github.com>
 <yNN_3wT_cFTtm-ZmdtbtxVE0HiHT9HKcdVYe6eV_Gn4=.f5b40a33-284f-4577-bfa3-bf9ceaaa0ef4@github.com>
Message-ID: <o-0jNj4vm7C4U-FuAnD5XzemL-oal-x-flVVPk-oyow=.e35d8591-8312-4f5d-9068-1092f4112e29@github.com>

On Tue, 13 Sep 2022 19:12:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > There is a bunch of VM code for this too. Should we clean that up separately?
> 
> 
> 
> Yes chatted with @dholmes-ora about this recently and he suggested separating out so there is a follow-on JBS issue created for that. Aside from JVM_StopThread, I suspect code that deals with pending exceptions before a thread start can go away as the JVM TI StopThread can't cause an async exception on an unstarted thread. I'm hoping Thread.stillborn can go away too.

Sounds good.

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

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

From alanb at openjdk.org  Tue Sep 13 19:17:47 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 Sep 2022 19:17:47 GMT
Subject: RFR: 8289610: Degrade Thread.stop
In-Reply-To: <FccBcuRP60nXHjvizhgiU_wr0QoD7vP6ZsJJYsdheLU=.0a392f5f-f3d7-4a28-9183-d1f6a8bfc29f@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <FccBcuRP60nXHjvizhgiU_wr0QoD7vP6ZsJJYsdheLU=.0a392f5f-f3d7-4a28-9183-d1f6a8bfc29f@github.com>
Message-ID: <g0EEBLhi7sK7lvdB8ocA1pzZungwW5grIhxctMyaiQ0=.e70a7f68-a282-4926-a40d-81836c488270@github.com>

On Tue, 13 Sep 2022 18:57:34 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> What about also removing and undocumenting `RuntimePermission("stopThread")` as part of this change?

Ah yes, the table RuntimePermission can be updated as part of this (and the corresponding constant in sun/security/util/SecurityConstants).

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

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

From alanb at openjdk.org  Tue Sep 13 19:33:44 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 Sep 2022 19:33:44 GMT
Subject: RFR: 8278165: Clarify that ZipInputStream does not access the CEN
 fields for a ZipEntry [v2]
In-Reply-To: <FiHbR5gj-gUpsK2IjaL-nuzPRNPn8gpvZqaiW55E-Ao=.92fea959-bdc4-46ef-9c63-14b9a433b9a3@github.com>
References: <5xFWPl4un_Ymri2We2utzNAj9UuqMqzIzF8yex4thFg=.c3d990c5-8765-452b-9775-08071d0576b5@github.com>
 <FiHbR5gj-gUpsK2IjaL-nuzPRNPn8gpvZqaiW55E-Ao=.92fea959-bdc4-46ef-9c63-14b9a433b9a3@github.com>
Message-ID: <RQgRHq7cswiPOVUR9pWemIQf_x-jZFg_7jGtM-qtYpY=.2f9cd96d-b30b-4703-b2ed-0258c75991c9@github.com>

On Tue, 13 Sep 2022 18:12:44 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Hi,
>> 
>> Please review this update to the ZipInputStream class description to clarify that ZipInputStream walks sequentially through each Zip Entry contained within the Zip File.  As a result, the CEN header for the Zip file entries are not read resulting in ZipInputStream not having access to information that is stored within the CEN Header fields such the as the external file attributes which can be used to store optional data such as Posix Permissions.
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address sample indentation and typo

src/java.base/share/classes/java/util/zip/ZipInputStream.java line 65:

> 63:  *      }
> 64:  *    }
> 65:  * </pre>

The updated class description looks okay. For the example then I assume you make this a code snippet.

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

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

From duke at openjdk.org  Tue Sep 13 20:07:40 2022
From: duke at openjdk.org (Bernd)
Date: Tue, 13 Sep 2022 20:07:40 GMT
Subject: RFR: 8292698: Improve performance of DataInputStream [v3]
In-Reply-To: <e4eIcbtpEZdZdn5KvOHjd3zrI8voMlr1aMuURWTJRN0=.7834a1a2-287a-4b3c-80bd-0918c7a04ae7@github.com>
References: <MXdBQj8qYqvvImT-MaBpf8mAm3b1tbNiPS93syrjfqg=.3ebdd952-f9d7-4ec9-9655-a63829828c67@github.com>
 <5v8lej62KNGYz6FTjQ6FyABbMfJxwLUSNCa6Z3DXZGQ=.1b35ef41-3b59-4b78-b035-6d1838eaebbd@github.com>
 <KIfIm02U3CPC53gSjSpi68Jk7BcoMgcmwHe3SDGVFSw=.0dc503c6-937b-4c7f-a05a-6ac7655f019e@github.com>
 <e4eIcbtpEZdZdn5KvOHjd3zrI8voMlr1aMuURWTJRN0=.7834a1a2-287a-4b3c-80bd-0918c7a04ae7@github.com>
Message-ID: <RKACHIHF07-2UJp9ByKLbdeFV5vCaqFpZ73-48REHMg=.bce10b60-7578-4441-9a43-627f0ee5c164@github.com>

On Thu, 25 Aug 2022 09:25:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > What is wrong with the change?
> 
> You'll need parentheses to make that work, changing it to use '|' would work too.

Does that mean there is no explicit test for DataInputStream endianess (if only accidential tests checking for magic numbers failed.. or where there other failures but you did not mention them).

btw the cleanup looks really good. (shame we have no easy way to stack allocate the scratch byte array)

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

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

From lancea at openjdk.org  Tue Sep 13 20:11:06 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 13 Sep 2022 20:11:06 GMT
Subject: RFR: 8278165: Clarify that ZipInputStream does not access the CEN
 fields for a ZipEntry [v3]
In-Reply-To: <5xFWPl4un_Ymri2We2utzNAj9UuqMqzIzF8yex4thFg=.c3d990c5-8765-452b-9775-08071d0576b5@github.com>
References: <5xFWPl4un_Ymri2We2utzNAj9UuqMqzIzF8yex4thFg=.c3d990c5-8765-452b-9775-08071d0576b5@github.com>
Message-ID: <PC2iVLJopUFIYbjZuVbpktkWvVZ3boeov4x09__Unas=.dc29b393-4390-432a-b54b-de113819ab69@github.com>

> Hi,
> 
> Please review this update to the ZipInputStream class description to clarify that ZipInputStream walks sequentially through each Zip Entry contained within the Zip File.  As a result, the CEN header for the Zip file entries are not read resulting in ZipInputStream not having access to information that is stored within the CEN Header fields such the as the external file attributes which can be used to store optional data such as Posix Permissions.

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

  Converted example to be a snippet

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10102/files
  - new: https://git.openjdk.org/jdk/pull/10102/files/fe462d7f..ea3510b9

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

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

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

From lancea at openjdk.org  Tue Sep 13 20:11:06 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 13 Sep 2022 20:11:06 GMT
Subject: RFR: 8278165: Clarify that ZipInputStream does not access the CEN
 fields for a ZipEntry [v2]
In-Reply-To: <RQgRHq7cswiPOVUR9pWemIQf_x-jZFg_7jGtM-qtYpY=.2f9cd96d-b30b-4703-b2ed-0258c75991c9@github.com>
References: <5xFWPl4un_Ymri2We2utzNAj9UuqMqzIzF8yex4thFg=.c3d990c5-8765-452b-9775-08071d0576b5@github.com>
 <FiHbR5gj-gUpsK2IjaL-nuzPRNPn8gpvZqaiW55E-Ao=.92fea959-bdc4-46ef-9c63-14b9a433b9a3@github.com>
 <RQgRHq7cswiPOVUR9pWemIQf_x-jZFg_7jGtM-qtYpY=.2f9cd96d-b30b-4703-b2ed-0258c75991c9@github.com>
Message-ID: <8hi3STE7_JeOUw0wpF0_5LWOOnXy5i-zxzvmDfDGH_U=.81af3e9c-c4ac-4390-97d0-a21bca2da986@github.com>

On Tue, 13 Sep 2022 19:30:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address sample indentation and typo
>
> src/java.base/share/classes/java/util/zip/ZipInputStream.java line 65:
> 
>> 63:  *      }
>> 64:  *    }
>> 65:  * </pre>
> 
> The updated class description looks okay. For the example then I assume you make this a code snippet.

Converted the example to a snippet.  Thanks for the suggestion

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

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

From weijun at openjdk.org  Tue Sep 13 20:48:11 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 Sep 2022 20:48:11 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access
In-Reply-To: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
Message-ID: <OSPxo28V-dP4aT8kFvUadO_b2dP8oWoKPIt5PuxFVa0=.063c1c68-1bf6-4123-a487-42fea8ca6702@github.com>

On Fri, 26 Aug 2022 15:48:55 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
> 
> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
> 
> 
> Best,
> Lance

Mostly good. Some small comments.

BTW, there are still a lot of `linkplain`. I'm not sure how javadoc are written for core-libs, but my experience on security-libs is that it's only used when the text is &mdash; er &mdash; plaintext that's neither a class name nor a method name.

src/java.base/share/classes/java/util/jar/JarInputStream.java line 36:

> 34:  * The {@code JarInputStream} class, which extends {@linkplain ZipInputStream},
> 35:  * is used to read the contents of a JAR file from an input stream.
> 36:  * It provides support for reading an optional {@linkplain JarFile#MANIFEST_NAME Manifest}

`Manifest` above is the same as the one below. If the one below is in fixed-width, so should be the one above.

src/java.base/share/classes/java/util/jar/JarInputStream.java line 67:

> 65:  *      </li>
> 66:  *      <li>
> 67:  *         All signature-related entries must immediately follow the {@code Manifest}

No need to say `must`. This is is one of the requirements.

src/java.base/share/classes/java/util/jar/JarInputStream.java line 78:

> 76:  * <b>Note:</b>If a {@code JarEntry} is modified after the Jar file is signed,
> 77:  * a {@linkplain SecurityException} will be thrown when an attempt is made to
> 78:  * read the entry.

Not sure if the the `an attempt` word is precise. The exception is only thrown when the last byte is read.

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

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

From lancea at openjdk.org  Tue Sep 13 21:05:41 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 13 Sep 2022 21:05:41 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access
In-Reply-To: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
Message-ID: <HiFgQPD_YWDsr8c_GZqCY6UwQnkB4GrSPt7pABcv42c=.23b75077-667e-480e-8398-84e7fe39e044@github.com>

On Fri, 26 Aug 2022 15:48:55 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
> 
> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
> 
> 
> Best,
> Lance

Max,

Thank you for your feedback.  See my responses below

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

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

From lancea at openjdk.org  Tue Sep 13 21:05:45 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 13 Sep 2022 21:05:45 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access
In-Reply-To: <OSPxo28V-dP4aT8kFvUadO_b2dP8oWoKPIt5PuxFVa0=.063c1c68-1bf6-4123-a487-42fea8ca6702@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <OSPxo28V-dP4aT8kFvUadO_b2dP8oWoKPIt5PuxFVa0=.063c1c68-1bf6-4123-a487-42fea8ca6702@github.com>
Message-ID: <5OfTyN2RiR2UpGRf4qMVaQuEWuTHko2L3elcwm3RHtU=.8360ba06-d606-4419-a839-33c09373dd63@github.com>

On Tue, 13 Sep 2022 20:39:31 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
>> 
>> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
>> 
>> 
>> Best,
>> Lance
>
> src/java.base/share/classes/java/util/jar/JarInputStream.java line 36:
> 
>> 34:  * The {@code JarInputStream} class, which extends {@linkplain ZipInputStream},
>> 35:  * is used to read the contents of a JAR file from an input stream.
>> 36:  * It provides support for reading an optional {@linkplain JarFile#MANIFEST_NAME Manifest}
> 
> `Manifest` above is the same as the one below. If the one below is in fixed-width, so should be the one above.

Could you please clarify what you are suggesting.  I am using the  `@linkplain` to provide a means to see the actual Manifest name.   I am happy to tweak, just need (perhaps an example) of what you would like

> src/java.base/share/classes/java/util/jar/JarInputStream.java line 67:
> 
>> 65:  *      </li>
>> 66:  *      <li>
>> 67:  *         All signature-related entries must immediately follow the {@code Manifest}
> 
> No need to say `must`. This is is one of the requirements.

addressed in the next update

> src/java.base/share/classes/java/util/jar/JarInputStream.java line 78:
> 
>> 76:  * <b>Note:</b>If a {@code JarEntry} is modified after the Jar file is signed,
>> 77:  * a {@linkplain SecurityException} will be thrown when an attempt is made to
>> 78:  * read the entry.
> 
> Not sure if the the `an attempt` word is precise. The exception is only thrown when the last byte is read.

Are you suggesting change:

"...will be thrown when an attempt is made to read the entry."

to

"...will be thrown when the entry has been read."

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

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

From lancea at openjdk.org  Tue Sep 13 21:13:15 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 13 Sep 2022 21:13:15 GMT
Subject: RFR: 8278165: Clarify that ZipInputStream does not access the CEN
 fields for a ZipEntry [v4]
In-Reply-To: <5xFWPl4un_Ymri2We2utzNAj9UuqMqzIzF8yex4thFg=.c3d990c5-8765-452b-9775-08071d0576b5@github.com>
References: <5xFWPl4un_Ymri2We2utzNAj9UuqMqzIzF8yex4thFg=.c3d990c5-8765-452b-9775-08071d0576b5@github.com>
Message-ID: <qF19Luc2f0untbmqkIPWamXaO3huSVk61MlvRZZBevU=.3951e9c9-0fcd-4220-b9e0-c5c0a03e0eea@github.com>

> Hi,
> 
> Please review this update to the ZipInputStream class description to clarify that ZipInputStream walks sequentially through each Zip Entry contained within the Zip File.  As a result, the CEN header for the Zip file entries are not read resulting in ZipInputStream not having access to information that is stored within the CEN Header fields such the as the external file attributes which can be used to store optional data such as Posix Permissions.

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

  Remove stray comma after ZipFile

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10102/files
  - new: https://git.openjdk.org/jdk/pull/10102/files/ea3510b9..b98c6e1e

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

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

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

From mchung at openjdk.org  Tue Sep 13 23:54:31 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 13 Sep 2022 23:54:31 GMT
Subject: RFR: 8289610: Degrade Thread.stop
In-Reply-To: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
Message-ID: <GUqUvGAgZaq3V6d7zLstLPcnDXJfC3Tn9nJ7FKCP4Is=.5d7a18f1-55fb-45f6-81e3-9a1372832d38@github.com>

On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
> 
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
> 
> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
> 
> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.

The change looks good.   There are other tests that reference `ThreadDeath` for example `test/lib/jdk/test/lib/process/ProcessTools.java`, `test/jdk/java/util/Timer/KillThread.java` , `test/jdk/java/net/httpclient/reactivestreams-tck/org/reactivestreams/tck/flow/support/NonFatal.java` etc.    Is it expected to update them in a follow-on issue?

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

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

From weijun at openjdk.org  Wed Sep 14 00:44:50 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 14 Sep 2022 00:44:50 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access
In-Reply-To: <5OfTyN2RiR2UpGRf4qMVaQuEWuTHko2L3elcwm3RHtU=.8360ba06-d606-4419-a839-33c09373dd63@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <OSPxo28V-dP4aT8kFvUadO_b2dP8oWoKPIt5PuxFVa0=.063c1c68-1bf6-4123-a487-42fea8ca6702@github.com>
 <5OfTyN2RiR2UpGRf4qMVaQuEWuTHko2L3elcwm3RHtU=.8360ba06-d606-4419-a839-33c09373dd63@github.com>
Message-ID: <F-9FaZUKRQ3W2FFaLzFtX2WfSD9bjNju4nXNJhchxpc=.156616ad-6d29-48ff-aa56-35f1d3046a87@github.com>

On Tue, 13 Sep 2022 20:58:04 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/jar/JarInputStream.java line 36:
>> 
>>> 34:  * The {@code JarInputStream} class, which extends {@linkplain ZipInputStream},
>>> 35:  * is used to read the contents of a JAR file from an input stream.
>>> 36:  * It provides support for reading an optional {@linkplain JarFile#MANIFEST_NAME Manifest}
>> 
>> `Manifest` above is the same as the one below. If the one below is in fixed-width, so should be the one above.
>
> Could you please clarify what you are suggesting.  I am using the  `@linkplain` to provide a means to see the actual Manifest name.   I am happy to tweak, just need (perhaps an example) of what you would like

On lines 36 and 37, there are two "Manifest". The first uses `linkplain` so it's using normal font style, the 2nd uses `code` so it's fixed-width. I would like them to be the same. In fact, I would not use `linkplain` at all. I only use it when the text is not a Java identifier. For example, `{@linkplain SecurityManager the Security Manager}`. However in this PR, for all the places where you use it, the text is either a class name or a method name. I would just use `link`.

>> src/java.base/share/classes/java/util/jar/JarInputStream.java line 78:
>> 
>>> 76:  * <b>Note:</b>If a {@code JarEntry} is modified after the Jar file is signed,
>>> 77:  * a {@linkplain SecurityException} will be thrown when an attempt is made to
>>> 78:  * read the entry.
>> 
>> Not sure if the the `an attempt` word is precise. The exception is only thrown when the last byte is read.
>
> Are you suggesting change:
> 
> "...will be thrown when an attempt is made to read the entry."
> 
> to
> 
> "...will be thrown when the entry has been read."

Not sure. Maybe just `is read` is OK.

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

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

From jpai at openjdk.org  Wed Sep 14 01:07:45 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 14 Sep 2022 01:07:45 GMT
Subject: RFR: 8293499: Provide jmod --compress option [v6]
In-Reply-To: <7mps9AwYW2ZWKhN_3LAeh247LIBuxz9VURde2qxoDxU=.32f31014-5c78-45e0-a511-dd4fbef466de@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
 <7mps9AwYW2ZWKhN_3LAeh247LIBuxz9VURde2qxoDxU=.32f31014-5c78-45e0-a511-dd4fbef466de@github.com>
Message-ID: <60KItbh0qt6O8-2OhNYTWlpKoqhXpDejCe4wvpnJ3rw=.57711c28-f764-4281-b89e-146ed56df2eb@github.com>

On Tue, 13 Sep 2022 17:41:04 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I have been looking into `make clean-images images` performance, and realized jmod keeps compressing files with default compression level. Tuning that toward lighter compression levels improves build performance considerably, without a heavy loss in *.jmod sizes. 
>> 
>> This PR allows JMOD to select the compression level. Follow-ups would use this in the build system, see #10214.
>> 
>> The interesting asymmetry against `jlink` is: `jlink` provides `--compress` option that only takes `2` for "ZIP compression". (Separately, we could argue if it would be beneficial to extend `--compress` to `jlink` as well, so to select the compression level there too.)
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Mention the default level

Hello Aleksey, could you also please create a release note for this? You may already know how to do that, if not, the steps are noted here https://openjdk.org/guide/#release-notes

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

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

From lancea at openjdk.org  Wed Sep 14 01:42:20 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 14 Sep 2022 01:42:20 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v2]
In-Reply-To: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
Message-ID: <vQ83lkQKJst8HkinJKHFtSLJgt8FFbjlJzVSAx5U6xU=.89054257-0f7e-49a4-b708-8f208dba58bc@github.com>

> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
> 
> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
> 
> 
> Best,
> Lance

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

  changed linkplain to link and updated note wording

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10045/files
  - new: https://git.openjdk.org/jdk/pull/10045/files/36a74efa..cfdfa06b

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

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

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

From lancea at openjdk.org  Wed Sep 14 01:42:21 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 14 Sep 2022 01:42:21 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v2]
In-Reply-To: <F-9FaZUKRQ3W2FFaLzFtX2WfSD9bjNju4nXNJhchxpc=.156616ad-6d29-48ff-aa56-35f1d3046a87@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <OSPxo28V-dP4aT8kFvUadO_b2dP8oWoKPIt5PuxFVa0=.063c1c68-1bf6-4123-a487-42fea8ca6702@github.com>
 <5OfTyN2RiR2UpGRf4qMVaQuEWuTHko2L3elcwm3RHtU=.8360ba06-d606-4419-a839-33c09373dd63@github.com>
 <F-9FaZUKRQ3W2FFaLzFtX2WfSD9bjNju4nXNJhchxpc=.156616ad-6d29-48ff-aa56-35f1d3046a87@github.com>
Message-ID: <jW20Sc4H1eNGdGkdKTLSRAU6gCoNyW1LGprCyeQkoMo=.b67a678e-8ca0-4273-b4a4-15a55b200f1a@github.com>

On Wed, 14 Sep 2022 00:39:37 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> On lines 36 and 37, there are two "Manifest". The first uses `linkplain` so it's using normal font style, the 2nd uses `code` so it's fixed-width. I would like them to be the same. In fact, I would not use `linkplain` at all. I only use it when the text is not a Java identifier. For example, `{@linkplain SecurityManager the Security Manager}`. However in this PR, for all the places where you use it, the text is either a class name or a method name. I would just use `link`.

Ok, thank you switched to use `link` from `linkplain` per your suggestion

> Not sure. Maybe just `is read` is OK.

Updated  as "...will be thrown when the entry is read."

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

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

From weijun at openjdk.org  Wed Sep 14 02:25:42 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 14 Sep 2022 02:25:42 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v2]
In-Reply-To: <vQ83lkQKJst8HkinJKHFtSLJgt8FFbjlJzVSAx5U6xU=.89054257-0f7e-49a4-b708-8f208dba58bc@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <vQ83lkQKJst8HkinJKHFtSLJgt8FFbjlJzVSAx5U6xU=.89054257-0f7e-49a4-b708-8f208dba58bc@github.com>
Message-ID: <ixnb9DdDiqCKevDjG7-wPnjQ7e4a-hx2HQ9KwL9bph0=.cf96e0e2-65eb-41dc-9790-652d6216bc96@github.com>

On Wed, 14 Sep 2022 01:42:20 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
>> 
>> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
>> 
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed linkplain to link and updated note wording

Only tiny comments for the last paragraph.

That said, I have some questions on the other parts of this file:
1. In `getNextEntry`, the method spec says "If verification has been enabled, any invalid signature detected while positioning the stream for the next entry will result in an exception." What does this mean?
2. In `getManifest`, the method spec says "or null if none". Do we need to say "if not found"?

src/java.base/share/classes/java/util/jar/JarInputStream.java line 76:

> 74:  *  the signers.
> 75:  * <p>
> 76:  * <b>Note:</b>If a {@code JarEntry} is modified after the Jar file is signed,

Add a space before `If`. Capitalize `Jar`.

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

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

From duke at openjdk.org  Wed Sep 14 06:55:39 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Wed, 14 Sep 2022 06:55:39 GMT
Subject: RFR: 8293579:
 tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese
 Windows platform
In-Reply-To: <xVnuvImRWDHz9kwNg2tjUsvu9BySBFkeyiAQfy3D_K4=.6e1b5e5a-962a-4789-b26f-f96591a597d1@github.com>
References: <ROgI801Y_MVdXiCKPYVtwN9C5kDZTT3gdAo4pnCACbs=.618721ad-4cc5-4db7-a923-3bf740e35181@github.com>
 <xVnuvImRWDHz9kwNg2tjUsvu9BySBFkeyiAQfy3D_K4=.6e1b5e5a-962a-4789-b26f-f96591a597d1@github.com>
Message-ID: <rcmryIg2i7NKdXWMz0t7U5SJvP8vTZ6ep9f8Vh4oCAk=.06093648-ab8f-4adc-8995-0526cf9b7dc3@github.com>

On Fri, 9 Sep 2022 23:23:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> I just wonder if the fix is working as intended... Since JDK18, `file.encoding` is always `UTF-8` with JEP 400, so the switch expression seems to fall into the `default` clause?

You?re right. `file.encoding` may not be useful for this test.  I will think about other methods to check the encording. Do you have a good idea about that?

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

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

From duke at openjdk.org  Wed Sep 14 07:35:43 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 14 Sep 2022 07:35:43 GMT
Subject: RFR: 8292698: Improve performance of DataInputStream [v3]
In-Reply-To: <RKACHIHF07-2UJp9ByKLbdeFV5vCaqFpZ73-48REHMg=.bce10b60-7578-4441-9a43-627f0ee5c164@github.com>
References: <MXdBQj8qYqvvImT-MaBpf8mAm3b1tbNiPS93syrjfqg=.3ebdd952-f9d7-4ec9-9655-a63829828c67@github.com>
 <5v8lej62KNGYz6FTjQ6FyABbMfJxwLUSNCa6Z3DXZGQ=.1b35ef41-3b59-4b78-b035-6d1838eaebbd@github.com>
 <KIfIm02U3CPC53gSjSpi68Jk7BcoMgcmwHe3SDGVFSw=.0dc503c6-937b-4c7f-a05a-6ac7655f019e@github.com>
 <e4eIcbtpEZdZdn5KvOHjd3zrI8voMlr1aMuURWTJRN0=.7834a1a2-287a-4b3c-80bd-0918c7a04ae7@github.com>
 <RKACHIHF07-2UJp9ByKLbdeFV5vCaqFpZ73-48REHMg=.bce10b60-7578-4441-9a43-627f0ee5c164@github.com>
Message-ID: <wCpkSJJRg1I7ElawZVc5bxjXu0IL3wRGwXvScr6quoE=.e1a319f9-22c6-471f-a635-15fd8c236dc6@github.com>

On Tue, 13 Sep 2022 20:04:08 GMT, Bernd <duke at openjdk.org> wrote:

> Does that mean there is no explicit test for DataInputStream endianess

@ecki I think this is not strictly necessary as order of bytes is explicitly specified in JavaDoc of `DataInput` implemented by `DataInputStream`

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

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

From shade at openjdk.org  Wed Sep 14 08:04:41 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 14 Sep 2022 08:04:41 GMT
Subject: RFR: 8293499: Provide jmod --compress option [v6]
In-Reply-To: <60KItbh0qt6O8-2OhNYTWlpKoqhXpDejCe4wvpnJ3rw=.57711c28-f764-4281-b89e-146ed56df2eb@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
 <7mps9AwYW2ZWKhN_3LAeh247LIBuxz9VURde2qxoDxU=.32f31014-5c78-45e0-a511-dd4fbef466de@github.com>
 <60KItbh0qt6O8-2OhNYTWlpKoqhXpDejCe4wvpnJ3rw=.57711c28-f764-4281-b89e-146ed56df2eb@github.com>
Message-ID: <o3iFoVlTBqHm6A6pTCU2TT18QgotQgU7-rGPMzFYIgM=.56511139-9703-4531-91c2-c06f7958dcf6@github.com>

On Wed, 14 Sep 2022 01:05:35 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Aleksey, could you also please create a release note for this? You may already know how to do that, if not, the steps are noted here https://openjdk.org/guide/#release-notes

Yes, but later, once CSR and this PR integrates in its final form.

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

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

From jiefu at openjdk.org  Wed Sep 14 09:51:13 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Wed, 14 Sep 2022 09:51:13 GMT
Subject: RFR: 8293792: runtime/Dictionary/ProtectionDomainCacheTest.java fails
 with FileAlreadyExistsException: /tmp
Message-ID: <Vfaxg8rSBOwZrJi22f0JlNCCmgohix2_LXoAUb9G0Io=.796dccd4-683c-4026-ba63-b1631d484085@github.com>

Hi all,

runtime/Dictionary/ProtectionDomainCacheTest.java fails on Linux if `/tmp` is a symbolic link directory.
The root cause is that `JarUtils.createJarFile` [1] will throw `FileAlreadyExistsException` if `parent` is a symbolic directory.
So it seems better to test the existance of `parent` before creation.

Testing:
- tier1~3 on Linux/x64 in progress, seems fine until now

Thanks.
Best regards,
Jie


[1] https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/util/JarUtils.java#L72

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

Commit messages:
 - 8293792: runtime/Dictionary/ProtectionDomainCacheTest.java fails with FileAlreadyExistsException: /tmp

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

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

From jpai at openjdk.org  Wed Sep 14 10:12:38 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 14 Sep 2022 10:12:38 GMT
Subject: RFR: 8293792: runtime/Dictionary/ProtectionDomainCacheTest.java
 fails with FileAlreadyExistsException: /tmp
In-Reply-To: <Vfaxg8rSBOwZrJi22f0JlNCCmgohix2_LXoAUb9G0Io=.796dccd4-683c-4026-ba63-b1631d484085@github.com>
References: <Vfaxg8rSBOwZrJi22f0JlNCCmgohix2_LXoAUb9G0Io=.796dccd4-683c-4026-ba63-b1631d484085@github.com>
Message-ID: <rx4gDlJbZHbSn1DnA9qzU6zfQN_g295PBwAJsixOEyo=.de327373-0edf-4a14-9a87-393d01f4b8cd@github.com>

On Wed, 14 Sep 2022 09:42:37 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> runtime/Dictionary/ProtectionDomainCacheTest.java fails on Linux if `/tmp` is a symbolic link directory.
> The root cause is that `JarUtils.createJarFile` [1] will throw `FileAlreadyExistsException` if `parent` is a symbolic directory.
> So it seems better to test the existance of `parent` before creation.
> 
> Testing:
> - tier1~3 on Linux/x64 in progress, seems fine until now
> 
> Thanks.
> Best regards,
> Jie
> 
> 
> [1] https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/util/JarUtils.java#L72

Hello Jie,

> The root cause is that `JarUtils.createJarFile` [1] will throw `FileAlreadyExistsException` if `parent` is a symbolic directory. 

The JarUtils.createJarFile on that line uses:


// create the target directory
        Path parent = jarfile.getParent();
        if (parent != null) {
            Files.createDirectories(parent);
        }

>From what I can see in the javadoc of `java.nio.file.Files.createDirectories`, it doesn't state that it will throw this exception in case of symbolic links (it actually doesn't talk about symbolic links). As per the API:


     * @throws  FileAlreadyExistsException
     *          if {@code dir} exists but is not a directory <i>(optional specific
     *          exception)</i>

So if it indeed is throwing a `FileAlreadyExistsException` then perhaps this API implementation needs a look at? I am not on a Linux system right now to test this, but would you be able to get the exact OS version and other details including the output of "ls -lh /tmp" to see what it is linked to?

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

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

From lancea at openjdk.org  Wed Sep 14 10:31:41 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 14 Sep 2022 10:31:41 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v3]
In-Reply-To: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
Message-ID: <yWkL_3JSAHJhp4axSq6QbNSmH1Wi_NHjEA36nkxdGPg=.f58f8569-8693-446c-834a-5374d854d97c@github.com>

> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
> 
> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
> 
> 
> Best,
> Lance

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

  Address a couple of typos in  Note

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10045/files
  - new: https://git.openjdk.org/jdk/pull/10045/files/cfdfa06b..aff39596

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

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

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

From lancea at openjdk.org  Wed Sep 14 10:39:44 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 14 Sep 2022 10:39:44 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v2]
In-Reply-To: <ixnb9DdDiqCKevDjG7-wPnjQ7e4a-hx2HQ9KwL9bph0=.cf96e0e2-65eb-41dc-9790-652d6216bc96@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <vQ83lkQKJst8HkinJKHFtSLJgt8FFbjlJzVSAx5U6xU=.89054257-0f7e-49a4-b708-8f208dba58bc@github.com>
 <ixnb9DdDiqCKevDjG7-wPnjQ7e4a-hx2HQ9KwL9bph0=.cf96e0e2-65eb-41dc-9790-652d6216bc96@github.com>
Message-ID: <wRE4TkmrctF7Pv3Hy3KujKcFxa7C5uj4TddczyRb8Vg=.120353ca-2d1a-4eac-ab7d-1f9819282a6e@github.com>

On Wed, 14 Sep 2022 02:22:17 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Only tiny comments for the last paragraph.

Thank you Max, I addressed the above
> 
> That said, I have some questions on the other parts of this file:
> 
>     1. In `getNextEntry`, the method spec says "If verification has been enabled, any invalid signature detected while positioning the stream for the next entry will result in an exception." What does this mean?

I don't know the history of this comment in the spec and on a quick scan of the code, I am not sure I know either.  As our signed JAR expert, I will defer to you (and Alan) if we should remove this or leave  for another time to address(which I would prefer if we are not removing the verbiage).

> 
>     2. In `getManifest`, the method spec says "or null if none". Do we need to say "if not found"?

I think we are OK given the changes to the class description.

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

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

From jpai at openjdk.org  Wed Sep 14 10:50:21 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 14 Sep 2022 10:50:21 GMT
Subject: RFR: 8293792: runtime/Dictionary/ProtectionDomainCacheTest.java
 fails with FileAlreadyExistsException: /tmp
In-Reply-To: <Vfaxg8rSBOwZrJi22f0JlNCCmgohix2_LXoAUb9G0Io=.796dccd4-683c-4026-ba63-b1631d484085@github.com>
References: <Vfaxg8rSBOwZrJi22f0JlNCCmgohix2_LXoAUb9G0Io=.796dccd4-683c-4026-ba63-b1631d484085@github.com>
Message-ID: <U9sTPdjGaCvsM5-h9sa68p2kuyngnHbUaBlxsEyKQ9w=.ad22cf27-d2a1-4953-82cf-2a36f6c196cd@github.com>

On Wed, 14 Sep 2022 09:42:37 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> runtime/Dictionary/ProtectionDomainCacheTest.java fails on Linux if `/tmp` is a symbolic link directory.
> The root cause is that `JarUtils.createJarFile` [1] will throw `FileAlreadyExistsException` if `parent` is a symbolic directory.
> So it seems better to test the existance of `parent` before creation.
> 
> Testing:
> - tier1~3 on Linux/x64 in progress, seems fine until now
> 
> Thanks.
> Best regards,
> Jie
> 
> 
> [1] https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/util/JarUtils.java#L72

I could reproduce the issue with `Files.createDirectories` on a macos with a trivial program. It appears to be because of the use of `NOFOLLOW_LINKS` here https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/file/Files.java#L808. To me this appears to be something that either needs to be clarified in the the `Files.createDirectories` API or addressed/fixed there. I have asked for inputs on this from others who have more knowledge of this area.

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

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

From jiefu at openjdk.org  Wed Sep 14 10:53:38 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Wed, 14 Sep 2022 10:53:38 GMT
Subject: RFR: 8293792: runtime/Dictionary/ProtectionDomainCacheTest.java
 fails with FileAlreadyExistsException: /tmp
In-Reply-To: <U9sTPdjGaCvsM5-h9sa68p2kuyngnHbUaBlxsEyKQ9w=.ad22cf27-d2a1-4953-82cf-2a36f6c196cd@github.com>
References: <Vfaxg8rSBOwZrJi22f0JlNCCmgohix2_LXoAUb9G0Io=.796dccd4-683c-4026-ba63-b1631d484085@github.com>
 <U9sTPdjGaCvsM5-h9sa68p2kuyngnHbUaBlxsEyKQ9w=.ad22cf27-d2a1-4953-82cf-2a36f6c196cd@github.com>
Message-ID: <bJQDT7GHate-wjv-FiZkeKKxE6FCoM6q_NslvsYWVoU=.3ea7d3a5-2a90-4f61-94d4-ed281409675d@github.com>

On Wed, 14 Sep 2022 10:47:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> I could reproduce the issue with `Files.createDirectories` on a macos with a trivial program. It appears to be because of the use of `NOFOLLOW_LINKS` here https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/file/Files.java#L808. To me this appears to be something that either needs to be clarified in the the `Files.createDirectories` API or addressed/fixed there. I have asked for inputs on this from others who have more knowledge of this area.

Okay, thanks @jaikiran .

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

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

From asotona at openjdk.org  Wed Sep 14 11:10:15 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 14 Sep 2022 11:10:15 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v16]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <C_FYdM2XDe98ShJRXMXZq3m7kyt30HOhvleFxV8hK4E=.cbb2971e-a4de-4d51-af0a-5e6bc3628081@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> 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 20 commits:

 - Merge branch 'openjdk:master' into JDK-8244681
 - Merge branch 'openjdk:master' into JDK-8244681
 - re-enabled lossy conversions warnings for java.security.jgss, jdk.crypto.ec and jdk.internal.le
 - Merge branch 'openjdk:master' into JDK-8244681
 - Merge branch 'openjdk:master' into JDK-8244681
 - Merge branch 'openjdk:master' into JDK-8244681
 - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module
 - Added man-page line about lossy-conversion lint
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   re-enabled warnings for java.base, java.rmi and java.smartcardio
 - ... and 10 more: https://git.openjdk.org/jdk/compare/7f3250d7...4b78b1c5

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

Changes: https://git.openjdk.org/jdk/pull/8599/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=15
  Stats: 439 lines in 14 files changed: 437 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8599/head:pull/8599

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

From asotona at openjdk.org  Wed Sep 14 11:25:38 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 14 Sep 2022 11:25:38 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v16]
In-Reply-To: <C_FYdM2XDe98ShJRXMXZq3m7kyt30HOhvleFxV8hK4E=.cbb2971e-a4de-4d51-af0a-5e6bc3628081@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <C_FYdM2XDe98ShJRXMXZq3m7kyt30HOhvleFxV8hK4E=.cbb2971e-a4de-4d51-af0a-5e6bc3628081@github.com>
Message-ID: <7HAZTQI9U8tr8hrc3uRhkeAnZU4yjyjVDhTB2vXd00E=.69ffd410-c37e-45ec-b812-69bf4a2782ea@github.com>

On Wed, 14 Sep 2022 11:10:15 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
>> 
>> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
>> 
>> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
>> 
>> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
>> 
>> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
>> 
>> Thanks for your review,
>> 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 20 commits:
> 
>  - Merge branch 'openjdk:master' into JDK-8244681
>  - Merge branch 'openjdk:master' into JDK-8244681
>  - re-enabled lossy conversions warnings for java.security.jgss, jdk.crypto.ec and jdk.internal.le
>  - Merge branch 'openjdk:master' into JDK-8244681
>  - Merge branch 'openjdk:master' into JDK-8244681
>  - Merge branch 'openjdk:master' into JDK-8244681
>  - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module
>  - Added man-page line about lossy-conversion lint
>  - Merge branch 'openjdk:master' into JDK-8244681
>  - 8244681: Add a warning for possibly lossy conversion in compound assignments
>    re-enabled warnings for java.base, java.rmi and java.smartcardio
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/7f3250d7...4b78b1c5

Please review also linked Release Note issue.

Thanks,
Adam

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

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

From asotona at openjdk.org  Wed Sep 14 11:35:03 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 14 Sep 2022 11:35:03 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v17]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <k9Qdyal0bxpvBIXY0gfBLch7SG9PO7LjV5zNhQumCWQ=.34d833b1-fe0d-481b-bb40-59b154689842@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

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

  re-enabled lossy-conversions warnings for jdk.hotspot.agent

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8599/files
  - new: https://git.openjdk.org/jdk/pull/8599/files/4b78b1c5..0b93c284

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=15-16

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

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

From sgehwolf at openjdk.org  Wed Sep 14 12:34:30 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 14 Sep 2022 12:34:30 GMT
Subject: RFR: 8293540: [Metrics] Incorrectly detected ressource limits with
 additional cgroup fs mounts
Message-ID: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>

Similar issue to the hotspot change discussed in https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation may get the resource limits wrong if there are additional cgroup fs mounts. Apparently that's more common than one might think. I've reproduced this with these existing tests on cg v2:


test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java
test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java
test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java 


I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` and amended `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which unconditionally fails (irrespective of cgroup version in use). The fix is fairly straight forward and is an extension which we already do for the `cpuset` controller: Allow duplicates, and if there are any prefer those mounted at `/sys/fs/cgroup`.

Testing:
- [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the product fix)
- [x] added tests fail before, pass after the product fix.
- [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still pass. 
- [ ] GHA still running.

Please review! Many thanks in advance.

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

Depends on: https://git.openjdk.org/jdk/pull/10193

Commit messages:
 - 8293540: [Metrics] Potentially incorrectly detected ressource limits with additional cgroup fs mounts

Changes: https://git.openjdk.org/jdk/pull/10248/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10248&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293540
  Stats: 175 lines in 6 files changed: 137 ins; 23 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/10248.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10248/head:pull/10248

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

From alanb at openjdk.org  Wed Sep 14 12:45:30 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Sep 2022 12:45:30 GMT
Subject: RFR: 8278165: Clarify that ZipInputStream does not access the CEN
 fields for a ZipEntry [v4]
In-Reply-To: <qF19Luc2f0untbmqkIPWamXaO3huSVk61MlvRZZBevU=.3951e9c9-0fcd-4220-b9e0-c5c0a03e0eea@github.com>
References: <5xFWPl4un_Ymri2We2utzNAj9UuqMqzIzF8yex4thFg=.c3d990c5-8765-452b-9775-08071d0576b5@github.com>
 <qF19Luc2f0untbmqkIPWamXaO3huSVk61MlvRZZBevU=.3951e9c9-0fcd-4220-b9e0-c5c0a03e0eea@github.com>
Message-ID: <3MFNvwoEkFmMSQo3GXfQcIkMCBV_8Lh_1oknxnch5GM=.ba54157d-cbb0-49bc-b9c0-47788ab2199b@github.com>

On Tue, 13 Sep 2022 21:13:15 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Hi,
>> 
>> Please review this update to the ZipInputStream class description to clarify that ZipInputStream walks sequentially through each Zip Entry contained within the Zip File.  As a result, the CEN header for the Zip file entries are not read resulting in ZipInputStream not having access to information that is stored within the CEN Header fields such the as the external file attributes which can be used to store optional data such as Posix Permissions.
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove stray comma after ZipFile

src/java.base/share/classes/java/util/zip/ZipInputStream.java line 55:

> 53:  *    {@snippet :
> 54:  *      try (FileInputStream fis = new FileInputStream(jar.toFile());
> 55:  *           ZipInputStream zis = new ZipInputStream(fis)) {

One other comment on the snippet is that the type of "jar" may not be obvious to readers. I think you'll need Path jar = ...  in which case changing it Files.newInputStream(jar) might be simpler.

src/java.base/share/classes/java/util/zip/ZipInputStream.java line 68:

> 66:  * will not have access to its metadata such as the external file attributes.
> 67:  * {@linkplain ZipFile} may be used when the information stored within
> 68:  * the CEN header is required.

I wonder if this paragraph should be an apiNote. It's not wrong as is but it feels like a note to remind developers that this is an "input stream" for iterating through the ZIP entries. The external files attributes are in the CEN at the end of the ZIP file so this is why they aren't available.

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

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

From alanb at openjdk.org  Wed Sep 14 13:01:49 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Sep 2022 13:01:49 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v3]
In-Reply-To: <yWkL_3JSAHJhp4axSq6QbNSmH1Wi_NHjEA36nkxdGPg=.f58f8569-8693-446c-834a-5374d854d97c@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <yWkL_3JSAHJhp4axSq6QbNSmH1Wi_NHjEA36nkxdGPg=.f58f8569-8693-446c-834a-5374d854d97c@github.com>
Message-ID: <8l5jHWgf0uRlQ73dADvKRAn1WknyANt08yKRYNg5TZU=.58a7f7d7-bbb4-43dc-8c0a-c454623ac44e@github.com>

On Wed, 14 Sep 2022 10:31:41 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
>> 
>> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
>> 
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address a couple of typos in  Note

src/java.base/share/classes/java/util/jar/JarInputStream.java line 44:

> 42:  * The {@link #getManifest} method will return the {@code Manifest} when it is
> 43:  * the first entry in the stream or {@code META-INF/} is the first entry and
> 44:  * the {@code Manifest} is the second entry within the stream. When the

I think you can insert a comma after "when it is the first entry in the stream"? I think that would make it a bit clearer that there are two cases.

Also I'm wondering if the paragraph should be split into two, meaning "When the Manifest ..."  can be the start of a new paragraph. The reason is that the text is trying to explain two things, the first is that the manifest must be at the start of the JAR file, the second is that the ordering that methods are invoked will influence how other methods behave.

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

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

From alanb at openjdk.org  Wed Sep 14 13:57:34 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Sep 2022 13:57:34 GMT
Subject: RFR: 8293792: runtime/Dictionary/ProtectionDomainCacheTest.java
 fails with FileAlreadyExistsException: /tmp
In-Reply-To: <bJQDT7GHate-wjv-FiZkeKKxE6FCoM6q_NslvsYWVoU=.3ea7d3a5-2a90-4f61-94d4-ed281409675d@github.com>
References: <Vfaxg8rSBOwZrJi22f0JlNCCmgohix2_LXoAUb9G0Io=.796dccd4-683c-4026-ba63-b1631d484085@github.com>
 <U9sTPdjGaCvsM5-h9sa68p2kuyngnHbUaBlxsEyKQ9w=.ad22cf27-d2a1-4953-82cf-2a36f6c196cd@github.com>
 <bJQDT7GHate-wjv-FiZkeKKxE6FCoM6q_NslvsYWVoU=.3ea7d3a5-2a90-4f61-94d4-ed281409675d@github.com>
Message-ID: <LCNKczBZgMQYP-Ui8q9CB9Di6RZxjkh3qq7izywa0PI=.22a59de2-02cb-4cdc-b9e1-4f42fbd9839f@github.com>

On Wed, 14 Sep 2022 10:51:21 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> I could reproduce the issue with `Files.createDirectories` on a macos with a trivial program. It appears to be because of the use of `NOFOLLOW_LINKS` here https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/file/Files.java#L808. To me this appears to be something that either needs to be clarified in the the `Files.createDirectories` API or addressed/fixed there. I have asked for inputs on this from others who have more knowledge of this area.

The specification is that symbolic links are followed by default, with a few exceptions (like delete and move) where it would be wrong to follow links. Files.createDirectories was originally intended to be like mkdir -p. We'd need to check the history but I suspect it is a long standing bug that createAndCheckIsDirectory opts out of following links.

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

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

From alanb at openjdk.org  Wed Sep 14 14:09:52 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Sep 2022 14:09:52 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v2]
In-Reply-To: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
Message-ID: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>

> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
> 
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
> 
> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
> 
> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.

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:

 - Merge
 - Remove stopThread permission from RuntimePermission table, exclude jshell tests
 - Deprecate for removal
 - Next iteration, update dates in headers
 - Merge
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10230/files
  - new: https://git.openjdk.org/jdk/pull/10230/files/380e4043..86424b65

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

  Stats: 2990 lines in 108 files changed: 2115 ins; 353 del; 522 mod
  Patch: https://git.openjdk.org/jdk/pull/10230.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10230/head:pull/10230

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

From alanb at openjdk.org  Wed Sep 14 14:09:53 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Sep 2022 14:09:53 GMT
Subject: RFR: 8289610: Degrade Thread.stop
In-Reply-To: <GUqUvGAgZaq3V6d7zLstLPcnDXJfC3Tn9nJ7FKCP4Is=.5d7a18f1-55fb-45f6-81e3-9a1372832d38@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <GUqUvGAgZaq3V6d7zLstLPcnDXJfC3Tn9nJ7FKCP4Is=.5d7a18f1-55fb-45f6-81e3-9a1372832d38@github.com>
Message-ID: <Y68P0aWEnsCoTeHVCyMDGD0YSkvUA6Z2Szi8wKNqsZw=.bcff87c3-29b9-4c42-b84a-200d9e6efd5f@github.com>

On Tue, 13 Sep 2022 23:51:03 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> The change looks good. There are other tests that reference `ThreadDeath` for example `test/lib/jdk/test/lib/process/ProcessTools.java`, `test/jdk/java/util/Timer/KillThread.java` , `test/jdk/java/net/httpclient/reactivestreams-tck/org/reactivestreams/tck/flow/support/NonFatal.java` etc. Is it expected to update them in a follow-on issue?

I've been trying to keep the test cleanup separate if possible, only because the changes become unwieldy. Aside from jshell, the tests that used Thread.stop have already been changed or removed in advance of this PR. The tests that have catch blocks for ThreadDeath will work as before as there is no Thread.stop. There are one or two tests that will need special attention - the reactivestreams-tck tests that you listed is 3rd party code and we might decide to do nothing there.

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

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

From alanb at openjdk.org  Wed Sep 14 14:09:55 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Sep 2022 14:09:55 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v2]
In-Reply-To: <aJKDQu_rOWDcc8-F2LXmygH9d-QBKSd5NOEAlUVI7lQ=.6235cad5-1193-4bc6-89ff-edbf75be21db@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <aJKDQu_rOWDcc8-F2LXmygH9d-QBKSd5NOEAlUVI7lQ=.6235cad5-1193-4bc6-89ff-edbf75be21db@github.com>
Message-ID: <Cam8C9hPg7hx4THYlkkTjowCfvLTS_lDEFG5LdIeEHI=.62bf0954-d2fc-4991-8152-305329f2b38a@github.com>

On Tue, 13 Sep 2022 14:03:52 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> fold with previous line.

Done.

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

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

From jpai at openjdk.org  Wed Sep 14 14:24:42 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 14 Sep 2022 14:24:42 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v2]
In-Reply-To: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
Message-ID: <mpzUIufncDST2C3xklaTg_IzMRpfF3BRD8VHQs2W0E4=.c41ae0b2-450c-4345-a551-3b2ca3c37b3e@github.com>

On Wed, 14 Sep 2022 14:09:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
>> 
>> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
>> 
>> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
>> 
>> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.
>
> 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:
> 
>  - Merge
>  - Remove stopThread permission from RuntimePermission table, exclude jshell tests
>  - Deprecate for removal
>  - Next iteration, update dates in headers
>  - Merge
>  - Initial commit

The changes to the `core-libs` look fine to me. There are some test security policy files (for example `IsKeepingAlive.policy`) and the `DynamicPolicy` which use the `stopThread` `RuntimePermission` which no longer exists. Should those policy files and artifacts be updated to remove reference to this permission too?

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

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

From jpai at openjdk.org  Wed Sep 14 14:29:11 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 14 Sep 2022 14:29:11 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v2]
In-Reply-To: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
Message-ID: <fPWT9f28uph0lYEBP7BTDEnQLASgOa6ZRln7P0ITZd4=.854a1da6-21e1-4467-97a0-c9b17fefaacc@github.com>

On Wed, 14 Sep 2022 14:09:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
>> 
>> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
>> 
>> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
>> 
>> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.
>
> 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:
> 
>  - Merge
>  - Remove stopThread permission from RuntimePermission table, exclude jshell tests
>  - Deprecate for removal
>  - Next iteration, update dates in headers
>  - Merge
>  - Initial commit

src/java.logging/share/classes/java/util/logging/LogManager.java line 2670:

> 2668:                 c.run();
> 2669:             } catch (ThreadDeath death) {
> 2670:                 throw death;

In theory, before this change, some (odd/weird) application code which was registered as a `listener` could throw a `ThreadDeath` and we would then abort any other `listeners` from being run. With this change that would no longer be that case. However, I think that is fine, since the API doc of `LogManager.addConfigurationListener()` already states:


* It is recommended that listeners do not throw errors or exceptions.
*
* If a listener terminates with an uncaught error or exception then
* the first exception will be propagated to the caller of
* {@link #readConfiguration()} (or {@link #readConfiguration(java.io.InputStream)})
* after all listeners have been invoked.

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

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

From alanb at openjdk.org  Wed Sep 14 14:38:41 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Sep 2022 14:38:41 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v2]
In-Reply-To: <mpzUIufncDST2C3xklaTg_IzMRpfF3BRD8VHQs2W0E4=.c41ae0b2-450c-4345-a551-3b2ca3c37b3e@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
 <mpzUIufncDST2C3xklaTg_IzMRpfF3BRD8VHQs2W0E4=.c41ae0b2-450c-4345-a551-3b2ca3c37b3e@github.com>
Message-ID: <V5ZUDTNRCBqbJFWqfiDZthxL-c6rdpf9YvNrcKa3OJs=.ac4dbf11-de65-4981-b0bd-719a969cb30e@github.com>

On Wed, 14 Sep 2022 14:21:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> The changes to the `core-libs` look fine to me. There are some test security policy files (for example `IsKeepingAlive.policy`) and the `DynamicPolicy` which use the `stopThread` `RuntimePermission` which no longer exists. Should those policy files and artifacts be updated to remove reference to this permission too?

Mandy asked the test cleanup too. I'm hoping that we will do the test cleanup separately, only to avoid the changes being too unwieldly.

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

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

From jpai at openjdk.org  Wed Sep 14 15:26:41 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 14 Sep 2022 15:26:41 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v2]
In-Reply-To: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
Message-ID: <S2NGdOvBFqHCU3kZ71lO-pI_be3rgiAjWyLymGkl7IQ=.f5c55647-8862-4b3f-a1cc-c9bcb74ffaf9@github.com>

On Wed, 14 Sep 2022 14:09:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
>> 
>> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
>> 
>> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
>> 
>> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.
>
> 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:
> 
>  - Merge
>  - Remove stopThread permission from RuntimePermission table, exclude jshell tests
>  - Deprecate for removal
>  - Next iteration, update dates in headers
>  - Merge
>  - Initial commit

Marked as reviewed by jpai (Reviewer).

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

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

From jpai at openjdk.org  Wed Sep 14 15:26:42 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 14 Sep 2022 15:26:42 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v2]
In-Reply-To: <V5ZUDTNRCBqbJFWqfiDZthxL-c6rdpf9YvNrcKa3OJs=.ac4dbf11-de65-4981-b0bd-719a969cb30e@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
 <mpzUIufncDST2C3xklaTg_IzMRpfF3BRD8VHQs2W0E4=.c41ae0b2-450c-4345-a551-3b2ca3c37b3e@github.com>
 <V5ZUDTNRCBqbJFWqfiDZthxL-c6rdpf9YvNrcKa3OJs=.ac4dbf11-de65-4981-b0bd-719a969cb30e@github.com>
Message-ID: <zqC1A9QUMyPBsucqh-ACPnCgu9NGXHuYEoIQVGocNDo=.aabd8baa-d81e-4c26-acd3-fad2f587404b@github.com>

On Wed, 14 Sep 2022 14:35:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > The changes to the `core-libs` look fine to me. There are some test security policy files (for example `IsKeepingAlive.policy`) and the `DynamicPolicy` which use the `stopThread` `RuntimePermission` which no longer exists. Should those policy files and artifacts be updated to remove reference to this permission too?
> 
> Mandy asked the test cleanup too. I'm hoping that we will do the test cleanup separately, only to avoid the changes being too unwieldly.

Sorry, I missed your previous response to that similar question. Doing those changes separately sounds fine to me.

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

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

From rriggs at openjdk.org  Wed Sep 14 15:33:45 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 14 Sep 2022 15:33:45 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v2]
In-Reply-To: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
Message-ID: <YV7yQcn2WBeqFXs0VJYYUaE0UQxX-o6155kHHgocV-4=.cfa6c0b8-477d-4db2-83b2-11313fce5e5d@github.com>

On Wed, 14 Sep 2022 14:09:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
>> 
>> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
>> 
>> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
>> 
>> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.
>
> 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:
> 
>  - Merge
>  - Remove stopThread permission from RuntimePermission table, exclude jshell tests
>  - Deprecate for removal
>  - Next iteration, update dates in headers
>  - Merge
>  - Initial commit

LGTM

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

Marked as reviewed by rriggs (Reviewer).

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

From weijun at openjdk.org  Wed Sep 14 15:56:07 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 14 Sep 2022 15:56:07 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v3]
In-Reply-To: <yWkL_3JSAHJhp4axSq6QbNSmH1Wi_NHjEA36nkxdGPg=.f58f8569-8693-446c-834a-5374d854d97c@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <yWkL_3JSAHJhp4axSq6QbNSmH1Wi_NHjEA36nkxdGPg=.f58f8569-8693-446c-834a-5374d854d97c@github.com>
Message-ID: <0bf2paYYal_MCs014sGdWjm0ElohULY16JGqJIzyM6I=.5958f587-f228-49f5-9daf-2b31e7aa697c@github.com>

On Wed, 14 Sep 2022 10:31:41 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
>> 
>> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
>> 
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address a couple of typos in  Note

I have no more comment.

My understanding is that `getNextEntry` does not throw a `SecurityException` since it should not read anything. If the signature does not match then a `SecurityException` should be thrown when reading a signature-related file. If a normal entry is modified it should be thrown when reading that entry.

This is a quite big change. I suggest we do not touch it this time.

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

Marked as reviewed by weijun (Reviewer).

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

From mchung at openjdk.org  Wed Sep 14 15:59:53 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 14 Sep 2022 15:59:53 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v2]
In-Reply-To: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
Message-ID: <Neq3XrV6wPCdnoNLwVcgAhgaK2Ei3hJIOZ0JARq9BNc=.1996b1f5-4220-433e-b6d2-24dd79c13200@github.com>

On Wed, 14 Sep 2022 14:09:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
>> 
>> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
>> 
>> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
>> 
>> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.
>
> 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:
> 
>  - Merge
>  - Remove stopThread permission from RuntimePermission table, exclude jshell tests
>  - Deprecate for removal
>  - Next iteration, update dates in headers
>  - Merge
>  - Initial commit

Marked as reviewed by mchung (Reviewer).

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

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

From andrew at openjdk.org  Wed Sep 14 16:09:50 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 14 Sep 2022 16:09:50 GMT
Subject: RFR: 8292579: (tz) Update Timezone Data to 2022c
In-Reply-To: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
References: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
Message-ID: <VPDj8Cj9iuKQ0rtWRUGzCJaJsSqM92uEwcbDsouKNy0=.e0767a00-c3f8-44dc-874c-6649ed3ad136@github.com>

On Thu, 25 Aug 2022 02:26:19 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  The PR adopts the official tzdata2022c as it is.
> It means the pre-1970s data merged in tzdata2022c doesn't exist.
> All tests have been passed with no failures.

Should this not have included an update to the resource bundles - as with https://github.com/openjdk/jdk/commit/ad3be04d2ac84836e393d696ff03ddfe72779094 - so that `Europe/Kyiv` is recognised?

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

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

From andrew at openjdk.org  Wed Sep 14 16:14:47 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 14 Sep 2022 16:14:47 GMT
Subject: RFR: 8292579: (tz) Update Timezone Data to 2022c
In-Reply-To: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
References: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
Message-ID: <suc7iuNWnUL_cV36NJ8p4nGQyiq2OnEQz176x_K2W4I=.931a8930-9c9b-4e6b-a202-62d2cc7e0149@github.com>

On Thu, 25 Aug 2022 02:26:19 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  The PR adopts the official tzdata2022c as it is.
> It means the pre-1970s data merged in tzdata2022c doesn't exist.
> All tests have been passed with no failures.

That is something we've patched locally e.g. https://src.fedoraproject.org/rpms/java-11-openjdk/pull-request/163 and we have a test which fails without and passes with, though it does use `sun.util.resources` directly.

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

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

From lancea at openjdk.org  Wed Sep 14 16:43:43 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 14 Sep 2022 16:43:43 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v4]
In-Reply-To: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
Message-ID: <bHrBh3zv6i5YDa0Hhgs_QCAql8IOnmE4GUZrAQ_ResU=.bb9a98fe-6f13-42cf-a410-d1c3bee62b6a@github.com>

> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
> 
> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
> 
> 
> Best,
> Lance

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

  Address latest input regarding wording

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10045/files
  - new: https://git.openjdk.org/jdk/pull/10045/files/aff39596..10ddfd31

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10045&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10045&range=02-03

  Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10045.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10045/head:pull/10045

PR: https://git.openjdk.org/jdk/pull/10045

From lancea at openjdk.org  Wed Sep 14 16:43:44 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 14 Sep 2022 16:43:44 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v3]
In-Reply-To: <0bf2paYYal_MCs014sGdWjm0ElohULY16JGqJIzyM6I=.5958f587-f228-49f5-9daf-2b31e7aa697c@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <yWkL_3JSAHJhp4axSq6QbNSmH1Wi_NHjEA36nkxdGPg=.f58f8569-8693-446c-834a-5374d854d97c@github.com>
 <0bf2paYYal_MCs014sGdWjm0ElohULY16JGqJIzyM6I=.5958f587-f228-49f5-9daf-2b31e7aa697c@github.com>
Message-ID: <_WstsrA3TqUNwvBCebh2rcW4GY0agCQxIxIlpBoYaJA=.63d8a273-04df-4bc7-8226-63d1109b03c0@github.com>

On Wed, 14 Sep 2022 15:53:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> I have no more comment.

Thank you Max for your time and input

-------------

PR: https://git.openjdk.org/jdk/pull/10045

From lancea at openjdk.org  Wed Sep 14 16:43:46 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 14 Sep 2022 16:43:46 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v3]
In-Reply-To: <8l5jHWgf0uRlQ73dADvKRAn1WknyANt08yKRYNg5TZU=.58a7f7d7-bbb4-43dc-8c0a-c454623ac44e@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <yWkL_3JSAHJhp4axSq6QbNSmH1Wi_NHjEA36nkxdGPg=.f58f8569-8693-446c-834a-5374d854d97c@github.com>
 <8l5jHWgf0uRlQ73dADvKRAn1WknyANt08yKRYNg5TZU=.58a7f7d7-bbb4-43dc-8c0a-c454623ac44e@github.com>
Message-ID: <V36LHH0-XBZFdlbPbcsW_oIpeVZmh4QEF4hGnaLu3Dk=.bb90a1b1-a3b2-43e4-857a-f61afe40dc57@github.com>

On Wed, 14 Sep 2022 12:53:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think you can insert a comma after "when it is the first entry in the stream"? I think that would make it a bit clearer that there are two cases.

Done
> 
> Also I'm wondering if the paragraph should be split into two, meaning "When the Manifest ..." can be the start of a new paragraph. The reason is that the text is trying to explain two things, the first is that the manifest must be at the start of the JAR file, the second is that the ordering that methods are invoked will influence how other methods behave.

Moved to a new paragraph per your suggestion

-------------

PR: https://git.openjdk.org/jdk/pull/10045

From lancea at openjdk.org  Wed Sep 14 16:54:56 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 14 Sep 2022 16:54:56 GMT
Subject: RFR: 8278165: Clarify that ZipInputStream does not access the CEN
 fields for a ZipEntry [v5]
In-Reply-To: <5xFWPl4un_Ymri2We2utzNAj9UuqMqzIzF8yex4thFg=.c3d990c5-8765-452b-9775-08071d0576b5@github.com>
References: <5xFWPl4un_Ymri2We2utzNAj9UuqMqzIzF8yex4thFg=.c3d990c5-8765-452b-9775-08071d0576b5@github.com>
Message-ID: <CCMk8nRLiim0DZm094E1WFWUjuqaL3Zm_8Hq8o63hoI=.c3ee4280-90f4-462e-93d1-091fdca0ea77@github.com>

> Hi,
> 
> Please review this update to the ZipInputStream class description to clarify that ZipInputStream walks sequentially through each Zip Entry contained within the Zip File.  As a result, the CEN header for the Zip file entries are not read resulting in ZipInputStream not having access to information that is stored within the CEN Header fields such the as the external file attributes which can be used to store optional data such as Posix Permissions.

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Minor update to snippet and made the last paragraph an apiNote

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10102/files
  - new: https://git.openjdk.org/jdk/pull/10102/files/b98c6e1e..e15660e3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10102&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10102&range=03-04

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10102.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10102/head:pull/10102

PR: https://git.openjdk.org/jdk/pull/10102

From lancea at openjdk.org  Wed Sep 14 16:54:57 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 14 Sep 2022 16:54:57 GMT
Subject: RFR: 8278165: Clarify that ZipInputStream does not access the CEN
 fields for a ZipEntry [v4]
In-Reply-To: <3MFNvwoEkFmMSQo3GXfQcIkMCBV_8Lh_1oknxnch5GM=.ba54157d-cbb0-49bc-b9c0-47788ab2199b@github.com>
References: <5xFWPl4un_Ymri2We2utzNAj9UuqMqzIzF8yex4thFg=.c3d990c5-8765-452b-9775-08071d0576b5@github.com>
 <qF19Luc2f0untbmqkIPWamXaO3huSVk61MlvRZZBevU=.3951e9c9-0fcd-4220-b9e0-c5c0a03e0eea@github.com>
 <3MFNvwoEkFmMSQo3GXfQcIkMCBV_8Lh_1oknxnch5GM=.ba54157d-cbb0-49bc-b9c0-47788ab2199b@github.com>
Message-ID: <Ef2rOPWimYpdPEYDGPP8Zc-OAe7bg3WeQcWWKNpDynY=.96220097-025b-40dc-8ce8-9e8fea59f5e3@github.com>

On Wed, 14 Sep 2022 11:57:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> One other comment on the snippet is that the type of "jar" may not be obvious to readers. I think you'll need Path jar = ... in which case changing it Files.newInputStream(jar) might be simpler.

Updated per your suggestion

> I wonder if this paragraph should be an apiNote. It's not wrong as is but it feels like a note to remind developers that this is an "input stream" for iterating through the ZIP entries. The external files attributes are in the CEN at the end of the ZIP file so this is why they aren't available.

converted to an apiNote

-------------

PR: https://git.openjdk.org/jdk/pull/10102

From coffeys at openjdk.org  Wed Sep 14 17:13:11 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 14 Sep 2022 17:13:11 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event
Message-ID: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>

Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls.

-------------

Commit messages:
 - Track successful getInstance calls only
 - Merge branch 'master' into 8254711-jfr-jca
 - Refactor and use of static Event on
 - Merge branch 'master' into 8254711-jfr-jca
 - new test
 - Event iteration
 - Merge branch 'master' into 8254711-jfr-jca
 - JFR edits

Changes: https://git.openjdk.org/jdk/pull/9657/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9657&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8254711
  Stats: 305 lines in 8 files changed: 269 ins; 27 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/9657.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9657/head:pull/9657

PR: https://git.openjdk.org/jdk/pull/9657

From coffeys at openjdk.org  Wed Sep 14 17:13:11 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 14 Sep 2022 17:13:11 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event
In-Reply-To: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
Message-ID: <QJlDzViaiirf-ANl-7Vw_l1WlRdArsYhIRuVlMMzNr4=.b1eb8913-4ac0-40ee-9eb0-54a4aafbd1b3@github.com>

On Wed, 27 Jul 2022 13:14:39 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls.

Reviewer request: @seanjmullan @egahlin

-------------

PR: https://git.openjdk.org/jdk/pull/9657

From prr at openjdk.org  Wed Sep 14 17:53:55 2022
From: prr at openjdk.org (Phil Race)
Date: Wed, 14 Sep 2022 17:53:55 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v2]
In-Reply-To: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
Message-ID: <PD97EHa4KSPIKDKxaS9ZqxwonA3e5DPhTiaTN90Wy9Y=.6d8d9d01-f294-45d4-a817-063cf1b8d40e@github.com>

On Wed, 14 Sep 2022 14:09:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
>> 
>> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
>> 
>> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
>> 
>> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.
>
> 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:
> 
>  - Merge
>  - Remove stopThread permission from RuntimePermission table, exclude jshell tests
>  - Deprecate for removal
>  - Next iteration, update dates in headers
>  - Merge
>  - Initial commit

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10230

From svkamath at openjdk.org  Wed Sep 14 18:27:49 2022
From: svkamath at openjdk.org (Smita Kamath)
Date: Wed, 14 Sep 2022 18:27:49 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v6]
In-Reply-To: <SkGmDPFWhQZGaglHmdt3p72B17yxGc8flLEei7F_H3s=.a6e53ae9-aac9-406a-8b7e-6886572ae3f2@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <0im5_Of4jj3BHOipBt4VkAuX3327nQbKtW_sYnzcVUU=.0153ab0a-aa0c-4c12-a150-407a85cf8d0c@github.com>
 <jp3g1e-Vjzar_GlVAN7CqFoj-EpNAcKwiX-C_HXDEhY=.eb36da15-a147-4730-b0af-da5825b58bb9@github.com>
 <SkGmDPFWhQZGaglHmdt3p72B17yxGc8flLEei7F_H3s=.a6e53ae9-aac9-406a-8b7e-6886572ae3f2@github.com>
Message-ID: <wQO6W4J9wRUlAFHOnhK7wsdI7uzXDzLtohVvTOQ66wc=.9101c32f-1b54-4d5c-9a25-0adc525aaa40@github.com>

On Thu, 1 Sep 2022 21:17:30 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Yes; I removed support for --release 7 in JDK 20 early today.
>> 
>> 
>> On Thu, Sep 1, 2022 at 1:36 PM Paul Sandoz ***@***.***> wrote:
>> 
>>> Likely requires a merge with master.
>>>
>>> ?
>>> Reply to this email directly, view it on GitHub
>>> <https://github.com/openjdk/jdk/pull/9781#issuecomment-1234753280>, or
>>> unsubscribe
>>> <https://github.com/notifications/unsubscribe-auth/AHPLHYCD2RZXG427WU2322DV4EHT3ANCNFSM55WURKVA>
>>> .
>>> You are receiving this because you were mentioned.Message ID:
>>> ***@***.***>
>>>
>
>> Yes; I removed support for --release 7 in JDK 20 early today.
> 
> Yes, I missed that my merge of master did not apply because I modified tests, Joe fixed, to test his changes.
> 
> Resubmitting testing after resolving the issue. Still missed parentheses issue should be fixed.

@vnkozlov Hi Vladimir, does the patch look good to you? Please do let me know. Thank you.

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From naoto at openjdk.org  Wed Sep 14 19:30:48 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 14 Sep 2022 19:30:48 GMT
Subject: RFR: 8292579: (tz) Update Timezone Data to 2022c
In-Reply-To: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
References: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
Message-ID: <cZEzP7KDxtNO2fHSNYtsa1voeZpmOySWEETANI33xgQ=.9d727895-bd3b-4827-b3c1-c71cf31ddc29@github.com>

On Thu, 25 Aug 2022 02:26:19 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  The PR adopts the official tzdata2022c as it is.
> It means the pre-1970s data merged in tzdata2022c doesn't exist.
> All tests have been passed with no failures.

Names are retrieved through aliases, so I think there is no need to add extra names in the COMPAT resource bundles.

% ./build/macosx-aarch64/jdk/bin/jshell -R-Djava.locale.providers=COMPAT JAVASE
|  Welcome to JShell -- Version 20-internal
|  For an introduction type: /help intro

jshell> ZoneId.of("Europe/Kyiv").getDisplayName(TextStyle.FULL, Locale.US)
$178 ==> "Eastern European Time"

jshell> ZoneId.of("Europe/Kiev").getDisplayName(TextStyle.FULL, Locale.US)
$179 ==> "Eastern European Time"

jshell> ZoneId.of("Europe/Kyiv").getDisplayName(TextStyle.FULL, Locale.JAPAN)
$180 ==> "?????????"

jshell> ZoneId.of("Europe/Kiev").getDisplayName(TextStyle.FULL, Locale.JAPAN)
$181 ==> "?????????"

CLDR incorporated the Kyiv/Kiev aliasing in their upcoming version 42, JDK does not have the alias yet, thus:

%  ./build/macosx-aarch64/jdk/bin/jshell JAVASE                                 
|  Welcome to JShell -- Version 20-internal
|  For an introduction type: /help intro

jshell> ZoneId.of("Europe/Kyiv").getDisplayName(TextStyle.FULL, Locale.US)
$178 ==> "Kyiv Time"

jshell> ZoneId.of("Europe/Kiev").getDisplayName(TextStyle.FULL, Locale.US)
$179 ==> "Eastern European Time"

jshell> ZoneId.of("Europe/Kyiv").getDisplayName(TextStyle.FULL, Locale.JAPAN)
$180 ==> "Kyiv??"

jshell> ZoneId.of("Europe/Kiev").getDisplayName(TextStyle.FULL, Locale.JAPAN)
$181 ==> "????????"

jshell> ZoneId.of("Europe/Kiev").getDisplayName(TextStyle.FULL, Locale.JAPAN)

This will be fixed once we incorporate CLDR v42 into JDK repository. Since we don't backport CLDR, TZ backports should separately cherry-pick the changes in timezone.xml, such as:

diff --git a/make/data/cldr/common/bcp47/timezone.xml b/make/data/cldr/common/bcp47/timezone.xml
index f0812776d5d..ddbccff077c 100644
--- a/make/data/cldr/common/bcp47/timezone.xml
+++ b/make/data/cldr/common/bcp47/timezone.xml
@@ -394,7 +394,7 @@ For terms of use, see http://www.unicode.org/copyright.html
             <type name="tvfun" description="Funafuti, Tuvalu" alias="Pacific/Funafuti"/>
             <type name="twtpe" description="Taipei, Taiwan" alias="Asia/Taipei ROC"/>
             <type name="tzdar" description="Dar es Salaam, Tanzania" alias="Africa/Dar_es_Salaam"/>
-            <type name="uaiev" description="Kyiv, Ukraine" alias="Europe/Kiev"/>
+            <type name="uaiev" description="Kyiv, Ukraine" alias="Europe/Kiev Europe/Kyiv"/>
             <type name="uaozh" description="Zaporizhia (Zaporozhye), Ukraine" alias="Europe/Zaporozhye"/>
             <type name="uasip" description="Simferopol, Ukraine" alias="Europe/Simferopol"/>
             <type name="uauzh" description="Uzhhorod (Uzhgorod), Ukraine" alias="Europe/Uzhgorod"/>

-------------

PR: https://git.openjdk.org/jdk/pull/10012

From mullan at openjdk.org  Wed Sep 14 20:32:47 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 14 Sep 2022 20:32:47 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v2]
In-Reply-To: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
Message-ID: <7rR40Xh40dmqQRAmSYBOl-h7vbUwKpq204tERqKKn0Q=.c168ee8e-2cb8-4aaa-a6b4-c562367013fb@github.com>

On Wed, 14 Sep 2022 14:09:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
>> 
>> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
>> 
>> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
>> 
>> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.
>
> 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:
> 
>  - Merge
>  - Remove stopThread permission from RuntimePermission table, exclude jshell tests
>  - Deprecate for removal
>  - Next iteration, update dates in headers
>  - Merge
>  - Initial commit

src/java.base/share/classes/java/lang/Thread.java line 1642:

> 1640:      *       {@code ThreadDeath} exception propagating up the stack).  If
> 1641:      *       any of the objects previously protected by these monitors were in
> 1642:      *       an inconsistent state, the damaged objects become visible to

s/become/became/ 
(because you are writing in past tense now).

-------------

PR: https://git.openjdk.org/jdk/pull/10230

From naoto at openjdk.org  Wed Sep 14 21:09:44 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 14 Sep 2022 21:09:44 GMT
Subject: RFR: 8293579:
 tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese
 Windows platform
In-Reply-To: <ROgI801Y_MVdXiCKPYVtwN9C5kDZTT3gdAo4pnCACbs=.618721ad-4cc5-4db7-a923-3bf740e35181@github.com>
References: <ROgI801Y_MVdXiCKPYVtwN9C5kDZTT3gdAo4pnCACbs=.618721ad-4cc5-4db7-a923-3bf740e35181@github.com>
Message-ID: <PslvzFQjyULART_fZym9bib6NkPAxiq9l8kFlpJbpjk=.5453fff3-e74a-4590-a44c-0ff3772403d5@github.com>

On Fri, 9 Sep 2022 08:30:55 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

> Could you please review the JDK-8293579 bug fixes?
> 
> tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java attempts to give 
> the launcher the character which is encoded by Windows API WideCharToMultiByte() 
> from UNICODE "?"(0x00e9) as an argument. However, this test fails because the 
> code point "?"(0x00e9) cannot be treated on Japanese Windows.
> 
> WideCharToMultiByte() encodes characters as Shift-JIS on Japanese Windows, but 
> the code point "?"(0x00e9) does not exist in Shift-JIS, and it is replaced with 
> "e"(0x0065) as substitute. Therefore, "?"(0x00e9) and "e"(0x0065) are compared 
> in this test and judged to be different characters, and return as failed.
> 
> So, in the Japanese encoding("MS932", "SJIS"), the test should be modified to 
> give a character such as "?"(0x3042) as the launcher's argument instead of 
> "?"(0x00e9).

`native.encoding` holds the host encoding that used to be `file.encoding`.
Another suggestion is that, the test should only run in encodings that are guaranteed to succeed, e.g., `Cp1252` or `UTF-8`, otherwise it should gracefully exit. Your proposed fix could still fail in locales/encodings other than SJIS/MS932.

-------------

PR: https://git.openjdk.org/jdk/pull/10226

From duke at openjdk.org  Wed Sep 14 21:42:43 2022
From: duke at openjdk.org (Bernd)
Date: Wed, 14 Sep 2022 21:42:43 GMT
Subject: RFR: 8292698: Improve performance of DataInputStream [v3]
In-Reply-To: <wCpkSJJRg1I7ElawZVc5bxjXu0IL3wRGwXvScr6quoE=.e1a319f9-22c6-471f-a635-15fd8c236dc6@github.com>
References: <MXdBQj8qYqvvImT-MaBpf8mAm3b1tbNiPS93syrjfqg=.3ebdd952-f9d7-4ec9-9655-a63829828c67@github.com>
 <5v8lej62KNGYz6FTjQ6FyABbMfJxwLUSNCa6Z3DXZGQ=.1b35ef41-3b59-4b78-b035-6d1838eaebbd@github.com>
 <KIfIm02U3CPC53gSjSpi68Jk7BcoMgcmwHe3SDGVFSw=.0dc503c6-937b-4c7f-a05a-6ac7655f019e@github.com>
 <e4eIcbtpEZdZdn5KvOHjd3zrI8voMlr1aMuURWTJRN0=.7834a1a2-287a-4b3c-80bd-0918c7a04ae7@github.com>
 <RKACHIHF07-2UJp9ByKLbdeFV5vCaqFpZ73-48REHMg=.bce10b60-7578-4441-9a43-627f0ee5c164@github.com>
 <wCpkSJJRg1I7ElawZVc5bxjXu0IL3wRGwXvScr6quoE=.e1a319f9-22c6-471f-a635-15fd8c236dc6@github.com>
Message-ID: <ph1uF8fmTAkDESxl2k-F5rS7J3VmIk-uC4ZmEzJPyAs=.e05a67be-93a3-47ec-85ae-2b87e9f6551f@github.com>

On Wed, 14 Sep 2022 07:33:32 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> > Does that mean there is no explicit test for DataInputStream endianess
> 
> @ecki I think this is not strictly necessary as order of bytes is explicitly specified in JavaDoc of `DataInput` implemented by `DataInputStream`

Hm, maybe I was not clear, what I mean the endianess of DataInputStream is specified by the spec, so I would expect it to be tested. But it sounded like an accidential discovery that the impl was broken. Maybe that?s part of the tck tests and they not yet have been run?

-------------

PR: https://git.openjdk.org/jdk/pull/9956

From rriggs at openjdk.org  Wed Sep 14 22:04:47 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 14 Sep 2022 22:04:47 GMT
Subject: RFR: 8292698: Improve performance of DataInputStream [v4]
In-Reply-To: <8Rm-eVp7g0Z5PojiU5DwSU2Cuej9zlFtDdKBkUljazo=.0a1c4182-3ade-4da4-b235-f7412bee3140@github.com>
References: <MXdBQj8qYqvvImT-MaBpf8mAm3b1tbNiPS93syrjfqg=.3ebdd952-f9d7-4ec9-9655-a63829828c67@github.com>
 <8Rm-eVp7g0Z5PojiU5DwSU2Cuej9zlFtDdKBkUljazo=.0a1c4182-3ade-4da4-b235-f7412bee3140@github.com>
Message-ID: <MlAkvuXhntij6Y-a3eypAGfAgRiuWmcVBuTKmy1T728=.230e74b0-3e6a-45a3-a01d-33b91d3fe734@github.com>

On Mon, 29 Aug 2022 08:46:20 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> I found out that reading from `DataInputStream` wrapping `ByteArrayInputStream` (as well as `BufferedInputStream` or any `InputStream` relying on `byte[]`) can be significantly improved by accessing volatile `in` field only once per operation.
>> 
>> Current implementation does it for each call of `in.read()`, i.e. in `readInt()` method we do it 4 times:
>> 
>> public final int readInt() throws IOException {
>>     int ch1 = in.read();
>>     int ch2 = in.read();
>>     int ch3 = in.read();
>>     int ch4 = in.read();
>>     if ((ch1 | ch2 | ch3 | ch4) < 0)
>>         throw new EOFException();
>>     return ((ch1 << 24) + (ch2 << 16) + (ch3 << 8) + (ch4 << 0));
>> }
>> 
>> Apparently accessing volatile reference with underlying `byte[]` prevents runtime from doing some optimizations, so dereferencing local variable should be more efficient.
>> 
>> Benchmarking:
>> 
>> baseline:
>> 
>> Benchmark                     Mode  Cnt   Score   Error  Units
>> DataInputStreamTest.readChar  avgt   20  22,889 ? 0,648  us/op
>> DataInputStreamTest.readInt   avgt   20  21,804 ? 0,197  us/op
>> 
>> patch:
>> 
>> Benchmark                     Mode  Cnt   Score   Error  Units
>> DataInputStreamTest.readChar  avgt   20  11,018 ? 0,089  us/op
>> DataInputStreamTest.readInt   avgt   20   5,608 ? 0,087  us/op
>
> ?????? ??????? 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:
> 
>  - 8292698: Reuse existing code
>  - Merge branch 'master' into 8292698
>  - 8292698: Fix copyright year
>  - 8292698: Revert dubious changes
>  - 8292698: Improve performance of reading from DataInputStream

The tests for endianess for DataInputStream are in the TCK and would have caught this case.
Tests for endianess are not duplicated in the jtreg test suite.

-------------

PR: https://git.openjdk.org/jdk/pull/9956

From dcubed at openjdk.org  Wed Sep 14 22:46:43 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 14 Sep 2022 22:46:43 GMT
Subject: RFR: 8293540: [Metrics] Incorrectly detected ressource limits with
 additional cgroup fs mounts
In-Reply-To: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
References: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
Message-ID: <wE0xvQHMnxGRRaYHtjIDa33S3iHMDQLJ_cdO2Dfq53w=.bb439697-0516-4247-8bbe-80a8057b93ac@github.com>

On Tue, 13 Sep 2022 13:06:10 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Similar issue to the hotspot change discussed in https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation may get the resource limits wrong if there are additional cgroup fs mounts. Apparently that's more common than one might think. I've reproduced this with these existing tests on cg v2:
> 
> 
> test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java
> test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java
> test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java 
> 
> 
> I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` and amended `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which unconditionally fails (irrespective of cgroup version in use). The fix is fairly straight forward and is an extension which we already do for the `cpuset` controller: Allow duplicates, and if there are any prefer those mounted at `/sys/fs/cgroup`.
> 
> Testing:
> - [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the product fix)
> - [x] added tests fail before, pass after the product fix.
> - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still pass. 
> - [ ] GHA still running.
> 
> Please review! Many thanks in advance.

I fixed a typo in the bug's synopsis line so this PR's title needs to be update.
Doing a "/issue JDK-8293540" will do the trick.

-------------

PR: https://git.openjdk.org/jdk/pull/10248

From bpb at openjdk.org  Thu Sep 15 00:18:51 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 15 Sep 2022 00:18:51 GMT
Subject: RFR: 8291911: java/io/File/GetXSpace.java fails with
 "53687091200 != 161051996160" [v2]
In-Reply-To: <PAUFPRZ0OYt3MXRK2q77fOyiePIzHI8TrOYAjvWJLCQ=.62917036-86fa-4a30-b6a5-b45b8da6c61c@github.com>
References: <hiHVLJUNxuALrLC5xiE9RgTKHO_HQ-IRxI7ZYdRrjQA=.a6a20de6-1348-4247-bac5-6d7c1281cc5d@github.com>
 <PAUFPRZ0OYt3MXRK2q77fOyiePIzHI8TrOYAjvWJLCQ=.62917036-86fa-4a30-b6a5-b45b8da6c61c@github.com>
Message-ID: <zXPc9ziTTQr8-y-dS_A13rQbwnho5GgnHhDjctwxVOI=.4a9d81ba-5aef-409e-a4a4-c8308564b590@github.com>

On Wed, 17 Aug 2022 17:59:34 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> On Windows, suppress failure if the total space indicated by `df` is less than `FileStore::getTotalSpace` and the free space indicated by `df` equals `FileStore::getUnallocatedSpace`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8291911: Account for quotas on Windows.

continue;

-------------

PR: https://git.openjdk.org/jdk/pull/9856

From duke at openjdk.org  Thu Sep 15 01:32:51 2022
From: duke at openjdk.org (duke)
Date: Thu, 15 Sep 2022 01:32:51 GMT
Subject: Withdrawn: 8290471: jpackage: allow to specify codepage on Windows
In-Reply-To: <im25xPB2N7WxOqhZHQS3ln22ACk4CK2ua-aCeKADJOs=.77b36be1-79e1-4dd8-8dfe-c965131727f1@github.com>
References: <im25xPB2N7WxOqhZHQS3ln22ACk4CK2ua-aCeKADJOs=.77b36be1-79e1-4dd8-8dfe-c965131727f1@github.com>
Message-ID: <z0C47vlwVXaKNbbV-9xi-LVqK7jqqVnvFvl9Ty_lV3M=.f8e48392-9d00-4773-bbb6-01798739ff50@github.com>

On Mon, 18 Jul 2022 22:33:15 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> It is proposed to introduce support for `--win-codepage` argument, and substitute the `Codepage` attribute with `--win-codepage` specified value in primary l10n file when it is being copied to the config dir.
> 
> Instead of copying all internal l10n files, it is proposed to copy only the primary file. Plain copy is used if `--win-codepage` is not specified. Otherwise `--win-codepage` value is substituted in l10n file using DOM and XPath.
> 
> See more details in issue description and in links added there.
> 
> Testing:
> 
>  - [x] ran `jtreg:jdk/tools/jpackage`
>  - [x] test for `--win-codepage` argument is included with the patch

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/9546

From andrew at openjdk.org  Thu Sep 15 02:01:52 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 15 Sep 2022 02:01:52 GMT
Subject: RFR: 8292579: (tz) Update Timezone Data to 2022c
In-Reply-To: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
References: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
Message-ID: <PDozDO_6mHovqzwEKa81CPMutXS3DMqS6YiH3DjfCVU=.238d2900-113d-47ff-ba76-95551a39dded@github.com>

On Thu, 25 Aug 2022 02:26:19 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  The PR adopts the official tzdata2022c as it is.
> It means the pre-1970s data merged in tzdata2022c doesn't exist.
> All tests have been passed with no failures.

Interesting, I remember changes like this causing failures in the past. Maybe they were introducing completely new zones. It looks good for the old `java.util` API as well:

~~~
$ ~/builder/trunk/images/jdk/bin/jshell -R-Djava.locale.providers=COMPAT JAVASE
|  Welcome to JShell -- Version 20-internal
|  For an introduction type: /help intro

jshell> ZoneId.of("Europe/Kyiv").getDisplayName(TextStyle.FULL, Locale.US)
$178 ==> "Eastern European Time"

jshell> TimeZone.getTimeZone("Europe/Kyiv").getDisplayName(false, TimeZone.LONG, Locale.US)
$179 ==> "Eastern European Time"
~~~

and similar for 11u & 17u with an updated tzdb. I guess we just need the CLDR change in a backport then.

-------------

PR: https://git.openjdk.org/jdk/pull/10012

From andrew at openjdk.org  Thu Sep 15 02:22:50 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 15 Sep 2022 02:22:50 GMT
Subject: RFR: 8292579: (tz) Update Timezone Data to 2022c
In-Reply-To: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
References: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
Message-ID: <i1K28HsAtEV2IvDDaJeUQa9UiMp-9hovbDZy9ZH-AQM=.ac052d80-1ed8-43b5-963d-ee02791336b6@github.com>

On Thu, 25 Aug 2022 02:26:19 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  The PR adopts the official tzdata2022c as it is.
> It means the pre-1970s data merged in tzdata2022c doesn't exist.
> All tests have been passed with no failures.

I've opened https://bugs.openjdk.org/browse/JDK-8293834 for the CLDR backport and will open a PR tomorrow for 19u.

-------------

PR: https://git.openjdk.org/jdk/pull/10012

From duke at openjdk.org  Thu Sep 15 06:25:53 2022
From: duke at openjdk.org (Rahul Prabhu)
Date: Thu, 15 Sep 2022 06:25:53 GMT
Subject: RFR: 8289508: Improve test coverage for XPath Axes: ancestor,
 ancestor-or-self, preceding, and preceding-sibling [v2]
In-Reply-To: <xn1BRpM7AtPakAYm2AdbtoddvmCNqP3wBPwjMGUPx8w=.4aaac0f2-1383-4e45-b49e-d1da3cfbdf43@github.com>
References: <xn1BRpM7AtPakAYm2AdbtoddvmCNqP3wBPwjMGUPx8w=.4aaac0f2-1383-4e45-b49e-d1da3cfbdf43@github.com>
Message-ID: <iLgmj_jFQ-xCnZAKWTDLKG59_n1N5PBo08IgKEZtUk0=.02043d75-32d4-402b-a50e-85e059d89a5b@github.com>

> Created two files for testing XPath Axes: XPathAncestors.java tests the ancestor and ancestor-or-self axes, while XPathPrecedingTest.java tests the preceding and preceding-sibling axes.

Rahul Prabhu 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:

  8289508: added more tests/superficial changes (2.2,3.3,5.7)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10211/files
  - new: https://git.openjdk.org/jdk/pull/10211/files/326185a3..72537e12

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10211&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10211&range=00-01

  Stats: 43 lines in 2 files changed: 13 ins; 0 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/10211.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10211/head:pull/10211

PR: https://git.openjdk.org/jdk/pull/10211

From duke at openjdk.org  Thu Sep 15 06:41:00 2022
From: duke at openjdk.org (Rahul Prabhu)
Date: Thu, 15 Sep 2022 06:41:00 GMT
Subject: RFR: 8289508: Improve test coverage for XPath Axes: ancestor,
 ancestor-or-self, preceding, and preceding-sibling [v3]
In-Reply-To: <xn1BRpM7AtPakAYm2AdbtoddvmCNqP3wBPwjMGUPx8w=.4aaac0f2-1383-4e45-b49e-d1da3cfbdf43@github.com>
References: <xn1BRpM7AtPakAYm2AdbtoddvmCNqP3wBPwjMGUPx8w=.4aaac0f2-1383-4e45-b49e-d1da3cfbdf43@github.com>
Message-ID: <hl9DGDrnzG29bC8404FhNM0J9pisrHb5D6eIaDQfjUY=.7d90779b-4eb4-49e7-accb-516fdaabd77e@github.com>

> Created two files for testing XPath Axes: XPathAncestors.java tests the ancestor and ancestor-or-self axes, while XPathPrecedingTest.java tests the preceding and preceding-sibling axes.

Rahul Prabhu has updated the pull request incrementally with one additional commit since the last revision:

  8289508: fixed whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10211/files
  - new: https://git.openjdk.org/jdk/pull/10211/files/72537e12..8ca54503

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10211&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10211&range=01-02

  Stats: 34 lines in 2 files changed: 1 ins; 2 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/10211.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10211/head:pull/10211

PR: https://git.openjdk.org/jdk/pull/10211

From duke at openjdk.org  Thu Sep 15 06:51:34 2022
From: duke at openjdk.org (Rahul Prabhu)
Date: Thu, 15 Sep 2022 06:51:34 GMT
Subject: RFR: 8289508: Improve test coverage for XPath Axes: ancestor,
 ancestor-or-self, preceding, and preceding-sibling [v4]
In-Reply-To: <xn1BRpM7AtPakAYm2AdbtoddvmCNqP3wBPwjMGUPx8w=.4aaac0f2-1383-4e45-b49e-d1da3cfbdf43@github.com>
References: <xn1BRpM7AtPakAYm2AdbtoddvmCNqP3wBPwjMGUPx8w=.4aaac0f2-1383-4e45-b49e-d1da3cfbdf43@github.com>
Message-ID: <k6taP148VO1CD7cP4ihqcp0KAVl-_BsXlIWliJgZMD4=.afd6c9f6-ecd3-4a2c-a028-b624cfe91efa@github.com>

> Created two files for testing XPath Axes: XPathAncestors.java tests the ancestor and ancestor-or-self axes, while XPathPrecedingTest.java tests the preceding and preceding-sibling axes.

Rahul Prabhu has updated the pull request incrementally with one additional commit since the last revision:

  8289508: fixed whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10211/files
  - new: https://git.openjdk.org/jdk/pull/10211/files/8ca54503..3b9437b7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10211&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10211&range=02-03

  Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/10211.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10211/head:pull/10211

PR: https://git.openjdk.org/jdk/pull/10211

From duke at openjdk.org  Thu Sep 15 06:51:35 2022
From: duke at openjdk.org (Rahul Prabhu)
Date: Thu, 15 Sep 2022 06:51:35 GMT
Subject: RFR: 8289508: Improve test coverage for XPath Axes: ancestor,
 ancestor-or-self, preceding, and preceding-sibling [v4]
In-Reply-To: <c-9Cw8545qISG2K8aloCbyaE1N-WOpL-XO5DBsXMcUQ=.cb4420cc-1d4f-43cb-9be9-fdbbd32927c8@github.com>
References: <xn1BRpM7AtPakAYm2AdbtoddvmCNqP3wBPwjMGUPx8w=.4aaac0f2-1383-4e45-b49e-d1da3cfbdf43@github.com>
 <c-9Cw8545qISG2K8aloCbyaE1N-WOpL-XO5DBsXMcUQ=.cb4420cc-1d4f-43cb-9be9-fdbbd32927c8@github.com>
Message-ID: <HwqPhiKslmzzUwF_01mMgKpqCfY-bkjrGPoF66AIBSM=.63b46d7e-d3b0-45dd-8069-20e0457fda51@github.com>

On Tue, 13 Sep 2022 05:23:20 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Rahul Prabhu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8289508: fixed whitespace
>
> It would be nice to cover some of the assertions made in the spec, e.g.:
> 2.2 Axes
>       ... if the context node is an attribute node or namespace node, the preceding-sibling axis is empty
>       
> 3.3 Node-sets
>             ...
>             NOTE: The meaning of a Predicate depends crucially on which axis applies. 
>             For example, preceding::foo[1] returns the first foo element in reverse document order, because the axis that applies to the [1] predicate is the preceding axis; by contrast, (preceding::foo)[1] returns the first foo element in document order, because the axis that applies to the [1] predicate is the child axis.
>             
> 5.7 Text Nodes
>       ... a text node never has an immediately following or preceding sibling that is a text node

@JoeWang-Java Added the tests you recommended, thanks for the suggestion.

-------------

PR: https://git.openjdk.org/jdk/pull/10211

From sgehwolf at openjdk.org  Thu Sep 15 08:07:08 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 15 Sep 2022 08:07:08 GMT
Subject: RFR: 8293540: [Metrics] Incorrectly detected resource limits with
 additional cgroup fs mounts
In-Reply-To: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
References: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
Message-ID: <4fY8V3tuDctSf_kqS2pDNuIKKlJMVNPllkm753EwmTc=.5519d859-57b2-4493-9d5e-7e7311538d12@github.com>

On Tue, 13 Sep 2022 13:06:10 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Similar issue to the hotspot change discussed in https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation may get the resource limits wrong if there are additional cgroup fs mounts. Apparently that's more common than one might think. I've reproduced this with these existing tests on cg v2:
> 
> 
> test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java
> test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java
> test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java 
> 
> 
> I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` and amended `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which unconditionally fails (irrespective of cgroup version in use). The fix is fairly straight forward and is an extension which we already do for the `cpuset` controller: Allow duplicates, and if there are any prefer those mounted at `/sys/fs/cgroup`.
> 
> Testing:
> - [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the product fix)
> - [x] added tests fail before, pass after the product fix.
> - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still pass. 
> - [ ] GHA still running.
> 
> Please review! Many thanks in advance.

Thanks! I've updated the PR title to match the bug synopsis.

-------------

PR: https://git.openjdk.org/jdk/pull/10248

From sgehwolf at openjdk.org  Thu Sep 15 08:51:55 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 15 Sep 2022 08:51:55 GMT
Subject: RFR: 8293540: [Metrics] Incorrectly detected resource limits with
 additional cgroup fs mounts [v2]
In-Reply-To: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
References: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
Message-ID: <wwto6_qZN_7QJNXaswOYSs3dMkUjghbly4PzFXtwfIc=.1dc331ba-8633-4ae2-9d3d-ffe5110a86a3@github.com>

> Similar issue to the hotspot change discussed in https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation may get the resource limits wrong if there are additional cgroup fs mounts. Apparently that's more common than one might think. I've reproduced this with these existing tests on cg v2:
> 
> 
> test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java
> test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java
> test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java 
> 
> 
> I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` and amended `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which unconditionally fails (irrespective of cgroup version in use). The fix is fairly straight forward and is an extension which we already do for the `cpuset` controller: Allow duplicates, and if there are any prefer those mounted at `/sys/fs/cgroup`.
> 
> Testing:
> - [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the product fix)
> - [x] added tests fail before, pass after the product fix.
> - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still pass. 
> - [ ] GHA still running.
> 
> Please review! Many thanks in advance.

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10248/files
  - new: https://git.openjdk.org/jdk/pull/10248/files/9cc6c7cd..9cc6c7cd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10248&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10248&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10248.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10248/head:pull/10248

PR: https://git.openjdk.org/jdk/pull/10248

From sgehwolf at openjdk.org  Thu Sep 15 08:55:41 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 15 Sep 2022 08:55:41 GMT
Subject: RFR: 8293540: [Metrics] Incorrectly detected resource limits with
 additional cgroup fs mounts [v3]
In-Reply-To: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
References: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
Message-ID: <-GC6RSB-rnXjie1pCd0k7bzPNbGlmyRbR6xyNNJNWzU=.c428b704-c7e6-450f-8107-63ce417e6408@github.com>

> Similar issue to the hotspot change discussed in https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation may get the resource limits wrong if there are additional cgroup fs mounts. Apparently that's more common than one might think. I've reproduced this with these existing tests on cg v2:
> 
> 
> test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java
> test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java
> test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java 
> 
> 
> I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` and amended `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which unconditionally fails (irrespective of cgroup version in use). The fix is fairly straight forward and is an extension which we already do for the `cpuset` controller: Allow duplicates, and if there are any prefer those mounted at `/sys/fs/cgroup`.
> 
> Testing:
> - [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the product fix)
> - [x] added tests fail before, pass after the product fix.
> - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still pass. 
> - [ ] GHA still running.
> 
> Please review! Many thanks in advance.

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  8293540: [Metrics] Potentially incorrectly detected resource limits with additional cgroup fs mounts

-------------

Changes: https://git.openjdk.org/jdk/pull/10248/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10248&range=02
  Stats: 175 lines in 6 files changed: 137 ins; 23 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/10248.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10248/head:pull/10248

PR: https://git.openjdk.org/jdk/pull/10248

From asotona at openjdk.org  Thu Sep 15 10:12:53 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 15 Sep 2022 10:12:53 GMT
Subject: Integrated: 8244681: Add a warning for possibly lossy conversion in
 compound assignments
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <z-bQGuu0bN_VqBmdbjUEkFe7TyQXUo47sVNnCXKvuvU=.23ec3739-9d31-484d-a296-11d5991ed934@github.com>

On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

This pull request has now been integrated.

Changeset: aff5ff14
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aff5ff14b208b3c2be93d7b4fab8b07c5be12f3e
Stats:     438 lines in 13 files changed: 437 ins; 0 del; 1 mod

8244681: Add a warning for possibly lossy conversion in compound assignments
8293797: Release Note: Javac warns about type casts in compound assignments with possible lossy conversions

Reviewed-by: erikj, prr

-------------

PR: https://git.openjdk.org/jdk/pull/8599

From dfuchs at openjdk.org  Thu Sep 15 11:40:18 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 15 Sep 2022 11:40:18 GMT
Subject: RFR: 8293819: sun/util/logging/PlatformLoggerTest.java failed with
 "RuntimeException: Retrieved backing PlatformLogger level null is not the
 expected CONFIG"
Message-ID: <Y3K_Tirot06glD3-zu9HXr13rmWfgw1pa4D8OD65a8s=.37c2114e-eedc-4240-8097-e1e391891d5e@github.com>

The sun/util/logging/PlatformLoggerTest.java is missing a couple of Reference::reachabilityFence calls to maintain loggers alive while the test is running. It has been observed failing under stress.

-------------

Commit messages:
 - Update Copyright year
 - 8293819

Changes: https://git.openjdk.org/jdk/pull/10284/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10284&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293819
  Stats: 10 lines in 1 file changed: 5 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/10284.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10284/head:pull/10284

PR: https://git.openjdk.org/jdk/pull/10284

From duke at openjdk.org  Thu Sep 15 11:50:57 2022
From: duke at openjdk.org (Strahinja Stanojevic)
Date: Thu, 15 Sep 2022 11:50:57 GMT
Subject: RFR: 8292914: Introduce a system property that enables stable
 names for lambda classes [v3]
In-Reply-To: <pYF675FND8BK8SUHFnvstPMcoKTcW81zs7yGCli5Mxo=.aac8b180-6101-4320-aa73-7e640952afaf@github.com>
References: <pYF675FND8BK8SUHFnvstPMcoKTcW81zs7yGCli5Mxo=.aac8b180-6101-4320-aa73-7e640952afaf@github.com>
Message-ID: <iFFHsX25viGS5ReNPWevzElqy8ArqnHJfaz_qMf8mc0=.50faef18-ca1c-4c58-8a20-bfab7a5b190a@github.com>

> This PR introduces a system property that creates stable names for the lambda classes in the JDK. Instead of using an atomic counter in the lambda name, we can use a 32-bit hash after `$$Lambda$`. Thus, the name becomes `lambdaCapturingClass$$Lambda$hashValue`.
> Parameters used to create a stable part of the name (hash value) are a superset of the parameters used for lambda class archiving when the CDS dumping option is enabled. During the stable name creation process,
> all the common parameters are in the same form as in the low-level implementation (C part of the code) of the archiving process.
> We concatenate all of those parameters in one string `hashData`. We calculate the long hash value for `hashData` in the same manner as the `java.lang.StringUTF16#hashCode` does, and then we hash that value using `Long.toString(longHashValue, Character.MAX_RADIX)`. The desired length for this hash is equal to the length of the `Long.toString(Long.MAX_VALUE, Character.MAX_RADIX)`.
> Sometimes, the calculated hash value is shorter than the desired length, so we pad it with the character `#` to hit it. Appending `#` only affects the hash length, but not its stability.
> 
> Link to the related issue: https://bugs.openjdk.org/browse/JDK-8292914

Strahinja Stanojevic has updated the pull request incrementally with one additional commit since the last revision:

  Add additional parameter to hashCode, because in Scala, lambda can be serializable without implementing Serializable interface

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10024/files
  - new: https://git.openjdk.org/jdk/pull/10024/files/dd268934..6a8f9128

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10024&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10024&range=01-02

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10024.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10024/head:pull/10024

PR: https://git.openjdk.org/jdk/pull/10024

From mbaesken at openjdk.org  Thu Sep 15 12:00:19 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 15 Sep 2022 12:00:19 GMT
Subject: RFR: JDK-8293659: Improve UnsatisfiedLinkError error message to
 include dlopen error details
Message-ID: <ifR_svzVaPWpTZ48Mm7a_bANpIvAgQB1HEiBrXlA0oQ=.1dd92d2d-c9f2-4bbf-9a02-8bde08cdb8fb@github.com>

When trying to load a x64 lib on macOS aarch64 one got previously this detailed message before [JDK-8275703](https://bugs.openjdk.org/browse/JDK-8275703):

java.lang.UnsatisfiedLinkError: /testing/jco3/macOsx64/libsapjco3.dylib: dlopen(/testing/jco3/macOsx64/libsapjco3.dylib, 1): no suitable image found. Did find:

-------------

Commit messages:
 - JDK-8293659

Changes: https://git.openjdk.org/jdk/pull/10286/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10286&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293659
  Stats: 17 lines in 1 file changed: 16 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10286.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10286/head:pull/10286

PR: https://git.openjdk.org/jdk/pull/10286

From jpai at openjdk.org  Thu Sep 15 13:59:46 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 15 Sep 2022 13:59:46 GMT
Subject: RFR: 8293819: sun/util/logging/PlatformLoggerTest.java failed with
 "RuntimeException: Retrieved backing PlatformLogger level null is not the
 expected CONFIG"
In-Reply-To: <Y3K_Tirot06glD3-zu9HXr13rmWfgw1pa4D8OD65a8s=.37c2114e-eedc-4240-8097-e1e391891d5e@github.com>
References: <Y3K_Tirot06glD3-zu9HXr13rmWfgw1pa4D8OD65a8s=.37c2114e-eedc-4240-8097-e1e391891d5e@github.com>
Message-ID: <6212MwjiZoIc1vkrEExtjcaNosynphWWitS8zNC4suQ=.cdf1eb9d-6bf0-4e88-a59e-3e95f6fb15b9@github.com>

On Thu, 15 Sep 2022 11:29:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The sun/util/logging/PlatformLoggerTest.java is missing a couple of Reference::reachabilityFence calls to maintain loggers alive while the test is running. It has been observed failing under stress.

test/jdk/sun/util/logging/PlatformLoggerTest.java line 136:

> 134:                 logger.getName() + " " + logger.getLevel());
> 135:         }
> 136:         Reference.reachabilityFence(logger);

Hello Daniel, I don't follow why the reachabilityFence would be needed here for the `logger`. Wouldn't the `logger` be already "alive" at this line in the method?

-------------

PR: https://git.openjdk.org/jdk/pull/10284

From alanb at openjdk.org  Thu Sep 15 14:06:05 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 15 Sep 2022 14:06:05 GMT
Subject: RFR: 8278165: Clarify that ZipInputStream does not access the CEN
 fields for a ZipEntry [v5]
In-Reply-To: <CCMk8nRLiim0DZm094E1WFWUjuqaL3Zm_8Hq8o63hoI=.c3ee4280-90f4-462e-93d1-091fdca0ea77@github.com>
References: <5xFWPl4un_Ymri2We2utzNAj9UuqMqzIzF8yex4thFg=.c3d990c5-8765-452b-9775-08071d0576b5@github.com>
 <CCMk8nRLiim0DZm094E1WFWUjuqaL3Zm_8Hq8o63hoI=.c3ee4280-90f4-462e-93d1-091fdca0ea77@github.com>
Message-ID: <BHMUDMB1U2GokKQiZob4B2JCsbY3t8tMgegS2HTbHtg=.43963ac9-8ec0-412b-9e3e-066fdc1a8cce@github.com>

On Wed, 14 Sep 2022 16:54:56 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Hi,
>> 
>> Please review this update to the ZipInputStream class description to clarify that ZipInputStream walks sequentially through each Zip Entry contained within the Zip File.  As a result, the CEN header for the Zip file entries are not read resulting in ZipInputStream not having access to information that is stored within the CEN Header fields such the as the external file attributes which can be used to store optional data such as Posix Permissions.
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor update to snippet and made the last paragraph an apiNote

I think version e15660e3 looks okay.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10102

From dfuchs at openjdk.org  Thu Sep 15 14:42:43 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 15 Sep 2022 14:42:43 GMT
Subject: RFR: 8293819: sun/util/logging/PlatformLoggerTest.java failed with
 "RuntimeException: Retrieved backing PlatformLogger level null is not the
 expected CONFIG"
In-Reply-To: <6212MwjiZoIc1vkrEExtjcaNosynphWWitS8zNC4suQ=.cdf1eb9d-6bf0-4e88-a59e-3e95f6fb15b9@github.com>
References: <Y3K_Tirot06glD3-zu9HXr13rmWfgw1pa4D8OD65a8s=.37c2114e-eedc-4240-8097-e1e391891d5e@github.com>
 <6212MwjiZoIc1vkrEExtjcaNosynphWWitS8zNC4suQ=.cdf1eb9d-6bf0-4e88-a59e-3e95f6fb15b9@github.com>
Message-ID: <nC-9adp2aC_YjbaVnkvJlNaTR0Zuijw8yLt29cESLsM=.6d46ccbc-b45c-40ed-9680-c4a8f6afba81@github.com>

On Thu, 15 Sep 2022 13:57:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The sun/util/logging/PlatformLoggerTest.java is missing a couple of Reference::reachabilityFence calls to maintain loggers alive while the test is running. It has been observed failing under stress.
>
> test/jdk/sun/util/logging/PlatformLoggerTest.java line 136:
> 
>> 134:                 logger.getName() + " " + logger.getLevel());
>> 135:         }
>> 136:         Reference.reachabilityFence(logger);
> 
> Hello Daniel, I don't follow why the reachabilityFence would be needed here for the `logger`. Wouldn't the `logger` already be reachable till the `if` block evaluation is complete?

Yes - it's not strictly needed here - I added it for symmetry in case we add more checks to the method.
I also suspect that the only place where it's needed is at line 179, since all other loggers are saved into statics. 
But better safe than sorry :-)

-------------

PR: https://git.openjdk.org/jdk/pull/10284

From jpai at openjdk.org  Thu Sep 15 15:02:47 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 15 Sep 2022 15:02:47 GMT
Subject: RFR: 8293819: sun/util/logging/PlatformLoggerTest.java failed with
 "RuntimeException: Retrieved backing PlatformLogger level null is not the
 expected CONFIG"
In-Reply-To: <Y3K_Tirot06glD3-zu9HXr13rmWfgw1pa4D8OD65a8s=.37c2114e-eedc-4240-8097-e1e391891d5e@github.com>
References: <Y3K_Tirot06glD3-zu9HXr13rmWfgw1pa4D8OD65a8s=.37c2114e-eedc-4240-8097-e1e391891d5e@github.com>
Message-ID: <3GhpN3KLwq-gjvQeEMHiydd2mVVl3LJ6LJX0f-H_o_I=.65b345b1-9424-44c3-accf-aa2530d1bb7e@github.com>

On Thu, 15 Sep 2022 11:29:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The sun/util/logging/PlatformLoggerTest.java is missing a couple of Reference::reachabilityFence calls to maintain loggers alive while the test is running. It has been observed failing under stress.

Marked as reviewed by jpai (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10284

From jpai at openjdk.org  Thu Sep 15 15:02:48 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 15 Sep 2022 15:02:48 GMT
Subject: RFR: 8293819: sun/util/logging/PlatformLoggerTest.java failed with
 "RuntimeException: Retrieved backing PlatformLogger level null is not the
 expected CONFIG"
In-Reply-To: <nC-9adp2aC_YjbaVnkvJlNaTR0Zuijw8yLt29cESLsM=.6d46ccbc-b45c-40ed-9680-c4a8f6afba81@github.com>
References: <Y3K_Tirot06glD3-zu9HXr13rmWfgw1pa4D8OD65a8s=.37c2114e-eedc-4240-8097-e1e391891d5e@github.com>
 <6212MwjiZoIc1vkrEExtjcaNosynphWWitS8zNC4suQ=.cdf1eb9d-6bf0-4e88-a59e-3e95f6fb15b9@github.com>
 <nC-9adp2aC_YjbaVnkvJlNaTR0Zuijw8yLt29cESLsM=.6d46ccbc-b45c-40ed-9680-c4a8f6afba81@github.com>
Message-ID: <I2wAXU3GolgX4MFPv5CO7aRZnEYaK7lMV3rXGNijDQo=.e0f9c9dd-cada-4389-8282-87faf94fd2af@github.com>

On Thu, 15 Sep 2022 14:38:54 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/sun/util/logging/PlatformLoggerTest.java line 136:
>> 
>>> 134:                 logger.getName() + " " + logger.getLevel());
>>> 135:         }
>>> 136:         Reference.reachabilityFence(logger);
>> 
>> Hello Daniel, I don't follow why the reachabilityFence would be needed here for the `logger`. Wouldn't the `logger` already be reachable till the `if` block evaluation is complete?
>
> Yes - it's not strictly needed here - I added it for symmetry in case we add more checks to the method.
> I also suspect that the only place where it's needed is at line 179, since all other loggers are saved into statics. 
> But better safe than sorry :-)

That sounds fine to me then.

-------------

PR: https://git.openjdk.org/jdk/pull/10284

From mchung at openjdk.org  Thu Sep 15 17:46:27 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 15 Sep 2022 17:46:27 GMT
Subject: RFR: JDK-8293659: Improve UnsatisfiedLinkError error message to
 include dlopen error details
In-Reply-To: <ifR_svzVaPWpTZ48Mm7a_bANpIvAgQB1HEiBrXlA0oQ=.1dd92d2d-c9f2-4bbf-9a02-8bde08cdb8fb@github.com>
References: <ifR_svzVaPWpTZ48Mm7a_bANpIvAgQB1HEiBrXlA0oQ=.1dd92d2d-c9f2-4bbf-9a02-8bde08cdb8fb@github.com>
Message-ID: <uc0aLj2mzvL5ELFQk-rhV1MsRE5n-Mzc2ajZNCPydSY=.84097c69-6827-4052-902b-bfc00249c3f0@github.com>

On Thu, 15 Sep 2022 11:54:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When trying to load a x64 lib on macOS aarch64 one got previously this detailed message before [JDK-8275703](https://bugs.openjdk.org/browse/JDK-8275703):
> 
> java.lang.UnsatisfiedLinkError: /testing/jco3/macOsx64/libsapjco3.dylib: dlopen(/testing/jco3/macOsx64/libsapjco3.dylib, 1): no suitable image found. Did find:

src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 347:

> 345:             // If the file exists but fails to load, UnsatisfiedLinkException thrown by the VM
> 346:             // will include the error message from dlopen to provide diagnostic information
> 347:             return fileExists;

Can drop the `fileExists` variable and simply `return AccessController.doPrivileged(....);`

Otherwise, looks good.

-------------

PR: https://git.openjdk.org/jdk/pull/10286

From mchung at openjdk.org  Thu Sep 15 17:59:43 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 15 Sep 2022 17:59:43 GMT
Subject: RFR: JDK-8293659: Improve UnsatisfiedLinkError error message to
 include dlopen error details
In-Reply-To: <ifR_svzVaPWpTZ48Mm7a_bANpIvAgQB1HEiBrXlA0oQ=.1dd92d2d-c9f2-4bbf-9a02-8bde08cdb8fb@github.com>
References: <ifR_svzVaPWpTZ48Mm7a_bANpIvAgQB1HEiBrXlA0oQ=.1dd92d2d-c9f2-4bbf-9a02-8bde08cdb8fb@github.com>
Message-ID: <wDNTMY8vuq9QDlz6da2-JrqIvyqqdlRLo74dEmctVlk=.ccb230df-73c7-42d5-bb4b-0cb441fd1e3b@github.com>

On Thu, 15 Sep 2022 11:54:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When trying to load a x64 lib on macOS aarch64 one got previously this detailed message before [JDK-8275703](https://bugs.openjdk.org/browse/JDK-8275703):
> 
> java.lang.UnsatisfiedLinkError: /testing/jco3/macOsx64/libsapjco3.dylib: dlopen(/testing/jco3/macOsx64/libsapjco3.dylib, 1): no suitable image found. Did find:

Adding the background and details for this review:

The `throwException` parameter in `JVM_LoadLibrary` was added to support dynamic linker cache.   dlopen may succeed when the given path does not exist but in the dynamic linker cache.   `System::loadLibrary` on macOS that supports dynamic linker cache calls `JVM_LoadLibrary` with `throwException == false` and so VM doesn't throw  `UnsatisfiedLinkException`.  Instead the libraries code throws `UnsatisfiedLinkException` if it fails to load the library.

For this issue,  a library to be loaded exists.    A simple fix is to call `JVM_LoadLibrary` with throwException = true such that the VM throws `UnsatisfiedLinkException` with the detailed error message.

-------------

PR: https://git.openjdk.org/jdk/pull/10286

From joehw at openjdk.org  Thu Sep 15 21:17:46 2022
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 15 Sep 2022 21:17:46 GMT
Subject: RFR: 8289508: Improve test coverage for XPath Axes: ancestor,
 ancestor-or-self, preceding, and preceding-sibling [v4]
In-Reply-To: <k6taP148VO1CD7cP4ihqcp0KAVl-_BsXlIWliJgZMD4=.afd6c9f6-ecd3-4a2c-a028-b624cfe91efa@github.com>
References: <xn1BRpM7AtPakAYm2AdbtoddvmCNqP3wBPwjMGUPx8w=.4aaac0f2-1383-4e45-b49e-d1da3cfbdf43@github.com>
 <k6taP148VO1CD7cP4ihqcp0KAVl-_BsXlIWliJgZMD4=.afd6c9f6-ecd3-4a2c-a028-b624cfe91efa@github.com>
Message-ID: <qLJCOrdHuuLi_WPbL-aK7RBUDDvWhYCE0sRGpccwccI=.80ff619a-542e-4c4c-8dc6-cb0acdfc9c90@github.com>

On Thu, 15 Sep 2022 06:51:34 GMT, Rahul Prabhu <duke at openjdk.org> wrote:

>> Created two files for testing XPath Axes: XPathAncestors.java tests the ancestor and ancestor-or-self axes, while XPathPrecedingTest.java tests the preceding and preceding-sibling axes.
>
> Rahul Prabhu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8289508: fixed whitespace

Looks good overall. 

Note that if the editor you use is prone to add whitespaces, running the normalizer before commit would do the trick.

test/jaxp/javax/xml/jaxp/unittest/xpath/XPathAncestorsTest.java line 121:

> 119: 
> 120:     /*
> 121:      * DataProvider: provides XPath expressions that return null

... expressions that return empty NodeSet.

Note that the test called to evaluate to a Node though the expressions themselves return an empty NodeSet.

test/jaxp/javax/xml/jaxp/unittest/xpath/XPathAncestorsTest.java line 124:

> 122:      */
> 123:     @DataProvider(name = "noResults")
> 124:     public Object[][] getNoResults() {

s/noResults/emptyNodeSet. Refer to the above, it's therefore not that it returns "no result" but the processor treats requesting Node on an empty NodeSet as null.

-------------

PR: https://git.openjdk.org/jdk/pull/10211

From joehw at openjdk.org  Thu Sep 15 21:17:49 2022
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 15 Sep 2022 21:17:49 GMT
Subject: RFR: 8289508: Improve test coverage for XPath Axes: ancestor,
 ancestor-or-self, preceding, and preceding-sibling [v2]
In-Reply-To: <iLgmj_jFQ-xCnZAKWTDLKG59_n1N5PBo08IgKEZtUk0=.02043d75-32d4-402b-a50e-85e059d89a5b@github.com>
References: <xn1BRpM7AtPakAYm2AdbtoddvmCNqP3wBPwjMGUPx8w=.4aaac0f2-1383-4e45-b49e-d1da3cfbdf43@github.com>
 <iLgmj_jFQ-xCnZAKWTDLKG59_n1N5PBo08IgKEZtUk0=.02043d75-32d4-402b-a50e-85e059d89a5b@github.com>
Message-ID: <xU8yKCmYQNc-GkMUIxihHJLYAaJBQ2uaomwFu-tw0DI=.a8f02096-9bae-45d6-bd19-ad8ba9503676@github.com>

On Thu, 15 Sep 2022 06:25:53 GMT, Rahul Prabhu <duke at openjdk.org> wrote:

>> Created two files for testing XPath Axes: XPathAncestors.java tests the ancestor and ancestor-or-self axes, while XPathPrecedingTest.java tests the preceding and preceding-sibling axes.
>
> Rahul Prabhu 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:
> 
>   8289508: added more tests/superficial changes (2.2,3.3,5.7)

test/jaxp/javax/xml/jaxp/unittest/xpath/XPathPrecedingTest.java line 57:

> 55:                   <isbn>1234</isbn>
> 56:                </book>
> 57:                <book id="2" lang="en" xlmns="www.foo.com">

typo: s/xlmns/xmlns.  There's no namespace due to the typo. The test still passed since there's no namespace.

-------------

PR: https://git.openjdk.org/jdk/pull/10211

From darcy at openjdk.org  Fri Sep 16 03:07:16 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 16 Sep 2022 03:07:16 GMT
Subject: RFR: JDK-8293892: Add links to JVMS 19 and 20 from
 ClassFileFormatVersion enum constants
Message-ID: <IByqVSHVGiBnbV6_kt-d-GPQb3VxbmpgwG0ff8voTvs=.9dfdca89-b870-4474-82e5-d82877f164c6@github.com>

Analogous fix to one already done for javax.lang.model.SourceVersion (JDK-8293768), the links to JVMS 19 and 20 are not currently valid, but redirect to the spec language page

https://docs.oracle.com/javase/specs/index.html

The URLs will become valid when 19 and 20, respectively, ship.

-------------

Commit messages:
 - JDK-8293892: Add links to JVMS 19 and 20 from ClassFileFormatVersion enum constants

Changes: https://git.openjdk.org/jdk/pull/10298/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10298&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293892
  Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10298.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10298/head:pull/10298

PR: https://git.openjdk.org/jdk/pull/10298

From sundar at openjdk.org  Fri Sep 16 05:08:41 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Fri, 16 Sep 2022 05:08:41 GMT
Subject: RFR: JDK-8293892: Add links to JVMS 19 and 20 from
 ClassFileFormatVersion enum constants
In-Reply-To: <IByqVSHVGiBnbV6_kt-d-GPQb3VxbmpgwG0ff8voTvs=.9dfdca89-b870-4474-82e5-d82877f164c6@github.com>
References: <IByqVSHVGiBnbV6_kt-d-GPQb3VxbmpgwG0ff8voTvs=.9dfdca89-b870-4474-82e5-d82877f164c6@github.com>
Message-ID: <PJdR-ODJn1Z-TthEPejkia6LKq7b3xu81bfYE21dGK4=.a1429a11-6068-4d7f-8978-5f47ff6e5cfd@github.com>

On Fri, 16 Sep 2022 02:59:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Analogous fix to one already done for javax.lang.model.SourceVersion (JDK-8293768), the links to JVMS 19 and 20 are not currently valid, but redirect to the spec language page
> 
> https://docs.oracle.com/javase/specs/index.html
> 
> The URLs will become valid when 19 and 20, respectively, ship.

LGTM

-------------

Marked as reviewed by sundar (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10298

From duke at openjdk.org  Fri Sep 16 06:22:55 2022
From: duke at openjdk.org (duke)
Date: Fri, 16 Sep 2022 06:22:55 GMT
Subject: Withdrawn: JDK-8287597: List all preview features on the javadoc
 PREVIEW page
In-Reply-To: <0UfKceKzCT3_exJ2vDs5y7IeroB2IHU8kHPO7b46KDY=.bbc662cb-5bd9-4205-acc2-3025ad1a5ab1@github.com>
References: <0UfKceKzCT3_exJ2vDs5y7IeroB2IHU8kHPO7b46KDY=.bbc662cb-5bd9-4205-acc2-3025ad1a5ab1@github.com>
Message-ID: <Coc-Es1hTDQ7lXOHG3SWrk-th_xwv9Fmr1zJhHQM56k=.15cbd475-554c-40a5-8ced-8be3dc83ebcf@github.com>

On Thu, 30 Jun 2022 15:14:40 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review an enhancement to the preview page to add a list of preview features and allow users to explore the preview APIs by feature. 
> 
> While the changes for the enhancement itself are not overly complex, the work entailed a moderate cleanup of other summary API lists (Deprecated and New API pages) as well as a few unrelated summary pages that happened to share some of the CSS classes and HTML structure.
> 
> The change itself starts with a new internal `jdk.internal.javac.PreviewFeature.JEP` annotation interface to add JEP information to the nearby `jdk.internal.javac.PreviewFeature.Feature` enum. This JEP information is retrieved by new methods in the javadoc `Utils` class and then fetched by `PreviewAPIListBuilder` which passes it on to `PreviewListWriter`. 
> 
> The superclass of `PreviewListWriter` and other API summary writer classes, `SummaryListWriter`, gets a new `addContentSelectors(Content)` method to add the checkboxes to show/hide various parts of the page content. The class is also now abstract as this and other methods do not have useful implementations in the base class. 
> 
> Another change to `SummaryListWriter` is that `pageMode`, `description`, `headContent` and `titleKey` are no longer fields in the class but rather sent to the `generateSummaryListFile` method as parameters since they are mostly just used locally in that method. On the other hand, the associated Builder is used in many places and previously had to be retrieved from the configuration object or passed around as parameter, so that is now set as a final field in `SummaryListWriter`. 
> 
> Finally, a few words about changes in CSS and HTML: The "Contents" list containing various kinds of elements in the API list was previously contained in the `<div class="header">` element that also contains the page header, and the stylesheet used the `.header ul`  selector to style the list. Now that the checkboxes separate the page header from the contents list it felt wrong to put all this in the header div (most other pages only use the div for the header itself). I also didn't like the indirect CSS selector too much, `.header ul` is not very indicative of what it applies to.
> 
> I therefore decided to create a new dedicated CSS class for the contents list called `contents-list`, and move the `<ul>` element out of the header div. Apart from the summary API pages, this change also affects the "Constant Values"  page as well as the top and package level "Tree" (class hierarchy) pages. I made sure the contents list in these pages look the same as before.
> 
> The list items in the contents list now each have an `id` attribute to allow hiding the list item if no content for the element kind is currently selected/visible. The value of the `id` attribute uses the format `contents-<element-kind>`.
> 
> There is one additional CSS class called `preview-feature-list` used for the list of preview feature JEPs. 
> 
> Demo output for the new preview page as well as other pages is available here:
> http://cr.openjdk.java.net/~hannesw/8287597/api.03/preview-list.html

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/9336

From shade at openjdk.org  Fri Sep 16 06:53:48 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 16 Sep 2022 06:53:48 GMT
Subject: RFR: 8293499: Provide jmod --compress option [v6]
In-Reply-To: <7mps9AwYW2ZWKhN_3LAeh247LIBuxz9VURde2qxoDxU=.32f31014-5c78-45e0-a511-dd4fbef466de@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
 <7mps9AwYW2ZWKhN_3LAeh247LIBuxz9VURde2qxoDxU=.32f31014-5c78-45e0-a511-dd4fbef466de@github.com>
Message-ID: <25CXKRrUKol2CBeH-pRHDOYrVA0yz3cbkKrKvQJ6WZc=.1f9115a5-fc84-43f7-85cb-a77d8983d81c@github.com>

On Tue, 13 Sep 2022 17:41:04 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I have been looking into `make clean-images images` performance, and realized jmod keeps compressing files with default compression level. Tuning that toward lighter compression levels improves build performance considerably, without a heavy loss in *.jmod sizes. 
>> 
>> This PR allows JMOD to select the compression level. Follow-ups would use this in the build system, see #10214.
>> 
>> The interesting asymmetry against `jlink` is: `jlink` provides `--compress` option that only takes `2` for "ZIP compression". (Separately, we could argue if it would be beneficial to extend `--compress` to `jlink` as well, so to select the compression level there too.)
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Mention the default level

(posting a comment in the hopes that bots would check the CSR state)

-------------

PR: https://git.openjdk.org/jdk/pull/10213

From mbaesken at openjdk.org  Fri Sep 16 07:27:44 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 16 Sep 2022 07:27:44 GMT
Subject: RFR: JDK-8293659: Improve UnsatisfiedLinkError error message to
 include dlopen error details [v2]
In-Reply-To: <ifR_svzVaPWpTZ48Mm7a_bANpIvAgQB1HEiBrXlA0oQ=.1dd92d2d-c9f2-4bbf-9a02-8bde08cdb8fb@github.com>
References: <ifR_svzVaPWpTZ48Mm7a_bANpIvAgQB1HEiBrXlA0oQ=.1dd92d2d-c9f2-4bbf-9a02-8bde08cdb8fb@github.com>
Message-ID: <xF7xU_nv7od9QNvVMREbQGelSOQ0okJPyTnoQhkK2w0=.83257c39-be99-41ea-adf5-6affb2712f22@github.com>

> When trying to load a x64 lib on macOS aarch64 one got previously this detailed message before [JDK-8275703](https://bugs.openjdk.org/browse/JDK-8275703):
> 
> java.lang.UnsatisfiedLinkError: /testing/jco3/macOsx64/libsapjco3.dylib: dlopen(/testing/jco3/macOsx64/libsapjco3.dylib, 1): no suitable image found. Did find:

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Adjust throwExceptionIfFail

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10286/files
  - new: https://git.openjdk.org/jdk/pull/10286/files/79834e6b..8750d0f0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10286&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10286&range=00-01

  Stats: 7 lines in 1 file changed: 2 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10286.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10286/head:pull/10286

PR: https://git.openjdk.org/jdk/pull/10286

From mbaesken at openjdk.org  Fri Sep 16 07:27:45 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 16 Sep 2022 07:27:45 GMT
Subject: RFR: JDK-8293659: Improve UnsatisfiedLinkError error message to
 include dlopen error details
In-Reply-To: <ifR_svzVaPWpTZ48Mm7a_bANpIvAgQB1HEiBrXlA0oQ=.1dd92d2d-c9f2-4bbf-9a02-8bde08cdb8fb@github.com>
References: <ifR_svzVaPWpTZ48Mm7a_bANpIvAgQB1HEiBrXlA0oQ=.1dd92d2d-c9f2-4bbf-9a02-8bde08cdb8fb@github.com>
Message-ID: <_trp74jYp76FIvzmLCjr-j5qljlLYsy6r8t1Kj79WuY=.e97a6ecb-1bfc-47a8-bba4-167dd0d4410c@github.com>

On Thu, 15 Sep 2022 11:54:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When trying to load a x64 lib on macOS aarch64 one got previously this detailed message before [JDK-8275703](https://bugs.openjdk.org/browse/JDK-8275703):
> 
> java.lang.UnsatisfiedLinkError: /testing/jco3/macOsx64/libsapjco3.dylib: dlopen(/testing/jco3/macOsx64/libsapjco3.dylib, 1): no suitable image found. Did find:

Hi Mandy, thanks for the comment and the suggestion above. I adjusted throwExceptionIfFail.

-------------

PR: https://git.openjdk.org/jdk/pull/10286

From lzhai at openjdk.org  Fri Sep 16 07:44:20 2022
From: lzhai at openjdk.org (Leslie Zhai)
Date: Fri, 16 Sep 2022 07:44:20 GMT
Subject: RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx
Message-ID: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>

Hi,

@dumasun reported the issue:

Configured with jfx-ls-modular-sdk:


configure --with-import-modules=modular-sdk


`make run-test CONF=fastdebug TEST="tools/launcher/FXLauncherTest.java"` failed:


----------System.err:(11/697)----------
java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
    at FXLauncherTest.main(FXLauncherTest.java:451)
    at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
    at java.base/java.lang.reflect.Method.invoke(Method.java:578)
    at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
    at java.base/java.lang.Thread.run(Thread.java:1589)

JavaTest Message: Test threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK


Thanks,
Leslie Zhai

-------------

Commit messages:
 - 8293910: tools/launcher/FXLauncherTest.java fail with jfx

Changes: https://git.openjdk.org/jdk/pull/10299/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10299&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293910
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10299.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10299/head:pull/10299

PR: https://git.openjdk.org/jdk/pull/10299

From lzhai at openjdk.org  Fri Sep 16 07:44:20 2022
From: lzhai at openjdk.org (Leslie Zhai)
Date: Fri, 16 Sep 2022 07:44:20 GMT
Subject: RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx
In-Reply-To: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
References: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
Message-ID: <4yQuAMPyhIP6siABor_pq18XKTvvhZ2vX5_ptWy22ww=.3f45ec67-229b-4d40-a205-f069c6f43c31@github.com>

On Fri, 16 Sep 2022 07:35:03 GMT, Leslie Zhai <lzhai at openjdk.org> wrote:

> Hi,
> 
> @dumasun reported the issue:
> 
> Configured with jfx-ls-modular-sdk:
> 
> 
> configure --with-import-modules=modular-sdk
> 
> 
> `make run-test CONF=fastdebug TEST="tools/launcher/FXLauncherTest.java"` failed:
> 
> 
> ----------System.err:(11/697)----------
> java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>     at FXLauncherTest.main(FXLauncherTest.java:451)
>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>     at java.base/java.lang.Thread.run(Thread.java:1589)
> 
> JavaTest Message: Test threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
> JavaTest Message: shutting down test
> 
> STATUS:Failed.`main' threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
> 
> 
> Thanks,
> Leslie Zhai

Hi,

Thank @kevinrushforth [8202553: Update FXLauncherTest as part of removing JavaFX from JDK](https://github.com/openjdk/jdk/commit/8af434d695ca2f8da8fcdbbf058b85d4e79fbd1a).  And jdk11u-dev Passed:


make run-test CONF=fastdebug TEST="tools/launcher/FXLauncherTest.java"

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/jdk/tools/launcher/FXLauncherTest.java     1     1     0     0   
==============================
TEST SUCCESS


So I just skip the test for configured with jfx-ls-modular-sdk.

Please review my patch.

Thanks,
Leslie Zhai

-------------

PR: https://git.openjdk.org/jdk/pull/10299

From shade at openjdk.org  Fri Sep 16 08:03:28 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 16 Sep 2022 08:03:28 GMT
Subject: RFR: 8293499: Provide jmod --compress option [v7]
In-Reply-To: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
Message-ID: <NtlQYsnqYp5rh3OVL0OYtYlHhi6rYNft1DoXrNFFjYA=.7e847323-9b01-40eb-89f7-713667f290de@github.com>

> I have been looking into `make clean-images images` performance, and realized jmod keeps compressing files with default compression level. Tuning that toward lighter compression levels improves build performance considerably, without a heavy loss in *.jmod sizes. 
> 
> This PR allows JMOD to select the compression level. Follow-ups would use this in the build system, see #10214.
> 
> The interesting asymmetry against `jlink` is: `jlink` provides `--compress` option that only takes `2` for "ZIP compression". (Separately, we could argue if it would be beneficial to extend `--compress` to `jlink` as well, so to select the compression level there too.)

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup quotes in parameter help

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10213/files
  - new: https://git.openjdk.org/jdk/pull/10213/files/2729dfb4..78bf75c0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10213&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10213&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10213.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10213/head:pull/10213

PR: https://git.openjdk.org/jdk/pull/10213

From shade at openjdk.org  Fri Sep 16 08:03:30 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 16 Sep 2022 08:03:30 GMT
Subject: RFR: 8293499: Provide jmod --compress option [v6]
In-Reply-To: <7mps9AwYW2ZWKhN_3LAeh247LIBuxz9VURde2qxoDxU=.32f31014-5c78-45e0-a511-dd4fbef466de@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
 <7mps9AwYW2ZWKhN_3LAeh247LIBuxz9VURde2qxoDxU=.32f31014-5c78-45e0-a511-dd4fbef466de@github.com>
Message-ID: <6-04YLJu4Fi9QtTxFadDOjABuD5N8Jw7reI5ko8-e0M=.153acb74-2a8a-4079-9457-d9d5d1397df3@github.com>

On Tue, 13 Sep 2022 17:41:04 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I have been looking into `make clean-images images` performance, and realized jmod keeps compressing files with default compression level. Tuning that toward lighter compression levels improves build performance considerably, without a heavy loss in *.jmod sizes. 
>> 
>> This PR allows JMOD to select the compression level. Follow-ups would use this in the build system, see #10214.
>> 
>> The interesting asymmetry against `jlink` is: `jlink` provides `--compress` option that only takes `2` for "ZIP compression". (Separately, we could argue if it would be beneficial to extend `--compress` to `jlink` as well, so to select the compression level there too.)
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Mention the default level

I did a minor cleanup, unquoted: `"zip-6"` -> `zip-6` to be consistent in help message. Otherwise, this is ready to go and I will integrate it soon. Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/10213

From mbaesken at openjdk.org  Fri Sep 16 08:33:18 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 16 Sep 2022 08:33:18 GMT
Subject: RFR: JDK-8293701: jdeps InverseDepsAnalyzer runs into
 NoSuchElementException: No value present
Message-ID: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>

We noticed that with certain jar file input, jdeps runs into the following exception, this happens with jdk11, 17 and 20.

jdeps.exe --multi-release 11 --module-path . --inverse --package com.sap.nw.performance.supa.client test.jar

Inverse transitive dependences matching packages [com.sap.nw.performance.supa.client]
Exception in thread "main" java.util.NoSuchElementException: No value present
        at java.base/java.util.Optional.get(Optional.java:148)
        at jdk.jdeps/com.sun.tools.jdeps.InverseDepsAnalyzer.lambda$inverseDependences$2(InverseDepsAnalyzer.java:150)
        at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
        at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
        at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
        at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
        at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
        at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
        at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)

So an additional  check might be a good idea.

-------------

Commit messages:
 - JDK-8293701

Changes: https://git.openjdk.org/jdk/pull/10300/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10300&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293701
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10300.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10300/head:pull/10300

PR: https://git.openjdk.org/jdk/pull/10300

From duke at openjdk.org  Fri Sep 16 08:34:50 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Fri, 16 Sep 2022 08:34:50 GMT
Subject: RFR: 8289797: tools/launcher/I18NArgTest.java fails on Japanese
 Windows environment [v3]
In-Reply-To: <VRTnyuy9Qmw8lfm0_6PJtie5trsXqVQjY4mmt_fpE88=.afda6e0b-5be8-4629-9816-361ec8d243ad@github.com>
References: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
 <B4rHHDtIaxlHyH2YF9HMOuOf6sNeC7bsYhe3NfdgUqM=.a995ec62-0d39-4f43-95c5-03261ae325c0@github.com>
 <VRTnyuy9Qmw8lfm0_6PJtie5trsXqVQjY4mmt_fpE88=.afda6e0b-5be8-4629-9816-361ec8d243ad@github.com>
Message-ID: <Xu96knBpaa0kvEv_RtoXuIHahBieArKuvn26mISRu6s=.80832925-513a-4859-b0d0-6fe1c49062fc@github.com>

On Sat, 27 Aug 2022 00:20:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8289797: tools/launcher/I18NArgTest.java fails on Japanese Windows
>
> test/jdk/tools/launcher/I18NArgTest.java line 147:
> 
>> 145:             for (int i = 0; i < sysPropVal.length(); i++) {
>> 146:                 sysPropHexVal = sysPropHexVal.concat(Integer.toHexString(sysPropVal.charAt(i)));
>> 147:             }
> 
> It's OK as it stands, but this loop could be replaced with a `HexFormat` one-liner.

I'm sorry, I can't replace this code with a HexFormat one-line. Do you have an example code?

-------------

PR: https://git.openjdk.org/jdk/pull/9389

From alanb at openjdk.org  Fri Sep 16 08:41:48 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 Sep 2022 08:41:48 GMT
Subject: RFR: JDK-8293701: jdeps InverseDepsAnalyzer runs into
 NoSuchElementException: No value present
In-Reply-To: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
References: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
Message-ID: <7P635gj5EB9YmaiqPH09VCJkKOy666nWu89aY-wWIMc=.36ecd9b1-5227-408f-a4d6-0ac3743c3ee4@github.com>

On Fri, 16 Sep 2022 08:26:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We noticed that with certain jar file input, jdeps runs into the following exception, this happens with jdk11, 17 and 20.
> 
> jdeps.exe --multi-release 11 --module-path . --inverse --package com.sap.nw.performance.supa.client test.jar
> 
> Inverse transitive dependences matching packages [com.sap.nw.performance.supa.client]
> Exception in thread "main" java.util.NoSuchElementException: No value present
>         at java.base/java.util.Optional.get(Optional.java:148)
>         at jdk.jdeps/com.sun.tools.jdeps.InverseDepsAnalyzer.lambda$inverseDependences$2(InverseDepsAnalyzer.java:150)
>         at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>         at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>         at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
>         at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>         at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> 
> So an additional  check might be a good idea.

Do you think it would be possible to create a small test case that demonstrates the issue? A number of the fixes to jdeps in recent releases have be due to some unusual scenarios and I think it would be useful to build up more test cases for this scenarios, otherwise they could easily break again if there are no tests.

-------------

PR: https://git.openjdk.org/jdk/pull/10300

From duke at openjdk.org  Fri Sep 16 08:50:14 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Fri, 16 Sep 2022 08:50:14 GMT
Subject: RFR: 8289797: tools/launcher/I18NArgTest.java fails on Japanese
 Windows environment [v4]
In-Reply-To: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
References: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
Message-ID: <Sjiz9sPPIDsN6a1QpZ-R8k_eOLt6aQJdQrQrzIwYL1I=.f34f9d47-c300-4445-a996-03ef6270bdc4@github.com>

> I removed a section of via JDK_JAVA_OPTIONS because including main class is not allowed in the specification.
> This behavior is added in JDK-8170832, which add JAVA_OPTIONS environment variable. At this time, this test is mismatch with the specification.
> I tried to test and get Passed on Japanese Windows environment.
> Could you review this fix, please?

KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:

  8289797: tools/launcher/I18NArgTest.java fails on Japanese Windows environment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9389/files
  - new: https://git.openjdk.org/jdk/pull/9389/files/4dbf952d..e22d35c5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9389&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9389&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9389.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9389/head:pull/9389

PR: https://git.openjdk.org/jdk/pull/9389

From duke at openjdk.org  Fri Sep 16 08:50:15 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Fri, 16 Sep 2022 08:50:15 GMT
Subject: RFR: 8289797: tools/launcher/I18NArgTest.java fails on Japanese
 Windows environment [v3]
In-Reply-To: <VRTnyuy9Qmw8lfm0_6PJtie5trsXqVQjY4mmt_fpE88=.afda6e0b-5be8-4629-9816-361ec8d243ad@github.com>
References: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
 <B4rHHDtIaxlHyH2YF9HMOuOf6sNeC7bsYhe3NfdgUqM=.a995ec62-0d39-4f43-95c5-03261ae325c0@github.com>
 <VRTnyuy9Qmw8lfm0_6PJtie5trsXqVQjY4mmt_fpE88=.afda6e0b-5be8-4629-9816-361ec8d243ad@github.com>
Message-ID: <HrxcMxvmYOWbX_XpNetC-b19478G1wDJ7XjNfXsR4dQ=.854dc32e-e8b5-45a0-b77b-a121500706ac@github.com>

On Sat, 27 Aug 2022 00:19:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8289797: tools/launcher/I18NArgTest.java fails on Japanese Windows
>
> test/jdk/tools/launcher/I18NArgTest.java line 104:
> 
>> 102:         // we expect that system property value to be passed along to the main method with the
>> 103:         // correct encoding
>> 104:         // If <unicodestr> contains space or tab, it should beenclosed with double quotes.
> 
> Nit: space is missing between "be" and "enclosed"

Thank you for your comment, I fixed it.

-------------

PR: https://git.openjdk.org/jdk/pull/9389

From dfuchs at openjdk.org  Fri Sep 16 09:14:56 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 16 Sep 2022 09:14:56 GMT
Subject: Integrated: 8293819: sun/util/logging/PlatformLoggerTest.java failed
 with
 "RuntimeException: Retrieved backing PlatformLogger level null is not the
 expected CONFIG"
In-Reply-To: <Y3K_Tirot06glD3-zu9HXr13rmWfgw1pa4D8OD65a8s=.37c2114e-eedc-4240-8097-e1e391891d5e@github.com>
References: <Y3K_Tirot06glD3-zu9HXr13rmWfgw1pa4D8OD65a8s=.37c2114e-eedc-4240-8097-e1e391891d5e@github.com>
Message-ID: <fT83PjyeHZ2lYdR-ICHScKSnAoNS6bnb_uS5jo-NG6Q=.5f6f9d59-d414-40d1-ba07-baa90c6ed90f@github.com>

On Thu, 15 Sep 2022 11:29:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The sun/util/logging/PlatformLoggerTest.java is missing a couple of Reference::reachabilityFence calls to maintain loggers alive while the test is running. It has been observed failing under stress.

This pull request has now been integrated.

Changeset: 11e7d53b
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/11e7d53b23796cbd3d878048f7553885ae07f4d1
Stats:     10 lines in 1 file changed: 5 ins; 0 del; 5 mod

8293819: sun/util/logging/PlatformLoggerTest.java failed with "RuntimeException: Retrieved backing PlatformLogger level null is not the expected CONFIG"

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/10284

From jpai at openjdk.org  Fri Sep 16 09:18:39 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 16 Sep 2022 09:18:39 GMT
Subject: RFR: JDK-8293701: jdeps InverseDepsAnalyzer runs into
 NoSuchElementException: No value present
In-Reply-To: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
References: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
Message-ID: <EW_p4Z8WcY3oei_GUGxJ00Xy7sREytVv5SUjAijkniI=.8c48976c-c85e-4f8b-a4aa-682e104cf1f1@github.com>

On Fri, 16 Sep 2022 08:26:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We noticed that with certain jar file input, jdeps runs into the following exception, this happens with jdk11, 17 and 20.
> 
> jdeps.exe --multi-release 11 --module-path . --inverse --package com.sap.nw.performance.supa.client test.jar
> 
> Inverse transitive dependences matching packages [com.sap.nw.performance.supa.client]
> Exception in thread "main" java.util.NoSuchElementException: No value present
>         at java.base/java.util.Optional.get(Optional.java:148)
>         at jdk.jdeps/com.sun.tools.jdeps.InverseDepsAnalyzer.lambda$inverseDependences$2(InverseDepsAnalyzer.java:150)
>         at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>         at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>         at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
>         at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>         at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> 
> So an additional  check might be a good idea.

In addition to what Alan stated, it seems odd that a `isPresent` check is (now) necessary when the previously line states that the module "must be present". So I think having a reproducer, like Alan noted, would be important to decide what the fix should be.

-------------

PR: https://git.openjdk.org/jdk/pull/10300

From alanb at openjdk.org  Fri Sep 16 09:45:14 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 Sep 2022 09:45:14 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v3]
In-Reply-To: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
Message-ID: <aZkbd6g9FC4Q6gGvqygI1B3F5tk6bj6JE6y17_lZGrw=.60e86c67-9f06-4b82-801a-131c3eb044bf@github.com>

> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
> 
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
> 
> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
> 
> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.

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 10 additional commits since the last revision:

 - Repalce "it" with "victim thread"
 - Merge
 - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop
 - become -> became in javadoc
 - Merge
 - Remove stopThread permission from RuntimePermission table, exclude jshell tests
 - Deprecate for removal
 - Next iteration, update dates in headers
 - Merge
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10230/files
  - new: https://git.openjdk.org/jdk/pull/10230/files/86424b65..a00f38a2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10230&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10230&range=01-02

  Stats: 2575 lines in 102 files changed: 1741 ins; 370 del; 464 mod
  Patch: https://git.openjdk.org/jdk/pull/10230.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10230/head:pull/10230

PR: https://git.openjdk.org/jdk/pull/10230

From jpai at openjdk.org  Fri Sep 16 10:03:51 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 16 Sep 2022 10:03:51 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v3]
In-Reply-To: <aZkbd6g9FC4Q6gGvqygI1B3F5tk6bj6JE6y17_lZGrw=.60e86c67-9f06-4b82-801a-131c3eb044bf@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <aZkbd6g9FC4Q6gGvqygI1B3F5tk6bj6JE6y17_lZGrw=.60e86c67-9f06-4b82-801a-131c3eb044bf@github.com>
Message-ID: <gGA9M5tP46bhCY9PI2iJWQ_2Cn82ti6v8m3T4LgWkOg=.500b0275-0ba5-4b4b-9d42-15cee27bad5b@github.com>

On Fri, 16 Sep 2022 09:45:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
>> 
>> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
>> 
>> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
>> 
>> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.
>
> 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 10 additional commits since the last revision:
> 
>  - Repalce "it" with "victim thread"
>  - Merge
>  - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop
>  - become -> became in javadoc
>  - Merge
>  - Remove stopThread permission from RuntimePermission table, exclude jshell tests
>  - Deprecate for removal
>  - Next iteration, update dates in headers
>  - Merge
>  - Initial commit

Marked as reviewed by jpai (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10230

From aefimov at openjdk.org  Fri Sep 16 10:08:21 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Fri, 16 Sep 2022 10:08:21 GMT
Subject: Integrated: 8290367: Update default value and extend the scope of
 com.sun.jndi.ldap.object.trustSerialData system property
In-Reply-To: <T8JiNCNUKjV5bue6Bd8MjtatKCd9yik8cYMw2NIGTps=.02763149-a450-4e04-99b5-748d92b35714@github.com>
References: <T8JiNCNUKjV5bue6Bd8MjtatKCd9yik8cYMw2NIGTps=.02763149-a450-4e04-99b5-748d92b35714@github.com>
Message-ID: <spKZ5H9Tlp9sbiiQxMgpPtLcbWgcNkVzl64HzEueiTM=.e0661644-4de5-4f6a-9b95-7248c9b4ad6a@github.com>

On Fri, 9 Sep 2022 11:03:14 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> ### Summary of the change
> 
> The LDAP Naming Service Provider implementation's default settings are changed to disallow deserialization and reconstruction of Java objects from different LDAP attributes (RFC 2713). Currently, only the deserialization is controlled by the `com.sun.jndi.ldap.object.trustSerialData` system property, and it is allowed by default.
> The change proposed here switches the default value of the` com.sun.jndi.ldap.object.trustSerialData `system property to `"false"`, and also extends its scope to cover the reconstruction of RMI remote objects from the `javaRemoteLocation` LDAP attribute.
> 
> CSR for this change can be viewed [here](https://bugs.openjdk.org/browse/JDK-8290369).
> 
> ### List of code changes
> - Switch the default value of the 'com.sun.jndi.ldap.object.trustSerialData' system property to "false".
> 
> - Extend the scope of the property to also cover the reconstruction of RMI remote objects from the deprecated 'javaRemoteLocation' LDAP attribute.
> 
> - Document the support for `javaRemoteLocation` and the `javaReferenceAddress` LDAP attributes in `java.naming`'s module-info.
> 
> ### Test changes
> - New `test/jdk/com/sun/jndi/ldap/objects/RemoteLocationAttributeTest.java` test has been added to test that `com.sun.jndi.ldap.object.trustSerialData` system property can be used to control reconstruction of RMI objects from the `javaRemoteLocation` LDAP attribute.
> 
> -  `test/jdk/javax/naming/module/RunBasic.java` was modified to pass `com.sun.jndi.ldap.object.trustSerialData=true` to the sub-tests that rely on reconstruction/deserialization from LDAP attributes. 
> 
> - During the update for `test/jdk/javax/naming/module/RunBasic.java`, it was spotted that sub-tests apps launched in separate processes were returning the '0' exit value irrelevant to their execution status. All these sub-tests were modified to throw an exception when failure is observed. It helps to ensure that the exit value of launched process is not '0' for failed sub-tests.
> 
> ### Testing
> 
> `tier1`-`tier3` and JNDI regression/JCK tests not showing any failures related to this change.
> No failures observed for the modified regression tests.

This pull request has now been integrated.

Changeset: 7765942a
Author:    Aleksei Efimov <aefimov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7765942aeee25cbeb5fd932a93b3d8f9d4ca3655
Stats:     265 lines in 13 files changed: 213 ins; 3 del; 49 mod

8290367: Update default value and extend the scope of com.sun.jndi.ldap.object.trustSerialData system property

Reviewed-by: dfuchs, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/10228

From mbaesken at openjdk.org  Fri Sep 16 10:17:47 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 16 Sep 2022 10:17:47 GMT
Subject: RFR: JDK-8293701: jdeps InverseDepsAnalyzer runs into
 NoSuchElementException: No value present
In-Reply-To: <7P635gj5EB9YmaiqPH09VCJkKOy666nWu89aY-wWIMc=.36ecd9b1-5227-408f-a4d6-0ac3743c3ee4@github.com>
References: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
 <7P635gj5EB9YmaiqPH09VCJkKOy666nWu89aY-wWIMc=.36ecd9b1-5227-408f-a4d6-0ac3743c3ee4@github.com>
Message-ID: <LN5DiA5_bb0ZTrOlBIlO1Bt3MsT5ErMWKyedHj2zSM0=.96e25859-6c44-4c01-b04e-b6fe97d44ddf@github.com>

On Fri, 16 Sep 2022 08:38:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Do you think it would be possible to create a small test case that demonstrates the issue? A number of the fixes to jdeps in recent releases have be due to some unusual scenarios and I think it would be useful to build up more test cases for these scenarios, otherwise they could easily break again if there are no tests.

Hi Alan and Jaikiran , I agree  a small test case would be beneficial .  So far I unfortunately have only a large reproducer that cannot be shared and comes in the format of a couple of jars - far from ideal .

-------------

PR: https://git.openjdk.org/jdk/pull/10300

From lancea at openjdk.org  Fri Sep 16 11:01:02 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 16 Sep 2022 11:01:02 GMT
Subject: RFR: 8278165: Clarify that ZipInputStream does not access the CEN
 fields for a ZipEntry [v6]
In-Reply-To: <5xFWPl4un_Ymri2We2utzNAj9UuqMqzIzF8yex4thFg=.c3d990c5-8765-452b-9775-08071d0576b5@github.com>
References: <5xFWPl4un_Ymri2We2utzNAj9UuqMqzIzF8yex4thFg=.c3d990c5-8765-452b-9775-08071d0576b5@github.com>
Message-ID: <JI3qvJM8h9lY-27bn3ED_-O2L2yfua-nZGOT8JsNeXU=.a271f973-2791-4581-8126-c07f0c3e582d@github.com>

> Hi,
> 
> Please review this update to the ZipInputStream class description to clarify that ZipInputStream walks sequentially through each Zip Entry contained within the Zip File.  As a result, the CEN header for the Zip file entries are not read resulting in ZipInputStream not having access to information that is stored within the CEN Header fields such the as the external file attributes which can be used to store optional data such as Posix Permissions.

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Removing trailing space

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10102/files
  - new: https://git.openjdk.org/jdk/pull/10102/files/e15660e3..3e85f1d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10102&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10102&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10102.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10102/head:pull/10102

PR: https://git.openjdk.org/jdk/pull/10102

From alanb at openjdk.org  Fri Sep 16 11:51:43 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 Sep 2022 11:51:43 GMT
Subject: RFR: 8278165: Clarify that ZipInputStream does not access the CEN
 fields for a ZipEntry [v6]
In-Reply-To: <JI3qvJM8h9lY-27bn3ED_-O2L2yfua-nZGOT8JsNeXU=.a271f973-2791-4581-8126-c07f0c3e582d@github.com>
References: <5xFWPl4un_Ymri2We2utzNAj9UuqMqzIzF8yex4thFg=.c3d990c5-8765-452b-9775-08071d0576b5@github.com>
 <JI3qvJM8h9lY-27bn3ED_-O2L2yfua-nZGOT8JsNeXU=.a271f973-2791-4581-8126-c07f0c3e582d@github.com>
Message-ID: <uUEdJpl2AvzaVG8BFXAQ1w5StLnC0_833aGFf7f-_d0=.058ac7fe-7ed9-4301-8331-b4952b878977@github.com>

On Fri, 16 Sep 2022 11:01:02 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Hi,
>> 
>> Please review this update to the ZipInputStream class description to clarify that ZipInputStream walks sequentially through each Zip Entry contained within the Zip File.  As a result, the CEN header for the Zip file entries are not read resulting in ZipInputStream not having access to information that is stored within the CEN Header fields such the as the external file attributes which can be used to store optional data such as Posix Permissions.
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing trailing space

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10102

From alanb at openjdk.org  Fri Sep 16 12:40:44 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 Sep 2022 12:40:44 GMT
Subject: RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx
In-Reply-To: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
References: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
Message-ID: <4SHQpONNSUnaZdiFKPh9iPUS664dd88H2WYioUJOM8E=.e85b1f91-c404-40a2-80af-36f997ef2738@github.com>

On Fri, 16 Sep 2022 07:35:03 GMT, Leslie Zhai <lzhai at openjdk.org> wrote:

> Hi,
> 
> @dumasun reported the issue:
> 
> Configured with jfx-ls-modular-sdk:
> 
> 
> configure --with-import-modules=modular-sdk
> 
> 
> `make run-test CONF=fastdebug TEST="tools/launcher/FXLauncherTest.java"` failed:
> 
> 
> ----------System.err:(11/697)----------
> java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>     at FXLauncherTest.main(FXLauncherTest.java:451)
>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>     at java.base/java.lang.Thread.run(Thread.java:1589)
> 
> JavaTest Message: Test threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
> JavaTest Message: shutting down test
> 
> STATUS:Failed.`main' threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
> 
> 
> Thanks,
> Leslie Zhai

Can you try the following:

1. Change doFxCompile and doFxExec to use --upgrade-module-path instead of --module-path?
2. Remove the check for javafx.application.Application from the main method.

It would be interesting to check if it passes with regular builds of the JDK and your build that includes the JavaFX modules.

Note that the test summary includes the sentence "It also verifies that FX is, in fact, not included with the JDK" so that will need to change if the test is changed.

-------------

PR: https://git.openjdk.org/jdk/pull/10299

From kcr at openjdk.org  Fri Sep 16 13:05:39 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 16 Sep 2022 13:05:39 GMT
Subject: RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx
In-Reply-To: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
References: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
Message-ID: <rtNdDgOs61FHLvc3ZkpTZtxFw7B-WF-EDdwyOt_iXQk=.719a528e-44b7-4b07-8f07-df81c170beb2@github.com>

On Fri, 16 Sep 2022 07:35:03 GMT, Leslie Zhai <lzhai at openjdk.org> wrote:

> Hi,
> 
> @dumasun reported the issue:
> 
> Configured with jfx-ls-modular-sdk:
> 
> 
> configure --with-import-modules=modular-sdk
> 
> 
> `make run-test CONF=fastdebug TEST="tools/launcher/FXLauncherTest.java"` failed:
> 
> 
> ----------System.err:(11/697)----------
> java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>     at FXLauncherTest.main(FXLauncherTest.java:451)
>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>     at java.base/java.lang.Thread.run(Thread.java:1589)
> 
> JavaTest Message: Test threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
> JavaTest Message: shutting down test
> 
> STATUS:Failed.`main' threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
> 
> 
> Thanks,
> Leslie Zhai

It does seem worth trying `--patch-module` if the javafx.graphics module is present in the Java runtime. If that works, it is better than skipping the test, since you will then be able to continue testing the FX launcher.

Another possibility would be to go with your proposed solution of skipping the test if the javafx.graphics module is present, and provide a second test that is only run when the `javafx.graphics` module is present. In that case, you could test the actual FX launcher rather than the dummy implementation. This could either be done in this PR or as a follow-on test bug.

-------------

PR: https://git.openjdk.org/jdk/pull/10299

From mullan at openjdk.org  Fri Sep 16 13:16:53 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 16 Sep 2022 13:16:53 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v3]
In-Reply-To: <aZkbd6g9FC4Q6gGvqygI1B3F5tk6bj6JE6y17_lZGrw=.60e86c67-9f06-4b82-801a-131c3eb044bf@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <aZkbd6g9FC4Q6gGvqygI1B3F5tk6bj6JE6y17_lZGrw=.60e86c67-9f06-4b82-801a-131c3eb044bf@github.com>
Message-ID: <JdnXbrQe1rDRzupg-hiZip7CEa_7OuPafwdNWzpZods=.031f494b-eb2e-44e2-8f03-58220a34139b@github.com>

On Fri, 16 Sep 2022 09:45:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
>> 
>> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
>> 
>> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
>> 
>> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.
>
> 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 10 additional commits since the last revision:
> 
>  - Repalce "it" with "victim thread"
>  - Merge
>  - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop
>  - become -> became in javadoc
>  - Merge
>  - Remove stopThread permission from RuntimePermission table, exclude jshell tests
>  - Deprecate for removal
>  - Next iteration, update dates in headers
>  - Merge
>  - Initial commit

Marked as reviewed by mullan (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10230

From alanb at openjdk.org  Fri Sep 16 13:34:48 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 Sep 2022 13:34:48 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v4]
In-Reply-To: <bHrBh3zv6i5YDa0Hhgs_QCAql8IOnmE4GUZrAQ_ResU=.bb9a98fe-6f13-42cf-a410-d1c3bee62b6a@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <bHrBh3zv6i5YDa0Hhgs_QCAql8IOnmE4GUZrAQ_ResU=.bb9a98fe-6f13-42cf-a410-d1c3bee62b6a@github.com>
Message-ID: <YLGNytqSz0Bro3G5f3si3lmHLzLYDe6CBRsNj82dpEI=.83e2878b-35dc-4895-8842-0514ccdc95cd@github.com>

On Wed, 14 Sep 2022 16:43:43 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
>> 
>> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
>> 
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address latest input regarding wording

src/java.base/share/classes/java/util/jar/JarInputStream.java line 44:

> 42:  * The {@link #getManifest} method will return the {@code Manifest} when it is
> 43:  * the first entry in the stream, or {@code META-INF/} is the first entry and
> 44:  * the {@code Manifest} is the second entry within the stream.

"within the stream" should probably be "in the stream" to be consistent the first part of the sentence.

src/java.base/share/classes/java/util/jar/JarInputStream.java line 51:

> 49:  * If {@code META-INF/} is the first entry in the input stream it will be
> 50:  * also not be returned by {@link #getNextEntry()} and
> 51:  * {@link #getNextJarEntry()}.

JAR files will almost always have the manifest as the first or second entry. It's very hazardous to have getNextEntry/getNextJarEntry work differently when the manifest is present but not at the start. This makes it really hard to specify too. I wonder what the impact would be of changing the implementation so that getNextEntry/getNextJarEntry consistently skip the manifest rather than only when it's at the start. I can't think of anything right now that could dependent on the current behavior where it might or might be returned.

src/java.base/share/classes/java/util/jar/JarInputStream.java line 78:

> 76:  *  the signers.
> 77:  * <p>
> 78:  * <b>Note:</b> If a {@code JarEntry} is modified after the JAR file is signed,

Can this be an apiNote?

-------------

PR: https://git.openjdk.org/jdk/pull/10045

From rriggs at openjdk.org  Fri Sep 16 14:01:44 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 16 Sep 2022 14:01:44 GMT
Subject: RFR: 8289797: tools/launcher/I18NArgTest.java fails on Japanese
 Windows environment [v3]
In-Reply-To: <Xu96knBpaa0kvEv_RtoXuIHahBieArKuvn26mISRu6s=.80832925-513a-4859-b0d0-6fe1c49062fc@github.com>
References: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
 <B4rHHDtIaxlHyH2YF9HMOuOf6sNeC7bsYhe3NfdgUqM=.a995ec62-0d39-4f43-95c5-03261ae325c0@github.com>
 <VRTnyuy9Qmw8lfm0_6PJtie5trsXqVQjY4mmt_fpE88=.afda6e0b-5be8-4629-9816-361ec8d243ad@github.com>
 <Xu96knBpaa0kvEv_RtoXuIHahBieArKuvn26mISRu6s=.80832925-513a-4859-b0d0-6fe1c49062fc@github.com>
Message-ID: <ozAQVBDrDFq8ZyuOVckfu3t_TSvpvRBFj_6k_YA8jJc=.64883f07-eb4a-4419-aeaf-9ffbb86b4d5b@github.com>

On Fri, 16 Sep 2022 08:31:19 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

>> test/jdk/tools/launcher/I18NArgTest.java line 147:
>> 
>>> 145:             for (int i = 0; i < sysPropVal.length(); i++) {
>>> 146:                 sysPropHexVal = sysPropHexVal.concat(Integer.toHexString(sysPropVal.charAt(i)));
>>> 147:             }
>> 
>> It's OK as it stands, but this loop could be replaced with a `HexFormat` one-liner.
>
> I'm sorry, I can't replace this code with a HexFormat one-line. Do you have an example code?

Extract to a byte array with the appropriate charset and then HexFormat the bytearray.


    var SysPropHexVal = HexFormat.of().formatHex(sysPropVal.getBytes(StandardCharsets.UTF_16));

-------------

PR: https://git.openjdk.org/jdk/pull/9389

From lancea at openjdk.org  Fri Sep 16 16:20:41 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 16 Sep 2022 16:20:41 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v5]
In-Reply-To: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
Message-ID: <g0ssx4ma6ABj_3rZdRwc38kZL-oCQ2qbGrEzZo9Slv4=.a3732275-2f7d-4a5e-8a01-da69b06fc2f1@github.com>

> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
> 
> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
> 
> 
> Best,
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Address additional javadoc comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10045/files
  - new: https://git.openjdk.org/jdk/pull/10045/files/10ddfd31..6d7795fe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10045&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10045&range=03-04

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10045.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10045/head:pull/10045

PR: https://git.openjdk.org/jdk/pull/10045

From lancea at openjdk.org  Fri Sep 16 16:20:45 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 16 Sep 2022 16:20:45 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v4]
In-Reply-To: <YLGNytqSz0Bro3G5f3si3lmHLzLYDe6CBRsNj82dpEI=.83e2878b-35dc-4895-8842-0514ccdc95cd@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <bHrBh3zv6i5YDa0Hhgs_QCAql8IOnmE4GUZrAQ_ResU=.bb9a98fe-6f13-42cf-a410-d1c3bee62b6a@github.com>
 <YLGNytqSz0Bro3G5f3si3lmHLzLYDe6CBRsNj82dpEI=.83e2878b-35dc-4895-8842-0514ccdc95cd@github.com>
Message-ID: <V4WsTSOPO0A5BqIQ9lQpyc9ipKzkpFD3IfHFWktCB_M=.2e51f394-d332-48d5-b8b9-1eb609bb1a53@github.com>

On Fri, 16 Sep 2022 13:06:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address latest input regarding wording
>
> src/java.base/share/classes/java/util/jar/JarInputStream.java line 44:
> 
>> 42:  * The {@link #getManifest} method will return the {@code Manifest} when it is
>> 43:  * the first entry in the stream, or {@code META-INF/} is the first entry and
>> 44:  * the {@code Manifest} is the second entry within the stream.
> 
> "within the stream" should probably be "in the stream" to be consistent the first part of the sentence.

Updated as you suggested

> src/java.base/share/classes/java/util/jar/JarInputStream.java line 51:
> 
>> 49:  * If {@code META-INF/} is the first entry in the input stream it will be
>> 50:  * also not be returned by {@link #getNextEntry()} and
>> 51:  * {@link #getNextJarEntry()}.
> 
> JAR files will almost always have the manifest as the first or second entry. It's very hazardous to have getNextEntry/getNextJarEntry work differently when the manifest is present but not at the start. This makes it really hard to specify too. I wonder what the impact would be of changing the implementation so that getNextEntry/getNextJarEntry consistently skip the manifest rather than only when it's at the start. I can't think of anything right now that could dependent on the current behavior where it might or might be returned.

I tend to agree but am reluctant to change 20+ year behavior via this PR as we don't know what we don't know.

> src/java.base/share/classes/java/util/jar/JarInputStream.java line 78:
> 
>> 76:  *  the signers.
>> 77:  * <p>
>> 78:  * <b>Note:</b> If a {@code JarEntry} is modified after the JAR file is signed,
> 
> Can this be an apiNote?

Sure Updated as suggested

-------------

PR: https://git.openjdk.org/jdk/pull/10045

From naoto at openjdk.org  Fri Sep 16 16:21:46 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 16 Sep 2022 16:21:46 GMT
Subject: RFR: 8289797: tools/launcher/I18NArgTest.java fails on Japanese
 Windows environment [v3]
In-Reply-To: <ozAQVBDrDFq8ZyuOVckfu3t_TSvpvRBFj_6k_YA8jJc=.64883f07-eb4a-4419-aeaf-9ffbb86b4d5b@github.com>
References: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
 <B4rHHDtIaxlHyH2YF9HMOuOf6sNeC7bsYhe3NfdgUqM=.a995ec62-0d39-4f43-95c5-03261ae325c0@github.com>
 <VRTnyuy9Qmw8lfm0_6PJtie5trsXqVQjY4mmt_fpE88=.afda6e0b-5be8-4629-9816-361ec8d243ad@github.com>
 <Xu96knBpaa0kvEv_RtoXuIHahBieArKuvn26mISRu6s=.80832925-513a-4859-b0d0-6fe1c49062fc@github.com>
 <ozAQVBDrDFq8ZyuOVckfu3t_TSvpvRBFj_6k_YA8jJc=.64883f07-eb4a-4419-aeaf-9ffbb86b4d5b@github.com>
Message-ID: <djedmAC0dHkHyeGxras2oHpdXMeY7EyXTYDyOnlPLTM=.eee0e269-cc45-4e90-8b15-ff7deae342bd@github.com>

On Fri, 16 Sep 2022 13:59:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I'm sorry, I can't replace this code with a HexFormat one-line. Do you have an example code?
>
> Extract to a byte array with the appropriate charset and then HexFormat the bytearray.
> 
> 
>     var SysPropHexVal = HexFormat.of().formatHex(sysPropVal.getBytes(StandardCharsets.UTF_16));

Thanks, Roger. You beat me to it ?

-------------

PR: https://git.openjdk.org/jdk/pull/9389

From mchung at openjdk.org  Fri Sep 16 16:44:42 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 16 Sep 2022 16:44:42 GMT
Subject: RFR: JDK-8293892: Add links to JVMS 19 and 20 from
 ClassFileFormatVersion enum constants
In-Reply-To: <IByqVSHVGiBnbV6_kt-d-GPQb3VxbmpgwG0ff8voTvs=.9dfdca89-b870-4474-82e5-d82877f164c6@github.com>
References: <IByqVSHVGiBnbV6_kt-d-GPQb3VxbmpgwG0ff8voTvs=.9dfdca89-b870-4474-82e5-d82877f164c6@github.com>
Message-ID: <BMJgSCBIxWEjMaWql6JJSmEBgIUIrlxYQ3DUfHBPRTQ=.5bdd9109-7339-441e-880d-aaf454b20338@github.com>

On Fri, 16 Sep 2022 02:59:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Analogous fix to one already done for javax.lang.model.SourceVersion (JDK-8293768), the links to JVMS 19 and 20 are not currently valid, but redirect to the spec language page
> 
> https://docs.oracle.com/javase/specs/index.html
> 
> The URLs will become valid when 19 and 20, respectively, ship.

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10298

From mchung at openjdk.org  Fri Sep 16 16:45:46 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 16 Sep 2022 16:45:46 GMT
Subject: RFR: JDK-8293659: Improve UnsatisfiedLinkError error message to
 include dlopen error details [v2]
In-Reply-To: <xF7xU_nv7od9QNvVMREbQGelSOQ0okJPyTnoQhkK2w0=.83257c39-be99-41ea-adf5-6affb2712f22@github.com>
References: <ifR_svzVaPWpTZ48Mm7a_bANpIvAgQB1HEiBrXlA0oQ=.1dd92d2d-c9f2-4bbf-9a02-8bde08cdb8fb@github.com>
 <xF7xU_nv7od9QNvVMREbQGelSOQ0okJPyTnoQhkK2w0=.83257c39-be99-41ea-adf5-6affb2712f22@github.com>
Message-ID: <hRAk8sVpyBaLR3C3XITrltWbJWWn4-plKgRxBg_qme8=.4129d868-b77d-4fcd-a9da-c469bac28e7d@github.com>

On Fri, 16 Sep 2022 07:27:44 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When trying to load a x64 lib on macOS aarch64 one got previously this detailed message before [JDK-8275703](https://bugs.openjdk.org/browse/JDK-8275703):
>> 
>> java.lang.UnsatisfiedLinkError: /testing/jco3/macOsx64/libsapjco3.dylib: dlopen(/testing/jco3/macOsx64/libsapjco3.dylib, 1): no suitable image found. Did find:
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust throwExceptionIfFail

Looks good to me.  Thanks for taking this.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10286

From mchung at openjdk.org  Fri Sep 16 16:49:44 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 16 Sep 2022 16:49:44 GMT
Subject: RFR: 8293499: Provide jmod --compress option [v7]
In-Reply-To: <NtlQYsnqYp5rh3OVL0OYtYlHhi6rYNft1DoXrNFFjYA=.7e847323-9b01-40eb-89f7-713667f290de@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
 <NtlQYsnqYp5rh3OVL0OYtYlHhi6rYNft1DoXrNFFjYA=.7e847323-9b01-40eb-89f7-713667f290de@github.com>
Message-ID: <giagyk1C1cz0TumgSdq6x2ncV3iRSuHUDxaq3I356eQ=.4dcd1652-d08a-4893-8d97-9a654d3f1e58@github.com>

On Fri, 16 Sep 2022 08:03:28 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I have been looking into `make clean-images images` performance, and realized jmod keeps compressing files with default compression level. Tuning that toward lighter compression levels improves build performance considerably, without a heavy loss in *.jmod sizes. 
>> 
>> This PR allows JMOD to select the compression level. Follow-ups would use this in the build system, see #10214.
>> 
>> The interesting asymmetry against `jlink` is: `jlink` provides `--compress` option that only takes `2` for "ZIP compression". (Separately, we could argue if it would be beneficial to extend `--compress` to `jlink` as well, so to select the compression level there too.)
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup quotes in parameter help

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10213

From darcy at openjdk.org  Fri Sep 16 16:56:53 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 16 Sep 2022 16:56:53 GMT
Subject: Integrated: JDK-8293892: Add links to JVMS 19 and 20 from
 ClassFileFormatVersion enum constants
In-Reply-To: <IByqVSHVGiBnbV6_kt-d-GPQb3VxbmpgwG0ff8voTvs=.9dfdca89-b870-4474-82e5-d82877f164c6@github.com>
References: <IByqVSHVGiBnbV6_kt-d-GPQb3VxbmpgwG0ff8voTvs=.9dfdca89-b870-4474-82e5-d82877f164c6@github.com>
Message-ID: <NXMKgr628TSrU1UdGk7HIuNS4_CNyRxU0ys27YyVORI=.40a681f8-a8db-429f-b01b-d6afbd7e532c@github.com>

On Fri, 16 Sep 2022 02:59:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Analogous fix to one already done for javax.lang.model.SourceVersion (JDK-8293768), the links to JVMS 19 and 20 are not currently valid, but redirect to the spec language page
> 
> https://docs.oracle.com/javase/specs/index.html
> 
> The URLs will become valid when 19 and 20, respectively, ship.

This pull request has now been integrated.

Changeset: 4b297c1c
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4b297c1c16fd2b3ae04694de1b772218e15c1ec8
Stats:     8 lines in 1 file changed: 8 ins; 0 del; 0 mod

8293892: Add links to JVMS 19 and 20 from ClassFileFormatVersion enum constants

Reviewed-by: sundar, mchung

-------------

PR: https://git.openjdk.org/jdk/pull/10298

From redestad at openjdk.org  Fri Sep 16 16:59:44 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 16 Sep 2022 16:59:44 GMT
Subject: RFR: 8293499: Provide jmod --compress option [v7]
In-Reply-To: <NtlQYsnqYp5rh3OVL0OYtYlHhi6rYNft1DoXrNFFjYA=.7e847323-9b01-40eb-89f7-713667f290de@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
 <NtlQYsnqYp5rh3OVL0OYtYlHhi6rYNft1DoXrNFFjYA=.7e847323-9b01-40eb-89f7-713667f290de@github.com>
Message-ID: <GwShEcaJYy8IAEPzvlWOlxwmajRCTayF-hlf6sG8qwU=.a8a1ca35-c677-4b6c-9ace-73022f20b001@github.com>

On Fri, 16 Sep 2022 08:03:28 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I have been looking into `make clean-images images` performance, and realized jmod keeps compressing files with default compression level. Tuning that toward lighter compression levels improves build performance considerably, without a heavy loss in *.jmod sizes. 
>> 
>> This PR allows JMOD to select the compression level. Follow-ups would use this in the build system, see #10214.
>> 
>> The interesting asymmetry against `jlink` is: `jlink` provides `--compress` option that only takes `2` for "ZIP compression". (Separately, we could argue if it would be beneficial to extend `--compress` to `jlink` as well, so to select the compression level there too.)
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup quotes in parameter help

Marked as reviewed by redestad (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10213

From alanb at openjdk.org  Fri Sep 16 18:03:47 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 Sep 2022 18:03:47 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v4]
In-Reply-To: <V4WsTSOPO0A5BqIQ9lQpyc9ipKzkpFD3IfHFWktCB_M=.2e51f394-d332-48d5-b8b9-1eb609bb1a53@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <bHrBh3zv6i5YDa0Hhgs_QCAql8IOnmE4GUZrAQ_ResU=.bb9a98fe-6f13-42cf-a410-d1c3bee62b6a@github.com>
 <YLGNytqSz0Bro3G5f3si3lmHLzLYDe6CBRsNj82dpEI=.83e2878b-35dc-4895-8842-0514ccdc95cd@github.com>
 <V4WsTSOPO0A5BqIQ9lQpyc9ipKzkpFD3IfHFWktCB_M=.2e51f394-d332-48d5-b8b9-1eb609bb1a53@github.com>
Message-ID: <ZOWXisIp8nY6jq8y-nYDWQFTVeWI6bYuNas5IRZx4p8=.ac9f82ad-d1a6-4dad-b469-955d9c42d59b@github.com>

On Fri, 16 Sep 2022 16:15:44 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/jar/JarInputStream.java line 51:
>> 
>>> 49:  * If {@code META-INF/} is the first entry in the input stream it will be
>>> 50:  * also not be returned by {@link #getNextEntry()} and
>>> 51:  * {@link #getNextJarEntry()}.
>> 
>> JAR files will almost always have the manifest as the first or second entry. It's very hazardous to have getNextEntry/getNextJarEntry work differently when the manifest is present but not at the start. This makes it really hard to specify too. I wonder what the impact would be of changing the implementation so that getNextEntry/getNextJarEntry consistently skip the manifest rather than only when it's at the start. I can't think of anything right now that could dependent on the current behavior where it might or might be returned.
>
> I tend to agree but am reluctant to change 20+ year behavior via this PR as we don't know what we don't know.

Okay, in which case what would you think about just saying that the getNextEntry/getNextJarEntry method do not return the Manifest when it's at the start of the stream, and it's unspecified whether they return the Manifest when it located later in the stream. I think this would give us wriggle room to change it in the future.

-------------

PR: https://git.openjdk.org/jdk/pull/10045

From lancea at openjdk.org  Fri Sep 16 18:37:44 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 16 Sep 2022 18:37:44 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v4]
In-Reply-To: <ZOWXisIp8nY6jq8y-nYDWQFTVeWI6bYuNas5IRZx4p8=.ac9f82ad-d1a6-4dad-b469-955d9c42d59b@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <bHrBh3zv6i5YDa0Hhgs_QCAql8IOnmE4GUZrAQ_ResU=.bb9a98fe-6f13-42cf-a410-d1c3bee62b6a@github.com>
 <YLGNytqSz0Bro3G5f3si3lmHLzLYDe6CBRsNj82dpEI=.83e2878b-35dc-4895-8842-0514ccdc95cd@github.com>
 <V4WsTSOPO0A5BqIQ9lQpyc9ipKzkpFD3IfHFWktCB_M=.2e51f394-d332-48d5-b8b9-1eb609bb1a53@github.com>
 <ZOWXisIp8nY6jq8y-nYDWQFTVeWI6bYuNas5IRZx4p8=.ac9f82ad-d1a6-4dad-b469-955d9c42d59b@github.com>
Message-ID: <5Izo5-kThb-CKVAmWq8qddyccWZfhp_1pahxJxbPXvA=.1add8dec-f1ea-49a7-abe2-ceedd1189fb9@github.com>

On Fri, 16 Sep 2022 18:01:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Okay, in which case what would you think about just saying that the getNextEntry/getNextJarEntry method do not return the Manifest when it's at the start of the stream, and it's unspecified whether they return the Manifest when it located later in the stream. I think this would give us wriggle room to change it in the future.

Is this any better:



 * <p>
 * When the {@code Manifest} is returned by {@code getManifest()}, the {@link #getNextEntry()}
 * and {@link #getNextJarEntry()} methods will not return the {@code Manifest}.
 * If {@code META-INF/} is the first entry in the input stream it will be
 * also not be returned by {@link #getNextEntry()} and {@link #getNextJarEntry()}. 
 * </p>
 * @apiNote 
 * It is unspecified whether {@link #getNextEntry()} and
 * {@link #getNextJarEntry()} will return the {@code Manifest}
 * when the {@code Manifest} occurs later in the input stream.
 * <p>
 * {@link JarEntry#getAttributes()} will return the {@code Manifest}'s
 *  attributes for the current JAR file entry, if any, providing
 *  {@code getManifest()} returns a {@code Manifest} for the JAR file.
 * </p>

-------------

PR: https://git.openjdk.org/jdk/pull/10045

From lancea at openjdk.org  Fri Sep 16 18:54:51 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 16 Sep 2022 18:54:51 GMT
Subject: Integrated: 8278165: Clarify that ZipInputStream does not access the
 CEN fields for a ZipEntry
In-Reply-To: <5xFWPl4un_Ymri2We2utzNAj9UuqMqzIzF8yex4thFg=.c3d990c5-8765-452b-9775-08071d0576b5@github.com>
References: <5xFWPl4un_Ymri2We2utzNAj9UuqMqzIzF8yex4thFg=.c3d990c5-8765-452b-9775-08071d0576b5@github.com>
Message-ID: <qpv-fM4oGujIfSlRiq7U30NqIQaYLGuxoCRXacL2ojw=.17adb74e-d8ec-4611-8037-b35e36d92c11@github.com>

On Wed, 31 Aug 2022 16:06:57 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi,
> 
> Please review this update to the ZipInputStream class description to clarify that ZipInputStream walks sequentially through each Zip Entry contained within the Zip File.  As a result, the CEN header for the Zip file entries are not read resulting in ZipInputStream not having access to information that is stored within the CEN Header fields such the as the external file attributes which can be used to store optional data such as Posix Permissions.

This pull request has now been integrated.

Changeset: a8f0f575
Author:    Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a8f0f575abab53e89fc315a68394b556543cbb2e
Stats:     30 lines in 1 file changed: 27 ins; 0 del; 3 mod

8278165: Clarify that ZipInputStream does not access the CEN fields for a ZipEntry

Reviewed-by: bpb, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/10102

From mchung at openjdk.org  Fri Sep 16 19:04:51 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 16 Sep 2022 19:04:51 GMT
Subject: RFR: JDK-8293701: jdeps InverseDepsAnalyzer runs into
 NoSuchElementException: No value present
In-Reply-To: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
References: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
Message-ID: <0Qrh5uG_labY8ipk1D70HvY74RUFUR4960LuyFLZL1Q=.571c158b-12ac-4c82-bee0-d441ceb1416b@github.com>

On Fri, 16 Sep 2022 08:26:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We noticed that with certain jar file input, jdeps runs into the following exception, this happens with jdk11, 17 and 20.
> 
> jdeps.exe --multi-release 11 --module-path . --inverse --package com.sap.nw.performance.supa.client test.jar
> 
> Inverse transitive dependences matching packages [com.sap.nw.performance.supa.client]
> Exception in thread "main" java.util.NoSuchElementException: No value present
>         at java.base/java.util.Optional.get(Optional.java:148)
>         at jdk.jdeps/com.sun.tools.jdeps.InverseDepsAnalyzer.lambda$inverseDependences$2(InverseDepsAnalyzer.java:150)
>         at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>         at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>         at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
>         at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>         at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> 
> So an additional  check might be a good idea.

What is the cause of this issue?   It expects the dependency can be found but missing in this case.   I wonder if it's due to a `requires static` dependency?

-------------

PR: https://git.openjdk.org/jdk/pull/10300

From duke at openjdk.org  Fri Sep 16 19:16:42 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 16 Sep 2022 19:16:42 GMT
Subject: RFR: 8292698: Improve performance of DataInputStream [v4]
In-Reply-To: <8Rm-eVp7g0Z5PojiU5DwSU2Cuej9zlFtDdKBkUljazo=.0a1c4182-3ade-4da4-b235-f7412bee3140@github.com>
References: <MXdBQj8qYqvvImT-MaBpf8mAm3b1tbNiPS93syrjfqg=.3ebdd952-f9d7-4ec9-9655-a63829828c67@github.com>
 <8Rm-eVp7g0Z5PojiU5DwSU2Cuej9zlFtDdKBkUljazo=.0a1c4182-3ade-4da4-b235-f7412bee3140@github.com>
Message-ID: <pbj9k87XAnzII__UkvfUyMVBDHQCGKr1eYEDC88j-3E=.ea33cb2e-5e56-4533-b7cd-bf274ff9412a@github.com>

On Mon, 29 Aug 2022 08:46:20 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> I found out that reading from `DataInputStream` wrapping `ByteArrayInputStream` (as well as `BufferedInputStream` or any `InputStream` relying on `byte[]`) can be significantly improved by accessing volatile `in` field only once per operation.
>> 
>> Current implementation does it for each call of `in.read()`, i.e. in `readInt()` method we do it 4 times:
>> 
>> public final int readInt() throws IOException {
>>     int ch1 = in.read();
>>     int ch2 = in.read();
>>     int ch3 = in.read();
>>     int ch4 = in.read();
>>     if ((ch1 | ch2 | ch3 | ch4) < 0)
>>         throw new EOFException();
>>     return ((ch1 << 24) + (ch2 << 16) + (ch3 << 8) + (ch4 << 0));
>> }
>> 
>> Apparently accessing volatile reference with underlying `byte[]` prevents runtime from doing some optimizations, so dereferencing local variable should be more efficient.
>> 
>> Benchmarking:
>> 
>> baseline:
>> 
>> Benchmark                     Mode  Cnt   Score   Error  Units
>> DataInputStreamTest.readChar  avgt   20  22,889 ? 0,648  us/op
>> DataInputStreamTest.readInt   avgt   20  21,804 ? 0,197  us/op
>> 
>> patch:
>> 
>> Benchmark                     Mode  Cnt   Score   Error  Units
>> DataInputStreamTest.readChar  avgt   20  11,018 ? 0,089  us/op
>> DataInputStreamTest.readInt   avgt   20   5,608 ? 0,087  us/op
>
> ?????? ??????? 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:
> 
>  - 8292698: Reuse existing code
>  - Merge branch 'master' into 8292698
>  - 8292698: Fix copyright year
>  - 8292698: Revert dubious changes
>  - 8292698: Improve performance of reading from DataInputStream

Btw, the changes is quite simple, so could it be backported to JDK11 and JDK17 updates?

-------------

PR: https://git.openjdk.org/jdk/pull/9956

From almatvee at openjdk.org  Fri Sep 16 23:02:25 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 16 Sep 2022 23:02:25 GMT
Subject: RFR: 8293462: [macos] app image signature invalid when creating DMG or
 PKG from post processed signed image
Message-ID: <-sMR9P3CEZeJ31UFe7bzIcnC86rSErUVbY0GOymUoo4=.7c954bca-25c7-4fa0-9e2a-076ce2a485d4@github.com>

Problem is that [JDK-8286850](https://bugs.openjdk.org/browse/JDK-8286850) never set correct value in .jpackage.xml to mark image as signed. [JDK-8289030](https://bugs.openjdk.org/browse/JDK-8289030) reads this value to check if we can add per-user and system wide configuration to packaged app. Fixed by setting correct value in .jpackage.xml when we signing predefine application image.

Added tests to cover this case and added check for values inside .jpackage.xml to validate signed and Mac App Store values.

-------------

Commit messages:
 - 8293462: [macos] app image signature invalid when creating DMG or PKG from post processed signed image

Changes: https://git.openjdk.org/jdk/pull/10316/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10316&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293462
  Stats: 367 lines in 12 files changed: 303 ins; 15 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/10316.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10316/head:pull/10316

PR: https://git.openjdk.org/jdk/pull/10316

From mik3hall at gmail.com  Sat Sep 17 01:19:58 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Fri, 16 Sep 2022 20:19:58 -0500
Subject: RFR: 8293462: [macos] app image signature invalid when creating
 DMG or PKG from post processed signed image
In-Reply-To: <-sMR9P3CEZeJ31UFe7bzIcnC86rSErUVbY0GOymUoo4=.7c954bca-25c7-4fa0-9e2a-076ce2a485d4@github.com>
References: <-sMR9P3CEZeJ31UFe7bzIcnC86rSErUVbY0GOymUoo4=.7c954bca-25c7-4fa0-9e2a-076ce2a485d4@github.com>
Message-ID: <20F8AC2D-C71B-4892-A2F3-C9A07501046F@gmail.com>



> On Sep 16, 2022, at 6:02 PM, Alexander Matveev <almatvee at openjdk.org> wrote:
> 
> Problem is that [JDK-8286850](https://bugs.openjdk.org/browse/JDK-8286850 <https://bugs.openjdk.org/browse/JDK-8286850>) never set correct value in .jpackage.xml to mark image as signed. [JDK-8289030](https://bugs.openjdk.org/browse/JDK-8289030 <https://bugs.openjdk.org/browse/JDK-8289030>) reads this value to check if we can add per-user and system wide configuration to packaged app. Fixed by setting correct value in .jpackage.xml when we signing predefine application image.

Alexander,

I think I figured out how to include PR?s in my build and this appears good.

codesign -v --verbose=4 "/Volumes/BlackJack Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app"
/Volumes/BlackJack Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app: valid on disk
/Volumes/BlackJack Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app: satisfies its Designated Requirement

This was new?
Warning: Support for per-user configuration of the installed application will not be supported due to missing "BlackJack Blastoff_Unsigned.app/Contents/app/.package" in predefined signed application image.

I?m not quite sure what it?s saying but it doesn?t seem to impact what I?m doing.

Thanks,
Mike

FWIW, I ran into 
[macos] cmstypes.c fails compilation with Xcode13.3
https://bugs.openjdk.org/browse/JDK-8283221 <https://bugs.openjdk.org/browse/JDK-8283221>

Adding this which I noticed in the source?
cmsUNUSED_PARAMETER(SizeOfTag);    // mjh

To the two erroring methods?
~/Documents/GitHub/jdk/build/macosx-x86_64-server-release/build.log:179: /Users/mjh/Documents/GitHub/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:3441:132: error: parameter 'SizeOfTag' set but not used [-Werror,-Wunused-but-set-parameter]
~/Documents/GitHub/jdk/build/macosx-x86_64-server-release/build.log:182: /Users/mjh/Documents/GitHub/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:5137:125: error: parameter 'SizeOfTag' set but not used [-Werror,-Wunused-but-set-parameter]


Seemed a fix. I could build.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220916/e0f5e9de/attachment-0001.htm>

From jpai at openjdk.org  Sat Sep 17 03:23:33 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 17 Sep 2022 03:23:33 GMT
Subject: RFR: 8293499: Provide jmod --compress option [v7]
In-Reply-To: <NtlQYsnqYp5rh3OVL0OYtYlHhi6rYNft1DoXrNFFjYA=.7e847323-9b01-40eb-89f7-713667f290de@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
 <NtlQYsnqYp5rh3OVL0OYtYlHhi6rYNft1DoXrNFFjYA=.7e847323-9b01-40eb-89f7-713667f290de@github.com>
Message-ID: <LnaF9sbjnEMVynxSRd2RaXdQBUIG2Ehd7V5lk2ur98g=.3057322c-8688-478b-b31c-97cfd144ec7b@github.com>

On Fri, 16 Sep 2022 08:03:28 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I have been looking into `make clean-images images` performance, and realized jmod keeps compressing files with default compression level. Tuning that toward lighter compression levels improves build performance considerably, without a heavy loss in *.jmod sizes. 
>> 
>> This PR allows JMOD to select the compression level. Follow-ups would use this in the build system, see #10214.
>> 
>> The interesting asymmetry against `jlink` is: `jlink` provides `--compress` option that only takes `2` for "ZIP compression". (Separately, we could argue if it would be beneficial to extend `--compress` to `jlink` as well, so to select the compression level there too.)
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup quotes in parameter help

Marked as reviewed by jpai (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10213

From lzhai at openjdk.org  Sat Sep 17 04:03:35 2022
From: lzhai at openjdk.org (Leslie Zhai)
Date: Sat, 17 Sep 2022 04:03:35 GMT
Subject: RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx
 [v2]
In-Reply-To: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
References: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
Message-ID: <eLkziaKhG6kfuVWg-zc6HxccXS9aL_wTUjOf8G7oR9s=.4892bc1b-fcb0-4e28-9a6d-53f38213665c@github.com>

> Hi,
> 
> @dumasun reported the issue:
> 
> Configured with jfx-ls-modular-sdk:
> 
> 
> configure --with-import-modules=modular-sdk
> 
> 
> `make run-test CONF=fastdebug TEST="tools/launcher/FXLauncherTest.java"` failed:
> 
> 
> ----------System.err:(11/697)----------
> java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>     at FXLauncherTest.main(FXLauncherTest.java:451)
>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>     at java.base/java.lang.Thread.run(Thread.java:1589)
> 
> JavaTest Message: Test threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
> JavaTest Message: shutting down test
> 
> STATUS:Failed.`main' threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
> 
> 
> Thanks,
> Leslie Zhai

Leslie Zhai has updated the pull request incrementally with one additional commit since the last revision:

  8293910: Try --upgrade-module-path and --patch-module but still failed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10299/files
  - new: https://git.openjdk.org/jdk/pull/10299/files/04aa629e..360148f2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10299&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10299&range=00-01

  Stats: 23 lines in 1 file changed: 15 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10299.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10299/head:pull/10299

PR: https://git.openjdk.org/jdk/pull/10299

From lzhai at openjdk.org  Sat Sep 17 04:04:54 2022
From: lzhai at openjdk.org (Leslie Zhai)
Date: Sat, 17 Sep 2022 04:04:54 GMT
Subject: RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx
 [v2]
In-Reply-To: <eLkziaKhG6kfuVWg-zc6HxccXS9aL_wTUjOf8G7oR9s=.4892bc1b-fcb0-4e28-9a6d-53f38213665c@github.com>
References: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
 <eLkziaKhG6kfuVWg-zc6HxccXS9aL_wTUjOf8G7oR9s=.4892bc1b-fcb0-4e28-9a6d-53f38213665c@github.com>
Message-ID: <QWlIpH0wHfeL22lFhFDCPTvQJGhNQkYVib6CBfNUK5M=.2ae16331-aeb5-4175-b8c6-2ed9923e7e3f@github.com>

On Sat, 17 Sep 2022 04:03:35 GMT, Leslie Zhai <lzhai at openjdk.org> wrote:

>> Hi,
>> 
>> @dumasun reported the issue:
>> 
>> Configured with jfx-ls-modular-sdk:
>> 
>> 
>> configure --with-import-modules=modular-sdk
>> 
>> 
>> `make run-test CONF=fastdebug TEST="tools/launcher/FXLauncherTest.java"` failed:
>> 
>> 
>> ----------System.err:(11/697)----------
>> java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>>     at FXLauncherTest.main(FXLauncherTest.java:451)
>>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>     at java.base/java.lang.Thread.run(Thread.java:1589)
>> 
>> JavaTest Message: Test threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>> JavaTest Message: shutting down test
>> 
>> STATUS:Failed.`main' threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>> 
>> 
>> Thanks,
>> Leslie Zhai
>
> Leslie Zhai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293910: Try --upgrade-module-path and --patch-module but still failed

test/jdk/tools/launcher/FXLauncherTest.java line 249:

> 247:             fxCmds.add(2, "--add-modules=javafx.graphics");
> 248:         } else {
> 249:             fxCmds.add(1, "--upgrade-module-path=" + IMPORT_MODULE_DIR);

Hi @kevinrushforth @AlanBateman 

Please point out my fault if I misunderstanding.

Thanks,
Leslie Zhai

-------------

PR: https://git.openjdk.org/jdk/pull/10299

From duke at openjdk.org  Sat Sep 17 06:39:40 2022
From: duke at openjdk.org (Rahul Prabhu)
Date: Sat, 17 Sep 2022 06:39:40 GMT
Subject: RFR: 8289508: Improve test coverage for XPath Axes: ancestor,
 ancestor-or-self, preceding, and preceding-sibling [v5]
In-Reply-To: <xn1BRpM7AtPakAYm2AdbtoddvmCNqP3wBPwjMGUPx8w=.4aaac0f2-1383-4e45-b49e-d1da3cfbdf43@github.com>
References: <xn1BRpM7AtPakAYm2AdbtoddvmCNqP3wBPwjMGUPx8w=.4aaac0f2-1383-4e45-b49e-d1da3cfbdf43@github.com>
Message-ID: <_PJjNzMPnu-myJxovYAw2BfSDuplLxNRdzLbcMZA6Wg=.0dbb0c3c-bedf-424c-b92e-877bef73485a@github.com>

> Created two files for testing XPath Axes: XPathAncestors.java tests the ancestor and ancestor-or-self axes, while XPathPrecedingTest.java tests the preceding and preceding-sibling axes.

Rahul Prabhu has updated the pull request incrementally with one additional commit since the last revision:

  8289508: updated test names and fixed namespace typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10211/files
  - new: https://git.openjdk.org/jdk/pull/10211/files/3b9437b7..cfab5f6a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10211&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10211&range=03-04

  Stats: 10 lines in 2 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/10211.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10211/head:pull/10211

PR: https://git.openjdk.org/jdk/pull/10211

From duke at openjdk.org  Sat Sep 17 06:41:55 2022
From: duke at openjdk.org (Rahul Prabhu)
Date: Sat, 17 Sep 2022 06:41:55 GMT
Subject: RFR: 8289508: Improve test coverage for XPath Axes: ancestor,
 ancestor-or-self, preceding, and preceding-sibling [v6]
In-Reply-To: <xn1BRpM7AtPakAYm2AdbtoddvmCNqP3wBPwjMGUPx8w=.4aaac0f2-1383-4e45-b49e-d1da3cfbdf43@github.com>
References: <xn1BRpM7AtPakAYm2AdbtoddvmCNqP3wBPwjMGUPx8w=.4aaac0f2-1383-4e45-b49e-d1da3cfbdf43@github.com>
Message-ID: <IN_PP7sn-XSna7RNt36-WxWBYUmUv5NygXAQBwi6ldI=.a5a5cf43-7085-433d-9bbd-b1e1543d9207@github.com>

> Created two files for testing XPath Axes: XPathAncestors.java tests the ancestor and ancestor-or-self axes, while XPathPrecedingTest.java tests the preceding and preceding-sibling axes.

Rahul Prabhu has updated the pull request incrementally with one additional commit since the last revision:

  8289508: fixed test name in XPathPrecedingTest

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10211/files
  - new: https://git.openjdk.org/jdk/pull/10211/files/cfab5f6a..2925d342

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10211&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10211&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10211.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10211/head:pull/10211

PR: https://git.openjdk.org/jdk/pull/10211

From duke at openjdk.org  Sat Sep 17 06:43:14 2022
From: duke at openjdk.org (Rahul Prabhu)
Date: Sat, 17 Sep 2022 06:43:14 GMT
Subject: RFR: 8289508: Improve test coverage for XPath Axes: ancestor,
 ancestor-or-self, preceding, and preceding-sibling [v4]
In-Reply-To: <qLJCOrdHuuLi_WPbL-aK7RBUDDvWhYCE0sRGpccwccI=.80ff619a-542e-4c4c-8dc6-cb0acdfc9c90@github.com>
References: <xn1BRpM7AtPakAYm2AdbtoddvmCNqP3wBPwjMGUPx8w=.4aaac0f2-1383-4e45-b49e-d1da3cfbdf43@github.com>
 <k6taP148VO1CD7cP4ihqcp0KAVl-_BsXlIWliJgZMD4=.afd6c9f6-ecd3-4a2c-a028-b624cfe91efa@github.com>
 <qLJCOrdHuuLi_WPbL-aK7RBUDDvWhYCE0sRGpccwccI=.80ff619a-542e-4c4c-8dc6-cb0acdfc9c90@github.com>
Message-ID: <0ROfquBWfs9B_ZzAV3Yzi10uLBPqE2eTI7fl16tpEzE=.df11d4df-0034-4f3a-85ca-30e55134537e@github.com>

On Thu, 15 Sep 2022 21:13:53 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Rahul Prabhu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8289508: fixed whitespace
>
> Looks good overall. 
> 
> Note that if the editor you use is prone to add whitespaces, running the normalizer before commit would do the trick.

@JoeWang-Java The test names/descriptions have been updated and the namespace test works after correcting the typo.

-------------

PR: https://git.openjdk.org/jdk/pull/10211

From stuefe at openjdk.org  Sat Sep 17 07:03:48 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 17 Sep 2022 07:03:48 GMT
Subject: RFR: JDK-8293659: Improve UnsatisfiedLinkError error message to
 include dlopen error details
In-Reply-To: <wDNTMY8vuq9QDlz6da2-JrqIvyqqdlRLo74dEmctVlk=.ccb230df-73c7-42d5-bb4b-0cb441fd1e3b@github.com>
References: <ifR_svzVaPWpTZ48Mm7a_bANpIvAgQB1HEiBrXlA0oQ=.1dd92d2d-c9f2-4bbf-9a02-8bde08cdb8fb@github.com>
 <wDNTMY8vuq9QDlz6da2-JrqIvyqqdlRLo74dEmctVlk=.ccb230df-73c7-42d5-bb4b-0cb441fd1e3b@github.com>
Message-ID: <F97g-kNuGcDnzUCohInR_L_l87Hm-vjqkKsrwHbPUb4=.8665f7ca-3aee-48fe-b087-8740186e835b@github.com>

On Thu, 15 Sep 2022 17:56:09 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> When trying to load a x64 lib on macOS aarch64 one got previously this detailed message before [JDK-8275703](https://bugs.openjdk.org/browse/JDK-8275703):
>> 
>> java.lang.UnsatisfiedLinkError: /testing/jco3/macOsx64/libsapjco3.dylib: dlopen(/testing/jco3/macOsx64/libsapjco3.dylib, 1): no suitable image found. Did find:
>
> Adding the background and details for this review:
> 
> The `throwException` parameter in `JVM_LoadLibrary` was added to support dynamic linker cache.   dlopen may succeed when the given path does not exist but in the dynamic linker cache.   `System::loadLibrary` on macOS that supports dynamic linker cache calls `JVM_LoadLibrary` with `throwException == false` and so VM doesn't throw  `UnsatisfiedLinkException`.  Instead the libraries code throws `UnsatisfiedLinkException` if it fails to load the library.
> 
> For this issue,  a library to be loaded exists.    A simple fix is to call `JVM_LoadLibrary` with throwException = true (if file exists) such that the VM throws `UnsatisfiedLinkException` with the detailed error message.

Hi @mlchung,

I tried to understand this, and your fix for JDK-8275703 (https://github.com/openjdk/jdk/pull/6127). What I don't understand is why we suppressed the exception in JVM_LoadLibrary in the first place.

So, in Big Sur dlopen could succeed if the library is not present in the file system. Therefore we have to omit the file exists check before attempting to dlopen. That makes sense.

Then we attempt to load the library, dive into JVM_LoadLibrary->os::dll_load(), and do a dlopen(), which could succeed or fail. If it succeeds, all is well. If it fails, os::dll_load() just returns dlerror() to JVM_LoadLibrary, which packs the error string into an exception and throws it.

But why did we have to prevent the exception in JVM_LoadLibrary at that point? As it is now, we don't get error details on systems with a dynamic loader cache, since we throw away the dlerror output?

-------------

PR: https://git.openjdk.org/jdk/pull/10286

From duke at openjdk.org  Sat Sep 17 07:40:45 2022
From: duke at openjdk.org (Markus KARG)
Date: Sat, 17 Sep 2022 07:40:45 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo
 [v11]
In-Reply-To: <34XpvO2kWiaGOek0LRM_ZW5Wlkbp1pW5NzDaKZc3N1I=.93222a1d-3ed7-4700-9115-8bc47a077bbd@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <_la5Co3yx5ik1wt7Y6Bi7MDC3MCVUxIKxz_iQQp2TT8=.1023ef6d-266f-45f5-aa93-7218d0d89c10@github.com>
 <34XpvO2kWiaGOek0LRM_ZW5Wlkbp1pW5NzDaKZc3N1I=.93222a1d-3ed7-4700-9115-8bc47a077bbd@github.com>
Message-ID: <KbzpoMq5YQiTlQwFQftPyRJ-A_jAi6FSrUrT5jxfLBQ=.c5b21be8-9589-4bc1-a4dd-547ef58812c2@github.com>

On Sun, 11 Sep 2022 07:44:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - corrected copyright
>>  - testing transferTo() after reset()
>
>> I do not quite understand what would be wrong with the code below instead of falling back to the super implementation _in case of non-empty buffer_?
> 
> I think you are asking if is safe to leak a reference to the internal buffer. If there is no mark then it might be okay because there is no replay for an evil output stream to attack. However, I think it would require wider review to be confident that there aren't other interesting ways to break it; hence the suggestion in one of the earlier comments to keep it simple and limit it when there is no subclassing, no mark, and no bytes buffered. This does not prevent widening the conditions in the future.

@AlanBateman Kindly requesting approval. :-)

-------------

PR: https://git.openjdk.org/jdk/pull/6935

From jwaters at openjdk.org  Sat Sep 17 07:48:16 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 17 Sep 2022 07:48:16 GMT
Subject: RFR: 8293595: tstrings::any() is missing an overload
In-Reply-To: <0tqqa1avFzs-MV0Veo0QnpBG1-0b1djoKap5D_vF62U=.4fed5b83-dfc2-4661-a031-f3d1b64eeca9@github.com>
References: <0tqqa1avFzs-MV0Veo0QnpBG1-0b1djoKap5D_vF62U=.4fed5b83-dfc2-4661-a031-f3d1b64eeca9@github.com>
Message-ID: <SHgHErtSNRVmgHi_A3LEPoKmclNcDxndLiLLnD-1sX8=.6abdcb16-4add-4248-860b-4c6702f451db@github.com>

On Fri, 9 Sep 2022 13:38:14 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> tstrings::any() has an overload for std::wstring (if required) but is missing the corresponding operator overload for std::string, leaving only the templated one as a fallback, which will expand into a std::wostringstream << std::string operation. This isn't particularly safe on Windows, considering that JDK-8292008 and JDK-8247283 have been recently merged, and can sporadically cause build failures. This change simply adds the missing overload with the appropriate format handling that jpackage expects from std::string. Also contains minor name changes to fit the rest of the parameter names in the other overloads.

Adding generic hotspot label since I don't know where this falls under, but it's likely not core-libs

-------------

PR: https://git.openjdk.org/jdk/pull/10231

From alanb at openjdk.org  Sat Sep 17 08:07:51 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 17 Sep 2022 08:07:51 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v4]
In-Reply-To: <5Izo5-kThb-CKVAmWq8qddyccWZfhp_1pahxJxbPXvA=.1add8dec-f1ea-49a7-abe2-ceedd1189fb9@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <bHrBh3zv6i5YDa0Hhgs_QCAql8IOnmE4GUZrAQ_ResU=.bb9a98fe-6f13-42cf-a410-d1c3bee62b6a@github.com>
 <YLGNytqSz0Bro3G5f3si3lmHLzLYDe6CBRsNj82dpEI=.83e2878b-35dc-4895-8842-0514ccdc95cd@github.com>
 <V4WsTSOPO0A5BqIQ9lQpyc9ipKzkpFD3IfHFWktCB_M=.2e51f394-d332-48d5-b8b9-1eb609bb1a53@github.com>
 <ZOWXisIp8nY6jq8y-nYDWQFTVeWI6bYuNas5IRZx4p8=.ac9f82ad-d1a6-4dad-b469-955d9c42d59b@github.com>
 <5Izo5-kThb-CKVAmWq8qddyccWZfhp_1pahxJxbPXvA=.1add8dec-f1ea-49a7-abe2-ceedd1189fb9@github.com>
Message-ID: <XFNQ2uRsRfcC9H3eyjfdGsljPN8CiSaFQdpGCzKt48c=.806e8a99-33f1-4f2d-944c-cdd90c00dbb0@github.com>

On Fri, 16 Sep 2022 18:33:46 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Okay, in which case what would you think about just saying that the getNextEntry/getNextJarEntry method do not return the Manifest when it's at the start of the stream, and it's unspecified whether they return the Manifest when it located later in the stream. I think this would give us wriggle room to change it in the future.
>
>> Okay, in which case what would you think about just saying that the getNextEntry/getNextJarEntry method do not return the Manifest when it's at the start of the stream, and it's unspecified whether they return the Manifest when it located later in the stream. I think this would give us wriggle room to change it in the future.
> 
> Is this any better:
> 
> 
> 
>  * <p>
>  * When the {@code Manifest} is returned by {@code getManifest()}, the {@link #getNextEntry()}
>  * and {@link #getNextJarEntry()} methods will not return the {@code Manifest}.
>  * If {@code META-INF/} is the first entry in the input stream it will be
>  * also not be returned by {@link #getNextEntry()} and {@link #getNextJarEntry()}. 
>  * </p>
>  * @apiNote 
>  * It is unspecified whether {@link #getNextEntry()} and
>  * {@link #getNextJarEntry()} will return the {@code Manifest}
>  * when the {@code Manifest} occurs later in the input stream.
>  * <p>
>  * {@link JarEntry#getAttributes()} will return the {@code Manifest}'s
>  *  attributes for the current JAR file entry, if any, providing
>  *  {@code getManifest()} returns a {@code Manifest} for the JAR file.
>  * </p>

It's a bit better but I think we can make it clearer and also link the JAR Manifest section of the JAR file spec.  Can you try this:


 * <p> The {@link #getManifest() getManifest} method is used to read the
 * <a href="{@docRoot}/../specs/jar/jar.html#jar-manifest">JAR Manifest</a>
 * from the entry {@code META-INF/MANIFEST.MF} when it is the first entry
 * in the stream (or the second entry in the case that the fist entry is
 * {@code META-INF/} and the second entry {@code META-INF/MANIFEST.MF}).
 *
 * <p> The {@link #getNextJarEntry()} and {@link #getNextEntry()} methods are
 * used to read JAR file entries from the stream. These methods skip over the
 * manifest ({@code META-INF/MANIFEST.MF}) when it is at the beginning of the
 * stream. In other words, these methods do not return an entry for the manifest
 * when the manifest is the first entry in the stream. If the first entry is
 * {@code META-INF/} and the second entry is the manifest then both are skipped
 * over by these methods. Whether these methods skip over the manifest when it
 * appears later in the stream is not specified.


I think we also have to update getManifest method to align with the above as doesn't say anything about the manifest needing to be at the beginning of the stream.

-------------

PR: https://git.openjdk.org/jdk/pull/10045

From lzhai at openjdk.org  Sat Sep 17 08:24:39 2022
From: lzhai at openjdk.org (Leslie Zhai)
Date: Sat, 17 Sep 2022 08:24:39 GMT
Subject: RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx
In-Reply-To: <rtNdDgOs61FHLvc3ZkpTZtxFw7B-WF-EDdwyOt_iXQk=.719a528e-44b7-4b07-8f07-df81c170beb2@github.com>
References: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
 <rtNdDgOs61FHLvc3ZkpTZtxFw7B-WF-EDdwyOt_iXQk=.719a528e-44b7-4b07-8f07-df81c170beb2@github.com>
Message-ID: <RZcpjMcdxZIVWQG-kDVROCRIetR-n3ZqLnSMcEjf4us=.ca00eb6a-744d-4dd9-a0aa-23afdbd21f2d@github.com>

On Fri, 16 Sep 2022 13:02:16 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Hi,
>> 
>> @dumasun reported the issue:
>> 
>> Configured with jfx-ls-modular-sdk:
>> 
>> 
>> configure --with-import-modules=modular-sdk
>> 
>> 
>> `make run-test CONF=fastdebug TEST="tools/launcher/FXLauncherTest.java"` failed:
>> 
>> 
>> ----------System.err:(11/697)----------
>> java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>>     at FXLauncherTest.main(FXLauncherTest.java:451)
>>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>     at java.base/java.lang.Thread.run(Thread.java:1589)
>> 
>> JavaTest Message: Test threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>> JavaTest Message: shutting down test
>> 
>> STATUS:Failed.`main' threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>> 
>> 
>> Thanks,
>> Leslie Zhai
>
> It does seem worth trying `--patch-module` if the javafx.graphics module is present in the Java runtime. If that works, it is better than skipping the test, since you will then be able to continue testing the FX launcher.
> 
> Another possibility would be to go with your proposed solution of skipping the test if the javafx.graphics module is present, and provide a second test that is only run when the `javafx.graphics` module is present. In that case, you could test the actual FX launcher rather than the dummy implementation. This could either be done in this PR or as a follow-on test bug.

Hi @kevinrushforth @AlanBateman

I have tried `--upgrade-module-path` and `--patch-module` but still failed. Please point out my fault if I misunderstanding.

Thanks,
Leslie Zhai

-------------

PR: https://git.openjdk.org/jdk/pull/10299

From alanb at openjdk.org  Sat Sep 17 08:41:19 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 17 Sep 2022 08:41:19 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v4]
In-Reply-To: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
Message-ID: <ZTzHjlUXhJf5U3PndgGMZUpwbIJhJ0kSxL2am_PfFT8=.4279d477-9a1e-4a2c-b334-90cc60b5592b@github.com>

> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
> 
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
> 
> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
> 
> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.

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 12 additional commits since the last revision:

 - Merge
 - Updates to Java Thread Primitive Deprecation page
 - Repalce "it" with "victim thread"
 - Merge
 - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop
 - become -> became in javadoc
 - Merge
 - Remove stopThread permission from RuntimePermission table, exclude jshell tests
 - Deprecate for removal
 - Next iteration, update dates in headers
 - ... and 2 more: https://git.openjdk.org/jdk/compare/214db2f4...93806f99

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10230/files
  - new: https://git.openjdk.org/jdk/pull/10230/files/a00f38a2..93806f99

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10230&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10230&range=02-03

  Stats: 5663 lines in 389 files changed: 1218 ins; 1745 del; 2700 mod
  Patch: https://git.openjdk.org/jdk/pull/10230.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10230/head:pull/10230

PR: https://git.openjdk.org/jdk/pull/10230

From lancea at openjdk.org  Sat Sep 17 14:35:46 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 17 Sep 2022 14:35:46 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v6]
In-Reply-To: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
Message-ID: <DRY5m5O6V8PQg4riHZDD4Ajf8LAKLnkRcIrmoG4DeGA=.f5a8aeda-aea0-4d81-888e-4a20ab6a83f6@github.com>

> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
> 
> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
> 
> 
> Best,
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Incorporated latest round of input

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10045/files
  - new: https://git.openjdk.org/jdk/pull/10045/files/6d7795fe..a0b7ae03

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10045&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10045&range=04-05

  Stats: 21 lines in 1 file changed: 6 ins; 1 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/10045.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10045/head:pull/10045

PR: https://git.openjdk.org/jdk/pull/10045

From lancea at openjdk.org  Sat Sep 17 14:38:29 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 17 Sep 2022 14:38:29 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v4]
In-Reply-To: <XFNQ2uRsRfcC9H3eyjfdGsljPN8CiSaFQdpGCzKt48c=.806e8a99-33f1-4f2d-944c-cdd90c00dbb0@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <bHrBh3zv6i5YDa0Hhgs_QCAql8IOnmE4GUZrAQ_ResU=.bb9a98fe-6f13-42cf-a410-d1c3bee62b6a@github.com>
 <YLGNytqSz0Bro3G5f3si3lmHLzLYDe6CBRsNj82dpEI=.83e2878b-35dc-4895-8842-0514ccdc95cd@github.com>
 <V4WsTSOPO0A5BqIQ9lQpyc9ipKzkpFD3IfHFWktCB_M=.2e51f394-d332-48d5-b8b9-1eb609bb1a53@github.com>
 <ZOWXisIp8nY6jq8y-nYDWQFTVeWI6bYuNas5IRZx4p8=.ac9f82ad-d1a6-4dad-b469-955d9c42d59b@github.com>
 <5Izo5-kThb-CKVAmWq8qddyccWZfhp_1pahxJxbPXvA=.1add8dec-f1ea-49a7-abe2-ceedd1189fb9@github.com>
 <XFNQ2uRsRfcC9H3eyjfdGsljPN8CiSaFQdpGCzKt48c=.806e8a99-33f1-4f2d-944c-cdd90c00dbb0@github.com>
Message-ID: <zrsQZbDwyP9hUsuekkM1801siREc1kEFhOtgbINmogE=.85d4526b-2fb1-4038-bfb6-8891cc0f7338@github.com>

On Sat, 17 Sep 2022 08:05:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> It's a bit better but I think we can make it clearer and also link the JAR Manifest section of the JAR file spec. Can you try this:
> 
> ```
>  * <p> The {@link #getManifest() getManifest} method is used to read the
>  * <a href="{@docRoot}/../specs/jar/jar.html#jar-manifest">JAR Manifest</a>
>  * from the entry {@code META-INF/MANIFEST.MF} when it is the first entry
>  * in the stream (or the second entry in the case that the fist entry is
>  * {@code META-INF/} and the second entry {@code META-INF/MANIFEST.MF}).
>  *
>  * <p> The {@link #getNextJarEntry()} and {@link #getNextEntry()} methods are
>  * used to read JAR file entries from the stream. These methods skip over the
>  * manifest ({@code META-INF/MANIFEST.MF}) when it is at the beginning of the
>  * stream. In other words, these methods do not return an entry for the manifest
>  * when the manifest is the first entry in the stream. If the first entry is
>  * {@code META-INF/} and the second entry is the manifest then both are skipped
>  * over by these methods. Whether these methods skip over the manifest when it
>  * appears later in the stream is not specified.
> ```
> 
Revised using the above

> I think we also have to update getManifest method to align with the above as doesn't say anything about the manifest needing to be at the beginning of the stream.

Ok,  I added some verbiage similar to what I had originally before we decided to update the class description.  Please let me know if this is what you had in mind

Thank you again for your feedback

-------------

PR: https://git.openjdk.org/jdk/pull/10045

From sspitsyn at openjdk.org  Sun Sep 18 09:31:53 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sun, 18 Sep 2022 09:31:53 GMT
Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions
Message-ID: <O_jzls_cv3HBC0NbzuYV2LXaW9VB2M18FroUfXWXd2w=.fa9d1f3c-40a2-42bd-a09b-dadd5032e513@github.com>

There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update.

There are a couple of details of this fix to highlight:
-  A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`.
- A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored.
- Suspending threads in temporary transition is allowed.

The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6.

-------------

Commit messages:
 -  8293613: need to properly handle and hide tmp VTMS transitions

Changes: https://git.openjdk.org/jdk/pull/10321/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10321&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293613
  Stats: 56 lines in 10 files changed: 49 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10321.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10321/head:pull/10321

PR: https://git.openjdk.org/jdk/pull/10321

From jpai at openjdk.org  Sun Sep 18 12:05:10 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 18 Sep 2022 12:05:10 GMT
Subject: RFR: 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest
 fails intermittently with cannot find a free port
Message-ID: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>

Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616?

The test has been intermittently failing with `cannot find a free port after 10 tries`.  The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`.

Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address.

The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free.

The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does.

Multiple test runs after this change hasn't yet run into the failure.

-------------

Commit messages:
 - 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently with cannot find a free port

Changes: https://git.openjdk.org/jdk/pull/10322/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10322&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8030616
  Stats: 7 lines in 3 files changed: 5 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10322.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10322/head:pull/10322

PR: https://git.openjdk.org/jdk/pull/10322

From alanb at openjdk.org  Sun Sep 18 19:55:03 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 18 Sep 2022 19:55:03 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v6]
In-Reply-To: <DRY5m5O6V8PQg4riHZDD4Ajf8LAKLnkRcIrmoG4DeGA=.f5a8aeda-aea0-4d81-888e-4a20ab6a83f6@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <DRY5m5O6V8PQg4riHZDD4Ajf8LAKLnkRcIrmoG4DeGA=.f5a8aeda-aea0-4d81-888e-4a20ab6a83f6@github.com>
Message-ID: <EFvr_1_wKxNI67dJ4SXoMlRXjGZ_kC1Ffzpg_tXYelw=.4d3c369f-6825-4de8-8d4b-64d7a5c9dc16@github.com>

On Sat, 17 Sep 2022 14:35:46 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
>> 
>> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
>> 
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporated latest round of input

src/java.base/share/classes/java/util/jar/JarInputStream.java line 36:

> 34:  * The {@code JarInputStream} class, which extends {@link ZipInputStream},
> 35:  * is used to read the contents of a JAR file from an input stream.
> 36:  * It provides support for reading an optional {@link JarFile#MANIFEST_NAME Manifest}

What would you think about linking this to {@docRoot}/../specs/jar/jar.html#jar-manifest rather tan JarFile#MANIFEST_NAME?

src/java.base/share/classes/java/util/jar/JarInputStream.java line 60:

> 58:  * {@link JarEntry#getAttributes()} will return the {@code Manifest}'s
> 59:  *  attributes for the current JAR file entry, if any, providing
> 60:  *  {@code getManifest()} returns a {@code Manifest} for the JAR file.

Per-entry attributes is an advanced feature to attempt to bring into the class description. I think it would be simpler to just drop this paragraph. If you really want something on this topic then it would require first describing main vs. per entry attributes and then explaining that the per-entry attributes are obtained with JarEntry::getAttributes when the manifest is at the beginning of the stream.

src/java.base/share/classes/java/util/jar/JarInputStream.java line 157:

> 155:      *
> 156:      * @return the {@code Manifest} for this JAR file when accessible, or
> 157:      *         {@code null} otherwise.

The word "accessible" suggests there is access control in the picture so I think drop that word. Maybe just drop "if none" from the original return description?

-------------

PR: https://git.openjdk.org/jdk/pull/10045

From lancea at openjdk.org  Sun Sep 18 20:37:43 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Sun, 18 Sep 2022 20:37:43 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v6]
In-Reply-To: <EFvr_1_wKxNI67dJ4SXoMlRXjGZ_kC1Ffzpg_tXYelw=.4d3c369f-6825-4de8-8d4b-64d7a5c9dc16@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <DRY5m5O6V8PQg4riHZDD4Ajf8LAKLnkRcIrmoG4DeGA=.f5a8aeda-aea0-4d81-888e-4a20ab6a83f6@github.com>
 <EFvr_1_wKxNI67dJ4SXoMlRXjGZ_kC1Ffzpg_tXYelw=.4d3c369f-6825-4de8-8d4b-64d7a5c9dc16@github.com>
Message-ID: <Pjw2AsAaEolE03cGFx5BlGL2PTYmQMhxbW4sd7I76g8=.f0db002b-e692-4f8b-ba6b-48a684b79f30@github.com>

On Sun, 18 Sep 2022 19:49:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Incorporated latest round of input
>
> src/java.base/share/classes/java/util/jar/JarInputStream.java line 36:
> 
>> 34:  * The {@code JarInputStream} class, which extends {@link ZipInputStream},
>> 35:  * is used to read the contents of a JAR file from an input stream.
>> 36:  * It provides support for reading an optional {@link JarFile#MANIFEST_NAME Manifest}
> 
> What would you think about linking this to {@docRoot}/../specs/jar/jar.html#jar-manifest rather tan JarFile#MANIFEST_NAME?

Sure if that is your preference.

> src/java.base/share/classes/java/util/jar/JarInputStream.java line 60:
> 
>> 58:  * {@link JarEntry#getAttributes()} will return the {@code Manifest}'s
>> 59:  *  attributes for the current JAR file entry, if any, providing
>> 60:  *  {@code getManifest()} returns a {@code Manifest} for the JAR file.
> 
> Per-entry attributes is an advanced feature to attempt to bring into the class description. I think it would be simpler to just drop this paragraph. If you really want something on this topic then it would require first describing main vs. per entry attributes and then explaining that the per-entry attributes are obtained with JarEntry::getAttributes when the manifest is at the beginning of the stream.

I can remove, but I am not sure I agree we need to describe main vs attribute here given we are pointing to the Jar spec and if there is any discussion of Pre-entry attributes, it should be in JarEntry IMHO.  I guess the clarification I was trying to make, apparently unsuccessfully is that `JarEntry` will not have access to the attributes if `getManifest` does not return the Manifest.

> src/java.base/share/classes/java/util/jar/JarInputStream.java line 157:
> 
>> 155:      *
>> 156:      * @return the {@code Manifest} for this JAR file when accessible, or
>> 157:      *         {@code null} otherwise.
> 
> The word "accessible" suggests there is access control in the picture so I think drop that word. Maybe just drop "if none" from the original return description?

Will change as you suggest

-------------

PR: https://git.openjdk.org/jdk/pull/10045

From lancea at openjdk.org  Sun Sep 18 20:43:25 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Sun, 18 Sep 2022 20:43:25 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v7]
In-Reply-To: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
Message-ID: <_tMtVfn6qdtAb3EZiSBqve0gM_WGZKUAyYwnYqtZMgA=.74bfe2cf-e1c4-47c2-99ba-14a804f6d470@github.com>

> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
> 
> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
> 
> 
> Best,
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Updated to address latest feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10045/files
  - new: https://git.openjdk.org/jdk/pull/10045/files/a0b7ae03..c16e5bb8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10045&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10045&range=05-06

  Stats: 8 lines in 1 file changed: 1 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10045.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10045/head:pull/10045

PR: https://git.openjdk.org/jdk/pull/10045

From msheppar at openjdk.org  Sun Sep 18 22:03:38 2022
From: msheppar at openjdk.org (Mark Sheppard)
Date: Sun, 18 Sep 2022 22:03:38 GMT
Subject: RFR: 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest
 fails intermittently with cannot find a free port
In-Reply-To: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
References: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
Message-ID: <Y3DKnRCbaVIZVsGyoz854SCYW5H1P5Meqj_F4S2GSQs=.15e1ccf9-ed9a-4ef7-b3a1-4373534497b2@github.com>

On Sun, 18 Sep 2022 11:52:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616?
> 
> The test has been intermittently failing with `cannot find a free port after 10 tries`.  The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`.
> 
> Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address.
> 
> The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free.
> 
> The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does.
> 
> Multiple test runs after this change hasn't yet run into the failure.

While the change is reasonable, I?m not sure about your rationale.
The contributing factors to the intermittent failures are due to the flawed ephemeral port allocation strategy, that incurs a race condition to use the selected  ephemeral port within the test before the OS uses it. 
So from the time that the port has been acquired, then released via the autoclose of the serversocket, 
and then reused in the test, it is possible that the OS may have also relocated that ephemeral port.

This change doesn?t alter this race condition.

The are a number of significant attributes to the port allocation strategy:
The port allocation strategy acquires an ephemeral port from the OS while binding it to a ServerSocket. 
The significance of ServerSocket is it surreptitiously sets SO_REUSEADDR socket option on the server socket (Net.socket0() == Java_sun_nio_ch_Net_socket0). The fact that SO_REUSEADDR is set is important in this scenario.

The objective with using SO_REUSEADDR on a serversocket is allow for efficient server restarts due to
a shutdown for whatever reason. With SO_REUSEADDR set the restarting server, which typically uses a well known port, won?t get a BindException, while the port may still be associated with the ?terminating? server i.e. it may not have been fully released by the OS, for general reuse.

Thus, this has a number of favourable consequences with your proposed change, as the address binding is the
same as that used for acquiring the port, so it is essential a ?server restart scenario?, albeit with an
Ephemeral port. As such, there still exists the possibility that the port will be reused by the OS, where
conditions of heavy ephemeral port allocation is occurring.

As such, the change may reduce the rate of intermittent failure, but it won?t solve the issue fully.
There is a possibility that it may increase the rate of failure as many network tests now use
Loopback address rather than the local host address i.e. the primary configured IP address.
This will depend on the load on a test system, and the amount of concurrently executing network tests,
with the corresponding high volume of ephemeral port allocation.

Nonetheless, it is a reasonable change, provided there is no subtle change in test semantics. I think it
will ameliorate the intermittent failures.

-------------

PR: https://git.openjdk.org/jdk/pull/10322

From jpai at openjdk.org  Mon Sep 19 00:44:40 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 Sep 2022 00:44:40 GMT
Subject: RFR: 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest
 fails intermittently with cannot find a free port
In-Reply-To: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
References: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
Message-ID: <J-KLEMAmqAnublzUOC1lNA5B9z96uI4dOzF4o9AgKog=.41421633-a84b-4ce8-a24d-902c8b440a00@github.com>

On Sun, 18 Sep 2022 11:52:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616?
> 
> The test has been intermittently failing with `cannot find a free port after 10 tries`.  The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`.
> 
> Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address.
> 
> The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free.
> 
> The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does.
> 
> Multiple test runs after this change hasn't yet run into the failure.

Hello Mark, this specific change is merely meant to address the specific test case which is running into this problem. As you note the free port identification logic has and will continue to have the race condition. It will be applicable to all tests that use that utility. This change doesn't propose to do anything for such cases. 

However, in this specific case it wasn't the race condition which was causing the issue. Data that was collected from those failures shows that the issue was because of using the wrong address while trying to bind the free port that was identified. The data collected from these failed runs has been added to the linked JBS issue as a comment to show the port usage.

-------------

PR: https://git.openjdk.org/jdk/pull/10322

From lzhai at openjdk.org  Mon Sep 19 00:52:52 2022
From: lzhai at openjdk.org (Leslie Zhai)
Date: Mon, 19 Sep 2022 00:52:52 GMT
Subject: RFR: 8293977: jdk/modules/etc/VerifyModuleDelegation.java fail with
 jfx
Message-ID: <K8keV23DhjOl2iAcpxEGUPEDKfRsrPMwVYf6ZvYV39M=.66a73163-007e-4951-a524-7cf8d5aa1f79@github.com>

Hi,

@dumasun reported the issue:

Configured with jfx-ls-modular-sdk:


configure --with-import-modules=modular-sdk


`make run-test CONF=fastdebug TEST="jdk/modules/etc/VerifyModuleDelegation.java"` failed:


----------System.out:(46/3114)----------
test VerifyModuleDelegation.checkJavaBase(): success
test VerifyModuleDelegation.checkLoaderDelegation(): failure
java.lang.Error: platform/javafx.swing can't delegate to find classes from app/jdk.unsupported.desktop
    at VerifyModuleDelegation.lambda$checkLoaderDelegation$1(VerifyModuleDelegation.java:77)
    at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
    at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1921)
    at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
    at VerifyModuleDelegation.lambda$checkLoaderDelegation$2(VerifyModuleDelegation.java:68)
    at java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1715)
    at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
    at VerifyModuleDelegation.checkLoaderDelegation(VerifyModuleDelegation.java:68)
    at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
    at java.base/java.lang.reflect.Method.invoke(Method.java:578)
    at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
    at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
    at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
    at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
    at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
    at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
    at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
    at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
    at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
    at org.testng.TestRunner.privateRun(TestRunner.java:764)
    at org.testng.TestRunner.run(TestRunner.java:585)
    at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
    at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
    at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
    at org.testng.SuiteRunner.run(SuiteRunner.java:286)
    at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
    at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
    at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
    at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
    at org.testng.TestNG.runSuites(TestNG.java:1069)
    at org.testng.TestNG.run(TestNG.java:1037)
    at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
    at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54)
    at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
    at java.base/java.lang.reflect.Method.invoke(Method.java:578)
    at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
    at java.base/java.lang.Thread.run(Thread.java:1589)

===============================================
jdk/modules/etc/VerifyModuleDelegation.java
Total tests run: 2, Passes: 1, Failures: 1, Skips: 0
===============================================

----------System.err:(13/753)----------
WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.concurrent
java.lang.Exception: failures: 1
    at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96)
    at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54)
    at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
    at java.base/java.lang.reflect.Method.invoke(Method.java:578)
    at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
    at java.base/java.lang.Thread.run(Thread.java:1589)


Thanks,
Leslie Zhai

-------------

Commit messages:
 - 8293977: jdk/modules/etc/VerifyModuleDelegation.java fail with jfx

Changes: https://git.openjdk.org/jdk/pull/10328/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10328&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293977
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10328.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10328/head:pull/10328

PR: https://git.openjdk.org/jdk/pull/10328

From alanb at openjdk.org  Mon Sep 19 06:16:39 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 19 Sep 2022 06:16:39 GMT
Subject: RFR: 8293977: jdk/modules/etc/VerifyModuleDelegation.java fail
 with jfx
In-Reply-To: <K8keV23DhjOl2iAcpxEGUPEDKfRsrPMwVYf6ZvYV39M=.66a73163-007e-4951-a524-7cf8d5aa1f79@github.com>
References: <K8keV23DhjOl2iAcpxEGUPEDKfRsrPMwVYf6ZvYV39M=.66a73163-007e-4951-a524-7cf8d5aa1f79@github.com>
Message-ID: <iijSij0NtDit62oPsyZx7y4F7euFl8CDaQD_CEWD4DI=.c88e54fb-2fae-4588-b87e-7060bc2d7007@github.com>

On Mon, 19 Sep 2022 00:45:32 GMT, Leslie Zhai <lzhai at openjdk.org> wrote:

> Hi,
> 
> @dumasun reported the issue:
> 
> Configured with jfx-ls-modular-sdk:
> 
> 
> configure --with-import-modules=modular-sdk
> 
> 
> `make run-test CONF=fastdebug TEST="jdk/modules/etc/VerifyModuleDelegation.java"` failed:
> 
> 
> ----------System.out:(46/3114)----------
> test VerifyModuleDelegation.checkJavaBase(): success
> test VerifyModuleDelegation.checkLoaderDelegation(): failure
> java.lang.Error: platform/javafx.swing can't delegate to find classes from app/jdk.unsupported.desktop
>     at VerifyModuleDelegation.lambda$checkLoaderDelegation$1(VerifyModuleDelegation.java:77)
>     at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>     at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1921)
>     at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>     at VerifyModuleDelegation.lambda$checkLoaderDelegation$2(VerifyModuleDelegation.java:68)
>     at java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1715)
>     at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>     at VerifyModuleDelegation.checkLoaderDelegation(VerifyModuleDelegation.java:68)
>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>     at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>     at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>     at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>     at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>     at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>     at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>     at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>     at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>     at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
>     at org.testng.TestRunner.privateRun(TestRunner.java:764)
>     at org.testng.TestRunner.run(TestRunner.java:585)
>     at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
>     at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
>     at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
>     at org.testng.SuiteRunner.run(SuiteRunner.java:286)
>     at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
>     at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
>     at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
>     at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
>     at org.testng.TestNG.runSuites(TestNG.java:1069)
>     at org.testng.TestNG.run(TestNG.java:1037)
>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54)
>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>     at java.base/java.lang.Thread.run(Thread.java:1589)
> 
> ===============================================
> jdk/modules/etc/VerifyModuleDelegation.java
> Total tests run: 2, Passes: 1, Failures: 1, Skips: 0
> ===============================================
> 
> ----------System.err:(13/753)----------
> WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.concurrent
> java.lang.Exception: failures: 1
>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96)
>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54)
>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>     at java.base/java.lang.Thread.run(Thread.java:1589)
> 
> 
> Thanks,
> Leslie Zhai

I don't think the test should be changed list this until there is more information on the issue. jdk.unsupported.desktop should mapped to the application class loader. Can you tell use which class loader that javafx.swing is mapped to? Has the module-loader-map.conf changed in your environment? I'm wondering if there is any residual configuration somewhere that is mapping the javafx.* modules the platform class loader.

-------------

PR: https://git.openjdk.org/jdk/pull/10328

From shade at openjdk.org  Mon Sep 19 06:20:46 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 19 Sep 2022 06:20:46 GMT
Subject: RFR: 8293499: Provide jmod --compress option [v7]
In-Reply-To: <NtlQYsnqYp5rh3OVL0OYtYlHhi6rYNft1DoXrNFFjYA=.7e847323-9b01-40eb-89f7-713667f290de@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
 <NtlQYsnqYp5rh3OVL0OYtYlHhi6rYNft1DoXrNFFjYA=.7e847323-9b01-40eb-89f7-713667f290de@github.com>
Message-ID: <doqcPVuDxb4fEts7yMgIr-wgtOrKPYuWN_mH74p2Suk=.dfa3da29-b752-48fa-af70-c2ec0013a283@github.com>

On Fri, 16 Sep 2022 08:03:28 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I have been looking into `make clean-images images` performance, and realized jmod keeps compressing files with default compression level. Tuning that toward lighter compression levels improves build performance considerably, without a heavy loss in *.jmod sizes. 
>> 
>> This PR allows JMOD to select the compression level. Follow-ups would use this in the build system, see #10214.
>> 
>> The interesting asymmetry against `jlink` is: `jlink` provides `--compress` option that only takes `2` for "ZIP compression". (Separately, we could argue if it would be beneficial to extend `--compress` to `jlink` as well, so to select the compression level there too.)
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup quotes in parameter help

Thank you!

-------------

PR: https://git.openjdk.org/jdk/pull/10213

From shade at openjdk.org  Mon Sep 19 06:23:47 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 19 Sep 2022 06:23:47 GMT
Subject: Integrated: 8293499: Provide jmod --compress option
In-Reply-To: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
References: <lT081yH1m-nRCjnLxcIkDxgRzgOkQSKrw4Oj7d-iItY=.9c5d711c-47b3-48bf-a5a4-128afa4161dc@github.com>
Message-ID: <bzWoqa8JRO3QUYSqPM7kAY2XSV_goTPvPdqYl0isWw8=.a3f6bfe7-36ce-4db2-9837-5e0477ef94a9@github.com>

On Thu, 8 Sep 2022 07:57:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have been looking into `make clean-images images` performance, and realized jmod keeps compressing files with default compression level. Tuning that toward lighter compression levels improves build performance considerably, without a heavy loss in *.jmod sizes. 
> 
> This PR allows JMOD to select the compression level. Follow-ups would use this in the build system, see #10214.
> 
> The interesting asymmetry against `jlink` is: `jlink` provides `--compress` option that only takes `2` for "ZIP compression". (Separately, we could argue if it would be beneficial to extend `--compress` to `jlink` as well, so to select the compression level there too.)

This pull request has now been integrated.

Changeset: 43f7f47a
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/43f7f47ae0f36a8147f6197804db3b74a9dda295
Stats:     154 lines in 4 files changed: 147 ins; 0 del; 7 mod

8293499: Provide jmod --compress option

Reviewed-by: alanb, mchung, jpai, redestad

-------------

PR: https://git.openjdk.org/jdk/pull/10213

From alanb at openjdk.org  Mon Sep 19 06:37:47 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 19 Sep 2022 06:37:47 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v6]
In-Reply-To: <Pjw2AsAaEolE03cGFx5BlGL2PTYmQMhxbW4sd7I76g8=.f0db002b-e692-4f8b-ba6b-48a684b79f30@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <DRY5m5O6V8PQg4riHZDD4Ajf8LAKLnkRcIrmoG4DeGA=.f5a8aeda-aea0-4d81-888e-4a20ab6a83f6@github.com>
 <EFvr_1_wKxNI67dJ4SXoMlRXjGZ_kC1Ffzpg_tXYelw=.4d3c369f-6825-4de8-8d4b-64d7a5c9dc16@github.com>
 <Pjw2AsAaEolE03cGFx5BlGL2PTYmQMhxbW4sd7I76g8=.f0db002b-e692-4f8b-ba6b-48a684b79f30@github.com>
Message-ID: <eM0gLdVLRGsrXmzZgoCdcgL2XmCnzaPjqm31PUpqWDs=.d1c1e560-edba-43a8-ba38-5f8fa459f7d5@github.com>

On Sun, 18 Sep 2022 20:33:55 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> I can remove, but I am not sure I agree we need to describe main vs attribute here given we are pointing to the Jar spec and if there is any discussion of Pre-entry attributes, it should be in JarEntry IMHO. I guess the clarification I was trying to make, apparently unsuccessfully is that `JarEntry` will not have access to the attributes if `getManifest` does not return the Manifest.

Wording it is hard. The draft wording made it look  that must call getManifest, ignore the return value, and then subsequent calls to JarEntry::getAttributes will return attributes for the JAR file entry. I think to properly describe would require more setup to explain that a manifest can optionally include per entry attributes and these are read with JarEntry::getAttributes when the manifest is found at the beginning of the stream..

-------------

PR: https://git.openjdk.org/jdk/pull/10045

From alanb at openjdk.org  Mon Sep 19 06:48:47 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 19 Sep 2022 06:48:47 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v7]
In-Reply-To: <_tMtVfn6qdtAb3EZiSBqve0gM_WGZKUAyYwnYqtZMgA=.74bfe2cf-e1c4-47c2-99ba-14a804f6d470@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <_tMtVfn6qdtAb3EZiSBqve0gM_WGZKUAyYwnYqtZMgA=.74bfe2cf-e1c4-47c2-99ba-14a804f6d470@github.com>
Message-ID: <FLeEDUKHCLDrIia-kRzHeu8qxqk5rEiWC3fpUmr9SqM=.ebdeaaf5-5c83-4940-ab84-2e8bf04d5ccd@github.com>

On Sun, 18 Sep 2022 20:43:25 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
>> 
>> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
>> 
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated to address latest feedback

src/java.base/share/classes/java/util/jar/JarInputStream.java line 60:

> 58:  *
> 59:  *  <h2>Verifying a JarInputStream</h2>
> 60:  *  {@link #JarInputStream(InputStream, boolean)} may be used to

I realise you've had a few iterations with Max on this section but I'm concerned that the text is telling the reader that they should use the 2-arg constructor to verify the signatures when a JAR is signed. The default is to verify and the a reason to use the 2-arg constructor is when you want to opt out, not opt-in.

I think the intro to this section will need to start with a sentence to say that JAR files can be signed (link to specs/jar/jar.html#signed-jar-file) and that JarInputStream can read a signed JAR from the input stream. As per the description further up, the manifest must be at the start of the stream.

-------------

PR: https://git.openjdk.org/jdk/pull/10045

From mbaesken at openjdk.org  Mon Sep 19 06:53:43 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 19 Sep 2022 06:53:43 GMT
Subject: RFR: JDK-8293701: jdeps InverseDepsAnalyzer runs into
 NoSuchElementException: No value present
In-Reply-To: <0Qrh5uG_labY8ipk1D70HvY74RUFUR4960LuyFLZL1Q=.571c158b-12ac-4c82-bee0-d441ceb1416b@github.com>
References: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
 <0Qrh5uG_labY8ipk1D70HvY74RUFUR4960LuyFLZL1Q=.571c158b-12ac-4c82-bee0-d441ceb1416b@github.com>
Message-ID: <6uzcNA0sdiVcisCSD_P7rGSqxXVbcYD--HBYF_txpk8=.2c5fc54f-2324-4bc6-bcf9-e4086f6a7099@github.com>

On Fri, 16 Sep 2022 19:02:40 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> What is the cause of this issue? It expects the dependency can be found but missing in this case. I wonder if it's due to a `requires static` dependency?

Hi Mandy, good question, so far I have just a zip with a coupple of jars inside , still try to find someone who can point me to the sources .

-------------

PR: https://git.openjdk.org/jdk/pull/10300

From alanb at openjdk.org  Mon Sep 19 07:02:45 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 19 Sep 2022 07:02:45 GMT
Subject: RFR: JDK-8293701: jdeps InverseDepsAnalyzer runs into
 NoSuchElementException: No value present
In-Reply-To: <6uzcNA0sdiVcisCSD_P7rGSqxXVbcYD--HBYF_txpk8=.2c5fc54f-2324-4bc6-bcf9-e4086f6a7099@github.com>
References: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
 <0Qrh5uG_labY8ipk1D70HvY74RUFUR4960LuyFLZL1Q=.571c158b-12ac-4c82-bee0-d441ceb1416b@github.com>
 <6uzcNA0sdiVcisCSD_P7rGSqxXVbcYD--HBYF_txpk8=.2c5fc54f-2324-4bc6-bcf9-e4086f6a7099@github.com>
Message-ID: <V9zxYIEFUrRvGXjPOAjsR-ytywDGjNY-4bgkgMpWla4=.c242a006-7c89-49a0-b98e-41ca86a6972d@github.com>

On Mon, 19 Sep 2022 06:51:36 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > What is the cause of this issue? It expects the dependency can be found but missing in this case. I wonder if it's due to a `requires static` dependency?
> 
> Hi Mandy, good question, so far I have just a zip with a coupple of jars inside , still try to find someone who can point me to the sources .

Could you use `jar --file=<file> --describe-module` to get a describe of each module? The bug report doesn't need the names of the SAP modules but getting a picture of what the input to jdeps is would help figure out what this is about.

-------------

PR: https://git.openjdk.org/jdk/pull/10300

From lzhai at openjdk.org  Mon Sep 19 07:04:47 2022
From: lzhai at openjdk.org (Leslie Zhai)
Date: Mon, 19 Sep 2022 07:04:47 GMT
Subject: RFR: 8293977: jdk/modules/etc/VerifyModuleDelegation.java fail
 with jfx
In-Reply-To: <iijSij0NtDit62oPsyZx7y4F7euFl8CDaQD_CEWD4DI=.c88e54fb-2fae-4588-b87e-7060bc2d7007@github.com>
References: <K8keV23DhjOl2iAcpxEGUPEDKfRsrPMwVYf6ZvYV39M=.66a73163-007e-4951-a524-7cf8d5aa1f79@github.com>
 <iijSij0NtDit62oPsyZx7y4F7euFl8CDaQD_CEWD4DI=.c88e54fb-2fae-4588-b87e-7060bc2d7007@github.com>
Message-ID: <4QTA4raTZcksYdWk95-DB684-4VD5wQPspOnP66lOUs=.cd7a6505-4322-455e-b2fc-725474715f09@github.com>

On Mon, 19 Sep 2022 06:14:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi,
>> 
>> @dumasun reported the issue:
>> 
>> Configured with jfx-ls-modular-sdk:
>> 
>> 
>> configure --with-import-modules=modular-sdk
>> 
>> 
>> `make run-test CONF=fastdebug TEST="jdk/modules/etc/VerifyModuleDelegation.java"` failed:
>> 
>> 
>> ----------System.out:(46/3114)----------
>> test VerifyModuleDelegation.checkJavaBase(): success
>> test VerifyModuleDelegation.checkLoaderDelegation(): failure
>> java.lang.Error: platform/javafx.swing can't delegate to find classes from app/jdk.unsupported.desktop
>>     at VerifyModuleDelegation.lambda$checkLoaderDelegation$1(VerifyModuleDelegation.java:77)
>>     at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>>     at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1921)
>>     at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>>     at VerifyModuleDelegation.lambda$checkLoaderDelegation$2(VerifyModuleDelegation.java:68)
>>     at java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1715)
>>     at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>>     at VerifyModuleDelegation.checkLoaderDelegation(VerifyModuleDelegation.java:68)
>>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>>     at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>>     at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>>     at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>>     at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>>     at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>>     at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>>     at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>>     at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>>     at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
>>     at org.testng.TestRunner.privateRun(TestRunner.java:764)
>>     at org.testng.TestRunner.run(TestRunner.java:585)
>>     at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
>>     at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
>>     at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
>>     at org.testng.SuiteRunner.run(SuiteRunner.java:286)
>>     at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
>>     at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
>>     at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
>>     at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
>>     at org.testng.TestNG.runSuites(TestNG.java:1069)
>>     at org.testng.TestNG.run(TestNG.java:1037)
>>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
>>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54)
>>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>     at java.base/java.lang.Thread.run(Thread.java:1589)
>> 
>> ===============================================
>> jdk/modules/etc/VerifyModuleDelegation.java
>> Total tests run: 2, Passes: 1, Failures: 1, Skips: 0
>> ===============================================
>> 
>> ----------System.err:(13/753)----------
>> WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.concurrent
>> java.lang.Exception: failures: 1
>>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96)
>>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54)
>>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>     at java.base/java.lang.Thread.run(Thread.java:1589)
>> 
>> 
>> Thanks,
>> Leslie Zhai
>
> I don't think the test should be changed list this until there is more information on the issue. jdk.unsupported.desktop should be mapped to the application class loader. Can you tell use which class loader that javafx.swing is mapped to? Has the module-loader-map.conf changed in your environment? I'm wondering if there is any residual configuration somewhere that is mapping the javafx.* modules the platform class loader.

Hi @AlanBateman 

Thanks for your kind response!

> Can you tell use which class loader that javafx.swing is mapped to?

According to the output:


java.lang.Error: platform/javafx.swing can't delegate to find classes from app/jdk.unsupported.desktop


app as the `loader2` that javafx.swing is mapped to:


    @Test
    public void checkLoaderDelegation() {
        ModuleLayer boot = ModuleLayer.boot();
        MREFS.stream()
             .forEach(md -> md.requires().stream().forEach(req ->
                 {
                     // check if M requires D and D's loader must be either the
                     // same or an ancestor of M's loader
                     ClassLoader loader1 = boot.findLoader(md.name());
                     ClassLoader loader2 = boot.findLoader(req.name());
                     if (loader1 != loader2 && !isAncestor(loader2, loader1) && !md.name().equals("javafx.swing")) {
                         throw new Error(loader1.getName() + "/" + md.name() +
                             " can't delegate to find classes from " +
                             loader2.getName() + "/" + req.name());
                     }
                 }));
    }   


> Has the module-loader-map.conf changed in your environment?

Nope.  And @dumasun also reproduced the issue for x86_64.  Perhaps she could provide more information.

Thanks,
Leslie Zhai

-------------

PR: https://git.openjdk.org/jdk/pull/10328

From alanb at openjdk.org  Mon Sep 19 07:34:10 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 19 Sep 2022 07:34:10 GMT
Subject: RFR: 8293977: jdk/modules/etc/VerifyModuleDelegation.java fail
 with jfx
In-Reply-To: <4QTA4raTZcksYdWk95-DB684-4VD5wQPspOnP66lOUs=.cd7a6505-4322-455e-b2fc-725474715f09@github.com>
References: <K8keV23DhjOl2iAcpxEGUPEDKfRsrPMwVYf6ZvYV39M=.66a73163-007e-4951-a524-7cf8d5aa1f79@github.com>
 <iijSij0NtDit62oPsyZx7y4F7euFl8CDaQD_CEWD4DI=.c88e54fb-2fae-4588-b87e-7060bc2d7007@github.com>
 <4QTA4raTZcksYdWk95-DB684-4VD5wQPspOnP66lOUs=.cd7a6505-4322-455e-b2fc-725474715f09@github.com>
Message-ID: <Slhsf6CSMafjPjgbB0l2ErGstMOCRPG_MRZ_4W2vxZ8=.e62f715f-cc93-4d10-a00b-51b2c341fa10@github.com>

On Mon, 19 Sep 2022 07:02:40 GMT, Leslie Zhai <lzhai at openjdk.org> wrote:

> java.lang.Error: platform/javafx.swing can't delegate to find classes from app/jdk.unsupported.desktop

There must be configuration somewhere that is mapping the javafx.* modules to the platform class loader So I think the test is doing its job and has found an issue. Hopefully your colleague can provide more Info.

-------------

PR: https://git.openjdk.org/jdk/pull/10328

From xgong at openjdk.org  Mon Sep 19 08:58:46 2022
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 19 Sep 2022 08:58:46 GMT
Subject: RFR: 8293409: [vectorapi] Intrinsify VectorSupport.indexVector
Message-ID: <CES8kmi34gT8zSdoc2iBcgAGeOMDvOnZJrCsjU-9xaA=.091a5ad1-55a4-41c4-9e8c-192a0bca47e4@github.com>

"`VectorSupport.indexVector()`" is used to compute a vector that contains the index values based on a given vector and a scale value (`i.e. index = vec + iota * scale`). This function is widely used in other APIs like "`VectorMask.indexInRange`" which is useful to the tail loop vectorization. And it can be easily implemented with the vector instructions.

This patch adds the vector intrinsic implementation of it. The steps are:

  1) Load the const "iota" vector.

  We extend the "`vector_iota_indices`" stubs from byte to other integral types. For floating point vectors, it needs an additional vector cast to get the right iota values.

  2) Compute indexes with "`vec + iota * scale`"

Here is the performance result to the new added micro benchmark on ARM NEON:

Benchmark                              Gain
IndexVectorBenchmark.byteIndexVector   1.477
IndexVectorBenchmark.doubleIndexVector 5.031
IndexVectorBenchmark.floatIndexVector  5.342
IndexVectorBenchmark.intIndexVector    5.529
IndexVectorBenchmark.longIndexVector   3.177
IndexVectorBenchmark.shortIndexVector  5.841


Please help to review and share the feedback! Thanks in advance!

-------------

Commit messages:
 - 8293409: [vectorapi] Intrinsify VectorSupport.indexVector

Changes: https://git.openjdk.org/jdk/pull/10332/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10332&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293409
  Stats: 358 lines in 14 files changed: 328 ins; 6 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/10332.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10332/head:pull/10332

PR: https://git.openjdk.org/jdk/pull/10332

From duke at openjdk.org  Mon Sep 19 10:17:50 2022
From: duke at openjdk.org (Raffaello Giulietti)
Date: Mon, 19 Sep 2022 10:17:50 GMT
Subject: RFR: 8279986: methods Math::asXExact for safely checked primitive
 casts [v6]
In-Reply-To: <VKdxc6IyKkKUbnjZsUCP8qEfVX87r3x74R8woOq-s8Y=.2d8f4482-36f8-4f19-82dc-a54d4fecdd3d@github.com>
References: <uBItJPyPmTs5mhb4_B4JNUwxcQvjkg608V9pu4_AIlI=.6400b97e-90b6-4b31-8e03-a49a8bf51197@github.com>
 <VKdxc6IyKkKUbnjZsUCP8qEfVX87r3x74R8woOq-s8Y=.2d8f4482-36f8-4f19-82dc-a54d4fecdd3d@github.com>
Message-ID: <XcxoRC1wspkAKalE5gZaZe6kV4HtgbvYUQb7zd7EqXY=.61720629-92db-407a-85ff-3166bbeb5aab@github.com>

On Wed, 25 May 2022 09:40:42 GMT, Raffaello Giulietti <duke at openjdk.org> wrote:

>> Add a family of "safe" cast methods.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8279986: methods Math::asXExact for safely checked primitive casts

keep open, waiting for review

-------------

PR: https://git.openjdk.org/jdk/pull/8548

From duke at openjdk.org  Mon Sep 19 10:18:43 2022
From: duke at openjdk.org (Raffaello Giulietti)
Date: Mon, 19 Sep 2022 10:18:43 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: <5jnGzAtF09xVurf3eINcROrd7xGP2QRapUzA2FvNH7Q=.3d072ac0-7adc-4654-847a-34301024cabc@github.com>

On Thu, 7 Jul 2022 15:20:32 GMT, Raffaello Giulietti <duke 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.

keep open, waiting for review

-------------

PR: https://git.openjdk.org/jdk/pull/9410

From lancea at openjdk.org  Mon Sep 19 10:23:47 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 19 Sep 2022 10:23:47 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v7]
In-Reply-To: <FLeEDUKHCLDrIia-kRzHeu8qxqk5rEiWC3fpUmr9SqM=.ebdeaaf5-5c83-4940-ab84-2e8bf04d5ccd@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <_tMtVfn6qdtAb3EZiSBqve0gM_WGZKUAyYwnYqtZMgA=.74bfe2cf-e1c4-47c2-99ba-14a804f6d470@github.com>
 <FLeEDUKHCLDrIia-kRzHeu8qxqk5rEiWC3fpUmr9SqM=.ebdeaaf5-5c83-4940-ab84-2e8bf04d5ccd@github.com>
Message-ID: <8BlTa_vNbW2I2WyDopUYmD-p45YJSq_Xg0uwdFY6IWU=.465f7021-e77e-4e08-9a90-2622f4981825@github.com>

On Mon, 19 Sep 2022 06:45:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I realise you've had a few iterations with Max on this section but I'm concerned that the text is telling the reader that they should use the 2-arg constructor to verify the signatures when a JAR is signed. The default is to verify and the main reason to use the 2-arg constructor is when you want to opt out, not opt-in.
> 
> I think the intro to this section will need to start with a sentence to say that JAR files can be signed (link to specs/jar/jar.html#signed-jar-file) and that JarInputStream can read a signed JAR from the input stream. As per the description further up, the manifest must be at the start of the stream.

OK, will make another pass at this today

-------------

PR: https://git.openjdk.org/jdk/pull/10045

From shade at openjdk.org  Mon Sep 19 10:32:14 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 19 Sep 2022 10:32:14 GMT
Subject: RFR: 8293991: java/lang/Float/Binary16ConversionNaN.java fails on
 silent NaN conversions
Message-ID: <afYfFbJj3gshaWbUks0uVsHBJLFkND1vY1ccwSpFW60=.6b0b7208-c02c-4fe5-808f-6f9f4dc13ac5@github.com>

Reliably reproduces on x86-32 with FPU:


$ CONF=linux-x86-server-fastdebug make test TEST=java/lang/Float/Binary16ConversionNaN.java TEST_VM_OPTS="-XX:UseAVX=0 -XX:UseSSE=0"
...
Roundtrip failure on NaN value 7de2 got back 7fe2
Roundtrip failure on NaN value fde2 got back ffe2


Since there are many NaN values in FP16 -- basically any non-zero significand works, we should probably just relax the test a bit.

Attn @jddarcy ;)

Additional testing:
 - [x] Linux x86_32 fastdebug, `-XX:UseAVX=0 -XX:UseSSE=0`, affected test now passes
 - [x]  Linux x86_64 fastdebug, affected test still passes

-------------

Commit messages:
 - Indenting
 - Fix

Changes: https://git.openjdk.org/jdk/pull/10333/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10333&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293991
  Stats: 44 lines in 1 file changed: 29 ins; 9 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10333.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10333/head:pull/10333

PR: https://git.openjdk.org/jdk/pull/10333

From mullan at openjdk.org  Mon Sep 19 12:18:43 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 19 Sep 2022 12:18:43 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event
In-Reply-To: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
Message-ID: <ejhjgEoZEAud8eR_a_TiIBtMK0sPKhL2CE8fBTklyXg=.e120a898-da08-4e95-9562-d0e88b4a9741@github.com>

On Wed, 27 Jul 2022 13:14:39 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls.

Looks good.

-------------

Marked as reviewed by mullan (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9657

From jwaters at openjdk.org  Mon Sep 19 13:14:17 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 19 Sep 2022 13:14:17 GMT
Subject: RFR: 8294006: Avoid hardcoding object file suffixes in make
Message-ID: <O4N4XJMjXG2eSKFNLJwKEMOstwzXGYI0gygq1lGCS8w=.7f0f7aa0-b96b-491c-9f8c-8e7073672b54@github.com>

Replaces hardcoding of object file suffixes in make, to ensure they are always reliably set from a single place in autoconf.

-------------

Commit messages:
 - Launcher.gmk
 - JvmMapfile.gmk
 - NativeCompilation.gmk

Changes: https://git.openjdk.org/jdk/pull/10341/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10341&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294006
  Stats: 9 lines in 3 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/10341.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10341/head:pull/10341

PR: https://git.openjdk.org/jdk/pull/10341

From asotona at openjdk.org  Mon Sep 19 13:21:04 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 19 Sep 2022 13:21:04 GMT
Subject: RFR: 8278863: Add method ClassDesc::ofInternalName [v6]
In-Reply-To: <3WrKiVDNyaAvxuxpWsaiY7FZT_W5WDftJdwUENnqQc0=.518b7bea-2c44-45de-8832-203819529b27@github.com>
References: <3WrKiVDNyaAvxuxpWsaiY7FZT_W5WDftJdwUENnqQc0=.518b7bea-2c44-45de-8832-203819529b27@github.com>
Message-ID: <HalUkGMaTBt8p8SSFmrNzxG2G9yjpgrW2bd19bUxZpQ=.bd55d215-50ae-4214-a657-7a3a3d463973@github.com>

> The symbolic constants API (`java.lang.constant`) was designed, in part, to provide bytecode parsing and generation APIs with a validated, common, symbolic form for constants in Java class files. 
> 
> There is an easy way to create a `ClassDesc` from a binary name (`ClassDesc::of`) or a field descriptor (`ClassDesc::ofDescriptor`) but not from an internal name. But, the internal name is common in low-level bytecode-manipulation code. 
> 
> This patch adds `ClassDesc::ofInternalName` static factory method that creates a `ClassDesc` from class internal name.
> Class internal name validation and extended ClassDescTest are also parts of this patch.
> 
> CSR is linked with the issue.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  javadoc fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9201/files
  - new: https://git.openjdk.org/jdk/pull/9201/files/b25351c1..1790cf29

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9201&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9201&range=04-05

  Stats: 10 lines in 1 file changed: 8 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9201.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9201/head:pull/9201

PR: https://git.openjdk.org/jdk/pull/9201

From erikj at openjdk.org  Mon Sep 19 13:28:44 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 19 Sep 2022 13:28:44 GMT
Subject: RFR: 8294006: Avoid hardcoding object file suffixes in make
In-Reply-To: <O4N4XJMjXG2eSKFNLJwKEMOstwzXGYI0gygq1lGCS8w=.7f0f7aa0-b96b-491c-9f8c-8e7073672b54@github.com>
References: <O4N4XJMjXG2eSKFNLJwKEMOstwzXGYI0gygq1lGCS8w=.7f0f7aa0-b96b-491c-9f8c-8e7073672b54@github.com>
Message-ID: <EZMJoSd0Lj-IDqQxHs9ab-qZOH42-D2P2J7NWyQYoic=.0caa70bb-9d70-4dbd-b580-4c01d581be18@github.com>

On Mon, 19 Sep 2022 12:55:47 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Replaces hardcoding of object file suffixes in make, to ensure they are always reliably set from a single place in autoconf.

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10341

From jpai at openjdk.org  Mon Sep 19 13:38:07 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 Sep 2022 13:38:07 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event
In-Reply-To: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
Message-ID: <wLSCRqjYZ6sQ4ALPzSJC5sU4aN0J6MA5sT0egSLgceY=.f68859ca-3a00-4953-b451-5e07bb960001@github.com>

On Wed, 27 Jul 2022 13:14:39 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls.

The failures reported in the GitHub Actions job look related to this change - `jdk.jfr.event.metadata.TestDefaultConfigurations` test appears to be failing:


java.lang.Exception: Setting 'threshold' in event 'jdk.SecurityProviderService' was not configured in the configuration 'default'
Setting 'threshold' in event 'jdk.SecurityProviderService' was not configured in the configuration 'profile'

	at jdk.jfr.event.metadata.TestDefaultConfigurations.throwExceptionWithErrors(TestDefaultConfigurations.java:115)
	at jdk.jfr.event.metadata.TestDefaultConfigurations.main(TestDefaultConfigurations.java:76)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:125)
	at java.base/java.lang.Thread.run(Thread.java:1589)

JavaTest Message: Test threw exception: java.lang.Exception: Setting 'threshold' in event 'jdk.SecurityProviderService' was not configured in the configuration 'default'
Setting 'threshold' in event 'jdk.SecurityProviderService' was not configured in the configuration 'profile'

src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 32:

> 30: 
> 31: import jdk.jfr.Event;
> 32: import jdk.jfr.events.*;

Hello Sean, rest of the changes look fine to me, except this one. Was this an intentional change to use `*` import instead of the explicit ones?

-------------

PR: https://git.openjdk.org/jdk/pull/9657

From egahlin at openjdk.org  Mon Sep 19 13:45:09 2022
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 19 Sep 2022 13:45:09 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event
In-Reply-To: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
Message-ID: <JAvq0QxlwoUmW_xsMGY_WeQ0SKcniEymy68ZmdrKexg=.2c025b74-e1ae-48f5-acb8-c7cd15804f7b@github.com>

On Wed, 27 Jul 2022 13:14:39 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls.

I noticed that the event is disabled by default.

Is it because of concerns of too many events, or too much overhead? Or something else?

I think we should strive to have events always on. Few users will take the time to learn about the event and enable it. Usage will probably drop by 99%, if not enabled by default.

If concerns are performance related, there might be other event designs that could be used, for example, a periodic event that is always enabled.

-------------

PR: https://git.openjdk.org/jdk/pull/9657

From jpai at openjdk.org  Mon Sep 19 14:29:52 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 Sep 2022 14:29:52 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event
In-Reply-To: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
Message-ID: <cz1JBsptiFB5ozbWYDzTFWtfrSgC2DX-6IGzYKsrliM=.796831cb-745d-415e-95d9-9614553f941b@github.com>

On Wed, 27 Jul 2022 13:14:39 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls.

src/java.base/share/classes/java/security/Provider.java line 1293:

> 1291:         }
> 1292: 
> 1293:         if (s != null && SecurityProviderServiceEvent.isTurnedOn()) {

Would it be useful to generate an event even for the cases where a call to this method was made but no service was available and `null` was returned? The event perhaps could capture  that there was no service found for such type/algorithm combination? That would help identify usages in applications where there might be fallbacks being used when this method returns null?

-------------

PR: https://git.openjdk.org/jdk/pull/9657

From ihse at openjdk.org  Mon Sep 19 15:07:44 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 19 Sep 2022 15:07:44 GMT
Subject: RFR: 8294006: Avoid hardcoding object file suffixes in make
In-Reply-To: <O4N4XJMjXG2eSKFNLJwKEMOstwzXGYI0gygq1lGCS8w=.7f0f7aa0-b96b-491c-9f8c-8e7073672b54@github.com>
References: <O4N4XJMjXG2eSKFNLJwKEMOstwzXGYI0gygq1lGCS8w=.7f0f7aa0-b96b-491c-9f8c-8e7073672b54@github.com>
Message-ID: <aMnCRW9EtuKyja57O7iHOIJfRNzgrk0WiqQSLD8REWs=.8e757ca0-28f1-4e19-9b31-0d299951521b@github.com>

On Mon, 19 Sep 2022 12:55:47 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Replaces hardcoding of object file suffixes in make, to ensure they are always reliably set from a single place in autoconf.

LGTM

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10341

From duke at openjdk.org  Mon Sep 19 15:40:29 2022
From: duke at openjdk.org (Raffaello Giulietti)
Date: Mon, 19 Sep 2022 15:40:29 GMT
Subject: RFR: 8293567: AbstractSplittableWithBrineGenerator: salt has digits
 that duplicate the marker
Message-ID: <cc1EW7QQpAv3nrKfgTDc-5EzhkGzgp6iHlhbk0-KknM=.b326cd49-179b-4b59-afbe-9bffb8610e9a@github.com>

8293567: AbstractSplittableWithBrineGenerator: salt has digits that duplicate the marker

-------------

Commit messages:
 - 8293567: AbstractSplittableWithBrineGenerator: salt has digits that duplicate the marker

Changes: https://git.openjdk.org/jdk/pull/10345/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10345&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293567
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10345.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10345/head:pull/10345

PR: https://git.openjdk.org/jdk/pull/10345

From duke at openjdk.org  Mon Sep 19 15:40:30 2022
From: duke at openjdk.org (Raffaello Giulietti)
Date: Mon, 19 Sep 2022 15:40:30 GMT
Subject: RFR: 8293567: AbstractSplittableWithBrineGenerator: salt has
 digits that duplicate the marker
In-Reply-To: <cc1EW7QQpAv3nrKfgTDc-5EzhkGzgp6iHlhbk0-KknM=.b326cd49-179b-4b59-afbe-9bffb8610e9a@github.com>
References: <cc1EW7QQpAv3nrKfgTDc-5EzhkGzgp6iHlhbk0-KknM=.b326cd49-179b-4b59-afbe-9bffb8610e9a@github.com>
Message-ID: <GIJAK2vHcvZYo0RkAcCnVQ_JNvB6b8_LDVvJdfJh9hQ=.7a01c46a-6d44-41cf-b8a1-6fb941c64eaf@github.com>

On Mon, 19 Sep 2022 15:32:34 GMT, Raffaello Giulietti <duke at openjdk.org> wrote:

> 8293567: AbstractSplittableWithBrineGenerator: salt has digits that duplicate the marker

See the JBS issue for background info

-------------

PR: https://git.openjdk.org/jdk/pull/10345

From coffeys at openjdk.org  Mon Sep 19 15:45:50 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 19 Sep 2022 15:45:50 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event
In-Reply-To: <cz1JBsptiFB5ozbWYDzTFWtfrSgC2DX-6IGzYKsrliM=.796831cb-745d-415e-95d9-9614553f941b@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
 <cz1JBsptiFB5ozbWYDzTFWtfrSgC2DX-6IGzYKsrliM=.796831cb-745d-415e-95d9-9614553f941b@github.com>
Message-ID: <5Mlk6TwFKLNBDKceYk-2u_ihr1MKZeZJ0xp-GHM-ZS4=.5d76df6c-3efe-42f0-821a-a7197840bc2f@github.com>

On Mon, 19 Sep 2022 14:25:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls.
>
> src/java.base/share/classes/java/security/Provider.java line 1293:
> 
>> 1291:         }
>> 1292: 
>> 1293:         if (s != null && SecurityProviderServiceEvent.isTurnedOn()) {
> 
> Would it be useful to generate an event even for the cases where a call to this method was made but no service was available and `null` was returned? The event perhaps could capture  that there was no service found for such type/algorithm combination? That would help identify usages in applications where there might be fallbacks being used when this method returns null?

I had this as the original design actually. I'm not sure how interesting it would be to record such "no-service" type events. It would probably add 2-4 times the number of events for this event type to a typical recording, given that the framework iterates over the providers in preferential order.

> src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 32:
> 
>> 30: 
>> 31: import jdk.jfr.Event;
>> 32: import jdk.jfr.events.*;
> 
> Hello Sean, rest of the changes look fine to me, except this one. Was this an intentional change to use `*` import instead of the explicit ones?

This was formatted via IDE. Seems like you've a preference to use the more verbose import style. I'll revert this change.

-------------

PR: https://git.openjdk.org/jdk/pull/9657

From coffeys at openjdk.org  Mon Sep 19 15:45:51 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 19 Sep 2022 15:45:51 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event
In-Reply-To: <5Mlk6TwFKLNBDKceYk-2u_ihr1MKZeZJ0xp-GHM-ZS4=.5d76df6c-3efe-42f0-821a-a7197840bc2f@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
 <cz1JBsptiFB5ozbWYDzTFWtfrSgC2DX-6IGzYKsrliM=.796831cb-745d-415e-95d9-9614553f941b@github.com>
 <5Mlk6TwFKLNBDKceYk-2u_ihr1MKZeZJ0xp-GHM-ZS4=.5d76df6c-3efe-42f0-821a-a7197840bc2f@github.com>
Message-ID: <GLm2s8J0vKM6eo0KoS4OjFGrwIHXyQwI0gW9WeJOW34=.f5fdf42a-6992-4c10-b73d-fbe03d19f24b@github.com>

On Mon, 19 Sep 2022 15:27:05 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 32:
>> 
>>> 30: 
>>> 31: import jdk.jfr.Event;
>>> 32: import jdk.jfr.events.*;
>> 
>> Hello Sean, rest of the changes look fine to me, except this one. Was this an intentional change to use `*` import instead of the explicit ones?
>
> This was formatted via IDE. Seems like you've a preference to use the more verbose import style. I'll revert this change.

Thanks for pointing out that test issue also. I missed it. I'll push a minor edit to correct.

-------------

PR: https://git.openjdk.org/jdk/pull/9657

From coffeys at openjdk.org  Mon Sep 19 15:48:55 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 19 Sep 2022 15:48:55 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event
In-Reply-To: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
Message-ID: <ARMnQasC6jHBtxbxSUDHRVtU65NXNUpKSZbf9HCuluU=.89bc857c-ceed-4365-9960-513eb26343da@github.com>

On Wed, 27 Jul 2022 13:14:39 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls.

> 

This new event is disabled by default just like the other crypto related events that were added some time back (e.g. `TLSHandshakeEvent`). My assumption is that these events will be enabled for audit mode when one is interested in finding out what their crypto operations looks like. Periodic events are good but for such operations I think it's critical that we capture all such crypto calls to ensure that admins get a good picture of what's been used/called. 

Perhaps we can have a discussion about whether such JDK events should be on by default and work the issue via another JBS issue. `jdk.Deserialization` is another example of a JDK level event that's off by default.

-------------

PR: https://git.openjdk.org/jdk/pull/9657

From mullan at openjdk.org  Mon Sep 19 15:55:46 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 19 Sep 2022 15:55:46 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event
In-Reply-To: <5Mlk6TwFKLNBDKceYk-2u_ihr1MKZeZJ0xp-GHM-ZS4=.5d76df6c-3efe-42f0-821a-a7197840bc2f@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
 <cz1JBsptiFB5ozbWYDzTFWtfrSgC2DX-6IGzYKsrliM=.796831cb-745d-415e-95d9-9614553f941b@github.com>
 <5Mlk6TwFKLNBDKceYk-2u_ihr1MKZeZJ0xp-GHM-ZS4=.5d76df6c-3efe-42f0-821a-a7197840bc2f@github.com>
Message-ID: <Sl5JOeQFX3SB1GJnQZKO2i68BWSqadulZDF1Ri6A12Y=.5b3aabe0-744c-4f65-872a-a1d7500e26cf@github.com>

On Mon, 19 Sep 2022 15:25:43 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/Provider.java line 1293:
>> 
>>> 1291:         }
>>> 1292: 
>>> 1293:         if (s != null && SecurityProviderServiceEvent.isTurnedOn()) {
>> 
>> Would it be useful to generate an event even for the cases where a call to this method was made but no service was available and `null` was returned? The event perhaps could capture  that there was no service found for such type/algorithm combination? That would help identify usages in applications where there might be fallbacks being used when this method returns null?
>
> I had this as the original design actually. I'm not sure how interesting it would be to record such "no-service" type events. It would probably add 2-4 times the number of events for this event type to a typical recording, given that the framework iterates over the providers in preferential order.

Yes, I think this would generate too much noise and detract from the main motivation for these events, which is to help users analyze the security of algorithms that are being used by their applications at the JCE layer.

-------------

PR: https://git.openjdk.org/jdk/pull/9657

From joehw at openjdk.org  Mon Sep 19 15:57:41 2022
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 19 Sep 2022 15:57:41 GMT
Subject: RFR: 8289508: Improve test coverage for XPath Axes: ancestor,
 ancestor-or-self, preceding, and preceding-sibling [v6]
In-Reply-To: <IN_PP7sn-XSna7RNt36-WxWBYUmUv5NygXAQBwi6ldI=.a5a5cf43-7085-433d-9bbd-b1e1543d9207@github.com>
References: <xn1BRpM7AtPakAYm2AdbtoddvmCNqP3wBPwjMGUPx8w=.4aaac0f2-1383-4e45-b49e-d1da3cfbdf43@github.com>
 <IN_PP7sn-XSna7RNt36-WxWBYUmUv5NygXAQBwi6ldI=.a5a5cf43-7085-433d-9bbd-b1e1543d9207@github.com>
Message-ID: <FtkOL40dJAbTeib-dBB1OAifCCnPtS4n2wKmiNzAIyU=.ad0bc3e4-53f7-4930-b889-4c7d9def3ce1@github.com>

On Sat, 17 Sep 2022 06:41:55 GMT, Rahul Prabhu <duke at openjdk.org> wrote:

>> Created two files for testing XPath Axes: XPathAncestors.java tests the ancestor and ancestor-or-self axes, while XPathPrecedingTest.java tests the preceding and preceding-sibling axes.
>
> Rahul Prabhu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8289508: fixed test name in XPathPrecedingTest

Thanks for the update.

-------------

Marked as reviewed by joehw (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10211

From coffeys at openjdk.org  Mon Sep 19 16:12:18 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 19 Sep 2022 16:12:18 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event [v2]
In-Reply-To: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
Message-ID: <H4JCf2_trHb7SpS2XO3fD1DuJ-XqCiMmXLn3E7j74Vg=.f2ca2277-fb00-4189-8fe1-f838986afe59@github.com>

> Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls.

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  update from review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9657/files
  - new: https://git.openjdk.org/jdk/pull/9657/files/aab692b2..e168152f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9657&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9657&range=00-01

  Stats: 29 lines in 2 files changed: 28 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9657.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9657/head:pull/9657

PR: https://git.openjdk.org/jdk/pull/9657

From egahlin at openjdk.org  Mon Sep 19 16:25:44 2022
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 19 Sep 2022 16:25:44 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event
In-Reply-To: <ARMnQasC6jHBtxbxSUDHRVtU65NXNUpKSZbf9HCuluU=.89bc857c-ceed-4365-9960-513eb26343da@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
 <ARMnQasC6jHBtxbxSUDHRVtU65NXNUpKSZbf9HCuluU=.89bc857c-ceed-4365-9960-513eb26343da@github.com>
Message-ID: <cKneYaBdWbW7-e2pkHa9K6j74BcTSSm_j1ZeD3W8ZCk=.ba9cca57-a107-43f1-9fe4-769a1c54a11a@github.com>

On Mon, 19 Sep 2022 15:46:46 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> This new event is disabled by default just like the other crypto related events that were added some time back (e.g. `TLSHandshakeEvent`). My assumption is that these events will be enabled for audit mode when one is interested in finding out what their crypto operations looks like. Periodic events are good but for such operations I think it's critical that we capture all such crypto calls to ensure that admins get a good picture of what's been used/called.

I remember we had this discussion a few years back and maybe we need both? Some events for audits and some that can be detected by the JMC rules engine in a normal recording?

Perhaps it's time to introduce a parameterized setting, similar to what we have for GC and compiler, where user can specify levels. From JDK 17, they can be specified on command line, i.e. 

$ java -XX:StartFlightRecording:security=off/normal/debug/audit 

This would lower the bar and make the events useful to more people.

We can do this in another JBS issue.

-------------

PR: https://git.openjdk.org/jdk/pull/9657

From valeriep at openjdk.org  Mon Sep 19 16:45:45 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 19 Sep 2022 16:45:45 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event [v2]
In-Reply-To: <Sl5JOeQFX3SB1GJnQZKO2i68BWSqadulZDF1Ri6A12Y=.5b3aabe0-744c-4f65-872a-a1d7500e26cf@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
 <cz1JBsptiFB5ozbWYDzTFWtfrSgC2DX-6IGzYKsrliM=.796831cb-745d-415e-95d9-9614553f941b@github.com>
 <5Mlk6TwFKLNBDKceYk-2u_ihr1MKZeZJ0xp-GHM-ZS4=.5d76df6c-3efe-42f0-821a-a7197840bc2f@github.com>
 <Sl5JOeQFX3SB1GJnQZKO2i68BWSqadulZDF1Ri6A12Y=.5b3aabe0-744c-4f65-872a-a1d7500e26cf@github.com>
Message-ID: <Fv1kdAJMhadva2Rq64Qnm5ntT6arEaPJ2CMxyhICfCE=.d31ed83d-646d-494b-8524-00b81bed79f5@github.com>

On Mon, 19 Sep 2022 15:52:08 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> I had this as the original design actually. I'm not sure how interesting it would be to record such "no-service" type events. It would probably add 2-4 times the number of events for this event type to a typical recording, given that the framework iterates over the providers in preferential order.
>
> Yes, I think this would generate too much noise and detract from the main motivation for these events, which is to help users analyze the security of algorithms that are being used by their applications at the JCE layer.

Plus one regarding "too much noise". This event is at the Provider.getService() level and would reports all calls regardless the type and algorithm. Crypto services which supports the delayed provider selection may call Provider.getService() to query but may not use all available ones. So, even if the service is returned, it may not be actually used. Just saying.
Does JFR events support filtering? Or is the expectation of this being a collection of usages and analyze is done separately?

-------------

PR: https://git.openjdk.org/jdk/pull/9657

From coffeys at openjdk.org  Mon Sep 19 16:58:43 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 19 Sep 2022 16:58:43 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event [v2]
In-Reply-To: <Fv1kdAJMhadva2Rq64Qnm5ntT6arEaPJ2CMxyhICfCE=.d31ed83d-646d-494b-8524-00b81bed79f5@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
 <cz1JBsptiFB5ozbWYDzTFWtfrSgC2DX-6IGzYKsrliM=.796831cb-745d-415e-95d9-9614553f941b@github.com>
 <5Mlk6TwFKLNBDKceYk-2u_ihr1MKZeZJ0xp-GHM-ZS4=.5d76df6c-3efe-42f0-821a-a7197840bc2f@github.com>
 <Sl5JOeQFX3SB1GJnQZKO2i68BWSqadulZDF1Ri6A12Y=.5b3aabe0-744c-4f65-872a-a1d7500e26cf@github.com>
 <Fv1kdAJMhadva2Rq64Qnm5ntT6arEaPJ2CMxyhICfCE=.d31ed83d-646d-494b-8524-00b81bed79f5@github.com>
Message-ID: <yhwL4gvGc1JzRzySXPoC5D_-F79QyHbTfqqqclP97bI=.05296d6e-2a00-49a1-9a6b-ff1d16e999c9@github.com>

On Mon, 19 Sep 2022 16:43:26 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Yes, I think this would generate too much noise and detract from the main motivation for these events, which is to help users analyze the security of algorithms that are being used by their applications at the JCE layer.
>
> Plus one regarding "too much noise". This event is at the Provider.getService() level and would reports all calls regardless the type and algorithm. Crypto services which supports the delayed provider selection may call Provider.getService() to query but may not use all available ones. So, even if the service is returned, it may not be actually used. Just saying.
> Does JFR events support filtering? Or is the expectation of this being a collection of usages and analyze is done separately?

Let's stick to just recording events where a match on service and provider is made then.

The expectation is that analysis would be done post recording. Probably best to reduce the runtime performance impact.

-------------

PR: https://git.openjdk.org/jdk/pull/9657

From lancea at openjdk.org  Mon Sep 19 17:25:53 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 19 Sep 2022 17:25:53 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v8]
In-Reply-To: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
Message-ID: <MTyWuWmTtcBAANKP0X9KirSub8EW1Bi-lbFHGSThuzk=.1fca1531-aabb-4290-81f2-647222d612a7@github.com>

> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
> 
> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
> 
> 
> Best,
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Minor clarification for verifying an JarInputStream

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10045/files
  - new: https://git.openjdk.org/jdk/pull/10045/files/c16e5bb8..bd4e0005

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10045&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10045&range=06-07

  Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10045.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10045/head:pull/10045

PR: https://git.openjdk.org/jdk/pull/10045

From asemenyuk at openjdk.org  Mon Sep 19 17:29:49 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 19 Sep 2022 17:29:49 GMT
Subject: RFR: 8293595: tstrings::any() is missing an overload
In-Reply-To: <0tqqa1avFzs-MV0Veo0QnpBG1-0b1djoKap5D_vF62U=.4fed5b83-dfc2-4661-a031-f3d1b64eeca9@github.com>
References: <0tqqa1avFzs-MV0Veo0QnpBG1-0b1djoKap5D_vF62U=.4fed5b83-dfc2-4661-a031-f3d1b64eeca9@github.com>
Message-ID: <dsydcefnkarOoVBM41jiBogBpD3V59rvME95tAKW1BE=.27118752-7dbc-487e-a7a1-6c3317aa2882@github.com>

On Fri, 9 Sep 2022 13:38:14 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> tstrings::any() has an overload for std::wstring (if required) but is missing the corresponding operator overload for std::string, leaving only the templated one as a fallback, which will expand into a std::wostringstream << std::string operation. This isn't particularly safe on Windows, considering that JDK-8292008 and JDK-8247283 have been recently merged, and can sporadically cause build failures. This change simply adds the missing overload with the appropriate format handling that jpackage expects from std::string. Also contains minor name changes to fit the rest of the parameter names in the other overloads.

Changes requested by asemenyuk (Reviewer).

src/jdk.jpackage/share/native/common/tstrings.h line 363:

> 361:             return *this;
> 362:         }
> 363: 

I guess you also need 

        any& operator << (LPSTR v) {
            data << (v ? fromUtf8(v) : "NULL");
            return *this;
        }

        any& operator << (LPCSTR v) {
            data << (v ? fromUtf8(v) : "NULL");
            return *this;
        }

to make a complete set of overloads

-------------

PR: https://git.openjdk.org/jdk/pull/10231

From valeriep at openjdk.org  Mon Sep 19 17:39:47 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 19 Sep 2022 17:39:47 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event [v2]
In-Reply-To: <H4JCf2_trHb7SpS2XO3fD1DuJ-XqCiMmXLn3E7j74Vg=.f2ca2277-fb00-4189-8fe1-f838986afe59@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
 <H4JCf2_trHb7SpS2XO3fD1DuJ-XqCiMmXLn3E7j74Vg=.f2ca2277-fb00-4189-8fe1-f838986afe59@github.com>
Message-ID: <G8cpKmx4jI2uamg9ssS2ldVMtoDoH6dEuBFPWLXCHto=.e841a94e-037e-4073-9fcc-e3bf909eec1c@github.com>

On Mon, 19 Sep 2022 16:12:18 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update from review comments

The java.base part of changes look good.

-------------

Marked as reviewed by valeriep (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9657

From duke at openjdk.org  Mon Sep 19 17:52:44 2022
From: duke at openjdk.org (Chris Hennick)
Date: Mon, 19 Sep 2022 17:52:44 GMT
Subject: RFR: 8284493: Fix rounding error in computeNextExponential [v14]
In-Reply-To: <bLPYyKu-bV3Blq9kH9-YW_uc6ltGFiogng4u-_Qeq68=.8d90a88e-0b6c-434a-b290-bc6441887781@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
 <bLPYyKu-bV3Blq9kH9-YW_uc6ltGFiogng4u-_Qeq68=.8d90a88e-0b6c-434a-b290-bc6441887781@github.com>
Message-ID: <p5930CuyqmRXS2KhYvNi_4iobV1jXktgK88eVlBWfYY=.06fad9ee-e7fb-4fc8-a863-5968ef950d03@github.com>

On Sun, 19 Jun 2022 23:38:36 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:
> 
>   Rewrite Javadoc

Keep open

-------------

PR: https://git.openjdk.org/jdk/pull/8131

From lancea at openjdk.org  Mon Sep 19 17:55:59 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 19 Sep 2022 17:55:59 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v6]
In-Reply-To: <eM0gLdVLRGsrXmzZgoCdcgL2XmCnzaPjqm31PUpqWDs=.d1c1e560-edba-43a8-ba38-5f8fa459f7d5@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <DRY5m5O6V8PQg4riHZDD4Ajf8LAKLnkRcIrmoG4DeGA=.f5a8aeda-aea0-4d81-888e-4a20ab6a83f6@github.com>
 <EFvr_1_wKxNI67dJ4SXoMlRXjGZ_kC1Ffzpg_tXYelw=.4d3c369f-6825-4de8-8d4b-64d7a5c9dc16@github.com>
 <Pjw2AsAaEolE03cGFx5BlGL2PTYmQMhxbW4sd7I76g8=.f0db002b-e692-4f8b-ba6b-48a684b79f30@github.com>
 <eM0gLdVLRGsrXmzZgoCdcgL2XmCnzaPjqm31PUpqWDs=.d1c1e560-edba-43a8-ba38-5f8fa459f7d5@github.com>
Message-ID: <2PVQURfKMSUCSxiwkWVpYiBN27oGnogfXUvx7zU-nQ0=.bc7ddc13-491f-4a5c-936b-59f37eb866cf@github.com>

On Mon, 19 Sep 2022 06:34:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > I can remove, but I am not sure I agree we need to describe main vs attribute here given we are pointing to the Jar spec and if there is any discussion of Pre-entry attributes, it should be in JarEntry IMHO. I guess the clarification I was trying to make, apparently unsuccessfully is that `JarEntry` will not have access to the attributes if `getManifest` does not return the Manifest.
> 
> Wording it is hard. The draft wording made it look that must call getManifest, ignore the return value, and then subsequent calls to JarEntry::getAttributes will return attributes for the JAR file entry. I think to properly describe would require more setup to explain that a manifest can optionally include per entry attributes and these are read with JarEntry::getAttributes when the manifest is found at the beginning of the stream..

Thinking about this some more, would the following be any better:


 * <p>
 * The {@code Manifest} for a JAR file may include
 *  <a href="{@docRoot}/../specs/jar/jar.html#main-attributes">main</a> and
 *  <a href="{@docRoot}/../specs/jar/jar.html#per-entry-attributes">per entry</a>
 *  attributes. {@link JarEntry#getAttributes()} will return the per entry
 *  attributes for the current JAR file entry, if any, providing
 *  {@code getManifest()} returns the {@code Manifest} for the JAR file.
 *  </p>

-------------

PR: https://git.openjdk.org/jdk/pull/10045

From sspitsyn at openjdk.org  Mon Sep 19 17:57:58 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 19 Sep 2022 17:57:58 GMT
Subject: RFR: 8293613: need to properly handle and hide tmp VTMS
 transitions [v2]
In-Reply-To: <O_jzls_cv3HBC0NbzuYV2LXaW9VB2M18FroUfXWXd2w=.fa9d1f3c-40a2-42bd-a09b-dadd5032e513@github.com>
References: <O_jzls_cv3HBC0NbzuYV2LXaW9VB2M18FroUfXWXd2w=.fa9d1f3c-40a2-42bd-a09b-dadd5032e513@github.com>
Message-ID: <eZR8_XADMl2CrnupAr7MFq_A6Y04HOeywMPhDq2KjkY=.621dcf5b-0dad-4599-9080-4c2fc56036b5@github.com>

> There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update.
> 
> There are a couple of details of this fix to highlight:
> -  A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`.
> - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored.
> - Suspending threads in temporary transition is allowed.
> 
> The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6.

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  some refactoring/renaming from Alan

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10321/files
  - new: https://git.openjdk.org/jdk/pull/10321/files/af80743a..7ff72d7f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10321&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10321&range=00-01

  Stats: 53 lines in 5 files changed: 27 ins; 12 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/10321.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10321/head:pull/10321

PR: https://git.openjdk.org/jdk/pull/10321

From jwaters at openjdk.org  Mon Sep 19 18:10:53 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 19 Sep 2022 18:10:53 GMT
Subject: RFR: 8293595: tstrings::any() is missing an overload
In-Reply-To: <dsydcefnkarOoVBM41jiBogBpD3V59rvME95tAKW1BE=.27118752-7dbc-487e-a7a1-6c3317aa2882@github.com>
References: <0tqqa1avFzs-MV0Veo0QnpBG1-0b1djoKap5D_vF62U=.4fed5b83-dfc2-4661-a031-f3d1b64eeca9@github.com>
 <dsydcefnkarOoVBM41jiBogBpD3V59rvME95tAKW1BE=.27118752-7dbc-487e-a7a1-6c3317aa2882@github.com>
Message-ID: <-LTFLRniQjzc1wQ9k3NHN2ZTVM07DV6PEf9IY9Ed6vM=.cdcdcc64-52ef-4363-b087-3efcca94c840@github.com>

On Mon, 19 Sep 2022 17:27:29 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> tstrings::any() has an overload for std::wstring (if required) but is missing the corresponding operator overload for std::string, leaving only the templated one as a fallback, which will expand into a std::wostringstream << std::string operation. This isn't particularly safe on Windows, considering that JDK-8292008 and JDK-8247283 have been recently merged, and can sporadically cause build failures. This change simply adds the missing overload with the appropriate format handling that jpackage expects from std::string. Also contains minor name changes to fit the rest of the parameter names in the other overloads.
>
> src/jdk.jpackage/share/native/common/tstrings.h line 363:
> 
>> 361:             return *this;
>> 362:         }
>> 363: 
> 
> I guess you also need 
> 
>         any& operator << (LPSTR v) {
>             data << (v ? fromUtf8(v) : "NULL");
>             return *this;
>         }
> 
>         any& operator << (LPCSTR v) {
>             data << (v ? fromUtf8(v) : "NULL");
>             return *this;
>         }
> 
> to make a complete set of overloads

I deliberately left those 2 out since the comments accompanying them seem to suggest that they're Windows specific overloads that are there for different reasons (As opposed to the one this PR is aimed at, which takes in a regular std::wstring), moreover not providing overloads for them don't seem to be causing issues either. I'm unsure if adding them too would be correct, I'll wait for more reviews before doing so

-------------

PR: https://git.openjdk.org/jdk/pull/10231

From asemenyuk at openjdk.org  Mon Sep 19 18:53:52 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 19 Sep 2022 18:53:52 GMT
Subject: RFR: 8293462: [macos] app image signature invalid when creating
 DMG or PKG from post processed signed image
In-Reply-To: <-sMR9P3CEZeJ31UFe7bzIcnC86rSErUVbY0GOymUoo4=.7c954bca-25c7-4fa0-9e2a-076ce2a485d4@github.com>
References: <-sMR9P3CEZeJ31UFe7bzIcnC86rSErUVbY0GOymUoo4=.7c954bca-25c7-4fa0-9e2a-076ce2a485d4@github.com>
Message-ID: <1EB1FpIxrJM5udvBxW4tApd5OxqEECNfU_k8AR8odgY=.7dba0637-9d85-430a-8208-f6f19ebf14c3@github.com>

On Fri, 16 Sep 2022 22:55:52 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Problem is that [JDK-8286850](https://bugs.openjdk.org/browse/JDK-8286850) never set correct value in .jpackage.xml to mark image as signed. [JDK-8289030](https://bugs.openjdk.org/browse/JDK-8289030) reads this value to check if we can add per-user and system wide configuration to packaged app. Fixed by setting correct value in .jpackage.xml when we signing predefine application image.
> 
> Added tests to cover this case and added check for values inside .jpackage.xml to validate signed and Mac App Store values.

Changes requested by asemenyuk (Reviewer).

src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageFile.java line 67:

> 65:     private final String mainClass;
> 66:     private final List<LauncherInfo> addLauncherInfos;
> 67:     private final boolean signed;

This change defeats the idea of keeping `AppImageFile` immutable. I'd rather add `AppImageFile.copyAsSigned()` method that will return the same `AppImageFile` instance if `signed` is `true`, or a copy with `signed` set to `true` otherwise.

I'd add `public AppImageFile.save(Path appImageDir)` member function to serialize `AppImageFile` instance and keep the signature of existing static `AppImageFile.save` unchanged. I'd make them call static `private AppImageFile.save(Path appImageDir, Map<String, Object> params, AppImageFile appImage)` that you have right now in the review. `AppImageFile.save(Path appImageDir, Map<String, Object> params, AppImageFile appImage)` is implementation details and should not be a part of class public interface.

-------------

PR: https://git.openjdk.org/jdk/pull/10316

From sspitsyn at openjdk.org  Mon Sep 19 19:18:57 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 19 Sep 2022 19:18:57 GMT
Subject: RFR: 8293613: need to properly handle and hide tmp VTMS
 transitions [v3]
In-Reply-To: <O_jzls_cv3HBC0NbzuYV2LXaW9VB2M18FroUfXWXd2w=.fa9d1f3c-40a2-42bd-a09b-dadd5032e513@github.com>
References: <O_jzls_cv3HBC0NbzuYV2LXaW9VB2M18FroUfXWXd2w=.fa9d1f3c-40a2-42bd-a09b-dadd5032e513@github.com>
Message-ID: <ve9g9LcSrawK3kb-TxKqxkSUOvkvnIsebd84GAub2DQ=.54a4a79b-be0a-47ef-99ba-63b93236cf08@github.com>

> There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update.
> 
> There are a couple of details of this fix to highlight:
> -  A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`.
> - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored.
> - Suspending threads in temporary transition is allowed.
> 
> The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6.

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  fixed typo in VirtualThread.c

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10321/files
  - new: https://git.openjdk.org/jdk/pull/10321/files/7ff72d7f..551d8d32

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10321&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10321&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10321.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10321/head:pull/10321

PR: https://git.openjdk.org/jdk/pull/10321

From naoto at openjdk.org  Mon Sep 19 19:20:18 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 19 Sep 2022 19:20:18 GMT
Subject: RFR: 8294008: Graphme implementation of setText() throws
 IndexOutOfBoundsException
Message-ID: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>

Fixing JCK failures caused by the new grapheme implementation. The length of a CharSequence should return the `endIndex`, not `endIndex - beginIndex`.

-------------

Commit messages:
 - 8294008: Graphme implementation of setText() throws IndexOutOfBoundsException

Changes: https://git.openjdk.org/jdk/pull/10349/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10349&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294008
  Stats: 6 lines in 2 files changed: 5 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10349.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10349/head:pull/10349

PR: https://git.openjdk.org/jdk/pull/10349

From asemenyuk at openjdk.org  Mon Sep 19 19:21:00 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 19 Sep 2022 19:21:00 GMT
Subject: RFR: 8293595: tstrings::any() is missing an overload
In-Reply-To: <0tqqa1avFzs-MV0Veo0QnpBG1-0b1djoKap5D_vF62U=.4fed5b83-dfc2-4661-a031-f3d1b64eeca9@github.com>
References: <0tqqa1avFzs-MV0Veo0QnpBG1-0b1djoKap5D_vF62U=.4fed5b83-dfc2-4661-a031-f3d1b64eeca9@github.com>
Message-ID: <B065M5tzSu1HC3H4Yq8_Oqoze0n_89SMT4W98tUTaAw=.804ebbf7-8dcd-47db-9911-9456c3b84e23@github.com>

On Fri, 9 Sep 2022 13:38:14 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> tstrings::any() has an overload for std::wstring (if required) but is missing the corresponding operator overload for std::string, leaving only the templated one as a fallback, which will expand into a std::wostringstream << std::string operation. This isn't particularly safe on Windows, considering that JDK-8292008 and JDK-8247283 have been recently merged, and can sporadically cause build failures. This change simply adds the missing overload with the appropriate format handling that jpackage expects from std::string. Also contains minor name changes to fit the rest of the parameter names in the other overloads.

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10231

From asemenyuk at openjdk.org  Mon Sep 19 19:21:00 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 19 Sep 2022 19:21:00 GMT
Subject: RFR: 8293595: tstrings::any() is missing an overload
In-Reply-To: <-LTFLRniQjzc1wQ9k3NHN2ZTVM07DV6PEf9IY9Ed6vM=.cdcdcc64-52ef-4363-b087-3efcca94c840@github.com>
References: <0tqqa1avFzs-MV0Veo0QnpBG1-0b1djoKap5D_vF62U=.4fed5b83-dfc2-4661-a031-f3d1b64eeca9@github.com>
 <dsydcefnkarOoVBM41jiBogBpD3V59rvME95tAKW1BE=.27118752-7dbc-487e-a7a1-6c3317aa2882@github.com>
 <-LTFLRniQjzc1wQ9k3NHN2ZTVM07DV6PEf9IY9Ed6vM=.cdcdcc64-52ef-4363-b087-3efcca94c840@github.com>
Message-ID: <Y55koSmY8NzWlGCjeIz-CBZkkZit9tMnfmXrMws450Q=.53a12444-6396-47ac-85d0-40a477a505db@github.com>

On Mon, 19 Sep 2022 18:06:51 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/jdk.jpackage/share/native/common/tstrings.h line 363:
>> 
>>> 361:             return *this;
>>> 362:         }
>>> 363: 
>> 
>> I guess you also need 
>> 
>>         any& operator << (LPSTR v) {
>>             data << (v ? fromUtf8(v) : "NULL");
>>             return *this;
>>         }
>> 
>>         any& operator << (LPCSTR v) {
>>             data << (v ? fromUtf8(v) : "NULL");
>>             return *this;
>>         }
>> 
>> to make a complete set of overloads
>
> I deliberately left those 2 out since the comments accompanying them seem to suggest that they're Windows specific overloads that are there for different reasons (As opposed to the one this PR is aimed at, which takes in a regular std::wstring), moreover not providing overloads for them don't seem to be causing issues either. I'm unsure if adding them too would be correct, I'll wait for more reviews before doing so

I'm the author of these comments and basically the entire source file.

You are right, it will work without the additional overloads. However the null pointers will be ignored (tested with G++ 7.4.0), but this is minor, probably implementation-specific and can be ignored.

-------------

PR: https://git.openjdk.org/jdk/pull/10231

From mullan at openjdk.org  Mon Sep 19 19:49:51 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 19 Sep 2022 19:49:51 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v8]
In-Reply-To: <MTyWuWmTtcBAANKP0X9KirSub8EW1Bi-lbFHGSThuzk=.1fca1531-aabb-4290-81f2-647222d612a7@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <MTyWuWmTtcBAANKP0X9KirSub8EW1Bi-lbFHGSThuzk=.1fca1531-aabb-4290-81f2-647222d612a7@github.com>
Message-ID: <C7z7JjGo9DPaQQt7XbJ412IJKRxLEV0iwGcscjRBEiA=.dc2f6fd1-4729-4dd6-b7ab-94f6a003abc6@github.com>

On Mon, 19 Sep 2022 17:25:53 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
>> 
>> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
>> 
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor clarification for verifying an JarInputStream

src/java.base/share/classes/java/util/jar/JarInputStream.java line 44:

> 42:  * <p>
> 43:  * The {@link #getManifest() getManifest} method is used to return the
> 44:  * <a href="{@docRoot}/../specs/jar/jar.html#jar-manifest">JAR Manifest</a>

Is it necessary to put "JAR" before "Manifest"? In the previous paragraph, you did not.

src/java.base/share/classes/java/util/jar/JarInputStream.java line 46:

> 44:  * <a href="{@docRoot}/../specs/jar/jar.html#jar-manifest">JAR Manifest</a>
> 45:  * from the entry {@code META-INF/MANIFEST.MF} when it is the first entry
> 46:  * in the stream (or the second entry the first entry in the stream is

missing "if": "or the second entry if ..."

src/java.base/share/classes/java/util/jar/JarInputStream.java line 47:

> 45:  * from the entry {@code META-INF/MANIFEST.MF} when it is the first entry
> 46:  * in the stream (or the second entry the first entry in the stream is
> 47:  * {@code META-INF/} and the second entry {@code META-INF/MANIFEST.MF}).

Missing "is": "and the second entry is ..."

src/java.base/share/classes/java/util/jar/JarInputStream.java line 48:

> 46:  * in the stream (or the second entry the first entry in the stream is
> 47:  * {@code META-INF/} and the second entry {@code META-INF/MANIFEST.MF}).
> 48:  *</p>

Nit, add space after "*".

src/java.base/share/classes/java/util/jar/JarInputStream.java line 59:

> 57:  * </p>
> 58:  *
> 59:  *  <h2>Verifying a JarInputStream</h2>

Is there a reason this is indented one extra space?

src/java.base/share/classes/java/util/jar/JarInputStream.java line 149:

> 147:     /**
> 148:      * Returns the {@code Manifest} for this JAR file when it is the first entry
> 149:      * in the stream (or the second entry the first entry in the stream is

missing "if": "or the second entry if ..."

src/java.base/share/classes/java/util/jar/JarInputStream.java line 150:

> 148:      * Returns the {@code Manifest} for this JAR file when it is the first entry
> 149:      * in the stream (or the second entry the first entry in the stream is
> 150:      * {@code META-INF/} and the second entry {@code META-INF/MANIFEST.MF}), or

Missing "is": "and the second entry is ..."

-------------

PR: https://git.openjdk.org/jdk/pull/10045

From lancea at openjdk.org  Mon Sep 19 20:04:18 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 19 Sep 2022 20:04:18 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v9]
In-Reply-To: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
Message-ID: <TwdhahrkUzeN0kDSyV1c6lKLENGCbH0f5_J7T5SRrH0=.78738797-e42b-4447-bf39-c998063bbf97@github.com>

> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
> 
> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
> 
> 
> Best,
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Address Sean's input

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10045/files
  - new: https://git.openjdk.org/jdk/pull/10045/files/bd4e0005..2bafc00c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10045&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10045&range=07-08

  Stats: 8 lines in 1 file changed: 0 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/10045.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10045/head:pull/10045

PR: https://git.openjdk.org/jdk/pull/10045

From lancea at openjdk.org  Mon Sep 19 20:07:11 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 19 Sep 2022 20:07:11 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v9]
In-Reply-To: <TwdhahrkUzeN0kDSyV1c6lKLENGCbH0f5_J7T5SRrH0=.78738797-e42b-4447-bf39-c998063bbf97@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <TwdhahrkUzeN0kDSyV1c6lKLENGCbH0f5_J7T5SRrH0=.78738797-e42b-4447-bf39-c998063bbf97@github.com>
Message-ID: <krpkrbRetivSurvWcEMe5BAeRlk__Bq2r3oOmJ6nXGg=.14ffe7dc-0794-4f63-a669-7576f560c10e@github.com>

On Mon, 19 Sep 2022 20:04:18 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
>> 
>> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
>> 
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address Sean's input

Thank you Sean for the input.  Your suggestions should have all been addressed (hopefully)

-------------

PR: https://git.openjdk.org/jdk/pull/10045

From lancea at openjdk.org  Mon Sep 19 20:07:12 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 19 Sep 2022 20:07:12 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v8]
In-Reply-To: <C7z7JjGo9DPaQQt7XbJ412IJKRxLEV0iwGcscjRBEiA=.dc2f6fd1-4729-4dd6-b7ab-94f6a003abc6@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <MTyWuWmTtcBAANKP0X9KirSub8EW1Bi-lbFHGSThuzk=.1fca1531-aabb-4290-81f2-647222d612a7@github.com>
 <C7z7JjGo9DPaQQt7XbJ412IJKRxLEV0iwGcscjRBEiA=.dc2f6fd1-4729-4dd6-b7ab-94f6a003abc6@github.com>
Message-ID: <Z-74DMU6M20_udsMSc9c3DG0J9s3tGrdqta8ElWX-IU=.4612cca8-6688-4a6d-a9d4-ab337c8f37cb@github.com>

On Mon, 19 Sep 2022 19:26:53 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor clarification for verifying an JarInputStream
>
> src/java.base/share/classes/java/util/jar/JarInputStream.java line 44:
> 
>> 42:  * <p>
>> 43:  * The {@link #getManifest() getManifest} method is used to return the
>> 44:  * <a href="{@docRoot}/../specs/jar/jar.html#jar-manifest">JAR Manifest</a>
> 
> Is it necessary to put "JAR" before "Manifest"? In the previous paragraph, you did not.

Removed JAR

> src/java.base/share/classes/java/util/jar/JarInputStream.java line 46:
> 
>> 44:  * <a href="{@docRoot}/../specs/jar/jar.html#jar-manifest">JAR Manifest</a>
>> 45:  * from the entry {@code META-INF/MANIFEST.MF} when it is the first entry
>> 46:  * in the stream (or the second entry the first entry in the stream is
> 
> missing "if": "or the second entry if ..."

updated

> src/java.base/share/classes/java/util/jar/JarInputStream.java line 47:
> 
>> 45:  * from the entry {@code META-INF/MANIFEST.MF} when it is the first entry
>> 46:  * in the stream (or the second entry the first entry in the stream is
>> 47:  * {@code META-INF/} and the second entry {@code META-INF/MANIFEST.MF}).
> 
> Missing "is": "and the second entry is ..."

updated

> src/java.base/share/classes/java/util/jar/JarInputStream.java line 48:
> 
>> 46:  * in the stream (or the second entry the first entry in the stream is
>> 47:  * {@code META-INF/} and the second entry {@code META-INF/MANIFEST.MF}).
>> 48:  *</p>
> 
> Nit, add space after "*".

fixed

> src/java.base/share/classes/java/util/jar/JarInputStream.java line 59:
> 
>> 57:  * </p>
>> 58:  *
>> 59:  *  <h2>Verifying a JarInputStream</h2>
> 
> Is there a reason this is indented one extra space?

Updated

> src/java.base/share/classes/java/util/jar/JarInputStream.java line 149:
> 
>> 147:     /**
>> 148:      * Returns the {@code Manifest} for this JAR file when it is the first entry
>> 149:      * in the stream (or the second entry the first entry in the stream is
> 
> missing "if": "or the second entry if ..."

updated

> src/java.base/share/classes/java/util/jar/JarInputStream.java line 150:
> 
>> 148:      * Returns the {@code Manifest} for this JAR file when it is the first entry
>> 149:      * in the stream (or the second entry the first entry in the stream is
>> 150:      * {@code META-INF/} and the second entry {@code META-INF/MANIFEST.MF}), or
> 
> Missing "is": "and the second entry is ..."

fixed

-------------

PR: https://git.openjdk.org/jdk/pull/10045

From weijun at openjdk.org  Mon Sep 19 20:34:46 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 19 Sep 2022 20:34:46 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v6]
In-Reply-To: <2PVQURfKMSUCSxiwkWVpYiBN27oGnogfXUvx7zU-nQ0=.bc7ddc13-491f-4a5c-936b-59f37eb866cf@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <DRY5m5O6V8PQg4riHZDD4Ajf8LAKLnkRcIrmoG4DeGA=.f5a8aeda-aea0-4d81-888e-4a20ab6a83f6@github.com>
 <EFvr_1_wKxNI67dJ4SXoMlRXjGZ_kC1Ffzpg_tXYelw=.4d3c369f-6825-4de8-8d4b-64d7a5c9dc16@github.com>
 <Pjw2AsAaEolE03cGFx5BlGL2PTYmQMhxbW4sd7I76g8=.f0db002b-e692-4f8b-ba6b-48a684b79f30@github.com>
 <eM0gLdVLRGsrXmzZgoCdcgL2XmCnzaPjqm31PUpqWDs=.d1c1e560-edba-43a8-ba38-5f8fa459f7d5@github.com>
 <2PVQURfKMSUCSxiwkWVpYiBN27oGnogfXUvx7zU-nQ0=.bc7ddc13-491f-4a5c-936b-59f37eb866cf@github.com>
Message-ID: <LlI1t4-s_xsY_VOmbrlPOHYoF2EUFJI8-PBs691M0XU=.28859b65-62d8-41e4-b519-fe096ef6fb89@github.com>

On Mon, 19 Sep 2022 17:53:51 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>>> I can remove, but I am not sure I agree we need to describe main vs attribute here given we are pointing to the Jar spec and if there is any discussion of Pre-entry attributes, it should be in JarEntry IMHO. I guess the clarification I was trying to make, apparently unsuccessfully is that `JarEntry` will not have access to the attributes if `getManifest` does not return the Manifest.
>> 
>> Wording it is hard. The draft wording made it look  that must call getManifest, ignore the return value, and then subsequent calls to JarEntry::getAttributes will return attributes for the JAR file entry. I think to properly describe would require more setup to explain that a manifest can optionally include per entry attributes and these are read with JarEntry::getAttributes when the manifest is found at the beginning of the stream..
>
>> > I can remove, but I am not sure I agree we need to describe main vs attribute here given we are pointing to the Jar spec and if there is any discussion of Pre-entry attributes, it should be in JarEntry IMHO. I guess the clarification I was trying to make, apparently unsuccessfully is that `JarEntry` will not have access to the attributes if `getManifest` does not return the Manifest.
>> 
>> Wording it is hard. The draft wording made it look that must call getManifest, ignore the return value, and then subsequent calls to JarEntry::getAttributes will return attributes for the JAR file entry. I think to properly describe would require more setup to explain that a manifest can optionally include per entry attributes and these are read with JarEntry::getAttributes when the manifest is found at the beginning of the stream..
> 
> Thinking about this some more, would the following be any better:
> 
> 
>  * <p>
>  * The {@code Manifest} for a JAR file may include
>  *  <a href="{@docRoot}/../specs/jar/jar.html#main-attributes">main</a> and
>  *  <a href="{@docRoot}/../specs/jar/jar.html#per-entry-attributes">per entry</a>
>  *  attributes. {@link JarEntry#getAttributes()} will return the per entry
>  *  attributes for the current JAR file entry, if any, providing
>  *  {@code getManifest()} returns the {@code Manifest} for the JAR file.
>  *  </p>

Does this mean that the "Verifying a JarInputStream" should also avoid mentioning "getManifest method returns the manifest"? I understand precisely it should be "getManifest method is able to return the manifest if you call it".

It almost sounds like we should first define the concepts of "well-formed JAR file" and "well-formed signed JAR" and then specify what these methods behave.

-------------

PR: https://git.openjdk.org/jdk/pull/10045

From cjplummer at openjdk.org  Mon Sep 19 20:46:10 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 19 Sep 2022 20:46:10 GMT
Subject: RFR: 8293613: need to properly handle and hide tmp VTMS
 transitions [v3]
In-Reply-To: <ve9g9LcSrawK3kb-TxKqxkSUOvkvnIsebd84GAub2DQ=.54a4a79b-be0a-47ef-99ba-63b93236cf08@github.com>
References: <O_jzls_cv3HBC0NbzuYV2LXaW9VB2M18FroUfXWXd2w=.fa9d1f3c-40a2-42bd-a09b-dadd5032e513@github.com>
 <ve9g9LcSrawK3kb-TxKqxkSUOvkvnIsebd84GAub2DQ=.54a4a79b-be0a-47ef-99ba-63b93236cf08@github.com>
Message-ID: <vMfCeRbX7oTnnv5-1PggLMUc1Q8MjZ0mnSFp5cutdTA=.08a9c27a-1bc2-4118-8f88-56c741df1435@github.com>

On Mon, 19 Sep 2022 19:18:57 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update.
>> 
>> There are a couple of details of this fix to highlight:
>> -  A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`.
>> - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored.
>> - Suspending threads in temporary transition is allowed.
>> 
>> The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed typo in VirtualThread.c

src/hotspot/share/prims/jvmtiEnvBase.cpp line 713:

> 711:   if (!jt->is_in_tmp_VTMS_transition()) {
> 712:     jvf = check_and_skip_hidden_frames(jt, jvf);
> 713:   }

I think this comment needs some help. It's hard to match it up with what the code is doing. I think you are saying you want to avoid skipping hidden frames when in transition, although if that's the case, it's not clear to me why not skipping is ok.

Also is skipping (or not skipping) ok regardless of the JvmtiEnvBase::is_cthread_with_continuation() result?

src/hotspot/share/prims/jvmtiExport.cpp line 1055:

> 1053:   if (JavaThread::current()->is_in_tmp_VTMS_transition()) {
> 1054:     return false;
> 1055:   }

You mentioned this in the PR description. However, it's not clear to me why this is ok.  Also, it should be commented.

Same thing for changes in JvmtiExport::post_class_load() and JvmtiExport::post_class_prepare().

src/hotspot/share/runtime/javaThread.cpp line 1174:

> 1172: #if INCLUDE_JVMTI
> 1173:   // Suspending a JavaThread in VTMS transition or disabling VTMS transitions can cause deadlocks.
> 1174:   assert(!is_in_non_tmp_VTMS_transition(), "no suspend allowed in VTMS transition");

IMHO, a non tmp VTMS transition should be considered a type of VTMS transition, so the assert check here does not really match the assert text. Also see my related comments below on naming and use of these flags and APIs.

src/hotspot/share/runtime/javaThread.hpp line 650:

> 648:   void set_is_in_VTMS_transition(bool val);
> 649:   bool is_in_tmp_VTMS_transition() const         { return _is_in_tmp_VTMS_transition; }
> 650:   void toggle_is_in_tmp_VTMS_transition()        { _is_in_tmp_VTMS_transition = !_is_in_tmp_VTMS_transition; };

The naming of the flags does not match up with the naming of the APIs, which is confusing.  An API named  is_in_VTMS_transition() should return _is_in_VTMS_transition. I think part of problem is that _is_in_VTMS_transition is not a superset of _is_in_tmp_VTMS_transition. The flags are never both set true, although both can be false. Maybe this should be changed to make it an invariant that if _is_in_tmp_VTMS_transit is true, then _is_in_tmp_VTMS_transition is true.

-------------

PR: https://git.openjdk.org/jdk/pull/10321

From joehw at openjdk.org  Mon Sep 19 20:49:48 2022
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 19 Sep 2022 20:49:48 GMT
Subject: RFR: 8294008: Graphme implementation of setText() throws
 IndexOutOfBoundsException
In-Reply-To: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>
References: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>
Message-ID: <9q1PEg15HYOhUIrTfUdKhpbUcXjpppP6JANXsj6Mlsw=.b5a81583-9470-4b68-b824-7a11583a8b70@github.com>

On Mon, 19 Sep 2022 19:01:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing JCK failures caused by the new grapheme implementation. The length of a CharSequence should return the `endIndex`, not `endIndex - beginIndex`.

src/java.base/share/classes/sun/util/locale/provider/BreakIteratorProviderImpl.java line 329:

> 327:         @Override
> 328:         public int length() {
> 329:             return src.getEndIndex();

Could the issue be somewhere else?  I mean it feels correct for length = endIndex - beginIndex.

-------------

PR: https://git.openjdk.org/jdk/pull/10349

From jwaters at openjdk.org  Mon Sep 19 20:49:49 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 19 Sep 2022 20:49:49 GMT
Subject: RFR: 8293595: tstrings::any() is missing an overload
In-Reply-To: <Y55koSmY8NzWlGCjeIz-CBZkkZit9tMnfmXrMws450Q=.53a12444-6396-47ac-85d0-40a477a505db@github.com>
References: <0tqqa1avFzs-MV0Veo0QnpBG1-0b1djoKap5D_vF62U=.4fed5b83-dfc2-4661-a031-f3d1b64eeca9@github.com>
 <dsydcefnkarOoVBM41jiBogBpD3V59rvME95tAKW1BE=.27118752-7dbc-487e-a7a1-6c3317aa2882@github.com>
 <-LTFLRniQjzc1wQ9k3NHN2ZTVM07DV6PEf9IY9Ed6vM=.cdcdcc64-52ef-4363-b087-3efcca94c840@github.com>
 <Y55koSmY8NzWlGCjeIz-CBZkkZit9tMnfmXrMws450Q=.53a12444-6396-47ac-85d0-40a477a505db@github.com>
Message-ID: <kg3ceAeYuxlJh3jbSCWaW2puuVm2ZsI8D_aNfLt34Tg=.b45ec586-6de3-4d46-9fc8-7cd8ed0984b6@github.com>

On Mon, 19 Sep 2022 19:17:06 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> I deliberately left those 2 out since the comments accompanying them seem to suggest that they're Windows specific overloads that are there for different reasons (As opposed to the one this PR is aimed at, which takes in a regular std::wstring), moreover not providing overloads for them don't seem to be causing issues either. I'm unsure if adding them too would be correct, I'll wait for more reviews before doing so
>
> I'm the author of these comments and basically the entire source file.
> 
> You are right, it will work without the additional overloads. However the null pointers will be ignored (tested with G++ 7.4.0), but this is minor, probably implementation-specific and can be ignored.

Strange, on my end gcc doesn't mind NULL being passed (though this may be due to a different gcc version being used), guess it's probably implementation specific like you mentioned

-------------

PR: https://git.openjdk.org/jdk/pull/10231

From naoto at openjdk.org  Mon Sep 19 21:04:52 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 19 Sep 2022 21:04:52 GMT
Subject: RFR: 8294008: Graphme implementation of setText() throws
 IndexOutOfBoundsException
In-Reply-To: <9q1PEg15HYOhUIrTfUdKhpbUcXjpppP6JANXsj6Mlsw=.b5a81583-9470-4b68-b824-7a11583a8b70@github.com>
References: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>
 <9q1PEg15HYOhUIrTfUdKhpbUcXjpppP6JANXsj6Mlsw=.b5a81583-9470-4b68-b824-7a11583a8b70@github.com>
Message-ID: <8o6GmYySek8iJI4rvXiSMxKhjI8UZyRORQeCVwaidzM=.ae213824-aca7-4162-a0c0-9cd39682160a@github.com>

On Mon, 19 Sep 2022 20:46:08 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Fixing JCK failures caused by the new grapheme implementation. The length of a CharSequence should return the `endIndex`, not `endIndex - beginIndex`.
>
> src/java.base/share/classes/sun/util/locale/provider/BreakIteratorProviderImpl.java line 329:
> 
>> 327:         @Override
>> 328:         public int length() {
>> 329:             return src.getEndIndex();
> 
> Could the issue be somewhere else?  I mean it feels correct for length = endIndex - beginIndex.

It's somewhat confusing as this class adapts `CharacterIterator` into `CharSequence` which are similar to each other (thus the bug). Those `beginIndex`/`endIndex` designate the range in the source `CharacterIterator`, and this `length()` method should return the entire text length of the `CharSequence` nevertheless, thus it should start from `0` to `endIndex`.

-------------

PR: https://git.openjdk.org/jdk/pull/10349

From almatvee at openjdk.org  Mon Sep 19 21:29:44 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 19 Sep 2022 21:29:44 GMT
Subject: RFR: 8293595: tstrings::any() is missing an overload
In-Reply-To: <0tqqa1avFzs-MV0Veo0QnpBG1-0b1djoKap5D_vF62U=.4fed5b83-dfc2-4661-a031-f3d1b64eeca9@github.com>
References: <0tqqa1avFzs-MV0Veo0QnpBG1-0b1djoKap5D_vF62U=.4fed5b83-dfc2-4661-a031-f3d1b64eeca9@github.com>
Message-ID: <IjLeVBhC2vz4lOpBd9XoN_Lwju2Ut05yiE8UJlrxcp4=.92aaac62-938c-4c5d-95c5-0d75caf59956@github.com>

On Fri, 9 Sep 2022 13:38:14 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> tstrings::any() has an overload for std::wstring (if required) but is missing the corresponding operator overload for std::string, leaving only the templated one as a fallback, which will expand into a std::wostringstream << std::string operation. This isn't particularly safe on Windows, considering that JDK-8292008 and JDK-8247283 have been recently merged, and can sporadically cause build failures. This change simply adds the missing overload with the appropriate format handling that jpackage expects from std::string. Also contains minor name changes to fit the rest of the parameter names in the other overloads.

Marked as reviewed by almatvee (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10231

From joehw at openjdk.org  Mon Sep 19 22:10:16 2022
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 19 Sep 2022 22:10:16 GMT
Subject: RFR: 8294008: Grapheme implementation of setText() throws
 IndexOutOfBoundsException
In-Reply-To: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>
References: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>
Message-ID: <whMN5DuXhD3HucrHMLxwG1n4JFEWBfesz5FnqwpQSEY=.b4cc3b4c-6d58-4ae3-8308-cce242bb2393@github.com>

On Mon, 19 Sep 2022 19:01:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing JCK failures caused by the new grapheme implementation. The length of a CharSequence should return the `endIndex`, not `endIndex - beginIndex`.

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10349

From joehw at openjdk.org  Mon Sep 19 22:10:17 2022
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 19 Sep 2022 22:10:17 GMT
Subject: RFR: 8294008: Grapheme implementation of setText() throws
 IndexOutOfBoundsException
In-Reply-To: <8o6GmYySek8iJI4rvXiSMxKhjI8UZyRORQeCVwaidzM=.ae213824-aca7-4162-a0c0-9cd39682160a@github.com>
References: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>
 <9q1PEg15HYOhUIrTfUdKhpbUcXjpppP6JANXsj6Mlsw=.b5a81583-9470-4b68-b824-7a11583a8b70@github.com>
 <8o6GmYySek8iJI4rvXiSMxKhjI8UZyRORQeCVwaidzM=.ae213824-aca7-4162-a0c0-9cd39682160a@github.com>
Message-ID: <9Zrf4UTRoFOdKg2lMZjHngzPuPnpiR3TgNtgpg_P1Go=.258d28fe-e571-40b9-b5b1-5154d09df9eb@github.com>

On Mon, 19 Sep 2022 21:02:38 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/sun/util/locale/provider/BreakIteratorProviderImpl.java line 329:
>> 
>>> 327:         @Override
>>> 328:         public int length() {
>>> 329:             return src.getEndIndex();
>> 
>> Could the issue be somewhere else?  I mean it feels correct for length = endIndex - beginIndex.
>
> It's somewhat confusing as this class adapts `CharacterIterator` into `CharSequence` which are similar to each other (thus the bug). Those `beginIndex`/`endIndex` designate the range in the source `CharacterIterator`, and this `length()` method should return the entire text length of the `CharSequence` nevertheless, thus it should start from `0` to `endIndex`.

Yeah, I saw there's a mismatch between the src and limit in this call that led to the index check Exception:
286             for (int b = ci.getBeginIndex(); b < end;) {
287                 boundaries.add(b);
288                 b = Grapheme.nextBoundary(text, b, end);
289             }

and nextBoundary could walk through the entire CharSequence. Maybe it's worth a note to the length() method.

-------------

PR: https://git.openjdk.org/jdk/pull/10349

From naoto at openjdk.org  Mon Sep 19 22:21:44 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 19 Sep 2022 22:21:44 GMT
Subject: RFR: 8294008: Grapheme implementation of setText() throws
 IndexOutOfBoundsException [v2]
In-Reply-To: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>
References: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>
Message-ID: <NR-tVVCQ9bpstL82QUacICiw9giirn5eOZMF2gfJlgA=.8df3f0b4-8dcb-4c8e-ab8e-333ed124dab1@github.com>

> Fixing JCK failures caused by the new grapheme implementation. The length of a CharSequence should return the `endIndex`, not `endIndex - beginIndex`.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Added comments to length()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10349/files
  - new: https://git.openjdk.org/jdk/pull/10349/files/2b176cd6..85291040

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10349&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10349&range=00-01

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10349.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10349/head:pull/10349

PR: https://git.openjdk.org/jdk/pull/10349

From naoto at openjdk.org  Mon Sep 19 22:21:45 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 19 Sep 2022 22:21:45 GMT
Subject: RFR: 8294008: Grapheme implementation of setText() throws
 IndexOutOfBoundsException [v2]
In-Reply-To: <9Zrf4UTRoFOdKg2lMZjHngzPuPnpiR3TgNtgpg_P1Go=.258d28fe-e571-40b9-b5b1-5154d09df9eb@github.com>
References: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>
 <9q1PEg15HYOhUIrTfUdKhpbUcXjpppP6JANXsj6Mlsw=.b5a81583-9470-4b68-b824-7a11583a8b70@github.com>
 <8o6GmYySek8iJI4rvXiSMxKhjI8UZyRORQeCVwaidzM=.ae213824-aca7-4162-a0c0-9cd39682160a@github.com>
 <9Zrf4UTRoFOdKg2lMZjHngzPuPnpiR3TgNtgpg_P1Go=.258d28fe-e571-40b9-b5b1-5154d09df9eb@github.com>
Message-ID: <rJrb_Srn7Q286QXnt6BQjMO4lM3F8tkO9ujKkdVYI74=.0a0830d2-8e56-4bd9-8c19-b09d2c9fe554@github.com>

On Mon, 19 Sep 2022 22:07:13 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> It's somewhat confusing as this class adapts `CharacterIterator` into `CharSequence` which are similar to each other (thus the bug). Those `beginIndex`/`endIndex` designate the range in the source `CharacterIterator`, and this `length()` method should return the entire text length of the `CharSequence` nevertheless, thus it should start from `0` to `endIndex`.
>
> Yeah, I saw there's a mismatch between the src and limit in this call that led to the index check Exception:
> 286             for (int b = ci.getBeginIndex(); b < end;) {
> 287                 boundaries.add(b);
> 288                 b = Grapheme.nextBoundary(text, b, end);
> 289             }
> 
> and nextBoundary could walk through the entire CharSequence. Maybe it's worth a note to the length() method.

Thanks, Joe. Added comment to the method.

-------------

PR: https://git.openjdk.org/jdk/pull/10349

From smarks at openjdk.org  Mon Sep 19 23:07:43 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 19 Sep 2022 23:07:43 GMT
Subject: RFR: 8294008: Grapheme implementation of setText() throws
 IndexOutOfBoundsException [v2]
In-Reply-To: <rJrb_Srn7Q286QXnt6BQjMO4lM3F8tkO9ujKkdVYI74=.0a0830d2-8e56-4bd9-8c19-b09d2c9fe554@github.com>
References: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>
 <9q1PEg15HYOhUIrTfUdKhpbUcXjpppP6JANXsj6Mlsw=.b5a81583-9470-4b68-b824-7a11583a8b70@github.com>
 <8o6GmYySek8iJI4rvXiSMxKhjI8UZyRORQeCVwaidzM=.ae213824-aca7-4162-a0c0-9cd39682160a@github.com>
 <9Zrf4UTRoFOdKg2lMZjHngzPuPnpiR3TgNtgpg_P1Go=.258d28fe-e571-40b9-b5b1-5154d09df9eb@github.com>
 <rJrb_Srn7Q286QXnt6BQjMO4lM3F8tkO9ujKkdVYI74=.0a0830d2-8e56-4bd9-8c19-b09d2c9fe554@github.com>
Message-ID: <jskb_0PWmITMwGYWcAd95VctIrkEXh_PpC5btLmstZM=.49282989-7524-42c3-a8f4-8b87f7f918c3@github.com>

On Mon, 19 Sep 2022 22:18:42 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Yeah, I saw there's a mismatch between the src and limit in this call that led to the index check Exception:
>> 286             for (int b = ci.getBeginIndex(); b < end;) {
>> 287                 boundaries.add(b);
>> 288                 b = Grapheme.nextBoundary(text, b, end);
>> 289             }
>> 
>> and nextBoundary could walk through the entire CharSequence. Maybe it's worth a note to the length() method.
>
> Thanks, Joe. Added comment to the method.

OK yeah this is really confusing. One might ask a similar question in `charAt` about why it doesn't call

    src.setIndex(index + src.getBeginIndex());

The answer is that this is a special-purpose `CharSequence` that represents characters in the index range [0..endIndex) of the underlying `CharacterIterator`, **even if** that `CharacterIterator` represents the subrange of some string. As Joe noted, the calling code in `GraphemeBreakIterator` takes care to ensure that only valid indexes into the `src` are used.

I think the comment on `length` helps a little bit but maybe a class-level comment would be better, since it applies to the whole model of this special `CharSequence` and not just the `length` method. Just a sentence or two is sufficient. Feel free to crib from the above.

-------------

PR: https://git.openjdk.org/jdk/pull/10349

From duke at openjdk.org  Tue Sep 20 01:01:39 2022
From: duke at openjdk.org (dumasun)
Date: Tue, 20 Sep 2022 01:01:39 GMT
Subject: RFR: 8293977: jdk/modules/etc/VerifyModuleDelegation.java fail
 with jfx
In-Reply-To: <K8keV23DhjOl2iAcpxEGUPEDKfRsrPMwVYf6ZvYV39M=.66a73163-007e-4951-a524-7cf8d5aa1f79@github.com>
References: <K8keV23DhjOl2iAcpxEGUPEDKfRsrPMwVYf6ZvYV39M=.66a73163-007e-4951-a524-7cf8d5aa1f79@github.com>
Message-ID: <FqNnNXVqj1DaORWiY7nVfOfoSI1MJsIbapV-3uENMHg=.01a80525-2ef1-4e20-9042-e28a713efb2f@github.com>

On Mon, 19 Sep 2022 00:45:32 GMT, Leslie Zhai <lzhai at openjdk.org> wrote:

> Hi,
> 
> @dumasun reported the issue:
> 
> Configured with jfx-ls-modular-sdk:
> 
> 
> configure --with-import-modules=modular-sdk
> 
> 
> `make run-test CONF=fastdebug TEST="jdk/modules/etc/VerifyModuleDelegation.java"` failed:
> 
> 
> ----------System.out:(46/3114)----------
> test VerifyModuleDelegation.checkJavaBase(): success
> test VerifyModuleDelegation.checkLoaderDelegation(): failure
> java.lang.Error: platform/javafx.swing can't delegate to find classes from app/jdk.unsupported.desktop
>     at VerifyModuleDelegation.lambda$checkLoaderDelegation$1(VerifyModuleDelegation.java:77)
>     at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>     at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1921)
>     at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>     at VerifyModuleDelegation.lambda$checkLoaderDelegation$2(VerifyModuleDelegation.java:68)
>     at java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1715)
>     at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>     at VerifyModuleDelegation.checkLoaderDelegation(VerifyModuleDelegation.java:68)
>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>     at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>     at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>     at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>     at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>     at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>     at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>     at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>     at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>     at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
>     at org.testng.TestRunner.privateRun(TestRunner.java:764)
>     at org.testng.TestRunner.run(TestRunner.java:585)
>     at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
>     at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
>     at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
>     at org.testng.SuiteRunner.run(SuiteRunner.java:286)
>     at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
>     at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
>     at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
>     at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
>     at org.testng.TestNG.runSuites(TestNG.java:1069)
>     at org.testng.TestNG.run(TestNG.java:1037)
>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54)
>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>     at java.base/java.lang.Thread.run(Thread.java:1589)
> 
> ===============================================
> jdk/modules/etc/VerifyModuleDelegation.java
> Total tests run: 2, Passes: 1, Failures: 1, Skips: 0
> ===============================================
> 
> ----------System.err:(13/753)----------
> WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.concurrent
> java.lang.Exception: failures: 1
>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96)
>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54)
>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>     at java.base/java.lang.Thread.run(Thread.java:1589)
> 
> 
> Thanks,
> Leslie Zhai

The replication step for 17 is simple on x86(no additional steps):

cd jdk17u-ls
jtreg/bin/jtreg -dir:test/jdk -testjdk:./zulu17.36.17-ca-fx-jdk17.0.4.1-linux_x64 \
-verbose:all jdk/modules/etc/VerifyModuleDelegation.java

Can you repeat the bug on x86?
**ps:test repo is jdk17u-ls**

Thanks,
dumasun

-------------

PR: https://git.openjdk.org/jdk/pull/10328

From dholmes at openjdk.org  Tue Sep 20 01:04:25 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 20 Sep 2022 01:04:25 GMT
Subject: RFR: 8290482: Update JNI Specification of DestroyJavaVM for better
 alignment with JLS, JVMS, and Java SE API Specifications
Message-ID: <M2IRKiuONiNI45YTu9wdu1o8ZXJslnxRmgMvnlVU478=.4aa03d22-0395-4354-bf41-f11a74df791a@github.com>

This update is primarily about changes to the JNI Invocation API specification, mainly in relation to `DestroyJavaVM`. The motivation for the changes is to align with changes being made to the JLS, JVMS and `java.lang.Runtime`, specifications in relation to VM termination - ref:

JDK-8290196 12.8: Clarify the definition of program exit
https://bugs.openjdk.org/browse/JDK-8290196

JDK-8290388 5.7: Clarify the definition of JVM termination
https://bugs.openjdk.org/browse/JDK-8290388

JDK-8290036 Define and specify Runtime shutdown sequence
https://bugs.openjdk.org/browse/JDK-8290036

Mostly these are just non-normative changes to the JNI spec prose but there are two actual specification changes:

1.  The fact it is an error to detach a thread with active Java frames was only mentioned in the overview section, not in the actual `DetachCurrentThread` specification. (Just an oversight - the VM already checked this)

2.  We need to make it an error to call `DestroyJavaVM` from an attached thread with active Java frames (as this can't work for the same reason we disallow `DetachCurrentThread`). This requires an implementation change in Hotspot.

Issue 2 covers the code change, and regression test, in this PR.

In addition the specification changes can be seen here:

- specdiff: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/diff.html
- original: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-original.html
- new: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-new.html

The specification itself is not open but comments on the spec changes are welcome - though please see the JBS issue and CSR request first. The revised wording has already been extensively reviewed/negotiated between Alex Buckley, Stuart Marks and myself, so any change must either be a glaring error/problem or else a trivial adjustment.

Thank you.

-------------

Commit messages:
 - Fix code format
 - Fix code format
 - Fix @bug number
 - Merge branch 'master' into 8290482-destroyjvm
 - Added testcase
 - 8290482: Update JNI Specification of DestroyJavaVM for better alignment with JLS, JVMS, and Java SE API Specifications

Changes: https://git.openjdk.org/jdk/pull/10352/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10352&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8290482
  Stats: 110 lines in 4 files changed: 108 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10352.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10352/head:pull/10352

PR: https://git.openjdk.org/jdk/pull/10352

From dholmes at openjdk.org  Tue Sep 20 01:11:47 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 20 Sep 2022 01:11:47 GMT
Subject: RFR: 8290482: Update JNI Specification of DestroyJavaVM for better
 alignment with JLS, JVMS, and Java SE API Specifications [v2]
In-Reply-To: <M2IRKiuONiNI45YTu9wdu1o8ZXJslnxRmgMvnlVU478=.4aa03d22-0395-4354-bf41-f11a74df791a@github.com>
References: <M2IRKiuONiNI45YTu9wdu1o8ZXJslnxRmgMvnlVU478=.4aa03d22-0395-4354-bf41-f11a74df791a@github.com>
Message-ID: <OGFkFqp4Vdm8cs2Su8zSnfcGqHmqYqvqQC1PQccXq1k=.cb906e96-0c22-41ed-b021-1d0c0c87f1c4@github.com>

> This update is primarily about changes to the JNI Invocation API specification, mainly in relation to `DestroyJavaVM`. The motivation for the changes is to align with changes being made to the JLS, JVMS and `java.lang.Runtime`, specifications in relation to VM termination - ref:
> 
> JDK-8290196 12.8: Clarify the definition of program exit
> https://bugs.openjdk.org/browse/JDK-8290196
> 
> JDK-8290388 5.7: Clarify the definition of JVM termination
> https://bugs.openjdk.org/browse/JDK-8290388
> 
> JDK-8290036 Define and specify Runtime shutdown sequence
> https://bugs.openjdk.org/browse/JDK-8290036
> 
> Mostly these are just non-normative changes to the JNI spec prose but there are two actual specification changes:
> 
> 1.  The fact it is an error to detach a thread with active Java frames was only mentioned in the overview section, not in the actual `DetachCurrentThread` specification. (Just an oversight - the VM already checked this)
> 
> 2.  We need to make it an error to call `DestroyJavaVM` from an attached thread with active Java frames (as this can't work for the same reason we disallow `DetachCurrentThread`). This requires an implementation change in Hotspot.
> 
> Issue 2 covers the code change, and regression test, in this PR.
> 
> In addition the specification changes can be seen here:
> 
> - specdiff: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/diff.html
> - original: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-original.html
> - new: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-new.html
> 
> The specification itself is not open but comments on the spec changes are welcome - though please see the JBS issue and CSR request first. The revised wording has already been extensively reviewed/negotiated between Alex Buckley, Stuart Marks and myself, so any change must either be a glaring error/problem or else a trivial adjustment.
> 
> Thank you.

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Fix code format

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10352/files
  - new: https://git.openjdk.org/jdk/pull/10352/files/3106d6a3..e6c36702

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10352&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10352&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10352.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10352/head:pull/10352

PR: https://git.openjdk.org/jdk/pull/10352

From naoto at openjdk.org  Tue Sep 20 01:14:38 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 20 Sep 2022 01:14:38 GMT
Subject: RFR: 8294008: Grapheme implementation of setText() throws
 IndexOutOfBoundsException [v3]
In-Reply-To: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>
References: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>
Message-ID: <OM6U1eNJOgC0WeTitQ2eI0_UGRb9_r2kNbmoSN9TUkg=.8f04c208-46cc-4184-bc66-b30cc1c49c07@github.com>

> Fixing JCK failures caused by the new grapheme implementation. The length of a CharSequence should return the `endIndex`, not `endIndex - beginIndex`.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Refine the comments by adding class level description in CharacterIteratorCharSequence

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10349/files
  - new: https://git.openjdk.org/jdk/pull/10349/files/85291040..f0a65ed0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10349&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10349&range=01-02

  Stats: 10 lines in 1 file changed: 8 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10349.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10349/head:pull/10349

PR: https://git.openjdk.org/jdk/pull/10349

From naoto at openjdk.org  Tue Sep 20 01:14:39 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 20 Sep 2022 01:14:39 GMT
Subject: RFR: 8294008: Grapheme implementation of setText() throws
 IndexOutOfBoundsException [v3]
In-Reply-To: <jskb_0PWmITMwGYWcAd95VctIrkEXh_PpC5btLmstZM=.49282989-7524-42c3-a8f4-8b87f7f918c3@github.com>
References: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>
 <9q1PEg15HYOhUIrTfUdKhpbUcXjpppP6JANXsj6Mlsw=.b5a81583-9470-4b68-b824-7a11583a8b70@github.com>
 <8o6GmYySek8iJI4rvXiSMxKhjI8UZyRORQeCVwaidzM=.ae213824-aca7-4162-a0c0-9cd39682160a@github.com>
 <9Zrf4UTRoFOdKg2lMZjHngzPuPnpiR3TgNtgpg_P1Go=.258d28fe-e571-40b9-b5b1-5154d09df9eb@github.com>
 <rJrb_Srn7Q286QXnt6BQjMO4lM3F8tkO9ujKkdVYI74=.0a0830d2-8e56-4bd9-8c19-b09d2c9fe554@github.com>
 <jskb_0PWmITMwGYWcAd95VctIrkEXh_PpC5btLmstZM=.49282989-7524-42c3-a8f4-8b87f7f918c3@github.com>
Message-ID: <cHC-nc8NQE81Htm6j-uWdr_oLC7AhlHqI1lS-80SejI=.fb87f5d9-5cd5-44b7-96a3-4e1ed8e0c6c0@github.com>

On Mon, 19 Sep 2022 23:04:12 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Thanks, Joe. Added comment to the method.
>
> OK yeah this is really confusing. One might ask a similar question in `charAt` about why it doesn't call
> 
>     src.setIndex(index + src.getBeginIndex());
> 
> The answer is that this is a special-purpose `CharSequence` that represents characters in the index range [0..endIndex) of the underlying `CharacterIterator`, **even if** that `CharacterIterator` represents the subrange of some string. As Joe noted, the calling code in `GraphemeBreakIterator` takes care to ensure that only valid indexes into the `src` are used.
> 
> I think the comment on `length` helps a little bit but maybe a class-level comment would be better, since it applies to the whole model of this special `CharSequence` and not just the `length` method. Just a sentence or two is sufficient. Feel free to crib from the above.

Thanks, Stuart. I used the paragraph almost intact for the class description ?

-------------

PR: https://git.openjdk.org/jdk/pull/10349

From almatvee at openjdk.org  Tue Sep 20 04:05:56 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 20 Sep 2022 04:05:56 GMT
Subject: RFR: 8293462: [macos] app image signature invalid when creating
 DMG or PKG from post processed signed image [v2]
In-Reply-To: <-sMR9P3CEZeJ31UFe7bzIcnC86rSErUVbY0GOymUoo4=.7c954bca-25c7-4fa0-9e2a-076ce2a485d4@github.com>
References: <-sMR9P3CEZeJ31UFe7bzIcnC86rSErUVbY0GOymUoo4=.7c954bca-25c7-4fa0-9e2a-076ce2a485d4@github.com>
Message-ID: <rx7LwNB89Ka3Y8cEOnCaQ4-XvsJhJEfPcpigwprrLUY=.9eccee19-4fde-49f1-bcec-a7c0bddbbeab@github.com>

> Problem is that [JDK-8286850](https://bugs.openjdk.org/browse/JDK-8286850) never set correct value in .jpackage.xml to mark image as signed. [JDK-8289030](https://bugs.openjdk.org/browse/JDK-8289030) reads this value to check if we can add per-user and system wide configuration to packaged app. Fixed by setting correct value in .jpackage.xml when we signing predefine application image.
> 
> Added tests to cover this case and added check for values inside .jpackage.xml to validate signed and Mac App Store values.

Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:

  8293462: [macos] app image signature invalid when creating DMG or PKG from post processed signed image [v2]

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10316/files
  - new: https://git.openjdk.org/jdk/pull/10316/files/22ead550..19d4981d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10316&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10316&range=00-01

  Stats: 105 lines in 4 files changed: 73 ins; 15 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/10316.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10316/head:pull/10316

PR: https://git.openjdk.org/jdk/pull/10316

From almatvee at openjdk.org  Tue Sep 20 04:05:56 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 20 Sep 2022 04:05:56 GMT
Subject: RFR: 8293462: [macos] app image signature invalid when creating
 DMG or PKG from post processed signed image [v2]
In-Reply-To: <1EB1FpIxrJM5udvBxW4tApd5OxqEECNfU_k8AR8odgY=.7dba0637-9d85-430a-8208-f6f19ebf14c3@github.com>
References: <-sMR9P3CEZeJ31UFe7bzIcnC86rSErUVbY0GOymUoo4=.7c954bca-25c7-4fa0-9e2a-076ce2a485d4@github.com>
 <1EB1FpIxrJM5udvBxW4tApd5OxqEECNfU_k8AR8odgY=.7dba0637-9d85-430a-8208-f6f19ebf14c3@github.com>
Message-ID: <6jPnHPPmzGjCOMqgAIwOg6jCLJARugLVP4QpP17aXhE=.3dd62b5b-deaf-44a1-b9ca-828e5a83f492@github.com>

On Mon, 19 Sep 2022 18:51:30 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8293462: [macos] app image signature invalid when creating DMG or PKG from post processed signed image [v2]
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageFile.java line 67:
> 
>> 65:     private final String mainClass;
>> 66:     private final List<LauncherInfo> addLauncherInfos;
>> 67:     private final boolean signed;
> 
> This change defeats the idea of keeping `AppImageFile` immutable. I'd rather add `AppImageFile.copyAsSigned()` method that will return the same `AppImageFile` instance if `signed` is `true`, or a copy with `signed` set to `true` otherwise.
> 
> I'd add `public AppImageFile.save(Path appImageDir)` member function to serialize `AppImageFile` instance and keep the signature of existing static `AppImageFile.save` unchanged. I'd make them call static `private AppImageFile.save(Path appImageDir, Map<String, Object> params, AppImageFile appImage)` that you have right now in the review. `AppImageFile.save(Path appImageDir, Map<String, Object> params, AppImageFile appImage)` is implementation details and should not be a part of class public interface.

8293462: [macos] app image signature invalid when creating DMG or PKG from post processed signed image [v2]
 - Fixed as suggested.
 - Moved getAttribute() under LauncherInfo class, since it is used only by this class.
 - Added unit test for AppImageFile.copyAsSigned().

-------------

PR: https://git.openjdk.org/jdk/pull/10316

From dholmes at openjdk.org  Tue Sep 20 05:42:57 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 20 Sep 2022 05:42:57 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v4]
In-Reply-To: <ZTzHjlUXhJf5U3PndgGMZUpwbIJhJ0kSxL2am_PfFT8=.4279d477-9a1e-4a2c-b334-90cc60b5592b@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <ZTzHjlUXhJf5U3PndgGMZUpwbIJhJ0kSxL2am_PfFT8=.4279d477-9a1e-4a2c-b334-90cc60b5592b@github.com>
Message-ID: <bjXGfmDhmaMyT_j_bQhZLezMj4Jb18w0yhQsYZhlXjU=.d5f0014e-9d6d-4c5f-b84f-5446166bb767@github.com>

On Sat, 17 Sep 2022 08:41:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
>> 
>> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
>> 
>> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
>> 
>> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.
>
> 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 12 additional commits since the last revision:
> 
>  - Merge
>  - Updates to Java Thread Primitive Deprecation page
>  - Repalce "it" with "victim thread"
>  - Merge
>  - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop
>  - become -> became in javadoc
>  - Merge
>  - Remove stopThread permission from RuntimePermission table, exclude jshell tests
>  - Deprecate for removal
>  - Next iteration, update dates in headers
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/4a31f682...93806f99

Hi Alan,

Good to see this finally become non-functional but as long as the debugger/JVMTI can trigger throwing an async ThreadDeath then I have to question the potential change in behaviour introduced by removing all the `catch (ThreadDeath td)` logic in various places.

src/java.base/share/classes/java/io/FilterOutputStream.java line 195:

> 193:                    // evaluate possible precedence of flushException over closeException
> 194:                    if ((flushException instanceof ThreadDeath) &&
> 195:                        !(closeException instanceof ThreadDeath)) {

If the ThreadDeath originates from the debugger then this is now a change in behaviour.

src/java.base/share/classes/java/lang/Shutdown.java line 132:

> 130:                 if (hook != null) hook.run();
> 131:             } catch (Throwable t) {
> 132:                 // ignore

Again change of behaviour if TD originates from debugger.

src/java.base/share/classes/java/lang/ThreadDeath.java line 30:

> 28: /**
> 29:  * An instance of {@code ThreadDeath} was originally specified to be thrown
> 30:  * by a victim thread when "stopped" with {@link Thread#stop()}.

Should this have always mentioned the possibility of TD coming from a debugger as well?

src/java.base/share/classes/java/lang/ThreadGroup.java line 700:

> 698:                 ueh.uncaughtException(t, e);
> 699:             } else {
> 700:                 System.err.print("Exception in thread \"" + t.getName() + "\" ");

Again change in behaviour.

src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html line 37:

> 35: stop a thread removed?</h2>
> 36: <p>Because it was inherently unsafe. Stopping a thread caused it to
> 37: unlock all the monitors that it had locked. (The monitors were

Just an aside but this rationale was always a significant under-statement as async-exceptions are inherently unsafe even if no concurrency or monitors are involved.

src/java.desktop/macosx/classes/sun/lwawt/LWToolkit.java line 170:

> 168:                     }
> 169:                 }
> 170:             } catch (ThreadDeath td) {

Again change in behaviour

src/java.desktop/share/classes/java/awt/EventDispatchThread.java line 205:

> 203:             eq.dispatchEvent(event);
> 204:         }
> 205:         catch (ThreadDeath death) {

Again change in behaviour.

-------------

PR: https://git.openjdk.org/jdk/pull/10230

From alanb at openjdk.org  Tue Sep 20 06:05:14 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 20 Sep 2022 06:05:14 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v4]
In-Reply-To: <bjXGfmDhmaMyT_j_bQhZLezMj4Jb18w0yhQsYZhlXjU=.d5f0014e-9d6d-4c5f-b84f-5446166bb767@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <ZTzHjlUXhJf5U3PndgGMZUpwbIJhJ0kSxL2am_PfFT8=.4279d477-9a1e-4a2c-b334-90cc60b5592b@github.com>
 <bjXGfmDhmaMyT_j_bQhZLezMj4Jb18w0yhQsYZhlXjU=.d5f0014e-9d6d-4c5f-b84f-5446166bb767@github.com>
Message-ID: <jhvaxnF1s7-oPaVsF9nf5ko8wP1gBWOo5TfO8T_j40A=.731ea409-ca17-488e-a0b1-3cb15334515a@github.com>

On Tue, 20 Sep 2022 04:21:39 GMT, David Holmes <dholmes 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 12 additional commits since the last revision:
>> 
>>  - Merge
>>  - Updates to Java Thread Primitive Deprecation page
>>  - Repalce "it" with "victim thread"
>>  - Merge
>>  - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop
>>  - become -> became in javadoc
>>  - Merge
>>  - Remove stopThread permission from RuntimePermission table, exclude jshell tests
>>  - Deprecate for removal
>>  - Next iteration, update dates in headers
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/26f404b2...93806f99
>
> src/java.base/share/classes/java/io/FilterOutputStream.java line 195:
> 
>> 193:                    // evaluate possible precedence of flushException over closeException
>> 194:                    if ((flushException instanceof ThreadDeath) &&
>> 195:                        !(closeException instanceof ThreadDeath)) {
> 
> If the ThreadDeath originates from the debugger then this is now a change in behaviour.

> Good to see this finally become non-functional but as long as the debugger/JVMTI can trigger throwing an async ThreadDeath then I have to question the potential change in behaviour introduced by removing all the `catch (ThreadDeath td)` logic in various places.

I've gone through a few times too and concluded it would be better to remove these untestable code paths. The debugger scenario is more like what used to be Thread.stop(Throwable). It can be used to throw any exception or error, e.g. ask the debugger to throw IllegalArgumentException or SQLException when I'm at this breakpoint so I can see how the code behaves. Yes, the user could ask the debugger to throw java.lang.ThreadDeath when prompted but it's not really interesting now because code won't get this error outside of a debugger. We could leave the special handing but we have no way to test is and we'll need to the remove the special handling when TD is removed.  As a general point, the special casing of TD is a bit inconsistent and more likely to be seen in older code rather newer code. A static analysis of 24M classes found very few usages in 3rd libraries.

> Should this have always mentioned the possibility of TD coming from a debugger as well?

The debugger can cause any error or exception to be thrown so I don't think we should put anything in the TD spec about this.

-------------

PR: https://git.openjdk.org/jdk/pull/10230

From alanb at openjdk.org  Tue Sep 20 06:15:28 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 20 Sep 2022 06:15:28 GMT
Subject: RFR: 8293977: jdk/modules/etc/VerifyModuleDelegation.java fail
 with jfx
In-Reply-To: <FqNnNXVqj1DaORWiY7nVfOfoSI1MJsIbapV-3uENMHg=.01a80525-2ef1-4e20-9042-e28a713efb2f@github.com>
References: <K8keV23DhjOl2iAcpxEGUPEDKfRsrPMwVYf6ZvYV39M=.66a73163-007e-4951-a524-7cf8d5aa1f79@github.com>
 <FqNnNXVqj1DaORWiY7nVfOfoSI1MJsIbapV-3uENMHg=.01a80525-2ef1-4e20-9042-e28a713efb2f@github.com>
Message-ID: <lfPQn4R5i_X77TB27E1AYsoCGsWGkmvYWQEFBtiF5r0=.0a7f0eb5-f789-46e0-a3a6-eb19c3fd7fb2@github.com>

On Mon, 19 Sep 2022 11:53:19 GMT, dumasun <duke at openjdk.org> wrote:

> jtreg/bin/jtreg -dir:test/jdk -testjdk:./jdk-fx-jdk-20+15-56-g4020ed53dd6-linux_x64 \
> -verbose:all jdk/modules/etc/VerifyModuleDelegation.java

Is jdk-fx-jdk-20+15-56-g4020ed53dd6-linux_x64 your build or is it coming from somewhere else? Also can you confirm that make/conf/module-loader-map.conf has not been edit to map the javafx.* modules to the platform class loader?

-------------

PR: https://git.openjdk.org/jdk/pull/10328

From jpai at openjdk.org  Tue Sep 20 06:19:58 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 20 Sep 2022 06:19:58 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event [v2]
In-Reply-To: <H4JCf2_trHb7SpS2XO3fD1DuJ-XqCiMmXLn3E7j74Vg=.f2ca2277-fb00-4189-8fe1-f838986afe59@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
 <H4JCf2_trHb7SpS2XO3fD1DuJ-XqCiMmXLn3E7j74Vg=.f2ca2277-fb00-4189-8fe1-f838986afe59@github.com>
Message-ID: <xbVtwov6ZBPq4qCrCSQ-1Ww0-u8WPJ4ApmpjzARVVAI=.3467f8bd-2b9c-4fdd-a58c-e60470f7aaa0@github.com>

On Mon, 19 Sep 2022 16:12:18 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update from review comments

Marked as reviewed by jpai (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9657

From jpai at openjdk.org  Tue Sep 20 06:19:58 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 20 Sep 2022 06:19:58 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event [v2]
In-Reply-To: <yhwL4gvGc1JzRzySXPoC5D_-F79QyHbTfqqqclP97bI=.05296d6e-2a00-49a1-9a6b-ff1d16e999c9@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
 <cz1JBsptiFB5ozbWYDzTFWtfrSgC2DX-6IGzYKsrliM=.796831cb-745d-415e-95d9-9614553f941b@github.com>
 <5Mlk6TwFKLNBDKceYk-2u_ihr1MKZeZJ0xp-GHM-ZS4=.5d76df6c-3efe-42f0-821a-a7197840bc2f@github.com>
 <Sl5JOeQFX3SB1GJnQZKO2i68BWSqadulZDF1Ri6A12Y=.5b3aabe0-744c-4f65-872a-a1d7500e26cf@github.com>
 <Fv1kdAJMhadva2Rq64Qnm5ntT6arEaPJ2CMxyhICfCE=.d31ed83d-646d-494b-8524-00b81bed79f5@github.com>
 <yhwL4gvGc1JzRzySXPoC5D_-F79QyHbTfqqqclP97bI=.05296d6e-2a00-49a1-9a6b-ff1d16e999c9@github.com>
Message-ID: <Qt8K6gJtCIGJXJta2otQPLmZRh2v8Get-CQpSPmb7Y0=.2a0cbb5d-4506-46ca-a3ac-51086ebb2df7@github.com>

On Mon, 19 Sep 2022 16:55:01 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Plus one regarding "too much noise". This event is at the Provider.getService() level and would reports all calls regardless the type and algorithm. Crypto services which supports the delayed provider selection may call Provider.getService() to query but may not use all available ones. So, even if the service is returned, it may not be actually used. Just saying.
>> Does JFR events support filtering? Or is the expectation of this being a collection of usages and analyze is done separately?
>
> Let's stick to just recording events where a match on service and provider is made then.
> 
> The expectation is that analysis would be done post recording. Probably best to reduce the runtime performance impact.

Thank you for noting the reason, Sean. It's reasonable to only generate an event for a match.

-------------

PR: https://git.openjdk.org/jdk/pull/9657

From alanb at openjdk.org  Tue Sep 20 07:00:44 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 20 Sep 2022 07:00:44 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v7]
In-Reply-To: <8BlTa_vNbW2I2WyDopUYmD-p45YJSq_Xg0uwdFY6IWU=.465f7021-e77e-4e08-9a90-2622f4981825@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <_tMtVfn6qdtAb3EZiSBqve0gM_WGZKUAyYwnYqtZMgA=.74bfe2cf-e1c4-47c2-99ba-14a804f6d470@github.com>
 <FLeEDUKHCLDrIia-kRzHeu8qxqk5rEiWC3fpUmr9SqM=.ebdeaaf5-5c83-4940-ab84-2e8bf04d5ccd@github.com>
 <8BlTa_vNbW2I2WyDopUYmD-p45YJSq_Xg0uwdFY6IWU=.465f7021-e77e-4e08-9a90-2622f4981825@github.com>
Message-ID: <smQJRfHa2D5WybPQrDn9XtaKrWeux7odcJbWYl6tgfI=.8e861b1c-b0ce-4b55-b5d3-81b00c36a6ee@github.com>

On Mon, 19 Sep 2022 10:21:30 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> OK, will make another pass at this today

I looked at the latest draft (2bafc00c). I think it would help if the section "Verifying a JarInputStream" were renamed to "Signed JAR files".  The link to getManifest makes the reader wonder if they have to call this method whereas I think what you want to say that the manifest must be at the start of the stream (as per the first section) and then followed by signature entries.

-------------

PR: https://git.openjdk.org/jdk/pull/10045

From mbaesken at openjdk.org  Tue Sep 20 07:36:18 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 20 Sep 2022 07:36:18 GMT
Subject: RFR: JDK-8293659: Improve UnsatisfiedLinkError error message to
 include dlopen error details [v2]
In-Reply-To: <xF7xU_nv7od9QNvVMREbQGelSOQ0okJPyTnoQhkK2w0=.83257c39-be99-41ea-adf5-6affb2712f22@github.com>
References: <ifR_svzVaPWpTZ48Mm7a_bANpIvAgQB1HEiBrXlA0oQ=.1dd92d2d-c9f2-4bbf-9a02-8bde08cdb8fb@github.com>
 <xF7xU_nv7od9QNvVMREbQGelSOQ0okJPyTnoQhkK2w0=.83257c39-be99-41ea-adf5-6affb2712f22@github.com>
Message-ID: <eEe12Wws5ZEiGI7QNhjC-EN6VUi11tSlY7mbhwSS88I=.6c25174f-0076-4fdf-a89d-9c0e9fbc7def@github.com>

On Fri, 16 Sep 2022 07:27:44 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When trying to load a x64 lib on macOS aarch64 one got previously this detailed message before [JDK-8275703](https://bugs.openjdk.org/browse/JDK-8275703):
>> 
>> java.lang.UnsatisfiedLinkError: /testing/jco3/macOsx64/libsapjco3.dylib: dlopen(/testing/jco3/macOsx64/libsapjco3.dylib, 1): no suitable image found. Did find:
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust throwExceptionIfFail

Hi Thomas, I think previously (before supporting the macOS dl-cache) we did not even attempted to call JVM_LoadLibrary when the file was not present. I asked myself the same think you mentioned , Mandy had this remark on the topic : 
"System::loadLibrary attempts to load library found from "java.library.path"  (and also from the system library path).  For each path given in "java.library.path", it constructs the filepath of the library and checks if that exists.   If exists, it loads the library using dlopen.  In that case, throw exception by VM makes sense.   If the filepath of that library does not exist, it could be in the dynamic cache or it could be just non-existent - at this point, we can't throw exception because we can't tell until all paths in "java.library.path" are searched. "

-------------

PR: https://git.openjdk.org/jdk/pull/10286

From asotona at openjdk.org  Tue Sep 20 07:45:38 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 20 Sep 2022 07:45:38 GMT
Subject: RFR: 8278863: Add method ClassDesc::ofInternalName [v3]
In-Reply-To: <_YwivDpNpN7dcsjgID8QfbfjbXgVrdJ6AoP_aRPVzuk=.62231086-0981-4f81-9096-8ffe835f08c1@github.com>
References: <3WrKiVDNyaAvxuxpWsaiY7FZT_W5WDftJdwUENnqQc0=.518b7bea-2c44-45de-8832-203819529b27@github.com>
 <D4wAQ1eHUnHYZsRzjjYwCIsdKpHeOugdKrNwxYh4Ufs=.fe14d73a-fde9-4e91-a8d1-214edde05a63@github.com>
 <xX9VDTF0NGm2tyiU3o6VZf9BYbhsbyxNMhK0No9k_O8=.7c6104e9-b31d-4f4d-b6b2-7b70a75f1827@github.com>
 <_YwivDpNpN7dcsjgID8QfbfjbXgVrdJ6AoP_aRPVzuk=.62231086-0981-4f81-9096-8ffe835f08c1@github.com>
Message-ID: <_l3aMkAx45iC9GYRhUcZvKDUtZf3xhplKjwm5fN7WNc=.83239be0-4080-4fc5-8a6f-7bbea054311b@github.com>

On Mon, 22 Aug 2022 07:24:14 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> test/jdk/java/lang/constant/ClassDescTest.java line 268:
>> 
>>> 266:         }
>>> 267: 
>>> 268:         List<String> badInternalNames = List.of("I;", "[]",
>> 
>> is `[]` a good test for arrays? Wouldn't something more realistic like `[Ljava/lang/String` be better? I note that `[]` is also used in another test. Problem with testing `[]` is that if the checking logic has a bug, or a regression is introduced so that it only detects `]` instead of `[` the test would not detect that (but I guess that's a remote possibility).
>
> Thanks for pointing it out, I'll add a valid array descriptor into the list of badInternalNames.

done, thanks

-------------

PR: https://git.openjdk.org/jdk/pull/9201

From asotona at openjdk.org  Tue Sep 20 07:53:48 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 20 Sep 2022 07:53:48 GMT
Subject: Integrated: 8278863: Add method ClassDesc::ofInternalName
In-Reply-To: <3WrKiVDNyaAvxuxpWsaiY7FZT_W5WDftJdwUENnqQc0=.518b7bea-2c44-45de-8832-203819529b27@github.com>
References: <3WrKiVDNyaAvxuxpWsaiY7FZT_W5WDftJdwUENnqQc0=.518b7bea-2c44-45de-8832-203819529b27@github.com>
Message-ID: <O52beDmp9TuTTvkkx5OWUSQwusmo2A9flFLfHX9tdiw=.230b93ed-464e-48f6-8fbc-23ad20075d06@github.com>

On Fri, 17 Jun 2022 14:19:11 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> The symbolic constants API (`java.lang.constant`) was designed, in part, to provide bytecode parsing and generation APIs with a validated, common, symbolic form for constants in Java class files. 
> 
> There is an easy way to create a `ClassDesc` from a binary name (`ClassDesc::of`) or a field descriptor (`ClassDesc::ofDescriptor`) but not from an internal name. But, the internal name is common in low-level bytecode-manipulation code. 
> 
> This patch adds `ClassDesc::ofInternalName` static factory method that creates a `ClassDesc` from class internal name.
> Class internal name validation and extended ClassDescTest are also parts of this patch.
> 
> CSR is linked with the issue.
> 
> Please review.
> 
> Thank you,
> Adam

This pull request has now been integrated.

Changeset: 0fa7d9e8
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0fa7d9e8cd34694c56f98fb4b86549cfd7a3ed1c
Stats:     61 lines in 3 files changed: 61 ins; 0 del; 0 mod

8278863: Add method ClassDesc::ofInternalName

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/9201

From duke at openjdk.org  Tue Sep 20 08:08:41 2022
From: duke at openjdk.org (dumasun)
Date: Tue, 20 Sep 2022 08:08:41 GMT
Subject: RFR: 8293977: jdk/modules/etc/VerifyModuleDelegation.java fail
 with jfx
In-Reply-To: <lfPQn4R5i_X77TB27E1AYsoCGsWGkmvYWQEFBtiF5r0=.0a7f0eb5-f789-46e0-a3a6-eb19c3fd7fb2@github.com>
References: <K8keV23DhjOl2iAcpxEGUPEDKfRsrPMwVYf6ZvYV39M=.66a73163-007e-4951-a524-7cf8d5aa1f79@github.com>
 <FqNnNXVqj1DaORWiY7nVfOfoSI1MJsIbapV-3uENMHg=.01a80525-2ef1-4e20-9042-e28a713efb2f@github.com>
 <lfPQn4R5i_X77TB27E1AYsoCGsWGkmvYWQEFBtiF5r0=.0a7f0eb5-f789-46e0-a3a6-eb19c3fd7fb2@github.com>
Message-ID: <RJV-K13pBzxCdfmw7zQNNu2G8VI8Qq5mWmqVuQ4-z44=.eab811bd-7e19-4649-a9ef-6ac20fdd1ba2@github.com>

On Tue, 20 Sep 2022 06:12:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > jtreg/bin/jtreg -dir:test/jdk -testjdk:./jdk-fx-jdk-20+15-56-g4020ed53dd6-linux_x64 
> > -verbose:all jdk/modules/etc/VerifyModuleDelegation.java
> 
> Is jdk-fx-jdk-20+15-56-g4020ed53dd6-linux_x64 your build or is it coming from somewhere else? 

yes, jdk-fx-jdk-20+15-56-g4020ed53dd6-linux_x64 my build
build steps:
step 1. git clone https://github.com/openjdk/jfx.git and buid modular-sdk.
step 2. git clone https://github.com/openjdk/jdk, configure --with-import-modules=/path/modular-sdk and make images.
then jdk-fx-jdk-20+15-56-g4020ed53dd6-linux_x64 as testjdk.

Is there something wrong with the way I test?

> Also can you confirm that make/conf/module-loader-map.conf has not been edit to map the javafx.* modules to the platform class loader?

I donot edit make/conf/module-loader-map.conf.

-------------

PR: https://git.openjdk.org/jdk/pull/10328

From dholmes at openjdk.org  Tue Sep 20 08:27:49 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 20 Sep 2022 08:27:49 GMT
Subject: RFR: 8290482: Update JNI Specification of DestroyJavaVM for better
 alignment with JLS, JVMS, and Java SE API Specifications [v3]
In-Reply-To: <M2IRKiuONiNI45YTu9wdu1o8ZXJslnxRmgMvnlVU478=.4aa03d22-0395-4354-bf41-f11a74df791a@github.com>
References: <M2IRKiuONiNI45YTu9wdu1o8ZXJslnxRmgMvnlVU478=.4aa03d22-0395-4354-bf41-f11a74df791a@github.com>
Message-ID: <iINw3IdBMBg4vDxfn-P_bK-q2gWXmp5Fimqp98zWezQ=.79c714f1-d938-4c17-8625-53d69d09a14d@github.com>

> This update is primarily about changes to the JNI Invocation API specification, mainly in relation to `DestroyJavaVM`. The motivation for the changes is to align with changes being made to the JLS, JVMS and `java.lang.Runtime`, specifications in relation to VM termination - ref:
> 
> JDK-8290196 12.8: Clarify the definition of program exit
> https://bugs.openjdk.org/browse/JDK-8290196
> 
> JDK-8290388 5.7: Clarify the definition of JVM termination
> https://bugs.openjdk.org/browse/JDK-8290388
> 
> JDK-8290036 Define and specify Runtime shutdown sequence
> https://bugs.openjdk.org/browse/JDK-8290036
> 
> Mostly these are just non-normative changes to the JNI spec prose but there are two actual specification changes:
> 
> 1.  The fact it is an error to detach a thread with active Java frames was only mentioned in the overview section, not in the actual `DetachCurrentThread` specification. (Just an oversight - the VM already checked this)
> 
> 2.  We need to make it an error to call `DestroyJavaVM` from an attached thread with active Java frames (as this can't work for the same reason we disallow `DetachCurrentThread`). This requires an implementation change in Hotspot.
> 
> Issue 2 covers the code change, and regression test, in this PR.
> 
> In addition the specification changes can be seen here:
> 
> - specdiff: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/diff.html
> - original: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-original.html
> - new: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-new.html
> 
> The specification itself is not open but comments on the spec changes are welcome - though please see the JBS issue and CSR request first. The revised wording has already been extensively reviewed/negotiated between Alex Buckley, Stuart Marks and myself, so any change must either be a glaring error/problem or else a trivial adjustment.
> 
> Thank you.

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Missed update to Threads::is_supported_jni_version

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10352/files
  - new: https://git.openjdk.org/jdk/pull/10352/files/e6c36702..e56fd09d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10352&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10352&range=01-02

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10352.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10352/head:pull/10352

PR: https://git.openjdk.org/jdk/pull/10352

From alanb at openjdk.org  Tue Sep 20 08:56:27 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 20 Sep 2022 08:56:27 GMT
Subject: RFR: 8293977: jdk/modules/etc/VerifyModuleDelegation.java fail
 with jfx
In-Reply-To: <RJV-K13pBzxCdfmw7zQNNu2G8VI8Qq5mWmqVuQ4-z44=.eab811bd-7e19-4649-a9ef-6ac20fdd1ba2@github.com>
References: <K8keV23DhjOl2iAcpxEGUPEDKfRsrPMwVYf6ZvYV39M=.66a73163-007e-4951-a524-7cf8d5aa1f79@github.com>
 <FqNnNXVqj1DaORWiY7nVfOfoSI1MJsIbapV-3uENMHg=.01a80525-2ef1-4e20-9042-e28a713efb2f@github.com>
 <lfPQn4R5i_X77TB27E1AYsoCGsWGkmvYWQEFBtiF5r0=.0a7f0eb5-f789-46e0-a3a6-eb19c3fd7fb2@github.com>
 <RJV-K13pBzxCdfmw7zQNNu2G8VI8Qq5mWmqVuQ4-z44=.eab811bd-7e19-4649-a9ef-6ac20fdd1ba2@github.com>
Message-ID: <to9OW-JHn5MR7HE0ZLcYhrQ5Y-cdN9C2S-_Gh_Q7Xcs=.b32c2afe-3dad-4773-b940-fa2afe47b818@github.com>

On Tue, 20 Sep 2022 08:04:48 GMT, dumasun <duke at openjdk.org> wrote:

> I donot edit make/conf/module-loader-map.conf.

@magicus @kevinrushforth  In the distant past, the javafx.* modules were mapped to the platform class loader. Do you recall how that worked with configure --with-import-modules? If someone uses jlink to create a run-time image that includes the javafx.* modules then they will be mapped to the application class loader. Somehow, using  --with-import-modules we seem to end up with these modules in the value of PLATFORM_MODULE_NAMES used by build. I'm wondering if there is some residual configuration somewhere.

-------------

PR: https://git.openjdk.org/jdk/pull/10328

From dholmes at openjdk.org  Tue Sep 20 10:37:41 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 20 Sep 2022 10:37:41 GMT
Subject: RFR: 8290482: Update JNI Specification of DestroyJavaVM for better
 alignment with JLS, JVMS, and Java SE API Specifications [v4]
In-Reply-To: <M2IRKiuONiNI45YTu9wdu1o8ZXJslnxRmgMvnlVU478=.4aa03d22-0395-4354-bf41-f11a74df791a@github.com>
References: <M2IRKiuONiNI45YTu9wdu1o8ZXJslnxRmgMvnlVU478=.4aa03d22-0395-4354-bf41-f11a74df791a@github.com>
Message-ID: <5LZVfXnTpbyr_NWeYid9qzKrnZ6t2b7ZL5BtHEZ4Syc=.bff15db2-726a-4976-89f1-edd826d75bf2@github.com>

> This update is primarily about changes to the JNI Invocation API specification, mainly in relation to `DestroyJavaVM`. The motivation for the changes is to align with changes being made to the JLS, JVMS and `java.lang.Runtime`, specifications in relation to VM termination - ref:
> 
> JDK-8290196 12.8: Clarify the definition of program exit
> https://bugs.openjdk.org/browse/JDK-8290196
> 
> JDK-8290388 5.7: Clarify the definition of JVM termination
> https://bugs.openjdk.org/browse/JDK-8290388
> 
> JDK-8290036 Define and specify Runtime shutdown sequence
> https://bugs.openjdk.org/browse/JDK-8290036
> 
> Mostly these are just non-normative changes to the JNI spec prose but there are two actual specification changes:
> 
> 1.  The fact it is an error to detach a thread with active Java frames was only mentioned in the overview section, not in the actual `DetachCurrentThread` specification. (Just an oversight - the VM already checked this)
> 
> 2.  We need to make it an error to call `DestroyJavaVM` from an attached thread with active Java frames (as this can't work for the same reason we disallow `DetachCurrentThread`). This requires an implementation change in Hotspot.
> 
> Issue 2 covers the code change, and regression test, in this PR.
> 
> In addition the specification changes can be seen here:
> 
> - specdiff: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/diff.html
> - original: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-original.html
> - new: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-new.html
> 
> The specification itself is not open but comments on the spec changes are welcome - though please see the JBS issue and CSR request first. The revised wording has already been extensively reviewed/negotiated between Alex Buckley, Stuart Marks and myself, so any change must either be a glaring error/problem or else a trivial adjustment.
> 
> Thank you.

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Fix JniVersion test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10352/files
  - new: https://git.openjdk.org/jdk/pull/10352/files/e56fd09d..9639dcf5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10352&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10352&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10352.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10352/head:pull/10352

PR: https://git.openjdk.org/jdk/pull/10352

From lancea at openjdk.org  Tue Sep 20 10:53:57 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 20 Sep 2022 10:53:57 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v7]
In-Reply-To: <smQJRfHa2D5WybPQrDn9XtaKrWeux7odcJbWYl6tgfI=.8e861b1c-b0ce-4b55-b5d3-81b00c36a6ee@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <_tMtVfn6qdtAb3EZiSBqve0gM_WGZKUAyYwnYqtZMgA=.74bfe2cf-e1c4-47c2-99ba-14a804f6d470@github.com>
 <FLeEDUKHCLDrIia-kRzHeu8qxqk5rEiWC3fpUmr9SqM=.ebdeaaf5-5c83-4940-ab84-2e8bf04d5ccd@github.com>
 <8BlTa_vNbW2I2WyDopUYmD-p45YJSq_Xg0uwdFY6IWU=.465f7021-e77e-4e08-9a90-2622f4981825@github.com>
 <smQJRfHa2D5WybPQrDn9XtaKrWeux7odcJbWYl6tgfI=.8e861b1c-b0ce-4b55-b5d3-81b00c36a6ee@github.com>
Message-ID: <AWhIH0LDO18YAojcpyshtOLalJAY4KKJB1IzIR8Eo5E=.ebfb1cb5-c4b0-4caf-bbe9-6f869de0cb09@github.com>

On Tue, 20 Sep 2022 06:56:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> I realise you've had a few iterations with Max on this section but I'm concerned that the text is telling the reader that they should use the 2-arg constructor to verify the signatures when a JAR is signed. The default is to verify and the main reason to use the 2-arg constructor is when you want to opt out, not opt-in.
>>> 
>>> I think the intro to this section will need to start with a sentence to say that JAR files can be signed (link to specs/jar/jar.html#signed-jar-file) and that JarInputStream can read a signed JAR from the input stream. As per the description further up, the manifest must be at the start of the stream.
>> 
>> OK, will make another pass at this today
>
>> OK, will make another pass at this today
> 
> I looked at the latest draft (2bafc00c). I think it would help if the section "Verifying a JarInputStream" were renamed to "Signed JAR files".  The link to getManifest makes the reader wonder if they have to call this method whereas I think what you want to say that the manifest must be at the start of the stream (as per the first section) and then followed by signature entries.

> > OK, will make another pass at this today
> 
> I looked at the latest draft ([2bafc00](https://github.com/openjdk/jdk/commit/2bafc00cc462b7af3f724371ac1bef5fd99c989c)). I think it would help if the section "Verifying a JarInputStream" were renamed to "Signed JAR files".

OK, I will change as you suggest

 The link to getManifest makes the reader wonder if they have to call this method whereas I think what you want to say that the manifest must be at the start of the stream (as per the first section) and then followed by signature entries.

The reason I used the getManifest wording is I felt it was easier and less redundant than copying the wording about the Manifest needing to be either the first or second entry (assuming META-INF/ is the first in the stream).  However if you prefer that, I will make that change.

-------------

PR: https://git.openjdk.org/jdk/pull/10045

From lancea at openjdk.org  Tue Sep 20 11:03:38 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 20 Sep 2022 11:03:38 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v6]
In-Reply-To: <LlI1t4-s_xsY_VOmbrlPOHYoF2EUFJI8-PBs691M0XU=.28859b65-62d8-41e4-b519-fe096ef6fb89@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <DRY5m5O6V8PQg4riHZDD4Ajf8LAKLnkRcIrmoG4DeGA=.f5a8aeda-aea0-4d81-888e-4a20ab6a83f6@github.com>
 <EFvr_1_wKxNI67dJ4SXoMlRXjGZ_kC1Ffzpg_tXYelw=.4d3c369f-6825-4de8-8d4b-64d7a5c9dc16@github.com>
 <Pjw2AsAaEolE03cGFx5BlGL2PTYmQMhxbW4sd7I76g8=.f0db002b-e692-4f8b-ba6b-48a684b79f30@github.com>
 <eM0gLdVLRGsrXmzZgoCdcgL2XmCnzaPjqm31PUpqWDs=.d1c1e560-edba-43a8-ba38-5f8fa459f7d5@github.com>
 <2PVQURfKMSUCSxiwkWVpYiBN27oGnogfXUvx7zU-nQ0=.bc7ddc13-491f-4a5c-936b-59f37eb866cf@github.com>
 <LlI1t4-s_xsY_VOmbrlPOHYoF2EUFJI8-PBs691M0XU=.28859b65-62d8-41e4-b519-fe096ef6fb89@github.com>
Message-ID: <DOtpoDAnkr2dN0Kq4d2ttjyY486ks5B9z2sbGgxk520=.7303f000-e8a7-4a86-b19f-040596a1095c@github.com>

On Mon, 19 Sep 2022 20:30:48 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Does this mean that the "Verifying a JarInputStream" should also avoid mentioning "getManifest method returns the manifest"? I understand precisely it should be "getManifest method is able to return the manifest if you call it".

See Alan's comment below.  I will be copying the wording regarding the Manifest being the 1st/2nd entry
> 
> It almost sounds like we should first define the concepts of "well-formed JAR file" and "well-formed signed JAR" and then specify what these methods behave.

The Manifest location requirement is unique to JarInputStream so really want to try to keep these updates to a minimum if at all possible so that we are not copying parts of the Jar spec into the javadoc.

-------------

PR: https://git.openjdk.org/jdk/pull/10045

From kcr at openjdk.org  Tue Sep 20 12:31:48 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 20 Sep 2022 12:31:48 GMT
Subject: RFR: 8293977: jdk/modules/etc/VerifyModuleDelegation.java fail
 with jfx
In-Reply-To: <K8keV23DhjOl2iAcpxEGUPEDKfRsrPMwVYf6ZvYV39M=.66a73163-007e-4951-a524-7cf8d5aa1f79@github.com>
References: <K8keV23DhjOl2iAcpxEGUPEDKfRsrPMwVYf6ZvYV39M=.66a73163-007e-4951-a524-7cf8d5aa1f79@github.com>
Message-ID: <UmwA4scrMxXQ4QbOoZHzR-PNH0c9nNg_dL4OhdRaIvA=.135d9044-ad31-4cea-90ec-1b453c58c1aa@github.com>

On Mon, 19 Sep 2022 00:45:32 GMT, Leslie Zhai <lzhai at openjdk.org> wrote:

> Hi,
> 
> @dumasun reported the issue:
> 
> Configured with jfx-ls-modular-sdk:
> 
> 
> configure --with-import-modules=modular-sdk
> 
> 
> `make run-test CONF=fastdebug TEST="jdk/modules/etc/VerifyModuleDelegation.java"` failed:
> 
> 
> ----------System.out:(46/3114)----------
> test VerifyModuleDelegation.checkJavaBase(): success
> test VerifyModuleDelegation.checkLoaderDelegation(): failure
> java.lang.Error: platform/javafx.swing can't delegate to find classes from app/jdk.unsupported.desktop
>     at VerifyModuleDelegation.lambda$checkLoaderDelegation$1(VerifyModuleDelegation.java:77)
>     at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>     at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1921)
>     at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>     at VerifyModuleDelegation.lambda$checkLoaderDelegation$2(VerifyModuleDelegation.java:68)
>     at java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1715)
>     at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>     at VerifyModuleDelegation.checkLoaderDelegation(VerifyModuleDelegation.java:68)
>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>     at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>     at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>     at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>     at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>     at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>     at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>     at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>     at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>     at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
>     at org.testng.TestRunner.privateRun(TestRunner.java:764)
>     at org.testng.TestRunner.run(TestRunner.java:585)
>     at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
>     at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
>     at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
>     at org.testng.SuiteRunner.run(SuiteRunner.java:286)
>     at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
>     at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
>     at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
>     at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
>     at org.testng.TestNG.runSuites(TestNG.java:1069)
>     at org.testng.TestNG.run(TestNG.java:1037)
>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54)
>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>     at java.base/java.lang.Thread.run(Thread.java:1589)
> 
> ===============================================
> jdk/modules/etc/VerifyModuleDelegation.java
> Total tests run: 2, Passes: 1, Failures: 1, Skips: 0
> ===============================================
> 
> ----------System.err:(13/753)----------
> WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.concurrent
> java.lang.Exception: failures: 1
>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96)
>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54)
>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>     at java.base/java.lang.Thread.run(Thread.java:1589)
> 
> 
> Thanks,
> Leslie Zhai

I haven't built a JDK using the `--with-import-modules` to include the `javafx.*` modules in quite a while, but my recollection is that yes, that did cause the JavaFX modules to be loaded by the platform class loader. The following is defined in the [`build.properties`](https://github.com/openjdk/jfx/blob/master/modules/javafx.swing/make/build.properties#L32) file for the `javafx.swing` module (as well as all other JavaFX modules), which is used by the JDK build when using `--with-import-modules`:


classloader=ext


I would guess that `ext` (which used to stand for the extension class loader) is causing it be included in the list of modules that are loaded by the platform class loader, but that needs to be checked.

-------------

PR: https://git.openjdk.org/jdk/pull/10328

From alanb at openjdk.org  Tue Sep 20 12:39:39 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 20 Sep 2022 12:39:39 GMT
Subject: RFR: 8293977: jdk/modules/etc/VerifyModuleDelegation.java fail
 with jfx
In-Reply-To: <UmwA4scrMxXQ4QbOoZHzR-PNH0c9nNg_dL4OhdRaIvA=.135d9044-ad31-4cea-90ec-1b453c58c1aa@github.com>
References: <K8keV23DhjOl2iAcpxEGUPEDKfRsrPMwVYf6ZvYV39M=.66a73163-007e-4951-a524-7cf8d5aa1f79@github.com>
 <UmwA4scrMxXQ4QbOoZHzR-PNH0c9nNg_dL4OhdRaIvA=.135d9044-ad31-4cea-90ec-1b453c58c1aa@github.com>
Message-ID: <2ddyCr8skoTc3z5FqEn7Tle-UZI2Q9d0mh8cXbT1mGc=.7c737f00-2197-4c5a-bbf4-c6ea1fb1aa41@github.com>

On Tue, 20 Sep 2022 12:27:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> I haven't built a JDK using the `--with-import-modules` to include the `javafx.*` modules in quite a while, but my recollection is that yes, that did cause the JavaFX modules to be loaded by the platform class loader. The following is defined in the [`build.properties`](https://github.com/openjdk/jfx/blob/master/modules/javafx.swing/make/build.properties#L32) file for the `javafx.swing` module (as well as all other JavaFX modules), which is used by the JDK build when using `--with-import-modules`:
> 
> ```
> classloader=ext
> ```

Thanks for this. In make/common/Modules.gmk, ReadSingleImportMetaData is adding to PLATFORM_MODULES. So I think this needs to re-examined as there should be no reason to have imported modules mapped to the boot or platform class loaders now.

-------------

PR: https://git.openjdk.org/jdk/pull/10328

From asemenyuk at openjdk.org  Tue Sep 20 13:05:18 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 20 Sep 2022 13:05:18 GMT
Subject: RFR: 8293595: tstrings::any() is missing an overload
In-Reply-To: <kg3ceAeYuxlJh3jbSCWaW2puuVm2ZsI8D_aNfLt34Tg=.b45ec586-6de3-4d46-9fc8-7cd8ed0984b6@github.com>
References: <0tqqa1avFzs-MV0Veo0QnpBG1-0b1djoKap5D_vF62U=.4fed5b83-dfc2-4661-a031-f3d1b64eeca9@github.com>
 <dsydcefnkarOoVBM41jiBogBpD3V59rvME95tAKW1BE=.27118752-7dbc-487e-a7a1-6c3317aa2882@github.com>
 <-LTFLRniQjzc1wQ9k3NHN2ZTVM07DV6PEf9IY9Ed6vM=.cdcdcc64-52ef-4363-b087-3efcca94c840@github.com>
 <Y55koSmY8NzWlGCjeIz-CBZkkZit9tMnfmXrMws450Q=.53a12444-6396-47ac-85d0-40a477a505db@github.com>
 <kg3ceAeYuxlJh3jbSCWaW2puuVm2ZsI8D_aNfLt34Tg=.b45ec586-6de3-4d46-9fc8-7cd8ed0984b6@github.com>
Message-ID: <hFGKK2UY7DmasSxuZHEvB1MJOTISUV4d0l8B4gVjo1A=.75097d08-d648-45ce-a5f6-6a49ac3ce904@github.com>

On Mon, 19 Sep 2022 20:46:12 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> I'm the author of these comments and basically the entire source file.
>> 
>> You are right, it will work without the additional overloads. However the null pointers will be ignored (tested with G++ 7.4.0), but this is minor, probably implementation-specific and can be ignored.
>
> Strange, on my end gcc doesn't mind NULL being passed (though this may be due to a different gcc version being used), guess it's probably implementation specific like you mentioned

Correct, it allows NULL to be passed. G++ 7.4.0 ignores it and doesn't append anything to the buffer, while msvc back when this code was created appended a "null" string to the buffer.

-------------

PR: https://git.openjdk.org/jdk/pull/10231

From jwaters at openjdk.org  Tue Sep 20 13:08:15 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 20 Sep 2022 13:08:15 GMT
Subject: Integrated: 8293595: tstrings::any() is missing an overload
In-Reply-To: <0tqqa1avFzs-MV0Veo0QnpBG1-0b1djoKap5D_vF62U=.4fed5b83-dfc2-4661-a031-f3d1b64eeca9@github.com>
References: <0tqqa1avFzs-MV0Veo0QnpBG1-0b1djoKap5D_vF62U=.4fed5b83-dfc2-4661-a031-f3d1b64eeca9@github.com>
Message-ID: <MgfFusBw2WgLQEzpYRXiwJd6qGnyQ8Ad0B7Qled5L8w=.63757e9d-8781-459d-a5c0-19ea822dbe2a@github.com>

On Fri, 9 Sep 2022 13:38:14 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> tstrings::any() has an overload for std::wstring (if required) but is missing the corresponding operator overload for std::string, leaving only the templated one as a fallback, which will expand into a std::wostringstream << std::string operation. This isn't particularly safe on Windows, considering that JDK-8292008 and JDK-8247283 have been recently merged, and can sporadically cause build failures. This change simply adds the missing overload with the appropriate format handling that jpackage expects from std::string. Also contains minor name changes to fit the rest of the parameter names in the other overloads.

This pull request has now been integrated.

Changeset: bb422f5c
Author:    Julian Waters <jwaters at openjdk.org>
Committer: Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bb422f5c14745bf29bc2cb741f819a17c8400543
Stats:     11 lines in 1 file changed: 5 ins; 0 del; 6 mod

8293595: tstrings::any() is missing an overload

Reviewed-by: asemenyuk, almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/10231

From asotona at openjdk.org  Tue Sep 20 13:18:25 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 20 Sep 2022 13:18:25 GMT
Subject: RFR: 8294062: Improve parsing performance of j.l.c.MethodTypeDesc
Message-ID: <Q0iEUit9CcB8dvFJUMCKQoSYx51BJ75Mejv-pGcl2OI=.f1a538b0-2d74-4c2c-a50d-ba70d64d84da@github.com>

Parsing performance of `j.l.c.MethodTypeDescriptor::ofDescriptor` can be significantly improved and add performance boost to intensive users.

Two main reasons have been identified and fixed in this patch:

First glitch is late insertion of return type to the first position of `j.u.ArrayList`, causing all previously parsed parameter types to shift using `System::arraycopy`.

Proposed patch inserts a placeholder for the return type first and replaces it with return type later.

Second performance degradation is in `MethodTypeDescriptor::skipOverFieldSignature`, where each identified class descriptor is exactly located by `String::indexOf`, extracted by `String::substring`, and passed for for the purpose of verification to `ConstantUtils::verifyUnqualifiedClassName`.

Proposed patch inlines the unqualified class name verification into `ConstantUtils::skipOverFieldSignature` parsing loop and so eliminates calls of `String::indexOf` and `String::substring`. Package private method `ConstantUtils::verifyUnqualifiedClassName` has no other use within the package, so it is removed.

Please review proposed performance improving patch.

Thanks,
Adam

-------------

Commit messages:
 - 8294062: Improve parsing performance of j.l.c.MethodTypeDesc

Changes: https://git.openjdk.org/jdk/pull/10358/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10358&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294062
  Stats: 39 lines in 1 file changed: 8 ins; 22 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/10358.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10358/head:pull/10358

PR: https://git.openjdk.org/jdk/pull/10358

From kcr at openjdk.org  Tue Sep 20 14:15:43 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 20 Sep 2022 14:15:43 GMT
Subject: RFR: 8293977: jdk/modules/etc/VerifyModuleDelegation.java fail
 with jfx
In-Reply-To: <K8keV23DhjOl2iAcpxEGUPEDKfRsrPMwVYf6ZvYV39M=.66a73163-007e-4951-a524-7cf8d5aa1f79@github.com>
References: <K8keV23DhjOl2iAcpxEGUPEDKfRsrPMwVYf6ZvYV39M=.66a73163-007e-4951-a524-7cf8d5aa1f79@github.com>
Message-ID: <uUAL_VrLHEuwOAc41MdzAy6ktRphzJfl2fa9ISkLYzU=.855083b1-04c4-49e9-97e3-e9598e1b5ae8@github.com>

On Mon, 19 Sep 2022 00:45:32 GMT, Leslie Zhai <lzhai at openjdk.org> wrote:

> Hi,
> 
> @dumasun reported the issue:
> 
> Configured with jfx-ls-modular-sdk:
> 
> 
> configure --with-import-modules=modular-sdk
> 
> 
> `make run-test CONF=fastdebug TEST="jdk/modules/etc/VerifyModuleDelegation.java"` failed:
> 
> 
> ----------System.out:(46/3114)----------
> test VerifyModuleDelegation.checkJavaBase(): success
> test VerifyModuleDelegation.checkLoaderDelegation(): failure
> java.lang.Error: platform/javafx.swing can't delegate to find classes from app/jdk.unsupported.desktop
>     at VerifyModuleDelegation.lambda$checkLoaderDelegation$1(VerifyModuleDelegation.java:77)
>     at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>     at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1921)
>     at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>     at VerifyModuleDelegation.lambda$checkLoaderDelegation$2(VerifyModuleDelegation.java:68)
>     at java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1715)
>     at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>     at VerifyModuleDelegation.checkLoaderDelegation(VerifyModuleDelegation.java:68)
>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>     at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>     at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>     at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>     at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>     at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>     at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>     at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>     at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>     at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
>     at org.testng.TestRunner.privateRun(TestRunner.java:764)
>     at org.testng.TestRunner.run(TestRunner.java:585)
>     at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
>     at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
>     at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
>     at org.testng.SuiteRunner.run(SuiteRunner.java:286)
>     at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
>     at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
>     at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
>     at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
>     at org.testng.TestNG.runSuites(TestNG.java:1069)
>     at org.testng.TestNG.run(TestNG.java:1037)
>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54)
>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>     at java.base/java.lang.Thread.run(Thread.java:1589)
> 
> ===============================================
> jdk/modules/etc/VerifyModuleDelegation.java
> Total tests run: 2, Passes: 1, Failures: 1, Skips: 0
> ===============================================
> 
> ----------System.err:(13/753)----------
> WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.concurrent
> java.lang.Exception: failures: 1
>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96)
>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54)
>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>     at java.base/java.lang.Thread.run(Thread.java:1589)
> 
> 
> Thanks,
> Leslie Zhai

In that case, a solution might be to remove `ext` from the `classloader` property from all of the `modules/javafx.*/make/build.properties` files in JavaFX:


classloader=


or


classloader=app

-------------

PR: https://git.openjdk.org/jdk/pull/10328

From asotona at openjdk.org  Tue Sep 20 14:15:49 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 20 Sep 2022 14:15:49 GMT
Subject: RFR: 8294062: Improve parsing performance of j.l.c.MethodTypeDesc
In-Reply-To: <Q0iEUit9CcB8dvFJUMCKQoSYx51BJ75Mejv-pGcl2OI=.f1a538b0-2d74-4c2c-a50d-ba70d64d84da@github.com>
References: <Q0iEUit9CcB8dvFJUMCKQoSYx51BJ75Mejv-pGcl2OI=.f1a538b0-2d74-4c2c-a50d-ba70d64d84da@github.com>
Message-ID: <OBj7c1lF79HUjZCnuM5xhHbCcEGiGSZxhhJRaqBcq-g=.4700bbb3-29a9-45ef-ab3c-195bb4ac1e93@github.com>

On Tue, 20 Sep 2022 13:08:20 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Parsing performance of `j.l.c.MethodTypeDescriptor::ofDescriptor` can be significantly improved and add performance boost to intensive users.
> 
> Two main reasons have been identified and fixed in this patch:
> 
> First glitch is late insertion of return type to the first position of `j.u.ArrayList`, causing all previously parsed parameter types to shift using `System::arraycopy`.
> 
> Proposed patch inserts a placeholder for the return type first and replaces it with return type later.
> 
> Second performance degradation is in `MethodTypeDescriptor::skipOverFieldSignature`, where each identified class descriptor is exactly located by `String::indexOf`, extracted by `String::substring`, and passed for for the purpose of verification to `ConstantUtils::verifyUnqualifiedClassName`.
> 
> Proposed patch inlines the unqualified class name verification into `ConstantUtils::skipOverFieldSignature` parsing loop and so eliminates calls of `String::indexOf` and `String::substring`. Package private method `ConstantUtils::verifyUnqualifiedClassName` has no other use within the package, so it is removed.
> 
> Please review proposed performance improving patch.
> 
> Thanks,
> Adam

JMH-measured performance boost of the patch when parsing single MethodTypeDesc with 8 Objects as method arguments is 33%.

-------------

PR: https://git.openjdk.org/jdk/pull/10358

From kcr at openjdk.org  Tue Sep 20 14:26:45 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 20 Sep 2022 14:26:45 GMT
Subject: RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx
 [v2]
In-Reply-To: <eLkziaKhG6kfuVWg-zc6HxccXS9aL_wTUjOf8G7oR9s=.4892bc1b-fcb0-4e28-9a6d-53f38213665c@github.com>
References: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
 <eLkziaKhG6kfuVWg-zc6HxccXS9aL_wTUjOf8G7oR9s=.4892bc1b-fcb0-4e28-9a6d-53f38213665c@github.com>
Message-ID: <_W8bK_pIfXVi4f1Yca9LzMu3OGyaUGnHmHjPv2EKM14=.a3586b95-ea5e-4f24-9a73-9f19c92cc887@github.com>

On Sat, 17 Sep 2022 04:03:35 GMT, Leslie Zhai <lzhai at openjdk.org> wrote:

>> Hi,
>> 
>> @dumasun reported the issue:
>> 
>> Configured with jfx-ls-modular-sdk:
>> 
>> 
>> configure --with-import-modules=modular-sdk
>> 
>> 
>> `make run-test CONF=fastdebug TEST="tools/launcher/FXLauncherTest.java"` failed:
>> 
>> 
>> ----------System.err:(11/697)----------
>> java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>>     at FXLauncherTest.main(FXLauncherTest.java:451)
>>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>     at java.base/java.lang.Thread.run(Thread.java:1589)
>> 
>> JavaTest Message: Test threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>> JavaTest Message: shutting down test
>> 
>> STATUS:Failed.`main' threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>> 
>> 
>> Thanks,
>> Leslie Zhai
>
> Leslie Zhai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293910: Try --upgrade-module-path and --patch-module but still failed

How does the test fail? Does it actually find and load the "mockfx" classes, but subsequently fail? Or is it unable to patch/upgrade the javafx.graphics module with the "mockfx" classes?

-------------

PR: https://git.openjdk.org/jdk/pull/10299

From smarks at openjdk.org  Tue Sep 20 15:56:02 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 20 Sep 2022 15:56:02 GMT
Subject: RFR: 8294008: Grapheme implementation of setText() throws
 IndexOutOfBoundsException [v3]
In-Reply-To: <OM6U1eNJOgC0WeTitQ2eI0_UGRb9_r2kNbmoSN9TUkg=.8f04c208-46cc-4184-bc66-b30cc1c49c07@github.com>
References: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>
 <OM6U1eNJOgC0WeTitQ2eI0_UGRb9_r2kNbmoSN9TUkg=.8f04c208-46cc-4184-bc66-b30cc1c49c07@github.com>
Message-ID: <ck3ob2bFGMmPHTF7dN88J0gVp2OkqovoixoCB9xjgaw=.e9a2e4d7-77d4-4f4e-835c-12b51cc74b5b@github.com>

On Tue, 20 Sep 2022 01:14:38 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing JCK failures caused by the new grapheme implementation. The length of a CharSequence should return the `endIndex`, not `endIndex - beginIndex`.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refine the comments by adding class level description in CharacterIteratorCharSequence

Marked as reviewed by smarks (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10349

From smarks at openjdk.org  Tue Sep 20 15:56:02 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 20 Sep 2022 15:56:02 GMT
Subject: RFR: 8294008: Grapheme implementation of setText() throws
 IndexOutOfBoundsException [v3]
In-Reply-To: <cHC-nc8NQE81Htm6j-uWdr_oLC7AhlHqI1lS-80SejI=.fb87f5d9-5cd5-44b7-96a3-4e1ed8e0c6c0@github.com>
References: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>
 <9q1PEg15HYOhUIrTfUdKhpbUcXjpppP6JANXsj6Mlsw=.b5a81583-9470-4b68-b824-7a11583a8b70@github.com>
 <8o6GmYySek8iJI4rvXiSMxKhjI8UZyRORQeCVwaidzM=.ae213824-aca7-4162-a0c0-9cd39682160a@github.com>
 <9Zrf4UTRoFOdKg2lMZjHngzPuPnpiR3TgNtgpg_P1Go=.258d28fe-e571-40b9-b5b1-5154d09df9eb@github.com>
 <rJrb_Srn7Q286QXnt6BQjMO4lM3F8tkO9ujKkdVYI74=.0a0830d2-8e56-4bd9-8c19-b09d2c9fe554@github.com>
 <jskb_0PWmITMwGYWcAd95VctIrkEXh_PpC5btLmstZM=.49282989-7524-42c3-a8f4-8b87f7f918c3@github.com>
 <cHC-nc8NQE81Htm6j-uWdr_oLC7AhlHqI1lS-80SejI=.fb87f5d9-5cd5-44b7-96a3-4e1ed8e0c6c0@github.com>
Message-ID: <EB-MSNpWbgoYRihA-sYo6ahG67z52g1Aw47RaT5W7_A=.c88a203b-1672-4aa6-8569-4f4764ff591f@github.com>

On Tue, 20 Sep 2022 01:09:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> OK yeah this is really confusing. One might ask a similar question in `charAt` about why it doesn't call
>> 
>>     src.setIndex(index + src.getBeginIndex());
>> 
>> The answer is that this is a special-purpose `CharSequence` that represents characters in the index range [0..endIndex) of the underlying `CharacterIterator`, **even if** that `CharacterIterator` represents the subrange of some string. As Joe noted, the calling code in `GraphemeBreakIterator` takes care to ensure that only valid indexes into the `src` are used.
>> 
>> I think the comment on `length` helps a little bit but maybe a class-level comment would be better, since it applies to the whole model of this special `CharSequence` and not just the `length` method. Just a sentence or two is sufficient. Feel free to crib from the above.
>
> Thanks, Stuart. I used the paragraph almost intact for the class description ?

OK looks good.

-------------

PR: https://git.openjdk.org/jdk/pull/10349

From smarks at openjdk.org  Tue Sep 20 16:32:54 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 20 Sep 2022 16:32:54 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v4]
In-Reply-To: <jhvaxnF1s7-oPaVsF9nf5ko8wP1gBWOo5TfO8T_j40A=.731ea409-ca17-488e-a0b1-3cb15334515a@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <ZTzHjlUXhJf5U3PndgGMZUpwbIJhJ0kSxL2am_PfFT8=.4279d477-9a1e-4a2c-b334-90cc60b5592b@github.com>
 <bjXGfmDhmaMyT_j_bQhZLezMj4Jb18w0yhQsYZhlXjU=.d5f0014e-9d6d-4c5f-b84f-5446166bb767@github.com>
 <jhvaxnF1s7-oPaVsF9nf5ko8wP1gBWOo5TfO8T_j40A=.731ea409-ca17-488e-a0b1-3cb15334515a@github.com>
Message-ID: <q6ToSabdUIWS0vK-13JWdvQySwco64A_gP20tVsm9FI=.7722abf4-9470-4a52-9f8e-48cb2481eb77@github.com>

On Tue, 20 Sep 2022 06:00:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/FilterOutputStream.java line 195:
>> 
>>> 193:                    // evaluate possible precedence of flushException over closeException
>>> 194:                    if ((flushException instanceof ThreadDeath) &&
>>> 195:                        !(closeException instanceof ThreadDeath)) {
>> 
>> If the ThreadDeath originates from the debugger then this is now a change in behaviour.
>
>> Good to see this finally become non-functional but as long as the debugger/JVMTI can trigger throwing an async ThreadDeath then I have to question the potential change in behaviour introduced by removing all the `catch (ThreadDeath td)` logic in various places.
> 
> I've gone through this a few times too and concluded it would be better to remove these untestable code paths. The debugger scenario is more like what used to be Thread.stop(Throwable). It can be used to throw any exception or error, e.g. ask the debugger to throw IllegalArgumentException or SQLException when I'm at this breakpoint so I can see how the code behaves. Yes, the user could ask the debugger to throw java.lang.ThreadDeath when prompted but it's not really interesting now because code won't get this error outside of a debugger. We could leave the special handing but we have no way to test is and we'll need to the remove the special handling when TD is removed.  As a general point, the special casing of TD is a bit inconsistent and more likely to be seen in older code rather newer code. A static analysis of 24M classes found very few usages in 3rd party libraries.

I agree with Alan on this. First, use and handling of `ThreadDeath` is quite rare; see my [analysis](https://bugs.openjdk.org/browse/JDK-8289610?focusedCommentId=14523723&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14523723) of the corpus search results in the bug report. Second, while this does change the behavior in the debugger case, I'm hard-pressed to see how anybody is _relying_ on such behavior. And maybe somebody somewhere is indeed relying on this behavior, but it doesn't seem to me this behavior is guaranteed by any specifications.

A more likely way that programs could observe changes in `ThreadDeath` handling occurs when programs throw `ThreadDeath` explicitly, that is, not using `Thread.stop`. This does seem to occur infrequently "in the wild" (we'll fix the jshell case). The point of throwing `ThreadDeath` explicitly is to take advantage of special-case handling of `ThreadDeath` that might occur higher in the call stack. Such special-casing was at one time an accepted exception handing idiom, but it's essentially disused. I don't think the JDK needs to continue to support this old idiom.

-------------

PR: https://git.openjdk.org/jdk/pull/10230

From naoto at openjdk.org  Tue Sep 20 16:49:54 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 20 Sep 2022 16:49:54 GMT
Subject: Integrated: 8294008: Grapheme implementation of setText() throws
 IndexOutOfBoundsException
In-Reply-To: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>
References: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>
Message-ID: <KoNMvktPzCGaQzs91scQrMBRjPHMz_z3NNSA_CyB4Sk=.5952203b-42cb-42e5-93ab-6d9ad606d322@github.com>

On Mon, 19 Sep 2022 19:01:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing JCK failures caused by the new grapheme implementation. The length of a CharSequence should return the `endIndex`, not `endIndex - beginIndex`.

This pull request has now been integrated.

Changeset: e3358e77
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e3358e77f524f4d448c2ebb7c5afd0aa432f0d44
Stats:     18 lines in 2 files changed: 16 ins; 0 del; 2 mod

8294008: Grapheme implementation of setText() throws IndexOutOfBoundsException

Reviewed-by: joehw, smarks

-------------

PR: https://git.openjdk.org/jdk/pull/10349

From lancea at openjdk.org  Tue Sep 20 16:55:51 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 20 Sep 2022 16:55:51 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v10]
In-Reply-To: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
Message-ID: <yXv2wx-Ec2fZ3y-7sVoVwPZZhYb-c3mN1E8WXF7vQFQ=.3fbee5be-5a7d-4af9-bc1a-850b7db17bb8@github.com>

> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
> 
> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
> 
> 
> Best,
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Address comments regarding Verifying a JarInputStreams

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10045/files
  - new: https://git.openjdk.org/jdk/pull/10045/files/2bafc00c..69138715

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10045&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10045&range=08-09

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10045.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10045/head:pull/10045

PR: https://git.openjdk.org/jdk/pull/10045

From psandoz at openjdk.org  Tue Sep 20 17:10:00 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 20 Sep 2022 17:10:00 GMT
Subject: RFR: 8294062: Improve parsing performance of j.l.c.MethodTypeDesc
In-Reply-To: <Q0iEUit9CcB8dvFJUMCKQoSYx51BJ75Mejv-pGcl2OI=.f1a538b0-2d74-4c2c-a50d-ba70d64d84da@github.com>
References: <Q0iEUit9CcB8dvFJUMCKQoSYx51BJ75Mejv-pGcl2OI=.f1a538b0-2d74-4c2c-a50d-ba70d64d84da@github.com>
Message-ID: <VDvbC1TFiKQEVZE9c_QP8jUBcBV1EmLFUDMGTVUrkpU=.46770485-1955-458b-9650-6a182b06a309@github.com>

On Tue, 20 Sep 2022 13:08:20 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Parsing performance of `j.l.c.MethodTypeDescriptor::ofDescriptor` can be significantly improved and add performance boost to intensive users.
> 
> Two main reasons have been identified and fixed in this patch:
> 
> First glitch is late insertion of return type to the first position of `j.u.ArrayList`, causing all previously parsed parameter types to shift using `System::arraycopy`.
> 
> Proposed patch inserts a placeholder for the return type first and replaces it with return type later.
> 
> Second performance degradation is in `MethodTypeDescriptor::skipOverFieldSignature`, where each identified class descriptor is exactly located by `String::indexOf`, extracted by `String::substring`, and passed for for the purpose of verification to `ConstantUtils::verifyUnqualifiedClassName`.
> 
> Proposed patch inlines the unqualified class name verification into `ConstantUtils::skipOverFieldSignature` parsing loop and so eliminates calls of `String::indexOf` and `String::substring`. Package private method `ConstantUtils::verifyUnqualifiedClassName` has no other use within the package, so it is removed.
> 
> Please review proposed performance improving patch.
> 
> Thanks,
> Adam

src/java.base/share/classes/java/lang/constant/ConstantUtils.java line 217:

> 215:                             }
> 216:                             case '/' -> {
> 217:                                 if (!legal) return 0;

IIUC that works to reject `//` and trailing `/`, but does not reject leading `/`? which the previous code rejected.

-------------

PR: https://git.openjdk.org/jdk/pull/10358

From mchung at openjdk.org  Tue Sep 20 17:15:57 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 20 Sep 2022 17:15:57 GMT
Subject: RFR: JDK-8293659: Improve UnsatisfiedLinkError error message to
 include dlopen error details [v2]
In-Reply-To: <xF7xU_nv7od9QNvVMREbQGelSOQ0okJPyTnoQhkK2w0=.83257c39-be99-41ea-adf5-6affb2712f22@github.com>
References: <ifR_svzVaPWpTZ48Mm7a_bANpIvAgQB1HEiBrXlA0oQ=.1dd92d2d-c9f2-4bbf-9a02-8bde08cdb8fb@github.com>
 <xF7xU_nv7od9QNvVMREbQGelSOQ0okJPyTnoQhkK2w0=.83257c39-be99-41ea-adf5-6affb2712f22@github.com>
Message-ID: <KCqXM79VHzwU1lPN33HgWyjvy278oqcVi9eZg5q0Jxg=.20e03a5a-1f4d-4c1c-bcab-796ad350de0b@github.com>

On Fri, 16 Sep 2022 07:27:44 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When trying to load a x64 lib on macOS aarch64 one got previously this detailed message before [JDK-8275703](https://bugs.openjdk.org/browse/JDK-8275703):
>> 
>> java.lang.UnsatisfiedLinkError: /testing/jco3/macOsx64/libsapjco3.dylib: dlopen(/testing/jco3/macOsx64/libsapjco3.dylib, 1): no suitable image found. Did find:
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust throwExceptionIfFail

If you load a library via `System::load`, it only loads the given file path which must be an absolute path name.  In this case, it only calls `JVM_LoadLibrary` once and also it will use dlopen's error message if it fails to load it.

If loading a library via `System::loadLibrary`, it will search through the library paths and system library paths and `UnsatisfiedLinkException` will be thrown if either (1) no file exists and not present in the dynamic cache or (2) a named library exists but fail to load.   

The case when `JVM_LoadLibrary` is called without exception is to allow the search through the library path (e.g. `dir1:dir2`) that libFoo does not exist in `dir1` and `dir2` but `dir2/libFoo` is present in the dynamic cache.

-------------

PR: https://git.openjdk.org/jdk/pull/10286

From jwaters at openjdk.org  Tue Sep 20 17:29:15 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 20 Sep 2022 17:29:15 GMT
Subject: Integrated: 8294006: Avoid hardcoding object file suffixes in make
In-Reply-To: <O4N4XJMjXG2eSKFNLJwKEMOstwzXGYI0gygq1lGCS8w=.7f0f7aa0-b96b-491c-9f8c-8e7073672b54@github.com>
References: <O4N4XJMjXG2eSKFNLJwKEMOstwzXGYI0gygq1lGCS8w=.7f0f7aa0-b96b-491c-9f8c-8e7073672b54@github.com>
Message-ID: <kmE9ReLuL0KAJukWo7SQ1ZzHNea7AegKfy5qBbK_15U=.a790671c-6e07-422d-baa8-3934764dd119@github.com>

On Mon, 19 Sep 2022 12:55:47 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Replaces hardcoding of object file suffixes in make, to ensure they are always reliably set from a single place in autoconf.

This pull request has now been integrated.

Changeset: cb5771dc
Author:    Julian Waters <jwaters at openjdk.org>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cb5771dc2a5e8c84436e300992f3c791a013062e
Stats:     9 lines in 3 files changed: 0 ins; 0 del; 9 mod

8294006: Avoid hardcoding object file suffixes in make

Reviewed-by: erikj, ihse

-------------

PR: https://git.openjdk.org/jdk/pull/10341

From alanb at openjdk.org  Tue Sep 20 17:39:53 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 20 Sep 2022 17:39:53 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v7]
In-Reply-To: <AWhIH0LDO18YAojcpyshtOLalJAY4KKJB1IzIR8Eo5E=.ebfb1cb5-c4b0-4caf-bbe9-6f869de0cb09@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <_tMtVfn6qdtAb3EZiSBqve0gM_WGZKUAyYwnYqtZMgA=.74bfe2cf-e1c4-47c2-99ba-14a804f6d470@github.com>
 <FLeEDUKHCLDrIia-kRzHeu8qxqk5rEiWC3fpUmr9SqM=.ebdeaaf5-5c83-4940-ab84-2e8bf04d5ccd@github.com>
 <8BlTa_vNbW2I2WyDopUYmD-p45YJSq_Xg0uwdFY6IWU=.465f7021-e77e-4e08-9a90-2622f4981825@github.com>
 <smQJRfHa2D5WybPQrDn9XtaKrWeux7odcJbWYl6tgfI=.8e861b1c-b0ce-4b55-b5d3-81b00c36a6ee@github.com>
 <AWhIH0LDO18YAojcpyshtOLalJAY4KKJB1IzIR8Eo5E=.ebfb1cb5-c4b0-4caf-bbe9-6f869de0cb09@github.com>
Message-ID: <81kHCQ96IVkOJzWSXbhmSgeyxL-DNNjCVYIcyZhGu6w=.fad3d1c3-c45d-468c-aaec-94765804f614@github.com>

On Tue, 20 Sep 2022 10:49:59 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>>> OK, will make another pass at this today
>> 
>> I looked at the latest draft (2bafc00c). I think it would help if the section "Verifying a JarInputStream" were renamed to "Signed JAR files".  The link to getManifest makes the reader wonder if they have to call this method whereas I think what you want to say that the manifest must be at the start of the stream (as per the first section) and then followed by signature entries.
>
>> > OK, will make another pass at this today
>> 
>> I looked at the latest draft ([2bafc00](https://github.com/openjdk/jdk/commit/2bafc00cc462b7af3f724371ac1bef5fd99c989c)). I think it would help if the section "Verifying a JarInputStream" were renamed to "Signed JAR files".
> 
> OK, I will change as you suggest
> 
>  The link to getManifest makes the reader wonder if they have to call this method whereas I think what you want to say that the manifest must be at the start of the stream (as per the first section) and then followed by signature entries.
> 
> The reason I used the getManifest wording is I felt it was easier and less redundant than copying the wording about the Manifest needing to be either the first or second entry (assuming META-INF/ is the first in the stream).  However if you prefer that, I will make that change.

Thanks for the updates in 69138715.  Just one comment on the updated text, and specifically this sentence:

+ *  A {@code JarInputStream} may be used to verify the signatures of a
+ *  <a href="{@docRoot}/../specs/jar/jar.html#signed-jar-file">signed JAR file</a>
+ *  assuming the following requirements are met:

The signatures are verified by default so I think you can reduce this down to:
 
A {@code JarInputStream}  verifies the signatures of entries in a <a href="{@docRoot}/../specs/jar/jar.html#signed-jar-file">Signed JAR file</a>  when:

We could say that a program could opt-out of verification by using the 2-arg constructor but that is probably too much to try to fit in here.

-------------

PR: https://git.openjdk.org/jdk/pull/10045

From duke at openjdk.org  Tue Sep 20 17:39:59 2022
From: duke at openjdk.org (Rahul Prabhu)
Date: Tue, 20 Sep 2022 17:39:59 GMT
Subject: Integrated: 8289508: Improve test coverage for XPath Axes: ancestor, 
 ancestor-or-self, preceding, and preceding-sibling
In-Reply-To: <xn1BRpM7AtPakAYm2AdbtoddvmCNqP3wBPwjMGUPx8w=.4aaac0f2-1383-4e45-b49e-d1da3cfbdf43@github.com>
References: <xn1BRpM7AtPakAYm2AdbtoddvmCNqP3wBPwjMGUPx8w=.4aaac0f2-1383-4e45-b49e-d1da3cfbdf43@github.com>
Message-ID: <_qj-aFr4u7egru1ZE80sTir8_C46wwENJ32ihNFy97g=.7f9f75f9-11e9-41c2-b493-c65862db00aa@github.com>

On Thu, 8 Sep 2022 06:19:10 GMT, Rahul Prabhu <duke at openjdk.org> wrote:

> Created two files for testing XPath Axes: XPathAncestors.java tests the ancestor and ancestor-or-self axes, while XPathPrecedingTest.java tests the preceding and preceding-sibling axes.

This pull request has now been integrated.

Changeset: caae53f4
Author:    Ruprabhu25 <ruprabhu25 at gmail.com>
Committer: Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/caae53f4dadd146426a1a2cd121ac00bb98ebc97
Stats:     371 lines in 2 files changed: 371 ins; 0 del; 0 mod

8289508: Improve test coverage for XPath Axes: ancestor, ancestor-or-self, preceding, and preceding-sibling

Reviewed-by: joehw

-------------

PR: https://git.openjdk.org/jdk/pull/10211

From lancea at openjdk.org  Tue Sep 20 17:47:03 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 20 Sep 2022 17:47:03 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v11]
In-Reply-To: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
Message-ID: <ivT0q9lxJ8JVOUgWGLArPp6cCOWqz_jKB_VK4T9wGV0=.cc64ee5d-def8-451f-9af9-6502cbdd6cc4@github.com>

> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
> 
> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
> 
> 
> Best,
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  More wordsmithing to the signed jar section

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10045/files
  - new: https://git.openjdk.org/jdk/pull/10045/files/69138715..4c4c2a06

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10045&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10045&range=09-10

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10045.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10045/head:pull/10045

PR: https://git.openjdk.org/jdk/pull/10045

From lancea at openjdk.org  Tue Sep 20 17:48:36 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 20 Sep 2022 17:48:36 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v7]
In-Reply-To: <81kHCQ96IVkOJzWSXbhmSgeyxL-DNNjCVYIcyZhGu6w=.fad3d1c3-c45d-468c-aaec-94765804f614@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <_tMtVfn6qdtAb3EZiSBqve0gM_WGZKUAyYwnYqtZMgA=.74bfe2cf-e1c4-47c2-99ba-14a804f6d470@github.com>
 <FLeEDUKHCLDrIia-kRzHeu8qxqk5rEiWC3fpUmr9SqM=.ebdeaaf5-5c83-4940-ab84-2e8bf04d5ccd@github.com>
 <8BlTa_vNbW2I2WyDopUYmD-p45YJSq_Xg0uwdFY6IWU=.465f7021-e77e-4e08-9a90-2622f4981825@github.com>
 <smQJRfHa2D5WybPQrDn9XtaKrWeux7odcJbWYl6tgfI=.8e861b1c-b0ce-4b55-b5d3-81b00c36a6ee@github.com>
 <AWhIH0LDO18YAojcpyshtOLalJAY4KKJB1IzIR8Eo5E=.ebfb1cb5-c4b0-4caf-bbe9-6f869de0cb09@github.com>
 <81kHCQ96IVkOJzWSXbhmSgeyxL-DNNjCVYIcyZhGu6w=.fad3d1c3-c45d-468c-aaec-94765804f614@github.com>
Message-ID: <mRiEannOneICGaDQu5Kpbmr8QOzrTOUHk4BR2mJ7gxE=.78dd8b1a-cbb7-48f2-9c07-f33b7eee07a3@github.com>

On Tue, 20 Sep 2022 17:37:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> > OK, will make another pass at this today
>>> 
>>> I looked at the latest draft ([2bafc00](https://github.com/openjdk/jdk/commit/2bafc00cc462b7af3f724371ac1bef5fd99c989c)). I think it would help if the section "Verifying a JarInputStream" were renamed to "Signed JAR files".
>> 
>> OK, I will change as you suggest
>> 
>>  The link to getManifest makes the reader wonder if they have to call this method whereas I think what you want to say that the manifest must be at the start of the stream (as per the first section) and then followed by signature entries.
>> 
>> The reason I used the getManifest wording is I felt it was easier and less redundant than copying the wording about the Manifest needing to be either the first or second entry (assuming META-INF/ is the first in the stream).  However if you prefer that, I will make that change.
>
> Thanks for the updates in 69138715.  Just one comment on the updated text, and specifically this sentence:
> 
> + *  A {@code JarInputStream} may be used to verify the signatures of a
> + *  <a href="{@docRoot}/../specs/jar/jar.html#signed-jar-file">signed JAR file</a>
> + *  assuming the following requirements are met:
> 
> The signatures are verified by default so I think you can reduce this down to:
>  
> A {@code JarInputStream}  verifies the signatures of entries in a <a href="{@docRoot}/../specs/jar/jar.html#signed-jar-file">Signed JAR file</a>  when:
> 
> We could say that a program could opt-out of verification by using the 2-arg constructor but that is probably too much to try to fit in here.

> Thanks for the updates in [6913871](https://github.com/openjdk/jdk/commit/691387157f01602ee25a1887223e00f880d071d1). Just one comment on the updated text, and specifically this sentence:
> 
> * * A {@code JarInputStream} may be used to verify the signatures of a
> * * [signed JAR file]({@docRoot}/../specs/jar/jar.html#signed-jar-file)
> * * assuming the following requirements are met:
> 
> The signatures are verified by default so I think you can reduce this down to:
> 
> A {@code JarInputStream} verifies the signatures of entries in a [Signed JAR file]({@docRoot}/../specs/jar/jar.html#signed-jar-file) when:
> 
> We could say that a program could opt-out of verification by using the 2-arg constructor but that is probably too much to try to fit in here.

Updated per your suggestion above.

-------------

PR: https://git.openjdk.org/jdk/pull/10045

From mullan at openjdk.org  Tue Sep 20 17:55:52 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 20 Sep 2022 17:55:52 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v11]
In-Reply-To: <ivT0q9lxJ8JVOUgWGLArPp6cCOWqz_jKB_VK4T9wGV0=.cc64ee5d-def8-451f-9af9-6502cbdd6cc4@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <ivT0q9lxJ8JVOUgWGLArPp6cCOWqz_jKB_VK4T9wGV0=.cc64ee5d-def8-451f-9af9-6502cbdd6cc4@github.com>
Message-ID: <OR1GB5lDiLLiWuCvxCQ_DF_vKLRyjJamorwkmyUwhyU=.5960d1d1-52d4-41b1-af82-1a87f377549b@github.com>

On Tue, 20 Sep 2022 17:47:03 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
>> 
>> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
>> 
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More wordsmithing to the signed jar section

src/java.base/share/classes/java/util/jar/JarInputStream.java line 77:

> 75:  *  {@link JarEntry#getCertificates()} may be called to obtain the certificates
> 76:  *  for this entry and {@link JarEntry#getCodeSigners()} may be called to obtain
> 77:  *  the signers.

Now that this API has a section about signed JARs, I think  it  is very important to include the following sentences which are copied from `JarFile`:

"Please note that the verification process does not include validating the signer's certificate. A caller should inspect the return value of [JarEntry.getCodeSigners()](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/jar/JarEntry.html#getCodeSigners()) to further determine if the signature can be trusted."

-------------

PR: https://git.openjdk.org/jdk/pull/10045

From lancea at openjdk.org  Tue Sep 20 18:08:23 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 20 Sep 2022 18:08:23 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v12]
In-Reply-To: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
Message-ID: <0wO5jFYhSTw702zqwi0_iLDgLcExZZZOuC5BQuCn4Z8=.4cab2b61-9156-4525-a787-a7dc75243ee2@github.com>

> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
> 
> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
> 
> 
> Best,
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Added the verification note from JarFile

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10045/files
  - new: https://git.openjdk.org/jdk/pull/10045/files/4c4c2a06..18f7e5dc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10045&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10045&range=10-11

  Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10045.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10045/head:pull/10045

PR: https://git.openjdk.org/jdk/pull/10045

From lancea at openjdk.org  Tue Sep 20 18:08:26 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 20 Sep 2022 18:08:26 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v11]
In-Reply-To: <OR1GB5lDiLLiWuCvxCQ_DF_vKLRyjJamorwkmyUwhyU=.5960d1d1-52d4-41b1-af82-1a87f377549b@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <ivT0q9lxJ8JVOUgWGLArPp6cCOWqz_jKB_VK4T9wGV0=.cc64ee5d-def8-451f-9af9-6502cbdd6cc4@github.com>
 <OR1GB5lDiLLiWuCvxCQ_DF_vKLRyjJamorwkmyUwhyU=.5960d1d1-52d4-41b1-af82-1a87f377549b@github.com>
Message-ID: <kwvoOBw-n77hZFz9WYOjJbwi6X7TZVDFquOlax9Jz8A=.d77523be-d329-4b40-ac43-672fdd6cc528@github.com>

On Tue, 20 Sep 2022 17:53:27 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Now that this API has a section about signed JARs, I think it is very important to include the following sentences which are copied from `JarFile`:
> 
> "Please note that the verification process does not include validating the signer's certificate. A caller should inspect the return value of [JarEntry.getCodeSigners()](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/jar/JarEntry.html#getCodeSigners()) to further determine if the signature can be trusted."

Add the note per your request

-------------

PR: https://git.openjdk.org/jdk/pull/10045

From lancea at openjdk.org  Tue Sep 20 18:12:07 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 20 Sep 2022 18:12:07 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v11]
In-Reply-To: <ivT0q9lxJ8JVOUgWGLArPp6cCOWqz_jKB_VK4T9wGV0=.cc64ee5d-def8-451f-9af9-6502cbdd6cc4@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <ivT0q9lxJ8JVOUgWGLArPp6cCOWqz_jKB_VK4T9wGV0=.cc64ee5d-def8-451f-9af9-6502cbdd6cc4@github.com>
Message-ID: <bx7g5-9oyrCEeQsjaDdAHqXvOKxkBm7LD2Pa33zmqD0=.0de43b78-4f23-4ed0-a839-2e981cff5a20@github.com>

On Tue, 20 Sep 2022 17:47:03 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
>> 
>> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
>> 
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More wordsmithing to the signed jar section

Alan,

Assuming we are set with the other changes, did you want to add the following paragraph (or similar) at line 58 to make it clear that if the Manifest is not found, then the JarEntry attributes will not be available:


 * <p>
 * The {@code Manifest} for a JAR file may include
 * <a href="{@docRoot}/../specs/jar/jar.html#main-attributes">main</a> and
 * <a href="{@docRoot}/../specs/jar/jar.html#per-entry-attributes">per entry</a>
 *  attributes. {@link JarEntry#getAttributes()} will return the per entry
 *  attributes for the current JAR file entry, if any, providing
 *  the {@code Manifest} is the first or second entry in the stream as described
 *  above.
 *  </p>
 *


If you have alternate wording, that is fine or we can leave it out entirely.

Hopefully this is the last piece to the update to resolve

Thank you (all) for your time and input

-------------

PR: https://git.openjdk.org/jdk/pull/10045

From errael at raelity.com  Tue Sep 20 19:08:39 2022
From: errael at raelity.com (Ernie Rael)
Date: Tue, 20 Sep 2022 12:08:39 -0700
Subject: Sequenced Collections
Message-ID: <f6edafc8-03f1-4f3a-1382-592688785c6e@raelity.com>

(There may be a better place to send this, let me know where)

Suggesting an option to limit the size of the collection, e.g 
"setMaxSize(int)", default of zero means no limit.

I put together "interface MRU<E> extends Collection<E>" some months ago, 
it has two implementations based on LinkedList and LinkedHashSet. The 
code can be seen at 
https://sourceforge.net/p/jvi/raelity-lib/ci/default/tree/lib/src/main/java/com/raelity/lib/

A SequencedCollection, as outlined in the JEP draft 2020/09/01, would be 
almost perfect to implement MRU; I've run into most of the 
problems/issues discussed in the JEP draft.

The MRU is a cache, as I use it; it typically has a max size for the 
collection. Handling this natively in the collection would be ideal; if 
an add operation would overflow, remove the item at the other end. Note 
that addAll() is used when initializing from backing store.

FYI, I use a "Supplier<Integer>" to the constructor to provide maxSize, 
but a property makes much more sense. I'll make that change in MRU for 
sanity, and get rid of the trim() method. setMaxSize can do the trim.

-ernie


From ihse at openjdk.org  Tue Sep 20 21:54:13 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 20 Sep 2022 21:54:13 GMT
Subject: RFR: 8294076: Improve ant detection in idea.sh
Message-ID: <9zPqCRX8ILNFC9XSfBGuvYBpQDAOMgnhRSELs74gcuI=.bfeee290-c24a-4620-b53d-03f2c689aee0@github.com>

The ant detection in bin/idea.sh is very rudimentary. It fails at a modern aarch64 macOS installation.

-------------

Commit messages:
 - 8294076: Improve ant detection in idea.sh

Changes: https://git.openjdk.org/jdk/pull/10364/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10364&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294076
  Stats: 23 lines in 1 file changed: 14 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/10364.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10364/head:pull/10364

PR: https://git.openjdk.org/jdk/pull/10364

From alexander.matveev at oracle.com  Tue Sep 20 21:57:06 2022
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Tue, 20 Sep 2022 21:57:06 +0000
Subject: RFR: 8293462: [macos] app image signature invalid when creating
 DMG or PKG from post processed signed image
In-Reply-To: <20F8AC2D-C71B-4892-A2F3-C9A07501046F@gmail.com>
References: <-sMR9P3CEZeJ31UFe7bzIcnC86rSErUVbY0GOymUoo4=.7c954bca-25c7-4fa0-9e2a-076ce2a485d4@github.com>
 <20F8AC2D-C71B-4892-A2F3-C9A07501046F@gmail.com>
Message-ID: <707A13E7-9047-428B-86FA-C4DFA047146C@oracle.com>

Hi Michael,

On Sep 16, 2022, at 6:19 PM, Michael Hall <mik3hall at gmail.com<mailto:mik3hall at gmail.com>> wrote:



On Sep 16, 2022, at 6:02 PM, Alexander Matveev <almatvee at openjdk.org<mailto:almatvee at openjdk.org>> wrote:

Problem is that [JDK-8286850](https://bugs.openjdk.org/browse/JDK-8286850) never set correct value in .jpackage.xml to mark image as signed. [JDK-8289030](https://bugs.openjdk.org/browse/JDK-8289030) reads this value to check if we can add per-user and system wide configuration to packaged app. Fixed by setting correct value in .jpackage.xml when we signing predefine application image.

Alexander,

I think I figured out how to include PR?s in my build and this appears good.

codesign -v --verbose=4 "/Volumes/BlackJack Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app"
/Volumes/BlackJack Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app: valid on disk
/Volumes/BlackJack Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app: satisfies its Designated Requirement

This was new?
Warning: Support for per-user configuration of the installed application will not be supported due to missing "BlackJack Blastoff_Unsigned.app/Contents/app/.package" in predefined signed application image.

I?m not quite sure what it?s saying but it doesn?t seem to impact what I?m doing.

This warning means that support for per-user configuration of the installed application will be disabled. We added support for per-user configuration with https://bugs.openjdk.org/browse/JDK-8250950 (Allow per-user and system wide configuration of a jpackaged app).

Thanks,
Alexander


Thanks,
Mike

FWIW, I ran into
[macos] cmstypes.c fails compilation with Xcode13.3
https://bugs.openjdk.org/browse/JDK-8283221

Adding this which I noticed in the source?
cmsUNUSED_PARAMETER(SizeOfTag);    // mjh

To the two erroring methods?
~/Documents/GitHub/jdk/build/macosx-x86_64-server-release/build.log:179: /Users/mjh/Documents/GitHub/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:3441:132: error: parameter 'SizeOfTag' set but not used [-Werror,-Wunused-but-set-parameter]
~/Documents/GitHub/jdk/build/macosx-x86_64-server-release/build.log:182: /Users/mjh/Documents/GitHub/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:5137:125: error: parameter 'SizeOfTag' set but not used [-Werror,-Wunused-but-set-parameter]


Seemed a fix. I could build.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220920/761200ee/attachment.htm>

From mik3hall at gmail.com  Tue Sep 20 22:01:06 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 20 Sep 2022 17:01:06 -0500
Subject: RFR: 8293462: [macos] app image signature invalid when creating
 DMG or PKG from post processed signed image
In-Reply-To: <707A13E7-9047-428B-86FA-C4DFA047146C@oracle.com>
References: <-sMR9P3CEZeJ31UFe7bzIcnC86rSErUVbY0GOymUoo4=.7c954bca-25c7-4fa0-9e2a-076ce2a485d4@github.com>
 <20F8AC2D-C71B-4892-A2F3-C9A07501046F@gmail.com>
 <707A13E7-9047-428B-86FA-C4DFA047146C@oracle.com>
Message-ID: <D847BFBF-6DEE-4F39-8EF8-5E1CF3CE3453@gmail.com>



>>> 
>>> 
>> 
>> Alexander,
>> 
>> I think I figured out how to include PR?s in my build and this appears good.
>> 
>> codesign -v --verbose=4 "/Volumes/BlackJack Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app"
>> /Volumes/BlackJack Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app: valid on disk
>> /Volumes/BlackJack Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app: satisfies its Designated Requirement
>> 
>> This was new?
>> Warning: Support for per-user configuration of the installed application will not be supported due to missing "BlackJack Blastoff_Unsigned.app/Contents/app/.package" in predefined signed application image.
>> 
>> I?m not quite sure what it?s saying but it doesn?t seem to impact what I?m doing.
> 
> This warning means that support for per-user configuration of the installed application will be disabled. We added support for per-user configuration with https://bugs.openjdk.org/browse/JDK-8250950 <https://bugs.openjdk.org/browse/JDK-8250950> (Allow per-user and system wide configuration of a jpackaged app).
> 
> Thanks,
> Alexander
> 

Alexander,

I?ll take a look. It sounds like it could be a useful feature at times. The last update still works for me.

Thanks again,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220920/9c3dfe1a/attachment-0001.htm>

From sspitsyn at openjdk.org  Tue Sep 20 22:19:55 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 20 Sep 2022 22:19:55 GMT
Subject: RFR: 8293613: need to properly handle and hide tmp VTMS
 transitions [v3]
In-Reply-To: <vMfCeRbX7oTnnv5-1PggLMUc1Q8MjZ0mnSFp5cutdTA=.08a9c27a-1bc2-4118-8f88-56c741df1435@github.com>
References: <O_jzls_cv3HBC0NbzuYV2LXaW9VB2M18FroUfXWXd2w=.fa9d1f3c-40a2-42bd-a09b-dadd5032e513@github.com>
 <ve9g9LcSrawK3kb-TxKqxkSUOvkvnIsebd84GAub2DQ=.54a4a79b-be0a-47ef-99ba-63b93236cf08@github.com>
 <vMfCeRbX7oTnnv5-1PggLMUc1Q8MjZ0mnSFp5cutdTA=.08a9c27a-1bc2-4118-8f88-56c741df1435@github.com>
Message-ID: <B6RFtDbP8hXLeKchONA5Oms2vNDsUU7EHV0wWotmayA=.726d876d-706b-4e70-ad7a-d49575796543@github.com>

On Mon, 19 Sep 2022 20:19:10 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed typo in VirtualThread.c
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 713:
> 
>> 711:   if (!jt->is_in_tmp_VTMS_transition()) {
>> 712:     jvf = check_and_skip_hidden_frames(jt, jvf);
>> 713:   }
> 
> I think this comment needs some help. It's hard to match it up with what the code is doing. I think you are saying you want to avoid skipping hidden frames when in transition, although if that's the case, it's not clear to me why not skipping is ok.
> 
> Also is skipping (or not skipping) ok regardless of the JvmtiEnvBase::is_cthread_with_continuation() result?

Thank you for reviewing and the comment, Chris.
I agree, this part and related comment is kind of obscure.
I'll think how to make the comment better.
In fact, all temporary VTMS transitions do temporary switch the `JavaThread` identity from virtual thread to carrier. There is no need to skip frames because there are no real carrier thread frames at the top. Moreover, any attempt to skip frames which are in transition works incorrectly and gives an empty stack. The check `JvmtiEnvBase::is_cthread_with_continuation()` is needed to make sure we have a deal with a continuation. There is no need to skip frames otherwise.

-------------

PR: https://git.openjdk.org/jdk/pull/10321

From sspitsyn at openjdk.org  Tue Sep 20 22:38:47 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 20 Sep 2022 22:38:47 GMT
Subject: RFR: 8293613: need to properly handle and hide tmp VTMS
 transitions [v3]
In-Reply-To: <vMfCeRbX7oTnnv5-1PggLMUc1Q8MjZ0mnSFp5cutdTA=.08a9c27a-1bc2-4118-8f88-56c741df1435@github.com>
References: <O_jzls_cv3HBC0NbzuYV2LXaW9VB2M18FroUfXWXd2w=.fa9d1f3c-40a2-42bd-a09b-dadd5032e513@github.com>
 <ve9g9LcSrawK3kb-TxKqxkSUOvkvnIsebd84GAub2DQ=.54a4a79b-be0a-47ef-99ba-63b93236cf08@github.com>
 <vMfCeRbX7oTnnv5-1PggLMUc1Q8MjZ0mnSFp5cutdTA=.08a9c27a-1bc2-4118-8f88-56c741df1435@github.com>
Message-ID: <SCb5RSNqx8_VOEBt85tDwnCH9r36GOK_-nE3WvyPwD0=.40baa8e2-4997-4534-8fe3-2274b206f8a5@github.com>

On Mon, 19 Sep 2022 20:22:54 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed typo in VirtualThread.c
>
> src/hotspot/share/prims/jvmtiExport.cpp line 1055:
> 
>> 1053:   if (JavaThread::current()->is_in_tmp_VTMS_transition()) {
>> 1054:     return false;
>> 1055:   }
> 
> You mentioned this in the PR description. However, it's not clear to me why this is ok.  Also, it should be commented.
> 
> Same thing for changes in JvmtiExport::post_class_load() and JvmtiExport::post_class_prepare().

I initially wanted to consult on this with Alan. It feels like it'd be better if I did it before posting this PR.
We have just two possible approaches here. The best approach is to move any class loading out of the temporary transition code path. Then we already have the relevant asserts in place. However, this is not that easy to solve. Alan already suggested a couple of patches which I've tested but new places with class loads were discovered. Another approach is to skip all ClassLoad, ClassPrepare and CFLH events in context of temporary transitions. It is hard to estimate how acceptable it is. At least, I've not found any failing tests because of it which means it most likely does not impact the debugger. My current suggestion is to file a bug and try to address it later as Alan may need more time for analysis.

-------------

PR: https://git.openjdk.org/jdk/pull/10321

From sspitsyn at openjdk.org  Tue Sep 20 22:45:04 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 20 Sep 2022 22:45:04 GMT
Subject: RFR: 8293613: need to properly handle and hide tmp VTMS
 transitions [v3]
In-Reply-To: <vMfCeRbX7oTnnv5-1PggLMUc1Q8MjZ0mnSFp5cutdTA=.08a9c27a-1bc2-4118-8f88-56c741df1435@github.com>
References: <O_jzls_cv3HBC0NbzuYV2LXaW9VB2M18FroUfXWXd2w=.fa9d1f3c-40a2-42bd-a09b-dadd5032e513@github.com>
 <ve9g9LcSrawK3kb-TxKqxkSUOvkvnIsebd84GAub2DQ=.54a4a79b-be0a-47ef-99ba-63b93236cf08@github.com>
 <vMfCeRbX7oTnnv5-1PggLMUc1Q8MjZ0mnSFp5cutdTA=.08a9c27a-1bc2-4118-8f88-56c741df1435@github.com>
Message-ID: <dv7Njja_pwgsqGMUu9Te08dhKnFsk5wXPf3O2OT65ic=.55108dd8-03e3-4cc1-b858-183d415ca9fd@github.com>

On Mon, 19 Sep 2022 20:41:50 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed typo in VirtualThread.c
>
> src/hotspot/share/runtime/javaThread.cpp line 1174:
> 
>> 1172: #if INCLUDE_JVMTI
>> 1173:   // Suspending a JavaThread in VTMS transition or disabling VTMS transitions can cause deadlocks.
>> 1174:   assert(!is_in_non_tmp_VTMS_transition(), "no suspend allowed in VTMS transition");
> 
> IMHO, a non tmp VTMS transition should be considered a type of VTMS transition, so the assert check here does not really match the assert text. Also see my related comments below on naming and use of these flags and APIs.

Thanks. Accepted.

> src/hotspot/share/runtime/javaThread.hpp line 650:
> 
>> 648:   void set_is_in_VTMS_transition(bool val);
>> 649:   bool is_in_tmp_VTMS_transition() const         { return _is_in_tmp_VTMS_transition; }
>> 650:   void toggle_is_in_tmp_VTMS_transition()        { _is_in_tmp_VTMS_transition = !_is_in_tmp_VTMS_transition; };
> 
> The naming of the flags does not match up with the naming of the APIs, which is confusing.  An API named  is_in_VTMS_transition() should return _is_in_VTMS_transition. I think part of problem is that _is_in_VTMS_transition is not a superset of _is_in_tmp_VTMS_transition. The flags are never both set true, although both can be false. Maybe this should be changed to make it an invariant that if _is_in_tmp_VTMS_transit is true, then _is_in_tmp_VTMS_transition is true.

I agree, this naming is not good. However, I was reluctant to do required renaming because it can potentially impact many spots and make review harder. Let me think a little bit more on this.

-------------

PR: https://git.openjdk.org/jdk/pull/10321

From mik3hall at gmail.com  Tue Sep 20 22:50:16 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 20 Sep 2022 17:50:16 -0500
Subject: RFR: 8293462: [macos] app image signature invalid when creating
 DMG or PKG from post processed signed image
In-Reply-To: <D847BFBF-6DEE-4F39-8EF8-5E1CF3CE3453@gmail.com>
References: <-sMR9P3CEZeJ31UFe7bzIcnC86rSErUVbY0GOymUoo4=.7c954bca-25c7-4fa0-9e2a-076ce2a485d4@github.com>
 <20F8AC2D-C71B-4892-A2F3-C9A07501046F@gmail.com>
 <707A13E7-9047-428B-86FA-C4DFA047146C@oracle.com>
 <D847BFBF-6DEE-4F39-8EF8-5E1CF3CE3453@gmail.com>
Message-ID: <A80F3462-C69A-401D-BD23-26391CD96B8C@gmail.com>



> On Sep 20, 2022, at 5:01 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> 
>>>> 
>>>> 
>>> 
>>> Alexander,
>>> 
>>> I think I figured out how to include PR?s in my build and this appears good.
>>> 
>>> codesign -v --verbose=4 "/Volumes/BlackJack Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app"
>>> /Volumes/BlackJack Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app: valid on disk
>>> /Volumes/BlackJack Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app: satisfies its Designated Requirement
>>> 
>>> This was new?
>>> Warning: Support for per-user configuration of the installed application will not be supported due to missing "BlackJack Blastoff_Unsigned.app/Contents/app/.package" in predefined signed application image.
>>> 
>>> I?m not quite sure what it?s saying but it doesn?t seem to impact what I?m doing.
>> 
>> This warning means that support for per-user configuration of the installed application will be disabled. We added support for per-user configuration with https://bugs.openjdk.org/browse/JDK-8250950 <https://bugs.openjdk.org/browse/JDK-8250950> (Allow per-user and system wide configuration of a jpackaged app).
>> 
>> Thanks,
>> Alexander
>> 
> 
> Alexander,
> 
> I?ll take a look. It sounds like it could be a useful feature at times. The last update still works for me.
> 
> Thanks again,
> Mike

Alexander, 
One thing I notice is that 
Release Note: Allow per-user and System Wide Configuration of a jpackaged app
https://bugs.openjdk.org/browse/JDK-8288249 <https://bugs.openjdk.org/browse/JDK-8288249>
Mentions?
~/Library/Application Support/${PACKAGE_NAME} 
Which would be a per user location. But doesn?t mention
/Library
Which would be the system level location.

Since both of these locations are external to the application bundle I?m not understanding why they would no longer work with whatever you changed.
I may need to look closer.
Given that this does break that, one possibility might be to include parameter changes in the Info.plist file. Some time back Apple java applications used to include a java dictionary in the plist that was more or less equivalent to the jpackage .cfg file. Maybe a override mechanism could be added to that which would be up to the developer to add in post processing. 
Customizing the Info.plist file is still the main thing I am considering doing for this feature.
Another recent thought was that I could use this to add a hsdis dylib to the jdk lib directory for an application to allow printing disassembly. But then I noticed it doesn?t appear that hsdis is even needed in recent jdk?s? -XX:+PrintAssembly seems to just work. Still you could use post-processing to add whatever java binary executable commands you wanted. This again would mean changes to the embedded jdk that might have signing side effects. I haven?t tested.  

Mike



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220920/b231d6fd/attachment-0001.htm>

From mik3hall at gmail.com  Tue Sep 20 23:04:09 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 20 Sep 2022 18:04:09 -0500
Subject: RFR: 8293462: [macos] app image signature invalid when creating
 DMG or PKG from post processed signed image
In-Reply-To: <A80F3462-C69A-401D-BD23-26391CD96B8C@gmail.com>
References: <-sMR9P3CEZeJ31UFe7bzIcnC86rSErUVbY0GOymUoo4=.7c954bca-25c7-4fa0-9e2a-076ce2a485d4@github.com>
 <20F8AC2D-C71B-4892-A2F3-C9A07501046F@gmail.com>
 <707A13E7-9047-428B-86FA-C4DFA047146C@oracle.com>
 <D847BFBF-6DEE-4F39-8EF8-5E1CF3CE3453@gmail.com>
 <A80F3462-C69A-401D-BD23-26391CD96B8C@gmail.com>
Message-ID: <61218FCB-64AA-4A6E-AF10-FBF7CCD5D971@gmail.com>



> On Sep 20, 2022, at 5:50 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> Given that this does break that, one possibility might be to include parameter changes in the Info.plist file. Some time back Apple java applications used to include a java dictionary in the plist that was more or less equivalent to the jpackage .cfg file. Maybe a override mechanism could be added to that which would be up to the developer to add in post processing. 

Never mind on this. That is no different really from the .cfg file and doesn?t help with changing settings on the installed machine, user or system. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220920/17af5334/attachment.htm>

From kvn at openjdk.org  Tue Sep 20 23:20:42 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 20 Sep 2022 23:20:42 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v8]
In-Reply-To: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com>
Message-ID: <f9RRU04uZxriWVABYRZjOkwbiBuTPeoCvGf9OJM5TTs=.bcc128fb-231f-4361-b33f-9c6e39a6ebde@github.com>

On Fri, 2 Sep 2022 00:52:49 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> 8289552: Make intrinsic conversions between bit representations of half precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments

I still got failures in tier1. All JVMCI tests filed with runs on AMD you with:

jdk.vm.ci.common.JVMCIError: Missing CPU feature constants: [F16C]
	at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIBackendFactory.convertFeatures(HotSpotJVMCIBackendFactory.java:79)
	at jdk.internal.vm.ci/jdk.vm.ci.hotspot.amd64.AMD64HotSpotJVMCIBackendFactory.computeFeatures(AMD64HotSpotJVMCIBackendFactory.java:53)
	at jdk.internal.vm.ci/jdk.vm.ci.hotspot.amd64.AMD64HotSpotJVMCIBackendFactory.createTarget(AMD64HotSpotJVMCIBackendFactory.java:74)
	at jdk.internal.vm.ci/jdk.vm.ci.hotspot.amd64.AMD64HotSpotJVMCIBackendFactory.createJVMCIBackend(AMD64HotSpotJVMCIBackendFactory.java:109)
	at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.<init>(HotSpotJVMCIRuntime.java:587)
	at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.runtime(HotSpotJVMCIRuntime.java:179)
	at jdk.internal.vm.ci/jdk.vm.ci.runtime.JVMCI.initializeRuntime(Native Method)
	at jdk.internal.vm.ci/jdk.vm.ci.runtime.JVMCI.getRuntime(JVMCI.java:65)

And `jdk/test/whitebox/CPUInfoTest.java` test failed with:

----------System.err:(13/810)----------
java.lang.RuntimeException: not all features are known: expected true, was false
	at jdk.test.lib.Asserts.fail(Asserts.java:594)
	at jdk.test.lib.Asserts.assertTrue(Asserts.java:486)
	at CPUInfoTest.main(CPUInfoTest.java:92)

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From kvn at openjdk.org  Tue Sep 20 23:36:35 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 20 Sep 2022 23:36:35 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v8]
In-Reply-To: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com>
Message-ID: <c8fPsgkhWW4KQ2sAwEyWvhjEgUCa2zTllj7_MNMMyFk=.24ce2eb1-a659-4d45-9748-ce412813f921@github.com>

On Fri, 2 Sep 2022 00:52:49 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> 8289552: Make intrinsic conversions between bit representations of half precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments

Looking on `cpuinfo` on this machines I do see `f16c`.

Here is additional output from `jdk/test/whitebox/CPUInfoTest.java`:

WB.getCPUFeatures(): "(12 cores per cpu, 2 threads per core) family 25 model 1 stepping 1 microcode 0x1000065, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4a, sse4.1, sse4.2, popcnt, lzcnt, tsc, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, hv, rdtscp, rdpid, f16c"
CPUInfo.getAdditionalCPUInfo(): "(12 cores per cpu, 2 threads per core) family 25 model 1 stepping 1 microcode 0x1000065"
CPUInfo.getFeatures(): [cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4a, sse4.1, sse4.2, popcnt, lzcnt, tsc, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, hv, rdtscp, rdpid, f16c]
Well-known CPU features: [avx512bw, avx512pf, avx512_vbmi, avx2, rdpid, clflush, avx512cd, avx512_vbmi2, aes, 3dnowpref, avx512_vpopcntdq, avx512f, sha, avx512_vnni, avx512_vpclmulqdq, avx, erms, fsrm, sse4a, mmx, gfni, lzcnt, clmul, sse, avx512_vaes, avx512dq, fma, rtm, vzeroupper, cx8, ht, tsc, tscinv, clwb, tscinvbit, cmov, clflushopt, rdtscp, hv, sse2, sse3, avx512er, avx512vl, sse4.1, sse4.2, bmi1, bmi2, adx, avx512_bitalg, popcnt, fxsr, ssse3]

Here is test location: `test/lib-test/jdk/test/whitebox/CPUInfoTest.java`
I think you need to add `f16c` to it.
I am still not sure why JVMCI tests failed. May be JVMCI also have a list of CPU features you need to update.

I also don't see GitHub Action testing on your branch.

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From sviswanathan at openjdk.org  Tue Sep 20 23:39:21 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 20 Sep 2022 23:39:21 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v8]
In-Reply-To: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com>
Message-ID: <Pl1as0SM3SQ1VkGxvFp7l6fIkHH31UUvnxYvwFlevMg=.78f5b994-4ab3-4836-9ca4-2c369d9444d7@github.com>

On Fri, 2 Sep 2022 00:52:49 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> 8289552: Make intrinsic conversions between bit representations of half precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments

Yes, jmvci also seems to have feature list in jdk/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.amd64/src/jdk/vm/ci/amd64/AMD64.java.

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From erikj at openjdk.org  Tue Sep 20 23:40:56 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 20 Sep 2022 23:40:56 GMT
Subject: RFR: 8294076: Improve ant detection in idea.sh
In-Reply-To: <9zPqCRX8ILNFC9XSfBGuvYBpQDAOMgnhRSELs74gcuI=.bfeee290-c24a-4620-b53d-03f2c689aee0@github.com>
References: <9zPqCRX8ILNFC9XSfBGuvYBpQDAOMgnhRSELs74gcuI=.bfeee290-c24a-4620-b53d-03f2c689aee0@github.com>
Message-ID: <Wr_ZNouq8j4zsofpp8ub9Ww7IMmh80yntrAgK0vXcfg=.986885ff-f566-4f76-a059-0d259164e19b@github.com>

On Tue, 20 Sep 2022 21:45:05 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The ant detection in bin/idea.sh is very rudimentary. It fails at a modern aarch64 macOS installation.

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10364

From kvn at openjdk.org  Tue Sep 20 23:45:47 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 20 Sep 2022 23:45:47 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v8]
In-Reply-To: <Pl1as0SM3SQ1VkGxvFp7l6fIkHH31UUvnxYvwFlevMg=.78f5b994-4ab3-4836-9ca4-2c369d9444d7@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com>
 <Pl1as0SM3SQ1VkGxvFp7l6fIkHH31UUvnxYvwFlevMg=.78f5b994-4ab3-4836-9ca4-2c369d9444d7@github.com>
Message-ID: <qPsn6tlxTHzqnGihmBMmXlgdCrHY9fgXbJfR1B59fEo=.eb491d72-178d-4b4f-b3fc-d69bab63131a@github.com>

On Tue, 20 Sep 2022 23:36:23 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressed review comments
>
> Yes, jmvci also seems to have feature list in jdk/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.amd64/src/jdk/vm/ci/amd64/AMD64.java.

Thank you @sviswa7 
I submitted tier1 testing again with fixed `CPUInfoTest.java` and `AMD64.java`.

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From svkamath at openjdk.org  Wed Sep 21 00:20:45 2022
From: svkamath at openjdk.org (Smita Kamath)
Date: Wed, 21 Sep 2022 00:20:45 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v8]
In-Reply-To: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com>
Message-ID: <vBn4HKuS1vjnMia-ZuYWJy7-vR2yErYmY-wucfqi0W4=.e231c22f-5a98-4820-ac4b-d8a5795d3553@github.com>

On Fri, 2 Sep 2022 00:52:49 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> 8289552: Make intrinsic conversions between bit representations of half precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments

> 

Hi @vnkozlov , Github actions seems to be disabled for my account. I am working with Github support to fix this issue.

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From kvn at openjdk.org  Wed Sep 21 00:25:46 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 21 Sep 2022 00:25:46 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v8]
In-Reply-To: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com>
Message-ID: <Vo5xoKOtMoGIN_5rbEfkIk-OPnsQzfGmxPtemsN6Yjo=.1158f300-daa9-4273-ae42-1b9198dd37fc@github.com>

On Fri, 2 Sep 2022 00:52:49 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> 8289552: Make intrinsic conversions between bit representations of half precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments

Tier1 tests passed now. I am submitting higher tiers.

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From lzhai at openjdk.org  Wed Sep 21 00:43:50 2022
From: lzhai at openjdk.org (Leslie Zhai)
Date: Wed, 21 Sep 2022 00:43:50 GMT
Subject: RFR: 8293977: jdk/modules/etc/VerifyModuleDelegation.java fail
 with jfx
In-Reply-To: <uUAL_VrLHEuwOAc41MdzAy6ktRphzJfl2fa9ISkLYzU=.855083b1-04c4-49e9-97e3-e9598e1b5ae8@github.com>
References: <K8keV23DhjOl2iAcpxEGUPEDKfRsrPMwVYf6ZvYV39M=.66a73163-007e-4951-a524-7cf8d5aa1f79@github.com>
 <uUAL_VrLHEuwOAc41MdzAy6ktRphzJfl2fa9ISkLYzU=.855083b1-04c4-49e9-97e3-e9598e1b5ae8@github.com>
Message-ID: <br5XwsOE_aEsuPAC6hKMfVzrNsxCrIySHruXBGpNImA=.d25829f1-ef75-4412-9431-7c165a8688ae@github.com>

On Tue, 20 Sep 2022 14:11:55 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Hi,
>> 
>> @dumasun reported the issue:
>> 
>> Configured with jfx-ls-modular-sdk:
>> 
>> 
>> configure --with-import-modules=modular-sdk
>> 
>> 
>> `make run-test CONF=fastdebug TEST="jdk/modules/etc/VerifyModuleDelegation.java"` failed:
>> 
>> 
>> ----------System.out:(46/3114)----------
>> test VerifyModuleDelegation.checkJavaBase(): success
>> test VerifyModuleDelegation.checkLoaderDelegation(): failure
>> java.lang.Error: platform/javafx.swing can't delegate to find classes from app/jdk.unsupported.desktop
>>     at VerifyModuleDelegation.lambda$checkLoaderDelegation$1(VerifyModuleDelegation.java:77)
>>     at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>>     at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1921)
>>     at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>>     at VerifyModuleDelegation.lambda$checkLoaderDelegation$2(VerifyModuleDelegation.java:68)
>>     at java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1715)
>>     at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>>     at VerifyModuleDelegation.checkLoaderDelegation(VerifyModuleDelegation.java:68)
>>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>>     at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>>     at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>>     at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>>     at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>>     at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>>     at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>>     at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>>     at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>>     at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
>>     at org.testng.TestRunner.privateRun(TestRunner.java:764)
>>     at org.testng.TestRunner.run(TestRunner.java:585)
>>     at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
>>     at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
>>     at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
>>     at org.testng.SuiteRunner.run(SuiteRunner.java:286)
>>     at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
>>     at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
>>     at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
>>     at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
>>     at org.testng.TestNG.runSuites(TestNG.java:1069)
>>     at org.testng.TestNG.run(TestNG.java:1037)
>>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
>>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54)
>>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>     at java.base/java.lang.Thread.run(Thread.java:1589)
>> 
>> ===============================================
>> jdk/modules/etc/VerifyModuleDelegation.java
>> Total tests run: 2, Passes: 1, Failures: 1, Skips: 0
>> ===============================================
>> 
>> ----------System.err:(13/753)----------
>> WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.concurrent
>> java.lang.Exception: failures: 1
>>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96)
>>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54)
>>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>     at java.base/java.lang.Thread.run(Thread.java:1589)
>> 
>> 
>> Thanks,
>> Leslie Zhai
>
> In that case, a solution might be to remove `ext` from the `classloader` property from all of the `modules/javafx.*/make/build.properties` files in JavaFX:
> 
> 
> classloader=
> 
> 
> or
> 
> 
> classloader=app

Hi @kevinrushforth 

Thanks for your hint!

@dumasun  is building jfx with the quick debug patch:


diff --git a/modules/javafx.swing/make/build.properties b/modules/javafx.swing/make/build.properties
index f913584cb4..5d04f77111 100644
--- a/modules/javafx.swing/make/build.properties
+++ b/modules/javafx.swing/make/build.properties
@@ -29,4 +29,4 @@ include_in_jre=true
 include_in_jdk=true
 include_in_jdk_server=false
 include_in_docs=true
-classloader=ext
+classloader=app


Thanks,
Leslie Zhai

-------------

PR: https://git.openjdk.org/jdk/pull/10328

From lzhai at openjdk.org  Wed Sep 21 01:41:52 2022
From: lzhai at openjdk.org (Leslie Zhai)
Date: Wed, 21 Sep 2022 01:41:52 GMT
Subject: RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx
 [v2]
In-Reply-To: <_W8bK_pIfXVi4f1Yca9LzMu3OGyaUGnHmHjPv2EKM14=.a3586b95-ea5e-4f24-9a73-9f19c92cc887@github.com>
References: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
 <eLkziaKhG6kfuVWg-zc6HxccXS9aL_wTUjOf8G7oR9s=.4892bc1b-fcb0-4e28-9a6d-53f38213665c@github.com>
 <_W8bK_pIfXVi4f1Yca9LzMu3OGyaUGnHmHjPv2EKM14=.a3586b95-ea5e-4f24-9a73-9f19c92cc887@github.com>
Message-ID: <igJUOJMgFDEsZi3LbkzMC8KeIkWZ-JoRvYcyQmEytCk=.4d0bb809-49c7-4952-b331-cdeadfc37adb@github.com>

On Tue, 20 Sep 2022 14:23:22 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Leslie Zhai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8293910: Try --upgrade-module-path and --patch-module but still failed
>
> How does the test fail? Does it actually find and load the "mockfx" classes, but subsequently fail? Or is it unable to patch/upgrade the javafx.graphics module with the "mockfx" classes?

Hi @kevinrushforth 

I updated the testcase to check whether or not FX is part of jdk:


        // Check whether or not FX is part of jdk
        try {
            fxClass = Class.forName(FX_MARKER_CLASS);
        } catch (ClassNotFoundException ex) {
            // do nothing
        }
        if (fxClass != null) {
            System.out.println("JavaFX modules included in the JDK");
        }


And tried to `--upgrade-module-path` in the `doFxCompile` when JavaFX modules included in the JDK:


    static void doFxCompile(String...compilerArgs) {
        if (fxClass == null) {
            compileFXModule();
        }

        List<String> fxCompilerArgs = new ArrayList<>();
        if (fxClass == null) {
            fxCompilerArgs.add("--module-path=" + MODULE_DIR);
        } else {
            fxCompilerArgs.add("--upgrade-module-path=" + IMPORT_MODULE_DIR);
        }
        fxCompilerArgs.add("--add-modules=javafx.graphics");
        fxCompilerArgs.addAll(Arrays.asList(compilerArgs));
        compile(fxCompilerArgs.toArray(new String[fxCompilerArgs.size()]));
    }


Also tried `--patch-module` in the `doFxExec`:


    static TestResult doFxExec(String...cmds) {
        List<String> fxCmds = new ArrayList<>();
        fxCmds.addAll(Arrays.asList(cmds));
        if (fxClass == null) {
            fxCmds.add(1, "--module-path=" + MODULE_DIR);
            fxCmds.add(2, "--add-modules=javafx.graphics");
        } else {
            fxCmds.add(1, "--upgrade-module-path=" + IMPORT_MODULE_DIR);
            fxCmds.add(2, "--patch-module=javafx.graphics=" + IMPORT_MODULE_DIR + "/javafx.graphics.jmod");
        }
        return doExec(fxCmds.toArray(new String[fxCmds.size()]));
    }


But it might be unable to patch/upgrade the javafx.graphics module with the "mockfx" classes:


STDOUT:
_____________________________________________
test# 1-  Main method: public static void main(String[] args) { launch(args); }
Main-Class: helloworld.HelloWorld
renaming fxtest.jar to testBasicFXApp_useCP_noJAC-1-fxtest.jar
FAIL: testBasicFXApp_useCP_noJAC:1 : test with helloworld.HelloWorld
Test static void FXLauncherTest.testBasicFXApp() throws java.lang.Exception failed: java.lang.reflect.InvocationTargetException 
----begin detailed exceptions----
java.lang.reflect.InvocationTargetException
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:119)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at TestHelper.run(TestHelper.java:200)
	at FXLauncherTest.main(FXLauncherTest.java:469)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:125)
	at java.base/java.lang.Thread.run(Thread.java:1589)
Caused by: java.lang.Exception: Failed: testBasicFXApp_useCP_noJAC:1
	at FXLauncherTest.checkStatus(FXLauncherTest.java:205)
	at FXLauncherTest.testBasicFXApp(FXLauncherTest.java:311)
	at FXLauncherTest.testBasicFXApp(FXLauncherTest.java:266)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	... 7 more
----end detailed exceptions----
_____________________________________________
test# 2-  Main method: public static void main(String[] args) { launch(args); }
Main-Class: helloworld.ExtHello
renaming fxtest.jar to testExtendFXApp_useCP_noJAC-2-fxtest.jar
FAIL: testExtendFXApp_useCP_noJAC:2 : test with helloworld.ExtHello
Test static void FXLauncherTest.testExtendFXApp() throws java.lang.Exception failed: java.lang.reflect.InvocationTargetException 
----begin detailed exceptions----
java.lang.reflect.InvocationTargetException
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:119)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at TestHelper.run(TestHelper.java:200)
	at FXLauncherTest.main(FXLauncherTest.java:469)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:125)
	at java.base/java.lang.Thread.run(Thread.java:1589)
Caused by: java.lang.Exception: Failed: testExtendFXApp_useCP_noJAC:2
	at FXLauncherTest.checkStatus(FXLauncherTest.java:205)
	at FXLauncherTest.testExtendFXApp(FXLauncherTest.java:369)
	at FXLauncherTest.testExtendFXApp(FXLauncherTest.java:323)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	... 7 more
----end detailed exceptions----
_____________________________________________
test# 3: abort on missing Main-Class
JavaFX-Application-Class: helloworld.HelloWorld
renaming fxtest.jar to testMissingMC-3-fxtest.jar
FAIL: testMissingMC:3 : test with helloworld.HelloWorld
Test static void FXLauncherTest.testMissingMC() throws java.lang.Exception failed: java.lang.reflect.InvocationTargetException 
----begin detailed exceptions----
java.lang.reflect.InvocationTargetException
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:119)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at TestHelper.run(TestHelper.java:200)
	at FXLauncherTest.main(FXLauncherTest.java:469)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:125)
	at java.base/java.lang.Thread.run(Thread.java:1589)
Caused by: java.lang.Exception: Failed: testMissingMC:3
	at FXLauncherTest.checkStatus(FXLauncherTest.java:205)
	at FXLauncherTest.testMissingMC(FXLauncherTest.java:399)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	... 7 more
----end detailed exceptions----
_____________________________________________
test# 4: test for erroneous jfxrt.jar loading
Main-Class: helloworld.HelloJava
renaming fxtest.jar to testExtraneousJars_useCP-4-fxtest.jar
FAIL: testExtraneousJars_useCP:4 : test with helloworld.HelloJava
Test static void FXLauncherTest.testExtraneousJars() throws java.lang.Exception failed: java.lang.reflect.InvocationTargetException 
----begin detailed exceptions----
java.lang.reflect.InvocationTargetException
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:119)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at TestHelper.run(TestHelper.java:200)
	at FXLauncherTest.main(FXLauncherTest.java:469)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:125)
	at java.base/java.lang.Thread.run(Thread.java:1589)
Caused by: java.lang.Exception: Failed: testExtraneousJars_useCP:4
	at FXLauncherTest.checkStatus(FXLauncherTest.java:205)
	at FXLauncherTest.testExtraneousJars(FXLauncherTest.java:453)
	at FXLauncherTest.testExtraneousJars(FXLauncherTest.java:410)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	... 7 more
----end detailed exceptions----
Total: Passed: 0, Failed 4
STDERR:
Executed command: /home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/images/jdk/bin/java --module-path=mods --add-modules=javafx.graphics -cp /home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/test-support/jtreg_test_jdk_tools_launcher_FXLauncherTest_java/scratch/0/fxtest.jar helloworld.HelloWorld one two 

###TestError###: test did not return 0 exit value
++++Begin Test Info++++
Test Status: FAIL
++++Test Environment++++
  PATH=/bin:/usr/bin:/usr/sbin
  DISPLAY=:0
  TEST_IMAGE_DIR=/home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/images/test
  _JVM_DWARF_PATH=/home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/images/symbols
  XMODIFIERS=@im=fcitx
  LC_ALL=C
  CLASSPATH=/home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/test-support/jtreg_test_jdk_tools_launcher_FXLauncherTest_java/classes/0/tools/launcher/FXLauncherTest.d:/home/loongson/private/jdk-ls/test/jdk/tools/launcher:/home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/test-support/jtreg_test_jdk_tools_launcher_FXLauncherTest_java/classes/0/test/lib:/home/loongson/private/jdk-ls/test/lib:/home/loongson/public/jtreg/lib/javatest.jar:/home/loongson/public/jtreg/lib/jtreg.jar
  LANG=zh_CN.UTF-8
  HOME=/home/loongson
++++Test Output++++
  Error occurred during initialization of boot layer
  java.lang.module.FindException: Unable to compute the hash of module javafx.graphics
++++Test Stack Trace++++
java.lang.Throwable: current stack of the test
  TestHelper.doExec(TestHelper.java:476)
  TestHelper.doExec(TestHelper.java:437)
  FXLauncherTest.doFxExec(FXLauncherTest.java:252)
  FXLauncherTest.testBasicFXApp(FXLauncherTest.java:292)
  FXLauncherTest.testBasicFXApp(FXLauncherTest.java:266)
  java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
  java.base/java.lang.reflect.Method.invoke(Method.java:578)
  TestHelper.run(TestHelper.java:200)
  FXLauncherTest.main(FXLauncherTest.java:469)
  java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
  java.base/java.lang.reflect.Method.invoke(Method.java:578)
  com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:125)
  java.base/java.lang.Thread.run(Thread.java:1589)
++++End of Test Info++++

Executed command: /home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/images/jdk/bin/java --module-path=mods --add-modules=javafx.graphics -cp /home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/test-support/jtreg_test_jdk_tools_launcher_FXLauncherTest_java/scratch/0/fxtest.jar helloworld.ExtHello one two 

###TestError###: test did not return 0 exit value
++++Begin Test Info++++
Test Status: FAIL
++++Test Environment++++
  PATH=/bin:/usr/bin:/usr/sbin
  DISPLAY=:0
  TEST_IMAGE_DIR=/home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/images/test
  _JVM_DWARF_PATH=/home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/images/symbols
  XMODIFIERS=@im=fcitx
  LC_ALL=C
  CLASSPATH=/home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/test-support/jtreg_test_jdk_tools_launcher_FXLauncherTest_java/classes/0/tools/launcher/FXLauncherTest.d:/home/loongson/private/jdk-ls/test/jdk/tools/launcher:/home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/test-support/jtreg_test_jdk_tools_launcher_FXLauncherTest_java/classes/0/test/lib:/home/loongson/private/jdk-ls/test/lib:/home/loongson/public/jtreg/lib/javatest.jar:/home/loongson/public/jtreg/lib/jtreg.jar
  LANG=zh_CN.UTF-8
  HOME=/home/loongson
++++Test Output++++
  Error occurred during initialization of boot layer
  java.lang.module.FindException: Unable to compute the hash of module javafx.graphics
++++Test Stack Trace++++
java.lang.Throwable: current stack of the test
  TestHelper.doExec(TestHelper.java:476)
  TestHelper.doExec(TestHelper.java:437)
  FXLauncherTest.doFxExec(FXLauncherTest.java:252)
  FXLauncherTest.testExtendFXApp(FXLauncherTest.java:350)
  FXLauncherTest.testExtendFXApp(FXLauncherTest.java:323)
  java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
  java.base/java.lang.reflect.Method.invoke(Method.java:578)
  TestHelper.run(TestHelper.java:200)
  FXLauncherTest.main(FXLauncherTest.java:469)
  java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
  java.base/java.lang.reflect.Method.invoke(Method.java:578)
  com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:125)
  java.base/java.lang.Thread.run(Thread.java:1589)
++++End of Test Info++++

ERROR: launcher did not abort properly
Executed command: /home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/images/jdk/bin/java --module-path=mods --add-modules=javafx.graphics -jar /home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/test-support/jtreg_test_jdk_tools_launcher_FXLauncherTest_java/scratch/0/fxtest.jar one two 

###TestError###: string <no main manifest attribute> not found
++++Begin Test Info++++
Test Status: FAIL
++++Test Environment++++
  PATH=/bin:/usr/bin:/usr/sbin
  DISPLAY=:0
  TEST_IMAGE_DIR=/home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/images/test
  _JVM_DWARF_PATH=/home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/images/symbols
  XMODIFIERS=@im=fcitx
  LC_ALL=C
  CLASSPATH=/home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/test-support/jtreg_test_jdk_tools_launcher_FXLauncherTest_java/classes/0/tools/launcher/FXLauncherTest.d:/home/loongson/private/jdk-ls/test/jdk/tools/launcher:/home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/test-support/jtreg_test_jdk_tools_launcher_FXLauncherTest_java/classes/0/test/lib:/home/loongson/private/jdk-ls/test/lib:/home/loongson/public/jtreg/lib/javatest.jar:/home/loongson/public/jtreg/lib/jtreg.jar
  LANG=zh_CN.UTF-8
  HOME=/home/loongson
++++Test Output++++
  Error occurred during initialization of boot layer
  java.lang.module.FindException: Unable to compute the hash of module javafx.graphics
++++Test Stack Trace++++
java.lang.Throwable: current stack of the test
  TestHelper.doExec(TestHelper.java:476)
  TestHelper.doExec(TestHelper.java:437)
  FXLauncherTest.doFxExec(FXLauncherTest.java:252)
  FXLauncherTest.testMissingMC(FXLauncherTest.java:390)
  java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
  java.base/java.lang.reflect.Method.invoke(Method.java:578)
  TestHelper.run(TestHelper.java:200)
  FXLauncherTest.main(FXLauncherTest.java:469)
  java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
  java.base/java.lang.reflect.Method.invoke(Method.java:578)
  com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:125)
  java.base/java.lang.Thread.run(Thread.java:1589)
++++End of Test Info++++

Executed command: /home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/images/jdk/bin/java --module-path=mods --add-modules=javafx.graphics -verbose:class -cp /home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/test-support/jtreg_test_jdk_tools_launcher_FXLauncherTest_java/scratch/0/fxtest.jar helloworld.HelloJava one two 

###TestError###: test did not return 0 exit value
++++Begin Test Info++++
Test Status: FAIL
++++Test Environment++++
  PATH=/bin:/usr/bin:/usr/sbin
  DISPLAY=:0
  TEST_IMAGE_DIR=/home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/images/test
  _JVM_DWARF_PATH=/home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/images/symbols
  XMODIFIERS=@im=fcitx
  LC_ALL=C
  CLASSPATH=/home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/test-support/jtreg_test_jdk_tools_launcher_FXLauncherTest_java/classes/0/tools/launcher/FXLauncherTest.d:/home/loongson/private/jdk-ls/test/jdk/tools/launcher:/home/loongson/private/jdk-ls/build/linux-loongarch64-server-fastdebug/test-support/jtreg_test_jdk_tools_launcher_FXLauncherTest_java/classes/0/test/lib:/home/loongson/private/jdk-ls/test/lib:/home/loongson/public/jtreg/lib/javatest.jar:/home/loongson/public/jtreg/lib/jtreg.jar
  LANG=zh_CN.UTF-8
  HOME=/home/loongson
++++Test Output++++
  [0.016s][info][class,load] java.lang.Object source: shared objects file
  [0.019s][info][class,load] java.io.Serializable source: shared objects file
...


Thanks,
Leslie Zhai

-------------

PR: https://git.openjdk.org/jdk/pull/10299

From mik3hall at gmail.com  Wed Sep 21 02:42:51 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 20 Sep 2022 21:42:51 -0500
Subject: RFR: 8293462: [macos] app image signature invalid when creating
 DMG or PKG from post processed signed image
In-Reply-To: <61218FCB-64AA-4A6E-AF10-FBF7CCD5D971@gmail.com>
References: <-sMR9P3CEZeJ31UFe7bzIcnC86rSErUVbY0GOymUoo4=.7c954bca-25c7-4fa0-9e2a-076ce2a485d4@github.com>
 <20F8AC2D-C71B-4892-A2F3-C9A07501046F@gmail.com>
 <707A13E7-9047-428B-86FA-C4DFA047146C@oracle.com>
 <D847BFBF-6DEE-4F39-8EF8-5E1CF3CE3453@gmail.com>
 <A80F3462-C69A-401D-BD23-26391CD96B8C@gmail.com>
 <61218FCB-64AA-4A6E-AF10-FBF7CCD5D971@gmail.com>
Message-ID: <75051DD2-9987-4E1F-85DE-ACBA472B2C1B@gmail.com>



> On Sep 20, 2022, at 6:04 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> 
>> On Sep 20, 2022, at 5:50 PM, Michael Hall <mik3hall at gmail.com <mailto:mik3hall at gmail.com>> wrote:
>> 
>> Given that this does break that, one possibility might be to include parameter changes in the Info.plist file. Some time back Apple java applications used to include a java dictionary in the plist that was more or less equivalent to the jpackage .cfg file. Maybe a override mechanism could be added to that which would be up to the developer to add in post processing. 
> 
> Never mind on this. That is no different really from the .cfg file and doesn?t help with changing settings on the installed machine, user or system. 

Alexander,

If you don?t mind a little more opinion on this. When I started trying to figure out what to do with application external files on OS/X I began with the ?Application Support? directories. But it occurred to me that most users rarely look at or often possibly aren?t even aware of the ?Application Support? directory. So if I thought if I want the user to look at or actively manage a file I'd put it in their Documents directory. 

I also thought it might be nice going for different file types possibly on different platforms if you didn?t have to think about what would be the best place to put things. So I tried to come up with an API that would determine the locations for me and all I would indicate would be the data type. Like?

public enum DataTypes {
	/**
	 * temporary
	 */
	TEMP,
	/**
	 * log file type
	 */
	LOG,
	/**
	 * cache file type
	 */
	CACHE,
	/**
	 * preferences file type
	 */
	PREFERENCES,
	/**
	 * permanent, critical, not user accessible
	 */
	PERMANENT,
	/**
	 * permanent, non-critical, user accessible
	 */
	USER,
	/**
	 * 
	 * Documents folder
	 */
	DOCUMENTS;
}

Example usages:
// default path
path = Application.getApplication().getFolder(DOCUMENTS).resolve("userprefs.xml?);
Although that pretty obviously resolves to the Documents directory.

Or 
Path logDir = Application.getApplication().getFolder(LOG);

Where the API determines the best location for log files and you don?t have to be concerned.
Not so clear exactly where that might be, but you don?t really have to worry about it.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220920/ee62ecee/attachment-0001.htm>

From dholmes at openjdk.org  Wed Sep 21 06:47:58 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 21 Sep 2022 06:47:58 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v4]
In-Reply-To: <q6ToSabdUIWS0vK-13JWdvQySwco64A_gP20tVsm9FI=.7722abf4-9470-4a52-9f8e-48cb2481eb77@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <ZTzHjlUXhJf5U3PndgGMZUpwbIJhJ0kSxL2am_PfFT8=.4279d477-9a1e-4a2c-b334-90cc60b5592b@github.com>
 <bjXGfmDhmaMyT_j_bQhZLezMj4Jb18w0yhQsYZhlXjU=.d5f0014e-9d6d-4c5f-b84f-5446166bb767@github.com>
 <jhvaxnF1s7-oPaVsF9nf5ko8wP1gBWOo5TfO8T_j40A=.731ea409-ca17-488e-a0b1-3cb15334515a@github.com>
 <q6ToSabdUIWS0vK-13JWdvQySwco64A_gP20tVsm9FI=.7722abf4-9470-4a52-9f8e-48cb2481eb77@github.com>
Message-ID: <babX5XCHpbm-0i8-pwGE7t-8E4suI6kn5k3DAzgnkGs=.66c28495-4492-409f-8bf6-c92f87a153ec@github.com>

On Tue, 20 Sep 2022 16:29:08 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>>> Good to see this finally become non-functional but as long as the debugger/JVMTI can trigger throwing an async ThreadDeath then I have to question the potential change in behaviour introduced by removing all the `catch (ThreadDeath td)` logic in various places.
>> 
>> I've gone through this a few times too and concluded it would be better to remove these untestable code paths. The debugger scenario is more like what used to be Thread.stop(Throwable). It can be used to throw any exception or error, e.g. ask the debugger to throw IllegalArgumentException or SQLException when I'm at this breakpoint so I can see how the code behaves. Yes, the user could ask the debugger to throw java.lang.ThreadDeath when prompted but it's not really interesting now because code won't get this error outside of a debugger. We could leave the special handing but we have no way to test is and we'll need to the remove the special handling when TD is removed.  As a general point, the special casing of TD is a bit inconsistent and more likely to be seen in older code rather newer code. A static analysis of 24M classes found very few usages in 3rd party libraries.
>
> I agree with Alan on this. First, use and handling of `ThreadDeath` is quite rare; see my [analysis](https://bugs.openjdk.org/browse/JDK-8289610?focusedCommentId=14523723&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14523723) of the corpus search results in the bug report. Second, while this does change the behavior in the debugger case, I'm hard-pressed to see how anybody is _relying_ on such behavior. And maybe somebody somewhere is indeed relying on this behavior, but it doesn't seem to me this behavior is guaranteed by any specifications.
> 
> A more likely way that programs could observe changes in `ThreadDeath` handling occurs when programs throw `ThreadDeath` explicitly, that is, not using `Thread.stop`. This does seem to occur infrequently "in the wild" (we'll fix the jshell case). The point of throwing `ThreadDeath` explicitly is to take advantage of special-case handling of `ThreadDeath` that might occur higher in the call stack. Such special-casing was at one time an accepted exception handing idiom, but it's essentially disused. I don't think the JDK needs to continue to support this old idiom.

Okay I will defer to your views here. Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10230

From alanb at openjdk.org  Wed Sep 21 07:13:55 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 Sep 2022 07:13:55 GMT
Subject: RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx
 [v2]
In-Reply-To: <eLkziaKhG6kfuVWg-zc6HxccXS9aL_wTUjOf8G7oR9s=.4892bc1b-fcb0-4e28-9a6d-53f38213665c@github.com>
References: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
 <eLkziaKhG6kfuVWg-zc6HxccXS9aL_wTUjOf8G7oR9s=.4892bc1b-fcb0-4e28-9a6d-53f38213665c@github.com>
Message-ID: <7Wl20-TzHxzQLQyX-dCKoW4sA8nv6e4kZRGp3dlCrrk=.51861f98-b583-4e32-b116-1b9b02ebc930@github.com>

On Sat, 17 Sep 2022 04:03:35 GMT, Leslie Zhai <lzhai at openjdk.org> wrote:

>> Hi,
>> 
>> @dumasun reported the issue:
>> 
>> Configured with jfx-ls-modular-sdk:
>> 
>> 
>> configure --with-import-modules=modular-sdk
>> 
>> 
>> `make run-test CONF=fastdebug TEST="tools/launcher/FXLauncherTest.java"` failed:
>> 
>> 
>> ----------System.err:(11/697)----------
>> java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>>     at FXLauncherTest.main(FXLauncherTest.java:451)
>>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>     at java.base/java.lang.Thread.run(Thread.java:1589)
>> 
>> JavaTest Message: Test threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>> JavaTest Message: shutting down test
>> 
>> STATUS:Failed.`main' threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>> 
>> 
>> Thanks,
>> Leslie Zhai
>
> Leslie Zhai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293910: Try --upgrade-module-path and --patch-module but still failed

The --patch-module option is used to override or add classes/resources in the module, it doesn't override the module definition. I see you tried --upgrade-module-path too but you've set the value to IMPORT_MODULE_DIR and it's not clear what this means in this test.

Can you try this, I think this should do what you want:


--- a/test/jdk/tools/launcher/FXLauncherTest.java
+++ b/test/jdk/tools/launcher/FXLauncherTest.java
@@ -223,7 +223,7 @@ public class FXLauncherTest extends TestHelper {
         compileFXModule();
 
         List<String> fxCompilerArgs = new ArrayList<>();
-        fxCompilerArgs.add("--module-path=" + MODULE_DIR);
+        fxCompilerArgs.add("--upgrade-module-path=" + MODULE_DIR);
         fxCompilerArgs.add("--add-modules=javafx.graphics");
         fxCompilerArgs.addAll(Arrays.asList(compilerArgs));
         compile(fxCompilerArgs.toArray(new String[fxCompilerArgs.size()]));
@@ -232,7 +232,7 @@ public class FXLauncherTest extends TestHelper {
     static TestResult doFxExec(String...cmds) {
         List<String> fxCmds = new ArrayList<>();
         fxCmds.addAll(Arrays.asList(cmds));
-        fxCmds.add(1, "--module-path=" + MODULE_DIR);
+        fxCmds.add(1, "--upgrade-module-path=" + MODULE_DIR);
         fxCmds.add(2, "--add-modules=javafx.graphics");
         return doExec(fxCmds.toArray(new String[fxCmds.size()]));
     }
@@ -439,18 +439,6 @@ public class FXLauncherTest extends TestHelper {
     }
 
     public static void main(String... args) throws Exception {
-
-        // Ensure that FX is not part of jdk
-        Class<?> fxClass = null;
-        try {
-            fxClass = Class.forName(FX_MARKER_CLASS);
-        } catch (ClassNotFoundException ex) {
-            // do nothing
-        }
-        if (fxClass != null) {
-            throw new RuntimeException("JavaFX modules erroneously included in the JDK");
-        }
-
         FXLauncherTest fxt = new FXLauncherTest();
         fxt.run(args);
         if (testExitValue > 0) {

-------------

PR: https://git.openjdk.org/jdk/pull/10299

From duke at openjdk.org  Wed Sep 21 07:41:00 2022
From: duke at openjdk.org (dumasun)
Date: Wed, 21 Sep 2022 07:41:00 GMT
Subject: RFR: 8293977: jdk/modules/etc/VerifyModuleDelegation.java fail
 with jfx
In-Reply-To: <K8keV23DhjOl2iAcpxEGUPEDKfRsrPMwVYf6ZvYV39M=.66a73163-007e-4951-a524-7cf8d5aa1f79@github.com>
References: <K8keV23DhjOl2iAcpxEGUPEDKfRsrPMwVYf6ZvYV39M=.66a73163-007e-4951-a524-7cf8d5aa1f79@github.com>
Message-ID: <Ue9n0-ph8GTgHhdngZIX5Bg5xYeJjZcyD6dP66fej68=.81a3c045-aab2-420d-818d-49d3bc3407e9@github.com>

On Mon, 19 Sep 2022 00:45:32 GMT, Leslie Zhai <lzhai at openjdk.org> wrote:

> Hi,
> 
> @dumasun reported the issue:
> 
> Configured with jfx-ls-modular-sdk:
> 
> 
> configure --with-import-modules=modular-sdk
> 
> 
> `make run-test CONF=fastdebug TEST="jdk/modules/etc/VerifyModuleDelegation.java"` failed:
> 
> 
> ----------System.out:(46/3114)----------
> test VerifyModuleDelegation.checkJavaBase(): success
> test VerifyModuleDelegation.checkLoaderDelegation(): failure
> java.lang.Error: platform/javafx.swing can't delegate to find classes from app/jdk.unsupported.desktop
>     at VerifyModuleDelegation.lambda$checkLoaderDelegation$1(VerifyModuleDelegation.java:77)
>     at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>     at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1921)
>     at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>     at VerifyModuleDelegation.lambda$checkLoaderDelegation$2(VerifyModuleDelegation.java:68)
>     at java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1715)
>     at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>     at VerifyModuleDelegation.checkLoaderDelegation(VerifyModuleDelegation.java:68)
>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>     at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>     at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>     at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>     at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>     at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>     at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>     at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>     at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>     at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
>     at org.testng.TestRunner.privateRun(TestRunner.java:764)
>     at org.testng.TestRunner.run(TestRunner.java:585)
>     at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
>     at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
>     at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
>     at org.testng.SuiteRunner.run(SuiteRunner.java:286)
>     at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
>     at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
>     at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
>     at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
>     at org.testng.TestNG.runSuites(TestNG.java:1069)
>     at org.testng.TestNG.run(TestNG.java:1037)
>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54)
>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>     at java.base/java.lang.Thread.run(Thread.java:1589)
> 
> ===============================================
> jdk/modules/etc/VerifyModuleDelegation.java
> Total tests run: 2, Passes: 1, Failures: 1, Skips: 0
> ===============================================
> 
> ----------System.err:(13/753)----------
> WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.concurrent
> java.lang.Exception: failures: 1
>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96)
>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54)
>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>     at java.base/java.lang.Thread.run(Thread.java:1589)
> 
> 
> Thanks,
> Leslie Zhai

jdk/modules/etc/VerifyModuleDelegation.java has passed for building jfx with the debug patch. 
Thank you very much.


diff --git a/modules/javafx.swing/make/build.properties b/modules/javafx.swing/make/build.properties
index f913584cb4..5d04f77111 100644
--- a/modules/javafx.swing/make/build.properties
+++ b/modules/javafx.swing/make/build.properties
@@ -29,4 +29,4 @@ include_in_jre=true
 include_in_jdk=true
 include_in_jdk_server=false
 include_in_docs=true
-classloader=ext
+classloader=app

-------------

PR: https://git.openjdk.org/jdk/pull/10328

From lzhai at openjdk.org  Wed Sep 21 07:44:45 2022
From: lzhai at openjdk.org (Leslie Zhai)
Date: Wed, 21 Sep 2022 07:44:45 GMT
Subject: RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx
 [v2]
In-Reply-To: <7Wl20-TzHxzQLQyX-dCKoW4sA8nv6e4kZRGp3dlCrrk=.51861f98-b583-4e32-b116-1b9b02ebc930@github.com>
References: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
 <eLkziaKhG6kfuVWg-zc6HxccXS9aL_wTUjOf8G7oR9s=.4892bc1b-fcb0-4e28-9a6d-53f38213665c@github.com>
 <7Wl20-TzHxzQLQyX-dCKoW4sA8nv6e4kZRGp3dlCrrk=.51861f98-b583-4e32-b116-1b9b02ebc930@github.com>
Message-ID: <0eyHzzsdkudvF_9xuO4roXF0eRcKGvnMt7kpO2UCoRw=.fa062f93-1bbc-44bc-a803-9df3bdbfb055@github.com>

On Wed, 21 Sep 2022 07:10:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Leslie Zhai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8293910: Try --upgrade-module-path and --patch-module but still failed
>
> The --patch-module option is used to override or add classes/resources in the module, it doesn't override the module definition. I see you tried --upgrade-module-path too but you've set the value to IMPORT_MODULE_DIR and it's not clear what this means in this test.
> 
> Can you try this, I think this should do what you want:
> 
> 
> --- a/test/jdk/tools/launcher/FXLauncherTest.java
> +++ b/test/jdk/tools/launcher/FXLauncherTest.java
> @@ -223,7 +223,7 @@ public class FXLauncherTest extends TestHelper {
>          compileFXModule();
>  
>          List<String> fxCompilerArgs = new ArrayList<>();
> -        fxCompilerArgs.add("--module-path=" + MODULE_DIR);
> +        fxCompilerArgs.add("--upgrade-module-path=" + MODULE_DIR);
>          fxCompilerArgs.add("--add-modules=javafx.graphics");
>          fxCompilerArgs.addAll(Arrays.asList(compilerArgs));
>          compile(fxCompilerArgs.toArray(new String[fxCompilerArgs.size()]));
> @@ -232,7 +232,7 @@ public class FXLauncherTest extends TestHelper {
>      static TestResult doFxExec(String...cmds) {
>          List<String> fxCmds = new ArrayList<>();
>          fxCmds.addAll(Arrays.asList(cmds));
> -        fxCmds.add(1, "--module-path=" + MODULE_DIR);
> +        fxCmds.add(1, "--upgrade-module-path=" + MODULE_DIR);
>          fxCmds.add(2, "--add-modules=javafx.graphics");
>          return doExec(fxCmds.toArray(new String[fxCmds.size()]));
>      }
> @@ -439,18 +439,6 @@ public class FXLauncherTest extends TestHelper {
>      }
>  
>      public static void main(String... args) throws Exception {
> -
> -        // Ensure that FX is not part of jdk
> -        Class<?> fxClass = null;
> -        try {
> -            fxClass = Class.forName(FX_MARKER_CLASS);
> -        } catch (ClassNotFoundException ex) {
> -            // do nothing
> -        }
> -        if (fxClass != null) {
> -            throw new RuntimeException("JavaFX modules erroneously included in the JDK");
> -        }
> -
>          FXLauncherTest fxt = new FXLauncherTest();
>          fxt.run(args);
>          if (testExitValue > 0) {

Hi @AlanBateman 

Debug patch:


diff --git a/test/jdk/tools/launcher/FXLauncherTest.java b/test/jdk/tools/launcher/FXLauncherTest.java
index 9cc4b5aea98..33c3e2788ad 100644
--- a/test/jdk/tools/launcher/FXLauncherTest.java
+++ b/test/jdk/tools/launcher/FXLauncherTest.java
@@ -223,7 +223,7 @@ public class FXLauncherTest extends TestHelper {
         compileFXModule();
 
         List<String> fxCompilerArgs = new ArrayList<>();
-        fxCompilerArgs.add("--module-path=" + MODULE_DIR);
+        fxCompilerArgs.add("--upgrade-module-path=" + MODULE_DIR);
         fxCompilerArgs.add("--add-modules=javafx.graphics");
         fxCompilerArgs.addAll(Arrays.asList(compilerArgs));
         compile(fxCompilerArgs.toArray(new String[fxCompilerArgs.size()]));
@@ -232,7 +232,7 @@ public class FXLauncherTest extends TestHelper {
     static TestResult doFxExec(String...cmds) {
         List<String> fxCmds = new ArrayList<>();
         fxCmds.addAll(Arrays.asList(cmds));
-        fxCmds.add(1, "--module-path=" + MODULE_DIR);
+        fxCmds.add(1, "--upgrade-module-path=" + MODULE_DIR);
         fxCmds.add(2, "--add-modules=javafx.graphics");
         return doExec(fxCmds.toArray(new String[fxCmds.size()]));
     }
@@ -439,18 +439,6 @@ public class FXLauncherTest extends TestHelper {
     }
 
     public static void main(String... args) throws Exception {
-
-        // Ensure that FX is not part of jdk
-        Class<?> fxClass = null;
-        try {
-            fxClass = Class.forName(FX_MARKER_CLASS);
-        } catch (ClassNotFoundException ex) {
-            // do nothing
-        }
-        if (fxClass != null) {
-            throw new RuntimeException("JavaFX modules erroneously included in the JDK");
-        }
-
         FXLauncherTest fxt = new FXLauncherTest();
         fxt.run(args);
         if (testExitValue > 0) {


Still failed:  [debug.log](https://github.com/openjdk/jdk/files/9614161/debug.log)

Thanks,
Leslie Zhai

-------------

PR: https://git.openjdk.org/jdk/pull/10299

From lzhai at openjdk.org  Wed Sep 21 07:48:35 2022
From: lzhai at openjdk.org (Leslie Zhai)
Date: Wed, 21 Sep 2022 07:48:35 GMT
Subject: RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx
 [v2]
In-Reply-To: <7Wl20-TzHxzQLQyX-dCKoW4sA8nv6e4kZRGp3dlCrrk=.51861f98-b583-4e32-b116-1b9b02ebc930@github.com>
References: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
 <eLkziaKhG6kfuVWg-zc6HxccXS9aL_wTUjOf8G7oR9s=.4892bc1b-fcb0-4e28-9a6d-53f38213665c@github.com>
 <7Wl20-TzHxzQLQyX-dCKoW4sA8nv6e4kZRGp3dlCrrk=.51861f98-b583-4e32-b116-1b9b02ebc930@github.com>
Message-ID: <93Z70fHZVluqyZp5lKkJG8Qe55zPYKCEdTfgmJMV6xU=.13428b6b-9396-4e0c-b890-56817a21ae50@github.com>

On Wed, 21 Sep 2022 07:10:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> but you've set the value to IMPORT_MODULE_DIR and it's not clear what this means in this test

I just want to try the imported javafx modules:


--patch-module=javafx.graphics=build/linux-loongarch64-server-fastdebug/images/jdk/jmods/javafx.graphics.jmod

-------------

PR: https://git.openjdk.org/jdk/pull/10299

From alanb at openjdk.org  Wed Sep 21 07:48:37 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 Sep 2022 07:48:37 GMT
Subject: RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx
 [v2]
In-Reply-To: <eLkziaKhG6kfuVWg-zc6HxccXS9aL_wTUjOf8G7oR9s=.4892bc1b-fcb0-4e28-9a6d-53f38213665c@github.com>
References: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
 <eLkziaKhG6kfuVWg-zc6HxccXS9aL_wTUjOf8G7oR9s=.4892bc1b-fcb0-4e28-9a6d-53f38213665c@github.com>
Message-ID: <pVbQSMCMqSvuQaoI-qJUPNRwpawwvH-hgjTebjCytKQ=.dd60966c-4b03-4719-a663-2a81fdfe4104@github.com>

On Sat, 17 Sep 2022 04:03:35 GMT, Leslie Zhai <lzhai at openjdk.org> wrote:

>> Hi,
>> 
>> @dumasun reported the issue:
>> 
>> Configured with jfx-ls-modular-sdk:
>> 
>> 
>> configure --with-import-modules=modular-sdk
>> 
>> 
>> `make run-test CONF=fastdebug TEST="tools/launcher/FXLauncherTest.java"` failed:
>> 
>> 
>> ----------System.err:(11/697)----------
>> java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>>     at FXLauncherTest.main(FXLauncherTest.java:451)
>>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>     at java.base/java.lang.Thread.run(Thread.java:1589)
>> 
>> JavaTest Message: Test threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>> JavaTest Message: shutting down test
>> 
>> STATUS:Failed.`main' threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>> 
>> 
>> Thanks,
>> Leslie Zhai
>
> Leslie Zhai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293910: Try --upgrade-module-path and --patch-module but still failed

I've created JDK-8294093 to track changing ReadSingleImportMetaData (in Modules.gmk) to ignore the mapping in build.properties. If nothing else, that will avoid surprises that will otherwise arise if you run jlink to create a run-time image that includes the javafx.* modules; when you run jlink then it does not map unknown modules to the boot or platform class loader so they will be mapped to the application class loader.

The other aspect to this is whether javafx.* modules should be upgradable. The build adds the imported modules PLATFORM_MODULES but not UPGRADEABLE_PLATFORM_MODULES so this means they will be treated as if they are strongly coupled with the platform/JDK modules and hashed, which probably isn't right here.

-------------

PR: https://git.openjdk.org/jdk/pull/10299

From alanb at openjdk.org  Wed Sep 21 07:52:03 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 Sep 2022 07:52:03 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v4]
In-Reply-To: <babX5XCHpbm-0i8-pwGE7t-8E4suI6kn5k3DAzgnkGs=.66c28495-4492-409f-8bf6-c92f87a153ec@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <ZTzHjlUXhJf5U3PndgGMZUpwbIJhJ0kSxL2am_PfFT8=.4279d477-9a1e-4a2c-b334-90cc60b5592b@github.com>
 <bjXGfmDhmaMyT_j_bQhZLezMj4Jb18w0yhQsYZhlXjU=.d5f0014e-9d6d-4c5f-b84f-5446166bb767@github.com>
 <jhvaxnF1s7-oPaVsF9nf5ko8wP1gBWOo5TfO8T_j40A=.731ea409-ca17-488e-a0b1-3cb15334515a@github.com>
 <q6ToSabdUIWS0vK-13JWdvQySwco64A_gP20tVsm9FI=.7722abf4-9470-4a52-9f8e-48cb2481eb77@github.com>
 <babX5XCHpbm-0i8-pwGE7t-8E4suI6kn5k3DAzgnkGs=.66c28495-4492-409f-8bf6-c92f87a153ec@github.com>
Message-ID: <Nmq49Pi6YsAZQTWFK3729Iyyd6XCdVvCYlKFbETzv0U=.daeca85f-2d9e-4c02-af56-0754165b6466@github.com>

On Wed, 21 Sep 2022 06:43:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Okay I will defer to your views here. Thanks.

Thank you, I'll get the CSR moving again and we'll try to get this done.

-------------

PR: https://git.openjdk.org/jdk/pull/10230

From lzhai at openjdk.org  Wed Sep 21 07:52:54 2022
From: lzhai at openjdk.org (Leslie Zhai)
Date: Wed, 21 Sep 2022 07:52:54 GMT
Subject: RFR: 8293977: jdk/modules/etc/VerifyModuleDelegation.java fail
 with jfx
In-Reply-To: <uUAL_VrLHEuwOAc41MdzAy6ktRphzJfl2fa9ISkLYzU=.855083b1-04c4-49e9-97e3-e9598e1b5ae8@github.com>
References: <K8keV23DhjOl2iAcpxEGUPEDKfRsrPMwVYf6ZvYV39M=.66a73163-007e-4951-a524-7cf8d5aa1f79@github.com>
 <uUAL_VrLHEuwOAc41MdzAy6ktRphzJfl2fa9ISkLYzU=.855083b1-04c4-49e9-97e3-e9598e1b5ae8@github.com>
Message-ID: <zkpfVyQ3jTmXlqr2SSPAkmVRQyeW5o84kyyQfaHzaOQ=.a66cf084-7ccb-471c-a36b-d8203f349ab6@github.com>

On Tue, 20 Sep 2022 14:11:55 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Hi,
>> 
>> @dumasun reported the issue:
>> 
>> Configured with jfx-ls-modular-sdk:
>> 
>> 
>> configure --with-import-modules=modular-sdk
>> 
>> 
>> `make run-test CONF=fastdebug TEST="jdk/modules/etc/VerifyModuleDelegation.java"` failed:
>> 
>> 
>> ----------System.out:(46/3114)----------
>> test VerifyModuleDelegation.checkJavaBase(): success
>> test VerifyModuleDelegation.checkLoaderDelegation(): failure
>> java.lang.Error: platform/javafx.swing can't delegate to find classes from app/jdk.unsupported.desktop
>>     at VerifyModuleDelegation.lambda$checkLoaderDelegation$1(VerifyModuleDelegation.java:77)
>>     at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>>     at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1921)
>>     at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>>     at VerifyModuleDelegation.lambda$checkLoaderDelegation$2(VerifyModuleDelegation.java:68)
>>     at java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1715)
>>     at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>>     at VerifyModuleDelegation.checkLoaderDelegation(VerifyModuleDelegation.java:68)
>>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>>     at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>>     at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>>     at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>>     at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>>     at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>>     at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>>     at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>>     at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>>     at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
>>     at org.testng.TestRunner.privateRun(TestRunner.java:764)
>>     at org.testng.TestRunner.run(TestRunner.java:585)
>>     at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
>>     at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
>>     at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
>>     at org.testng.SuiteRunner.run(SuiteRunner.java:286)
>>     at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
>>     at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
>>     at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
>>     at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
>>     at org.testng.TestNG.runSuites(TestNG.java:1069)
>>     at org.testng.TestNG.run(TestNG.java:1037)
>>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
>>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54)
>>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>     at java.base/java.lang.Thread.run(Thread.java:1589)
>> 
>> ===============================================
>> jdk/modules/etc/VerifyModuleDelegation.java
>> Total tests run: 2, Passes: 1, Failures: 1, Skips: 0
>> ===============================================
>> 
>> ----------System.err:(13/753)----------
>> WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.concurrent
>> java.lang.Exception: failures: 1
>>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96)
>>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54)
>>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>     at java.base/java.lang.Thread.run(Thread.java:1589)
>> 
>> 
>> Thanks,
>> Leslie Zhai
>
> In that case, a solution might be to remove `ext` from the `classloader` property from all of the `modules/javafx.*/make/build.properties` files in JavaFX:
> 
> 
> classloader=
> 
> 
> or
> 
> 
> classloader=app

Hi @kevinrushforth 

> In that case, a solution might be to remove ext from the classloader property from all of the modules/javafx.*/make/build.properties files in JavaFX:

Thanks for your patch!

So I will close this PR.  Then create a new PR for the jfx repository instead.

Also thank @dumasun for your good job!

Cheers,
Leslie Zhai

-------------

PR: https://git.openjdk.org/jdk/pull/10328

From lzhai at openjdk.org  Wed Sep 21 07:52:55 2022
From: lzhai at openjdk.org (Leslie Zhai)
Date: Wed, 21 Sep 2022 07:52:55 GMT
Subject: Withdrawn: 8293977: jdk/modules/etc/VerifyModuleDelegation.java fail
 with jfx
In-Reply-To: <K8keV23DhjOl2iAcpxEGUPEDKfRsrPMwVYf6ZvYV39M=.66a73163-007e-4951-a524-7cf8d5aa1f79@github.com>
References: <K8keV23DhjOl2iAcpxEGUPEDKfRsrPMwVYf6ZvYV39M=.66a73163-007e-4951-a524-7cf8d5aa1f79@github.com>
Message-ID: <4L4iFUPnRIXiNuMAmQFb_Ask0wmEAQNNrN4F8IwwPn0=.427a1913-b6e7-44e0-9c39-886ca32a3874@github.com>

On Mon, 19 Sep 2022 00:45:32 GMT, Leslie Zhai <lzhai at openjdk.org> wrote:

> Hi,
> 
> @dumasun reported the issue:
> 
> Configured with jfx-ls-modular-sdk:
> 
> 
> configure --with-import-modules=modular-sdk
> 
> 
> `make run-test CONF=fastdebug TEST="jdk/modules/etc/VerifyModuleDelegation.java"` failed:
> 
> 
> ----------System.out:(46/3114)----------
> test VerifyModuleDelegation.checkJavaBase(): success
> test VerifyModuleDelegation.checkLoaderDelegation(): failure
> java.lang.Error: platform/javafx.swing can't delegate to find classes from app/jdk.unsupported.desktop
>     at VerifyModuleDelegation.lambda$checkLoaderDelegation$1(VerifyModuleDelegation.java:77)
>     at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>     at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1921)
>     at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>     at VerifyModuleDelegation.lambda$checkLoaderDelegation$2(VerifyModuleDelegation.java:68)
>     at java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1715)
>     at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>     at VerifyModuleDelegation.checkLoaderDelegation(VerifyModuleDelegation.java:68)
>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>     at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>     at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>     at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>     at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>     at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>     at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>     at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>     at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>     at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
>     at org.testng.TestRunner.privateRun(TestRunner.java:764)
>     at org.testng.TestRunner.run(TestRunner.java:585)
>     at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
>     at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
>     at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
>     at org.testng.SuiteRunner.run(SuiteRunner.java:286)
>     at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
>     at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
>     at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
>     at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
>     at org.testng.TestNG.runSuites(TestNG.java:1069)
>     at org.testng.TestNG.run(TestNG.java:1037)
>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54)
>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>     at java.base/java.lang.Thread.run(Thread.java:1589)
> 
> ===============================================
> jdk/modules/etc/VerifyModuleDelegation.java
> Total tests run: 2, Passes: 1, Failures: 1, Skips: 0
> ===============================================
> 
> ----------System.err:(13/753)----------
> WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.concurrent
> java.lang.Exception: failures: 1
>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96)
>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54)
>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>     at java.base/java.lang.Thread.run(Thread.java:1589)
> 
> 
> Thanks,
> Leslie Zhai

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/10328

From alanb at openjdk.org  Wed Sep 21 08:00:44 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 Sep 2022 08:00:44 GMT
Subject: RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx
 [v2]
In-Reply-To: <0eyHzzsdkudvF_9xuO4roXF0eRcKGvnMt7kpO2UCoRw=.fa062f93-1bbc-44bc-a803-9df3bdbfb055@github.com>
References: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
 <eLkziaKhG6kfuVWg-zc6HxccXS9aL_wTUjOf8G7oR9s=.4892bc1b-fcb0-4e28-9a6d-53f38213665c@github.com>
 <7Wl20-TzHxzQLQyX-dCKoW4sA8nv6e4kZRGp3dlCrrk=.51861f98-b583-4e32-b116-1b9b02ebc930@github.com>
 <0eyHzzsdkudvF_9xuO4roXF0eRcKGvnMt7kpO2UCoRw=.fa062f93-1bbc-44bc-a803-9df3bdbfb055@github.com>
Message-ID: <pOagnwFGM5M8Ybt6agPZNC4FztXhKTE3xkkoBkzexkA=.c06f15f3-e51d-4e40-91c0-0577a8924e00@github.com>

On Wed, 21 Sep 2022 07:42:29 GMT, Leslie Zhai <lzhai at openjdk.org> wrote:

> Still failed: [debug.log](https://github.com/openjdk/jdk/files/9614161/debug.log)

You are running into module hashes now so I think you'll need some of JDK-8294093. In make/common/Modules.gmk ReadSingleImportMetaData can you add

   UPGRADEABLE_PLATFORM_MODULES += $1

This will add the names of the imported modules to the list of upgradeable modules and should mean they are not hashed.

-------------

PR: https://git.openjdk.org/jdk/pull/10299

From lzhai at openjdk.org  Wed Sep 21 08:00:44 2022
From: lzhai at openjdk.org (Leslie Zhai)
Date: Wed, 21 Sep 2022 08:00:44 GMT
Subject: RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx
 [v2]
In-Reply-To: <pOagnwFGM5M8Ybt6agPZNC4FztXhKTE3xkkoBkzexkA=.c06f15f3-e51d-4e40-91c0-0577a8924e00@github.com>
References: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
 <eLkziaKhG6kfuVWg-zc6HxccXS9aL_wTUjOf8G7oR9s=.4892bc1b-fcb0-4e28-9a6d-53f38213665c@github.com>
 <7Wl20-TzHxzQLQyX-dCKoW4sA8nv6e4kZRGp3dlCrrk=.51861f98-b583-4e32-b116-1b9b02ebc930@github.com>
 <0eyHzzsdkudvF_9xuO4roXF0eRcKGvnMt7kpO2UCoRw=.fa062f93-1bbc-44bc-a803-9df3bdbfb055@github.com>
 <pOagnwFGM5M8Ybt6agPZNC4FztXhKTE3xkkoBkzexkA=.c06f15f3-e51d-4e40-91c0-0577a8924e00@github.com>
Message-ID: <BYsEf2SHnwj49eNqN5fEAxdv1QGhgYJIQygSvlMYwr4=.e90a1e85-78ea-4054-b1ef-37ddb6fe789e@github.com>

On Wed, 21 Sep 2022 07:56:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi @AlanBateman 
>> 
>> Debug patch:
>> 
>> 
>> diff --git a/test/jdk/tools/launcher/FXLauncherTest.java b/test/jdk/tools/launcher/FXLauncherTest.java
>> index 9cc4b5aea98..33c3e2788ad 100644
>> --- a/test/jdk/tools/launcher/FXLauncherTest.java
>> +++ b/test/jdk/tools/launcher/FXLauncherTest.java
>> @@ -223,7 +223,7 @@ public class FXLauncherTest extends TestHelper {
>>          compileFXModule();
>>  
>>          List<String> fxCompilerArgs = new ArrayList<>();
>> -        fxCompilerArgs.add("--module-path=" + MODULE_DIR);
>> +        fxCompilerArgs.add("--upgrade-module-path=" + MODULE_DIR);
>>          fxCompilerArgs.add("--add-modules=javafx.graphics");
>>          fxCompilerArgs.addAll(Arrays.asList(compilerArgs));
>>          compile(fxCompilerArgs.toArray(new String[fxCompilerArgs.size()]));
>> @@ -232,7 +232,7 @@ public class FXLauncherTest extends TestHelper {
>>      static TestResult doFxExec(String...cmds) {
>>          List<String> fxCmds = new ArrayList<>();
>>          fxCmds.addAll(Arrays.asList(cmds));
>> -        fxCmds.add(1, "--module-path=" + MODULE_DIR);
>> +        fxCmds.add(1, "--upgrade-module-path=" + MODULE_DIR);
>>          fxCmds.add(2, "--add-modules=javafx.graphics");
>>          return doExec(fxCmds.toArray(new String[fxCmds.size()]));
>>      }
>> @@ -439,18 +439,6 @@ public class FXLauncherTest extends TestHelper {
>>      }
>>  
>>      public static void main(String... args) throws Exception {
>> -
>> -        // Ensure that FX is not part of jdk
>> -        Class<?> fxClass = null;
>> -        try {
>> -            fxClass = Class.forName(FX_MARKER_CLASS);
>> -        } catch (ClassNotFoundException ex) {
>> -            // do nothing
>> -        }
>> -        if (fxClass != null) {
>> -            throw new RuntimeException("JavaFX modules erroneously included in the JDK");
>> -        }
>> -
>>          FXLauncherTest fxt = new FXLauncherTest();
>>          fxt.run(args);
>>          if (testExitValue > 0) {
>> 
>> 
>> Still failed:  [debug.log](https://github.com/openjdk/jdk/files/9614161/debug.log)
>> 
>> Thanks,
>> Leslie Zhai
>
>> Still failed: [debug.log](https://github.com/openjdk/jdk/files/9614161/debug.log)
> 
> You are running into module hashes now so I think you'll need some of JDK-8294093. In make/common/Modules.gmk ReadSingleImportMetaData can you add
> 
>    UPGRADEABLE_PLATFORM_MODULES += $1
> 
> This will add the names of the imported modules to the list of upgradeable modules and should mean they are not hashed.

Hi @AlanBateman 

> I've created JDK-8294093 to track changing ReadSingleImportMetaData (in Modules.gmk) to ignore the mapping in build.properties

Thanks for your report!

So 8293977: jdk/modules/etc/VerifyModuleDelegation.java fail with jfx could be fixed too.

> --with-import-modules option was used in JDK 9/10 for co-bundling JavaFX with the JDK. It seems this configure option is still in use, by some.

Yes, @dumasun use it :)

Thanks,
Leslie Zhai

-------------

PR: https://git.openjdk.org/jdk/pull/10299

From mbaesken at openjdk.org  Wed Sep 21 08:18:55 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 21 Sep 2022 08:18:55 GMT
Subject: RFR: JDK-8293701: jdeps InverseDepsAnalyzer runs into
 NoSuchElementException: No value present
In-Reply-To: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
References: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
Message-ID: <c8XuT5Mfk1Wja7fbBsepkZPAdvz1AIYULb2qhzXW1So=.ee973953-070a-4447-8c31-f1cc69170db8@github.com>

On Fri, 16 Sep 2022 08:26:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We noticed that with certain jar file input, jdeps runs into the following exception, this happens with jdk11, 17 and 20.
> 
> jdeps.exe --multi-release 11 --module-path . --inverse --package com.sap.nw.performance.supa.client test.jar
> 
> Inverse transitive dependences matching packages [com.sap.nw.performance.supa.client]
> Exception in thread "main" java.util.NoSuchElementException: No value present
>         at java.base/java.util.Optional.get(Optional.java:148)
>         at jdk.jdeps/com.sun.tools.jdeps.InverseDepsAnalyzer.lambda$inverseDependences$2(InverseDepsAnalyzer.java:150)
>         at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>         at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>         at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
>         at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>         at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> 
> So an additional  check might be a good idea.

Hi Alan, Mandy so far I unfortunately do not have the sources.

Here are as far as I can see the most important jars, with module descriptions.
I wondered about the com.sap.nw.performance.commons  requires - I did not notice and export for this one, looked a bit strange to me (this should have been in performance-commons.jar at least the authors told me so ...

supa_jdeps/SUPA/lib> jdk/images/jdk/bin/jar --file=supa-client.jar  --describe-module
com.sap.nw.performance.supa.client jar:file:///supa_jdeps/SUPA/lib/supa-client.jar!/module-info.class
exports com.sap.nw.performance.supa.automation
requires com.sap.nw.performance.commons transitive
requires com.sap.nw.performance.supa.api transitive
requires com.sap.nw.performance.supa.base transitive
requires java.base mandated
requires java.logging transitive
qualified exports com.sap.nw.performance.supa.automation.implementation to supa.tests
opens com.sap.nw.performance.supa.automation


supa_jdeps/SUPA/lib> jdk/images/jdk/bin/jar --file=supa-base.jar  --describe-module
com.sap.nw.performance.supa.base jar:file:///test/SUPA/lib/supa-base.jar!/module-info.class
exports com.sap.nw.performance.supa.base
exports com.sap.nw.performance.supa.base.command
exports com.sap.nw.performance.supa.base.config
exports com.sap.nw.performance.supa.base.cpuinfo
exports com.sap.nw.performance.supa.base.http
exports com.sap.nw.performance.supa.base.io
exports com.sap.nw.performance.supa.base.processinfo
exports com.sap.nw.performance.supa.base.processinfo.os
exports com.sap.nw.performance.supa.base.system
exports com.sap.nw.performance.supa.base.time
exports com.sap.nw.performance.supa.base.utils
exports com.sap.nw.performance.supa.base.utils.file
requires JNativeHook transitive
requires com.github.spotbugs.annotations static
requires com.google.common transitive
requires com.google.gson transitive
requires com.sap.nw.performance.commons transitive
requires com.sap.nw.performance.supa.api transitive
requires ecs transitive
requires java.base mandated
requires java.desktop transitive
requires java.net.http transitive
requires org.apache.commons.collections4 transitive
requires org.apache.commons.text transitive
requires org.apache.httpcomponents.httpclient transitive
requires org.apache.httpcomponents.httpcore transitive
requires org.apache.httpcomponents.httpmime transitive
qualified exports com.sap.nw.performance.supa.base.cpuinfo.os to supa.tests


supa_jdeps/SUPA/lib> jdk/images/jdk/bin/jar --file=supa-api.jar  --describe-module
com.sap.nw.performance.supa.api jar:file:///supa_jdeps/SUPA/lib/supa-api.jar!/module-info.class
exports com.sap.nw.performance.supa.api
exports com.sap.nw.performance.supa.api.config
exports com.sap.nw.performance.supa.api.manager.state
exports com.sap.nw.performance.supa.api.processinfo
exports com.sap.nw.performance.supa.api.processprofiler
requires com.sap.nw.performance.commons transitive
requires java.base mandated

supa_jdeps/SUPA/lib> jdk/images/jdk/bin/jar --file=performance-commons.jar  --describe-module
com.sap.nw.performance.commons jar:file:///supa_jdeps/SUPA/lib/performance-commons.jar!/module-info.class
exports com.sap.nw.performance.commons.command
exports com.sap.nw.performance.commons.config
exports com.sap.nw.performance.commons.exceptions
exports com.sap.nw.performance.commons.outlier
exports com.sap.nw.performance.commons.remote
exports com.sap.nw.performance.commons.remote.command
exports com.sap.nw.performance.commons.results
exports com.sap.nw.performance.commons.utils
exports com.sap.nw.performance.commons.utils.html
exports com.sap.nw.performance.commons.utils.http
exports com.sap.nw.performance.commons.utils.jdsr
exports com.sap.nw.performance.commons.utils.net
exports com.sap.nw.performance.commons.utils.path
exports com.sap.nw.performance.commons.utils.zip
exports com.sap.nw.performance.limits
exports com.sap.nw.performance.measrules
exports com.sap.nw.performance.measrules.rule
requires client.combined
requires com.github.spotbugs.annotations static
requires com.google.gson
requires commons.cli transitive
requires commons.configuration transitive
requires commons.lang transitive
requires java.base mandated
requires java.desktop
requires java.management
requires java.scripting
requires java.sql transitive
requires junit static
requires mustache.compiler
requires opencsv
requires org.apache.commons.io transitive
requires org.apache.commons.lang3
requires org.apache.commons.text
requires org.apache.derby.client static
requires org.apache.derby.engine static
requires org.apache.derby.tools static
requires org.objectweb.asm
requires org.objectweb.asm.commons
requires org.objectweb.asm.tree
requires org.objectweb.asm.tree.analysis
requires org.objectweb.asm.util
requires org.openjdk.nashorn
opens com.sap.nw.performance.measrules

-------------

PR: https://git.openjdk.org/jdk/pull/10300

From ihse at openjdk.org  Wed Sep 21 08:26:49 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 21 Sep 2022 08:26:49 GMT
Subject: Integrated: 8294076: Improve ant detection in idea.sh
In-Reply-To: <9zPqCRX8ILNFC9XSfBGuvYBpQDAOMgnhRSELs74gcuI=.bfeee290-c24a-4620-b53d-03f2c689aee0@github.com>
References: <9zPqCRX8ILNFC9XSfBGuvYBpQDAOMgnhRSELs74gcuI=.bfeee290-c24a-4620-b53d-03f2c689aee0@github.com>
Message-ID: <Qws6TNglK0XCoBB8qi7pDDNJ4qBzw7FVvjCnxREVReA=.8149e720-1d58-4d51-a4c1-31a85a49d759@github.com>

On Tue, 20 Sep 2022 21:45:05 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The ant detection in bin/idea.sh is very rudimentary. It fails at a modern aarch64 macOS installation.

This pull request has now been integrated.

Changeset: 8d1dd6a6
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8d1dd6a6cf2bc11e0cf5ac3600e78dc192a819e4
Stats:     23 lines in 1 file changed: 14 ins; 0 del; 9 mod

8294076: Improve ant detection in idea.sh

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/jdk/pull/10364

From ihse at openjdk.org  Wed Sep 21 08:37:47 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 21 Sep 2022 08:37:47 GMT
Subject: RFR: 8293977: jdk/modules/etc/VerifyModuleDelegation.java fail
 with jfx
In-Reply-To: <2ddyCr8skoTc3z5FqEn7Tle-UZI2Q9d0mh8cXbT1mGc=.7c737f00-2197-4c5a-bbf4-c6ea1fb1aa41@github.com>
References: <K8keV23DhjOl2iAcpxEGUPEDKfRsrPMwVYf6ZvYV39M=.66a73163-007e-4951-a524-7cf8d5aa1f79@github.com>
 <UmwA4scrMxXQ4QbOoZHzR-PNH0c9nNg_dL4OhdRaIvA=.135d9044-ad31-4cea-90ec-1b453c58c1aa@github.com>
 <2ddyCr8skoTc3z5FqEn7Tle-UZI2Q9d0mh8cXbT1mGc=.7c737f00-2197-4c5a-bbf4-c6ea1fb1aa41@github.com>
Message-ID: <106sxrVWYWuH2tRT0g8A8sQSz5VIFn7rwS1QrZiIaV0=.e984c682-e49d-4558-959b-42b05b009470@github.com>

On Tue, 20 Sep 2022 12:35:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I haven't built a JDK using the `--with-import-modules` to include the `javafx.*` modules in quite a while, but my recollection is that yes, that did cause the JavaFX modules to be loaded by the platform class loader. The following is defined in the [`build.properties`](https://github.com/openjdk/jfx/blob/master/modules/javafx.swing/make/build.properties#L32) file for the `javafx.swing` module (as well as all other JavaFX modules), which is used by the JDK build when using `--with-import-modules`:
>> 
>> 
>> classloader=ext
>> 
>> 
>> I would guess that `ext` (which used to stand for the extension class loader) is causing it be included in the list of modules that are loaded by the platform class loader, but that needs to be checked.
>
>> I haven't built a JDK using the `--with-import-modules` to include the `javafx.*` modules in quite a while, but my recollection is that yes, that did cause the JavaFX modules to be loaded by the platform class loader. The following is defined in the [`build.properties`](https://github.com/openjdk/jfx/blob/master/modules/javafx.swing/make/build.properties#L32) file for the `javafx.swing` module (as well as all other JavaFX modules), which is used by the JDK build when using `--with-import-modules`:
>> 
>> ```
>> classloader=ext
>> ```
> 
> Thanks for this. In make/common/Modules.gmk, ReadSingleImportMetaData is adding to PLATFORM_MODULES. So I think this needs to re-examined as there should be no reason to have imported modules mapped to the boot or platform class loaders now.

@AlanBateman While this particular issue was closed now, this is perhaps yet another indication that the "import modules" thing is causing problems, and should be removed now that it is not used anymore. I created [JDK-8294095](https://bugs.openjdk.org/browse/JDK-8294095) to explore this possibility.

-------------

PR: https://git.openjdk.org/jdk/pull/10328

From asotona at openjdk.org  Wed Sep 21 08:41:43 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 21 Sep 2022 08:41:43 GMT
Subject: RFR: 8294062: Improve parsing performance of j.l.c.MethodTypeDesc
In-Reply-To: <VDvbC1TFiKQEVZE9c_QP8jUBcBV1EmLFUDMGTVUrkpU=.46770485-1955-458b-9650-6a182b06a309@github.com>
References: <Q0iEUit9CcB8dvFJUMCKQoSYx51BJ75Mejv-pGcl2OI=.f1a538b0-2d74-4c2c-a50d-ba70d64d84da@github.com>
 <VDvbC1TFiKQEVZE9c_QP8jUBcBV1EmLFUDMGTVUrkpU=.46770485-1955-458b-9650-6a182b06a309@github.com>
Message-ID: <HNrMTCC8HTw4rxDajf0aNKDmehbLhtQ6H8rBe8e-qP8=.db17d330-8ec4-4884-9ddd-f30c3c9b4a68@github.com>

On Tue, 20 Sep 2022 16:54:27 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Parsing performance of `j.l.c.MethodTypeDescriptor::ofDescriptor` can be significantly improved and add performance boost to intensive users.
>> 
>> Two main reasons have been identified and fixed in this patch:
>> 
>> First glitch is late insertion of return type to the first position of `j.u.ArrayList`, causing all previously parsed parameter types to shift using `System::arraycopy`.
>> 
>> Proposed patch inserts a placeholder for the return type first and replaces it with return type later.
>> 
>> Second performance degradation is in `MethodTypeDescriptor::skipOverFieldSignature`, where each identified class descriptor is exactly located by `String::indexOf`, extracted by `String::substring`, and passed for for the purpose of verification to `ConstantUtils::verifyUnqualifiedClassName`.
>> 
>> Proposed patch inlines the unqualified class name verification into `ConstantUtils::skipOverFieldSignature` parsing loop and so eliminates calls of `String::indexOf` and `String::substring`. Package private method `ConstantUtils::verifyUnqualifiedClassName` has no other use within the package, so it is removed.
>> 
>> Please review proposed performance improving patch.
>> 
>> Thanks,
>> Adam
>
> src/java.base/share/classes/java/lang/constant/ConstantUtils.java line 217:
> 
>> 215:                             }
>> 216:                             case '/' -> {
>> 217:                                 if (!legal) return 0;
> 
> IIUC that works to reject `//` and trailing `/`, but does not reject leading `/`? which the previous code rejected.

`legal` is initially set to false, so leading `/` is also rejected

-------------

PR: https://git.openjdk.org/jdk/pull/10358

From lzhai at openjdk.org  Wed Sep 21 08:46:09 2022
From: lzhai at openjdk.org (Leslie Zhai)
Date: Wed, 21 Sep 2022 08:46:09 GMT
Subject: RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx
 [v2]
In-Reply-To: <pOagnwFGM5M8Ybt6agPZNC4FztXhKTE3xkkoBkzexkA=.c06f15f3-e51d-4e40-91c0-0577a8924e00@github.com>
References: <x_0QVFGeo9djDUp3ttexIRTRLGKPXp9ZeI1KKD_i-a8=.a96ab992-5a38-4540-ada9-2fb442a616d3@github.com>
 <eLkziaKhG6kfuVWg-zc6HxccXS9aL_wTUjOf8G7oR9s=.4892bc1b-fcb0-4e28-9a6d-53f38213665c@github.com>
 <7Wl20-TzHxzQLQyX-dCKoW4sA8nv6e4kZRGp3dlCrrk=.51861f98-b583-4e32-b116-1b9b02ebc930@github.com>
 <0eyHzzsdkudvF_9xuO4roXF0eRcKGvnMt7kpO2UCoRw=.fa062f93-1bbc-44bc-a803-9df3bdbfb055@github.com>
 <pOagnwFGM5M8Ybt6agPZNC4FztXhKTE3xkkoBkzexkA=.c06f15f3-e51d-4e40-91c0-0577a8924e00@github.com>
Message-ID: <pfGdbojtkG_eyNHmsM5Ec_CIWWYTLBD6a8troCBOZd8=.2dd3f459-e92e-4d75-8d47-b8b5329d225a@github.com>

On Wed, 21 Sep 2022 07:56:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi @AlanBateman 
>> 
>> Debug patch:
>> 
>> 
>> diff --git a/test/jdk/tools/launcher/FXLauncherTest.java b/test/jdk/tools/launcher/FXLauncherTest.java
>> index 9cc4b5aea98..33c3e2788ad 100644
>> --- a/test/jdk/tools/launcher/FXLauncherTest.java
>> +++ b/test/jdk/tools/launcher/FXLauncherTest.java
>> @@ -223,7 +223,7 @@ public class FXLauncherTest extends TestHelper {
>>          compileFXModule();
>>  
>>          List<String> fxCompilerArgs = new ArrayList<>();
>> -        fxCompilerArgs.add("--module-path=" + MODULE_DIR);
>> +        fxCompilerArgs.add("--upgrade-module-path=" + MODULE_DIR);
>>          fxCompilerArgs.add("--add-modules=javafx.graphics");
>>          fxCompilerArgs.addAll(Arrays.asList(compilerArgs));
>>          compile(fxCompilerArgs.toArray(new String[fxCompilerArgs.size()]));
>> @@ -232,7 +232,7 @@ public class FXLauncherTest extends TestHelper {
>>      static TestResult doFxExec(String...cmds) {
>>          List<String> fxCmds = new ArrayList<>();
>>          fxCmds.addAll(Arrays.asList(cmds));
>> -        fxCmds.add(1, "--module-path=" + MODULE_DIR);
>> +        fxCmds.add(1, "--upgrade-module-path=" + MODULE_DIR);
>>          fxCmds.add(2, "--add-modules=javafx.graphics");
>>          return doExec(fxCmds.toArray(new String[fxCmds.size()]));
>>      }
>> @@ -439,18 +439,6 @@ public class FXLauncherTest extends TestHelper {
>>      }
>>  
>>      public static void main(String... args) throws Exception {
>> -
>> -        // Ensure that FX is not part of jdk
>> -        Class<?> fxClass = null;
>> -        try {
>> -            fxClass = Class.forName(FX_MARKER_CLASS);
>> -        } catch (ClassNotFoundException ex) {
>> -            // do nothing
>> -        }
>> -        if (fxClass != null) {
>> -            throw new RuntimeException("JavaFX modules erroneously included in the JDK");
>> -        }
>> -
>>          FXLauncherTest fxt = new FXLauncherTest();
>>          fxt.run(args);
>>          if (testExitValue > 0) {
>> 
>> 
>> Still failed:  [debug.log](https://github.com/openjdk/jdk/files/9614161/debug.log)
>> 
>> Thanks,
>> Leslie Zhai
>
>> Still failed: [debug.log](https://github.com/openjdk/jdk/files/9614161/debug.log)
> 
> You are running into module hashes now so I think you'll need some of JDK-8294093. In make/common/Modules.gmk ReadSingleImportMetaData can you add
> 
>    UPGRADEABLE_PLATFORM_MODULES += $1
> 
> This will add the names of the imported modules to the list of upgradeable modules and should mean they are not hashed.

Hi @AlanBateman 

> You are running into module hashes now so I think you'll need some of JDK-8294093. In make/common/Modules.gmk ReadSingleImportMetaData can you add
> 
> UPGRADEABLE_PLATFORM_MODULES += $1

debug patch correct?


diff --git a/make/common/Modules.gmk b/make/common/Modules.gmk
index 0eb0fb2ddc1..3431384e168 100644
--- a/make/common/Modules.gmk
+++ b/make/common/Modules.gmk
@@ -272,6 +272,7 @@ FindModuleLegalSrcDirs = \
 
 # Param 1 - Name of module
 define ReadSingleImportMetaData
+    UPGRADEABLE_PLATFORM_MODULES += $1
     ifneq ($$(wildcard $(IMPORT_MODULES_MAKE)/$$(strip $1)/build.properties), )
       classloader :=
       include_in_jre :=


Quoted from JDK-8294093:

> --with-import-modules option was used in JDK 9/10 for co-bundling JavaFX with the JDK. It seems this configure option is still in use, by some.

BTW, how to release JavaFX and JDK together? or just release them seperately?

Thanks,
Leslie Zhai

-------------

PR: https://git.openjdk.org/jdk/pull/10299

From alanb at openjdk.org  Wed Sep 21 09:25:53 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 Sep 2022 09:25:53 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v11]
In-Reply-To: <bx7g5-9oyrCEeQsjaDdAHqXvOKxkBm7LD2Pa33zmqD0=.0de43b78-4f23-4ed0-a839-2e981cff5a20@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <ivT0q9lxJ8JVOUgWGLArPp6cCOWqz_jKB_VK4T9wGV0=.cc64ee5d-def8-451f-9af9-6502cbdd6cc4@github.com>
 <bx7g5-9oyrCEeQsjaDdAHqXvOKxkBm7LD2Pa33zmqD0=.0de43b78-4f23-4ed0-a839-2e981cff5a20@github.com>
Message-ID: <fRT_O_SNLwp6sNaQMdsA9TRK-S1xBVCHsSE6GCwGPnw=.40a62866-6111-44eb-808f-2ef9239c594d@github.com>

On Tue, 20 Sep 2022 18:08:21 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Assuming we are set with the other changes, did you want to add the following paragraph (or similar) at line 58 to make it clear that if the Manifest is not found, then the JarEntry attributes will not be available:

This is something the reader can read about in the Signed JAR section of the JAR file spec and I think it's too much to try to include in this section of JarInputStream. If there is a place for this in JarInputStream then it's probably in the method description of getNextJarEntry as that can talk about the properties of the JarEntry that it returns. You could separate that out to a separate issue if you want.

-------------

PR: https://git.openjdk.org/jdk/pull/10045

From lucy at openjdk.org  Wed Sep 21 09:33:56 2022
From: lucy at openjdk.org (Lutz Schmidt)
Date: Wed, 21 Sep 2022 09:33:56 GMT
Subject: RFR: JDK-8293659: Improve UnsatisfiedLinkError error message to
 include dlopen error details [v2]
In-Reply-To: <xF7xU_nv7od9QNvVMREbQGelSOQ0okJPyTnoQhkK2w0=.83257c39-be99-41ea-adf5-6affb2712f22@github.com>
References: <ifR_svzVaPWpTZ48Mm7a_bANpIvAgQB1HEiBrXlA0oQ=.1dd92d2d-c9f2-4bbf-9a02-8bde08cdb8fb@github.com>
 <xF7xU_nv7od9QNvVMREbQGelSOQ0okJPyTnoQhkK2w0=.83257c39-be99-41ea-adf5-6affb2712f22@github.com>
Message-ID: <fJ-hYxNGCKx8LzJTfiUtAkWzt-gUSGSEDhfCyRdr3e4=.ddf3cdf8-6369-43b2-84c5-c5e7ed6aa245@github.com>

On Fri, 16 Sep 2022 07:27:44 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When trying to load a x64 lib on macOS aarch64 one got previously this detailed message before [JDK-8275703](https://bugs.openjdk.org/browse/JDK-8275703):
>> 
>> java.lang.UnsatisfiedLinkError: /testing/jco3/macOsx64/libsapjco3.dylib: dlopen(/testing/jco3/macOsx64/libsapjco3.dylib, 1): no suitable image found. Did find:
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust throwExceptionIfFail

Changes look good to me.

-------------

Marked as reviewed by lucy (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10286

From sgehwolf at openjdk.org  Wed Sep 21 09:39:47 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 21 Sep 2022 09:39:47 GMT
Subject: RFR: 8293540: [Metrics] Incorrectly detected resource limits with
 additional cgroup fs mounts [v3]
In-Reply-To: <-GC6RSB-rnXjie1pCd0k7bzPNbGlmyRbR6xyNNJNWzU=.c428b704-c7e6-450f-8107-63ce417e6408@github.com>
References: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
 <-GC6RSB-rnXjie1pCd0k7bzPNbGlmyRbR6xyNNJNWzU=.c428b704-c7e6-450f-8107-63ce417e6408@github.com>
Message-ID: <aZOIvEIs1iWYeRZ_ZnCuGLBH8l-9qEhNXjkQR2NrfWE=.4a27a777-6bc6-4b31-81fb-eddadb9c47a3@github.com>

On Thu, 15 Sep 2022 08:55:41 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Similar issue to the hotspot change discussed in https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation may get the resource limits wrong if there are additional cgroup fs mounts. Apparently that's more common than one might think. I've reproduced this with these existing tests on cg v2:
>> 
>> 
>> test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java
>> test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java
>> test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java 
>> 
>> 
>> I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` and amended `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which unconditionally fails (irrespective of cgroup version in use). The fix is fairly straight forward and is an extension which we already do for the `cpuset` controller: Allow duplicates, and if there are any prefer those mounted at `/sys/fs/cgroup`.
>> 
>> Testing:
>> - [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the product fix)
>> - [x] added tests fail before, pass after the product fix.
>> - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still pass. 
>> - [x] GHA all pass.
>> 
>> Please review! Many thanks in advance.
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8293540: [Metrics] Potentially incorrectly detected resource limits with additional cgroup fs mounts

Anyone willing to review this? Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/10248

From john.hendrikx at gmail.com  Wed Sep 21 11:22:50 2022
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Wed, 21 Sep 2022 13:22:50 +0200
Subject: Sequenced Collections
In-Reply-To: <f6edafc8-03f1-4f3a-1382-592688785c6e@raelity.com>
References: <f6edafc8-03f1-4f3a-1382-592688785c6e@raelity.com>
Message-ID: <06ca6cc9-4d35-e327-5d03-2378302f72dd@gmail.com>

I don't see why you think a general collection, that is in 99.9% of the 
cases not used to implement an MRU, should burden every call to #add 
with a check to see if it isn't exceeding its maximum size or to see if 
a maximum size has been set.

This is much better done by composition, as I don't think all methods 
offered by `Collection` should even be part of an `MRU` interface.

--John

On 20/09/2022 21:08, Ernie Rael wrote:
> (There may be a better place to send this, let me know where)
>
> Suggesting an option to limit the size of the collection, e.g 
> "setMaxSize(int)", default of zero means no limit.
>
> I put together "interface MRU<E> extends Collection<E>" some months 
> ago, it has two implementations based on LinkedList and LinkedHashSet. 
> The code can be seen at 
> https://sourceforge.net/p/jvi/raelity-lib/ci/default/tree/lib/src/main/java/com/raelity/lib/
>
> A SequencedCollection, as outlined in the JEP draft 2020/09/01, would 
> be almost perfect to implement MRU; I've run into most of the 
> problems/issues discussed in the JEP draft.
>
> The MRU is a cache, as I use it; it typically has a max size for the 
> collection. Handling this natively in the collection would be ideal; 
> if an add operation would overflow, remove the item at the other end. 
> Note that addAll() is used when initializing from backing store.
>
> FYI, I use a "Supplier<Integer>" to the constructor to provide 
> maxSize, but a property makes much more sense. I'll make that change 
> in MRU for sanity, and get rid of the trim() method. setMaxSize can do 
> the trim.
>
> -ernie
>

From mbaesken at openjdk.org  Wed Sep 21 11:35:06 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 21 Sep 2022 11:35:06 GMT
Subject: Integrated: JDK-8293659: Improve UnsatisfiedLinkError error message to
 include dlopen error details
In-Reply-To: <ifR_svzVaPWpTZ48Mm7a_bANpIvAgQB1HEiBrXlA0oQ=.1dd92d2d-c9f2-4bbf-9a02-8bde08cdb8fb@github.com>
References: <ifR_svzVaPWpTZ48Mm7a_bANpIvAgQB1HEiBrXlA0oQ=.1dd92d2d-c9f2-4bbf-9a02-8bde08cdb8fb@github.com>
Message-ID: <fCtTVb431k3oNEXeC95CqgJcugZT4v48TYKZB21L7p8=.416b472a-a800-44b9-9326-5505ce46f6c3@github.com>

On Thu, 15 Sep 2022 11:54:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When trying to load a x64 lib on macOS aarch64 one got previously this detailed message before [JDK-8275703](https://bugs.openjdk.org/browse/JDK-8275703):
> 
> java.lang.UnsatisfiedLinkError: /testing/jco3/macOsx64/libsapjco3.dylib: dlopen(/testing/jco3/macOsx64/libsapjco3.dylib, 1): no suitable image found. Did find:

This pull request has now been integrated.

Changeset: da4fdfbb
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/da4fdfbbf4ba72ddaf4f27d95f71e95b7ebf8cc1
Stats:     15 lines in 1 file changed: 14 ins; 0 del; 1 mod

8293659: Improve UnsatisfiedLinkError error message to include dlopen error details

Reviewed-by: mchung, lucy

-------------

PR: https://git.openjdk.org/jdk/pull/10286

From duke at openjdk.org  Wed Sep 21 11:38:36 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Wed, 21 Sep 2022 11:38:36 GMT
Subject: RFR: 8289797: tools/launcher/I18NArgTest.java fails on Japanese
 Windows environment [v5]
In-Reply-To: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
References: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
Message-ID: <paq2Q8OefqqVpkogRRHxaV-WzGyb5mNMZ7xsn3uZURQ=.fb49c3f0-c160-40c3-a4fe-79576a0eba5b@github.com>

> I removed a section of via JDK_JAVA_OPTIONS because including main class is not allowed in the specification.
> This behavior is added in JDK-8170832, which add JAVA_OPTIONS environment variable. At this time, this test is mismatch with the specification.
> I tried to test and get Passed on Japanese Windows environment.
> Could you review this fix, please?

KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:

  8289797: tools/launcher/I18NArgTest.java fails on Japanese Windows environment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9389/files
  - new: https://git.openjdk.org/jdk/pull/9389/files/e22d35c5..1149de31

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9389&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9389&range=03-04

  Stats: 25 lines in 1 file changed: 2 ins; 6 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/9389.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9389/head:pull/9389

PR: https://git.openjdk.org/jdk/pull/9389

From duke at openjdk.org  Wed Sep 21 11:38:36 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Wed, 21 Sep 2022 11:38:36 GMT
Subject: RFR: 8289797: tools/launcher/I18NArgTest.java fails on Japanese
 Windows environment [v3]
In-Reply-To: <djedmAC0dHkHyeGxras2oHpdXMeY7EyXTYDyOnlPLTM=.eee0e269-cc45-4e90-8b15-ff7deae342bd@github.com>
References: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
 <B4rHHDtIaxlHyH2YF9HMOuOf6sNeC7bsYhe3NfdgUqM=.a995ec62-0d39-4f43-95c5-03261ae325c0@github.com>
 <VRTnyuy9Qmw8lfm0_6PJtie5trsXqVQjY4mmt_fpE88=.afda6e0b-5be8-4629-9816-361ec8d243ad@github.com>
 <Xu96knBpaa0kvEv_RtoXuIHahBieArKuvn26mISRu6s=.80832925-513a-4859-b0d0-6fe1c49062fc@github.com>
 <ozAQVBDrDFq8ZyuOVckfu3t_TSvpvRBFj_6k_YA8jJc=.64883f07-eb4a-4419-aeaf-9ffbb86b4d5b@github.com>
 <djedmAC0dHkHyeGxras2oHpdXMeY7EyXTYDyOnlPLTM=.eee0e269-cc45-4e90-8b15-ff7deae342bd@github.com>
Message-ID: <RBrk4R7jjhHLRBtueFeaODft1E7Cin2B1xbG_JleOuI=.26944ee7-7d14-4963-ac83-698ad87a4b60@github.com>

On Fri, 16 Sep 2022 16:19:35 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Extract to a byte array with the appropriate charset and then HexFormat the bytearray.
>> 
>> 
>>     var SysPropHexVal = HexFormat.of().formatHex(sysPropVal.getBytes(StandardCharsets.UTF_16));
>
> Thanks, Roger. You beat me to it ?

Thank you, I fixed it. In addition, since the return value of formatHex is four digits, I fixed the second argument passed to execTest to match that format.

-------------

PR: https://git.openjdk.org/jdk/pull/9389

From lancea at openjdk.org  Wed Sep 21 11:42:50 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 21 Sep 2022 11:42:50 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v11]
In-Reply-To: <fRT_O_SNLwp6sNaQMdsA9TRK-S1xBVCHsSE6GCwGPnw=.40a62866-6111-44eb-808f-2ef9239c594d@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <ivT0q9lxJ8JVOUgWGLArPp6cCOWqz_jKB_VK4T9wGV0=.cc64ee5d-def8-451f-9af9-6502cbdd6cc4@github.com>
 <bx7g5-9oyrCEeQsjaDdAHqXvOKxkBm7LD2Pa33zmqD0=.0de43b78-4f23-4ed0-a839-2e981cff5a20@github.com>
 <fRT_O_SNLwp6sNaQMdsA9TRK-S1xBVCHsSE6GCwGPnw=.40a62866-6111-44eb-808f-2ef9239c594d@github.com>
Message-ID: <7HqqjzAqvKy4vjgVkmouPOro7YyIXNuye-v08RujFAM=.b3d9a188-4835-4046-a87a-930dd617bb5e@github.com>

On Wed, 21 Sep 2022 09:23:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Assuming we are set with the other changes, did you want to add the following paragraph (or similar) at line 58 to make it clear that if the Manifest is not found, then the JarEntry attributes will not be available:
> 
> This is something the reader can read about in the Signed JAR section of the JAR file spec and I think it's too much to try to include in this section of JarInputStream. If there is a place for this in JarInputStream then it's probably in the method description of getNextJarEntry as that can talk about the properties of the JarEntry that it returns. You could separate that out to a separate issue if you want.

OK, we can deal with this separately.  I guess I was trying to articulate that if the Manifest is not found in beginning of the input stream, then you have no access to the attributes given this is unique to JarInputStream

-------------

PR: https://git.openjdk.org/jdk/pull/10045

From kcr at openjdk.org  Wed Sep 21 12:52:48 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 21 Sep 2022 12:52:48 GMT
Subject: RFR: 8293977: jdk/modules/etc/VerifyModuleDelegation.java fail
 with jfx
In-Reply-To: <106sxrVWYWuH2tRT0g8A8sQSz5VIFn7rwS1QrZiIaV0=.e984c682-e49d-4558-959b-42b05b009470@github.com>
References: <K8keV23DhjOl2iAcpxEGUPEDKfRsrPMwVYf6ZvYV39M=.66a73163-007e-4951-a524-7cf8d5aa1f79@github.com>
 <UmwA4scrMxXQ4QbOoZHzR-PNH0c9nNg_dL4OhdRaIvA=.135d9044-ad31-4cea-90ec-1b453c58c1aa@github.com>
 <2ddyCr8skoTc3z5FqEn7Tle-UZI2Q9d0mh8cXbT1mGc=.7c737f00-2197-4c5a-bbf4-c6ea1fb1aa41@github.com>
 <106sxrVWYWuH2tRT0g8A8sQSz5VIFn7rwS1QrZiIaV0=.e984c682-e49d-4558-959b-42b05b009470@github.com>
Message-ID: <XRZyLRdn6MdBKKsoOz05oWtGCLmD1JAeDwjKxBsREas=.f3235219-f030-4bd0-9fa4-8541df66726d@github.com>

On Wed, 21 Sep 2022 08:35:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> While this particular issue was closed now, this is perhaps yet another indication that the "import modules" thing is causing problems, and should be removed now that it is not used anymore. I created [JDK-8294095](https://bugs.openjdk.org/browse/JDK-8294095) to explore this possibility.

Other than the issue of adding the imported FX modules in the platform classes, they are successfully using the "import modules" feature. I don't see why it needs to be removed.

-------------

PR: https://git.openjdk.org/jdk/pull/10328

From alanb at openjdk.org  Wed Sep 21 13:47:47 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 Sep 2022 13:47:47 GMT
Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume
Message-ID: <l_lUEdZ-ORALa9ux2qu_PZZFm2IpIZs02kdC-tCQQBM=.e96f9fab-8d68-4ba1-b0f6-2b9b5c397226@github.com>

Degrade Thread.suspend/resume to throw UOE unconditionally.

Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive.

The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs.

Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread).

-------------

Commit messages:
 - Fix typo in test comment
 - Keep link to threadPrimitiveDeprecation.html
 - Merge
 - Tests
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/10324/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10324&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8249627
  Stats: 347 lines in 15 files changed: 148 ins; 139 del; 60 mod
  Patch: https://git.openjdk.org/jdk/pull/10324.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10324/head:pull/10324

PR: https://git.openjdk.org/jdk/pull/10324

From smarks at openjdk.org  Wed Sep 21 13:47:48 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 21 Sep 2022 13:47:48 GMT
Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume
In-Reply-To: <l_lUEdZ-ORALa9ux2qu_PZZFm2IpIZs02kdC-tCQQBM=.e96f9fab-8d68-4ba1-b0f6-2b9b5c397226@github.com>
References: <l_lUEdZ-ORALa9ux2qu_PZZFm2IpIZs02kdC-tCQQBM=.e96f9fab-8d68-4ba1-b0f6-2b9b5c397226@github.com>
Message-ID: <WTIR3z6rqMuLIJYeryBUjs2HtYMMD3I9rLTR21nWlvI=.75a74a05-b2cd-427e-bdf2-db6a9fdcb45e@github.com>

On Sun, 18 Sep 2022 16:32:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Degrade Thread.suspend/resume to throw UOE unconditionally.
> 
> Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive.
> 
> The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs.
> 
> Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread).

Code changes look fine, though I didn't look too closely at the JDWP and JVMTI stuff. Nice use of JUnit.

Not a big deal, but I could see leaving the links from `Thread::suspend` et. al. to the "Why deprecated?" doc, and then updating that doc to make it clear that the mechanisms have in fact been removed, but leaving the rationale that's there mostly in place.

Might also be useful in the CSR to re-emphasize that this does not affect the ability to suspend and resume threads through the debugging interfaces. Of course the specs in those areas need to be updated so they no longer deal with the case of a thread that's been suspended through the API, but the debugging mechanisms' functions themselves are unchanged.

-------------

PR: https://git.openjdk.org/jdk/pull/10324

From mbaesken at openjdk.org  Wed Sep 21 14:42:02 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 21 Sep 2022 14:42:02 GMT
Subject: RFR: JDK-8293701: jdeps InverseDepsAnalyzer runs into
 NoSuchElementException: No value present
In-Reply-To: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
References: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
Message-ID: <q3kxJJ2Nc09C47lndSw09Dk7iWzP_lVnF4gaEj9Z5sA=.9b796652-1afd-43b0-8ad2-b335e89c5e93@github.com>

On Fri, 16 Sep 2022 08:26:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We noticed that with certain jar file input, jdeps runs into the following exception, this happens with jdk11, 17 and 20.
> 
> jdeps.exe --multi-release 11 --module-path . --inverse --package com.sap.nw.performance.supa.client test.jar
> 
> Inverse transitive dependences matching packages [com.sap.nw.performance.supa.client]
> Exception in thread "main" java.util.NoSuchElementException: No value present
>         at java.base/java.util.Optional.get(Optional.java:148)
>         at jdk.jdeps/com.sun.tools.jdeps.InverseDepsAnalyzer.lambda$inverseDependences$2(InverseDepsAnalyzer.java:150)
>         at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>         at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>         at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
>         at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>         at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> 
> So an additional  check might be a good idea.

One additional comment about the jdeps --help output 
https://github.com/openjdk/jdk/blob/master/src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties#L139


main.opt.I=\
\  -I\n\
\  --inverse                     Analyzes the dependences per other given options\n\
\                                and then find all artifacts that directly\n\
\                                and indirectly depend on the matching nodes.\n\
\                                This is equivalent to the inverse of\n\
\                                compile-time view analysis and print\n\
\                                dependency summary.  This option must use\n\
\                                with --require, --package or --regex option.

Should this be better  'This option must be used . . .' ?  And what about a sentence explaining what 'nodes' you are talking about ?

Btw is there some trace mode telling me more where exactly the jdeps tool fails in this particular case ?

-------------

PR: https://git.openjdk.org/jdk/pull/10300

From ihse at openjdk.org  Wed Sep 21 15:07:42 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 21 Sep 2022 15:07:42 GMT
Subject: RFR: 8293977: jdk/modules/etc/VerifyModuleDelegation.java fail
 with jfx
In-Reply-To: <K8keV23DhjOl2iAcpxEGUPEDKfRsrPMwVYf6ZvYV39M=.66a73163-007e-4951-a524-7cf8d5aa1f79@github.com>
References: <K8keV23DhjOl2iAcpxEGUPEDKfRsrPMwVYf6ZvYV39M=.66a73163-007e-4951-a524-7cf8d5aa1f79@github.com>
Message-ID: <Wbbv6VLuccxYO9drkAaIrP7CVQVyI83l1N_o-Ql5G4o=.6c717723-23f6-4e57-9f64-3d03e20cff61@github.com>

On Mon, 19 Sep 2022 00:45:32 GMT, Leslie Zhai <lzhai at openjdk.org> wrote:

> Hi,
> 
> @dumasun reported the issue:
> 
> Configured with jfx-ls-modular-sdk:
> 
> 
> configure --with-import-modules=modular-sdk
> 
> 
> `make run-test CONF=fastdebug TEST="jdk/modules/etc/VerifyModuleDelegation.java"` failed:
> 
> 
> ----------System.out:(46/3114)----------
> test VerifyModuleDelegation.checkJavaBase(): success
> test VerifyModuleDelegation.checkLoaderDelegation(): failure
> java.lang.Error: platform/javafx.swing can't delegate to find classes from app/jdk.unsupported.desktop
>     at VerifyModuleDelegation.lambda$checkLoaderDelegation$1(VerifyModuleDelegation.java:77)
>     at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>     at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1921)
>     at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>     at VerifyModuleDelegation.lambda$checkLoaderDelegation$2(VerifyModuleDelegation.java:68)
>     at java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1715)
>     at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>     at VerifyModuleDelegation.checkLoaderDelegation(VerifyModuleDelegation.java:68)
>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>     at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>     at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>     at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>     at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>     at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>     at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>     at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>     at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>     at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
>     at org.testng.TestRunner.privateRun(TestRunner.java:764)
>     at org.testng.TestRunner.run(TestRunner.java:585)
>     at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
>     at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
>     at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
>     at org.testng.SuiteRunner.run(SuiteRunner.java:286)
>     at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
>     at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
>     at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
>     at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
>     at org.testng.TestNG.runSuites(TestNG.java:1069)
>     at org.testng.TestNG.run(TestNG.java:1037)
>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54)
>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>     at java.base/java.lang.Thread.run(Thread.java:1589)
> 
> ===============================================
> jdk/modules/etc/VerifyModuleDelegation.java
> Total tests run: 2, Passes: 1, Failures: 1, Skips: 0
> ===============================================
> 
> ----------System.err:(13/753)----------
> WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.concurrent
> java.lang.Exception: failures: 1
>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96)
>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54)
>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>     at java.base/java.lang.Thread.run(Thread.java:1589)
> 
> 
> Thanks,
> Leslie Zhai

See [JDK-8294095](https://bugs.openjdk.org/browse/JDK-8294095) for a discussion on the rationale. In short, it is because imported modules are intrusive in the build system, and it advertises a kind of "generality" that it is not designed for.

-------------

PR: https://git.openjdk.org/jdk/pull/10328

From psandoz at openjdk.org  Wed Sep 21 15:13:14 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 21 Sep 2022 15:13:14 GMT
Subject: RFR: 8294062: Improve parsing performance of j.l.c.MethodTypeDesc
In-Reply-To: <HNrMTCC8HTw4rxDajf0aNKDmehbLhtQ6H8rBe8e-qP8=.db17d330-8ec4-4884-9ddd-f30c3c9b4a68@github.com>
References: <Q0iEUit9CcB8dvFJUMCKQoSYx51BJ75Mejv-pGcl2OI=.f1a538b0-2d74-4c2c-a50d-ba70d64d84da@github.com>
 <VDvbC1TFiKQEVZE9c_QP8jUBcBV1EmLFUDMGTVUrkpU=.46770485-1955-458b-9650-6a182b06a309@github.com>
 <HNrMTCC8HTw4rxDajf0aNKDmehbLhtQ6H8rBe8e-qP8=.db17d330-8ec4-4884-9ddd-f30c3c9b4a68@github.com>
Message-ID: <2lfTFUOng4BYDuAgAfu-dbp_hdmqQslwhMdFr2QDU2E=.26eadf0d-537c-4fe5-b525-8f1efdb5888b@github.com>

On Wed, 21 Sep 2022 08:38:19 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/constant/ConstantUtils.java line 217:
>> 
>>> 215:                             }
>>> 216:                             case '/' -> {
>>> 217:                                 if (!legal) return 0;
>> 
>> IIUC that works to reject `//` and trailing `/`, but does not reject leading `/`? which the previous code rejected.
>
> `legal` is initially set to false, so leading `/` is also rejected

Doh! Could you add a comment with the case block, something like?
// Rejects a leading `/`, any "//", and a trailing '/' (by exit from the loop)

-------------

PR: https://git.openjdk.org/jdk/pull/10358

From iklam at openjdk.org  Wed Sep 21 15:21:28 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 21 Sep 2022 15:21:28 GMT
Subject: RFR: 8293792: runtime/Dictionary/ProtectionDomainCacheTest.java
 fails with FileAlreadyExistsException: /tmp
In-Reply-To: <Vfaxg8rSBOwZrJi22f0JlNCCmgohix2_LXoAUb9G0Io=.796dccd4-683c-4026-ba63-b1631d484085@github.com>
References: <Vfaxg8rSBOwZrJi22f0JlNCCmgohix2_LXoAUb9G0Io=.796dccd4-683c-4026-ba63-b1631d484085@github.com>
Message-ID: <fJT84WvTh7rulSPm5kIMuBY9QV03xEiw7AWb3t17Wkc=.f2a047e8-1b10-4284-a1d0-54f4d2698964@github.com>

On Wed, 14 Sep 2022 09:42:37 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> runtime/Dictionary/ProtectionDomainCacheTest.java fails on Linux if `/tmp` is a symbolic link directory.
> The root cause is that `JarUtils.createJarFile` [1] will throw `FileAlreadyExistsException` if `parent` is a symbolic directory.
> So it seems better to test the existance of `parent` before creation.
> 
> Testing:
> - tier1~3 on Linux/x64 in progress, seems fine until now
> 
> Thanks.
> Best regards,
> Jie
> 
> 
> [1] https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/util/JarUtils.java#L72

The fix looks reasonable to me.

There's a potential error case, if `parent` is not a directory. However, this should lead to an exception later inside `Files.newOutputStream(jarfile)`, so I think it's OK to not check for this.

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10266

From coffeys at openjdk.org  Wed Sep 21 15:22:17 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 21 Sep 2022 15:22:17 GMT
Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event [v3]
In-Reply-To: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
Message-ID: <USs_vDS5nXOTCPMXLrJ0SUufRlhCjR7fNrnaUmgK2Rg=.7bc0f094-abb1-4cde-ad0d-01a729adb679@github.com>

> Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls.

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  Correct Label annontation capitals

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9657/files
  - new: https://git.openjdk.org/jdk/pull/9657/files/e168152f..31cedc3a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9657&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9657&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9657.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9657/head:pull/9657

PR: https://git.openjdk.org/jdk/pull/9657

From alanb at openjdk.org  Wed Sep 21 15:28:15 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 Sep 2022 15:28:15 GMT
Subject: RFR: 8293792: runtime/Dictionary/ProtectionDomainCacheTest.java
 fails with FileAlreadyExistsException: /tmp
In-Reply-To: <Vfaxg8rSBOwZrJi22f0JlNCCmgohix2_LXoAUb9G0Io=.796dccd4-683c-4026-ba63-b1631d484085@github.com>
References: <Vfaxg8rSBOwZrJi22f0JlNCCmgohix2_LXoAUb9G0Io=.796dccd4-683c-4026-ba63-b1631d484085@github.com>
Message-ID: <XqYmY8rmtmGDKBpyBkaty9D8_Axe3KJ7N4dCtd_FuqM=.753567c2-70cc-4902-9808-8efa007c6b7e@github.com>

On Wed, 14 Sep 2022 09:42:37 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> runtime/Dictionary/ProtectionDomainCacheTest.java fails on Linux if `/tmp` is a symbolic link directory.
> The root cause is that `JarUtils.createJarFile` [1] will throw `FileAlreadyExistsException` if `parent` is a symbolic directory.
> So it seems better to test the existance of `parent` before creation.
> 
> Testing:
> - tier1~3 on Linux/x64 in progress, seems fine until now
> 
> Thanks.
> Best regards,
> Jie
> 
> 
> [1] https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/util/JarUtils.java#L72

I see Ioi has approved the change but I don't think we should put this workaround into the test library. The issue here is that Files.createDirectories should work like mkdir -p when there are sym links in the tree. Jai is experimenting with a fix to that.

-------------

Changes requested by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10266

From iklam at openjdk.org  Wed Sep 21 15:36:21 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 21 Sep 2022 15:36:21 GMT
Subject: RFR: 8293792: runtime/Dictionary/ProtectionDomainCacheTest.java
 fails with FileAlreadyExistsException: /tmp
In-Reply-To: <Vfaxg8rSBOwZrJi22f0JlNCCmgohix2_LXoAUb9G0Io=.796dccd4-683c-4026-ba63-b1631d484085@github.com>
References: <Vfaxg8rSBOwZrJi22f0JlNCCmgohix2_LXoAUb9G0Io=.796dccd4-683c-4026-ba63-b1631d484085@github.com>
Message-ID: <YId_n7sZfownuHpLtp7iC1FDTx9A4mzZ-eSQC40pilQ=.5c1e223f-3625-4a67-88d2-e099f3604946@github.com>

On Wed, 14 Sep 2022 09:42:37 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> runtime/Dictionary/ProtectionDomainCacheTest.java fails on Linux if `/tmp` is a symbolic link directory.
> The root cause is that `JarUtils.createJarFile` [1] will throw `FileAlreadyExistsException` if `parent` is a symbolic directory.
> So it seems better to test the existance of `parent` before creation.
> 
> Testing:
> - tier1~3 on Linux/x64 in progress, seems fine until now
> 
> Thanks.
> Best regards,
> Jie
> 
> 
> [1] https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/util/JarUtils.java#L72

Withdraw my approval per Alan's comment.

-------------

Changes requested by iklam (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10266

From errael at raelity.com  Wed Sep 21 16:32:05 2022
From: errael at raelity.com (Ernie Rael)
Date: Wed, 21 Sep 2022 09:32:05 -0700
Subject: Sequenced Collections
In-Reply-To: <06ca6cc9-4d35-e327-5d03-2378302f72dd@gmail.com>
References: <f6edafc8-03f1-4f3a-1382-592688785c6e@raelity.com>
 <06ca6cc9-4d35-e327-5d03-2378302f72dd@gmail.com>
Message-ID: <024fe055-c94e-94e2-cf21-bca828304929@raelity.com>

 > I don't see why you think a general collection...

I thought the Subject would be sufficient to indicate that I was not 
talking about collections in general. I should have been more precise 
with my words; guess I was just excited by a bi-directional ordered set.

The MRU _example_ is useful; the current collections handle it poorly 
and Sequenced Collections is ideal. Caches with an eviction policy are 
common; I suspect caches will be a common use for SequencedSet family. 
Note there are fixed sized Collections and SequencedCollection borrows 
heavily from that family. Perhaps this issue should be considered in the 
context of adding an **Eviction Policy** to appropriate collections.

MRU is a Collection; for example, I pass an MRU to a persistence 
mechanism that takes a collection. Saying "all methods offered by 
`Collection` should [not] even be part of an `MRU` interface" is 
innacurate, especially when considered in the context of a 
SequencedCollection.

-ernie

PS - Loosely related is extending a Collection and providing a 
synchronized version. Is there a discussion about making the 
SynchronizedCollection family of classes public?


On 9/21/22 4:22 AM, John Hendrikx wrote:
> I don't see why you think a general collection, that is in 99.9% of 
> the cases not used to implement an MRU, should burden every call to 
> #add with a check to see if it isn't exceeding its maximum size or to 
> see if a maximum size has been set.
>
> This is much better done by composition, as I don't think all methods 
> offered by `Collection` should even be part of an `MRU` interface.
>
> --John
>
> On 20/09/2022 21:08, Ernie Rael wrote:
>> (There may be a better place to send this, let me know where)
>>
>> Suggesting an option to limit the size of the collection, e.g 
>> "setMaxSize(int)", default of zero means no limit.
>>
>> I put together "interface MRU<E> extends Collection<E>" some months 
>> ago, it has two implementations based on LinkedList and 
>> LinkedHashSet. The code can be seen at 
>> https://sourceforge.net/p/jvi/raelity-lib/ci/default/tree/lib/src/main/java/com/raelity/lib/
>>
>> A SequencedCollection, as outlined in the JEP draft 2020/09/01, would 
>> be almost perfect to implement MRU; I've run into most of the 
>> problems/issues discussed in the JEP draft.
>>
>> The MRU is a cache, as I use it; it typically has a max size for the 
>> collection. Handling this natively in the collection would be ideal; 
>> if an add operation would overflow, remove the item at the other end. 
>> Note that addAll() is used when initializing from backing store.
>>
>> FYI, I use a "Supplier<Integer>" to the constructor to provide 
>> maxSize, but a property makes much more sense. I'll make that change 
>> in MRU for sanity, and get rid of the trim() method. setMaxSize can 
>> do the trim.
>>
>> -ernie
>>
>


From kvn at openjdk.org  Wed Sep 21 16:43:26 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 21 Sep 2022 16:43:26 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v8]
In-Reply-To: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com>
Message-ID: <QdS7Tx2gk2HR7Y-qe6Ig8_QgyGRi5i3k14aERVEHTs4=.b5839efb-e45f-4700-b9d6-7fca6d61cd77@github.com>

On Fri, 2 Sep 2022 00:52:49 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> 8289552: Make intrinsic conversions between bit representations of half precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments

tier2 and 3 passed. I will wait update with test and JVMCI fix before doing more testing.

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From asotona at openjdk.org  Wed Sep 21 16:49:32 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 21 Sep 2022 16:49:32 GMT
Subject: RFR: 8294062: Improve parsing performance of j.l.c.MethodTypeDesc
 [v2]
In-Reply-To: <Q0iEUit9CcB8dvFJUMCKQoSYx51BJ75Mejv-pGcl2OI=.f1a538b0-2d74-4c2c-a50d-ba70d64d84da@github.com>
References: <Q0iEUit9CcB8dvFJUMCKQoSYx51BJ75Mejv-pGcl2OI=.f1a538b0-2d74-4c2c-a50d-ba70d64d84da@github.com>
Message-ID: <HbfbgXdG5xMYPMKm1oMcQw0cPjYvaUXsSbEdf9iDBog=.cc46ee9a-65cb-41b3-9a9d-15592ccdef57@github.com>

> Parsing performance of `j.l.c.MethodTypeDescriptor::ofDescriptor` can be significantly improved and add performance boost to intensive users.
> 
> Two main reasons have been identified and fixed in this patch:
> 
> First glitch is late insertion of return type to the first position of `j.u.ArrayList`, causing all previously parsed parameter types to shift using `System::arraycopy`.
> 
> Proposed patch inserts a placeholder for the return type first and replaces it with return type later.
> 
> Second performance degradation is in `MethodTypeDescriptor::skipOverFieldSignature`, where each identified class descriptor is exactly located by `String::indexOf`, extracted by `String::substring`, and passed for for the purpose of verification to `ConstantUtils::verifyUnqualifiedClassName`.
> 
> Proposed patch inlines the unqualified class name verification into `ConstantUtils::skipOverFieldSignature` parsing loop and so eliminates calls of `String::indexOf` and `String::substring`. Package private method `ConstantUtils::verifyUnqualifiedClassName` has no other use within the package, so it is removed.
> 
> Please review proposed performance improving patch.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  added comments to j.l.ConstantUtils::skipOverFieldSignature parser loop

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10358/files
  - new: https://git.openjdk.org/jdk/pull/10358/files/e3fd40c0..80b8535a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10358&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10358&range=00-01

  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10358.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10358/head:pull/10358

PR: https://git.openjdk.org/jdk/pull/10358

From asotona at openjdk.org  Wed Sep 21 16:49:32 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 21 Sep 2022 16:49:32 GMT
Subject: RFR: 8294062: Improve parsing performance of j.l.c.MethodTypeDesc
 [v2]
In-Reply-To: <2lfTFUOng4BYDuAgAfu-dbp_hdmqQslwhMdFr2QDU2E=.26eadf0d-537c-4fe5-b525-8f1efdb5888b@github.com>
References: <Q0iEUit9CcB8dvFJUMCKQoSYx51BJ75Mejv-pGcl2OI=.f1a538b0-2d74-4c2c-a50d-ba70d64d84da@github.com>
 <VDvbC1TFiKQEVZE9c_QP8jUBcBV1EmLFUDMGTVUrkpU=.46770485-1955-458b-9650-6a182b06a309@github.com>
 <HNrMTCC8HTw4rxDajf0aNKDmehbLhtQ6H8rBe8e-qP8=.db17d330-8ec4-4884-9ddd-f30c3c9b4a68@github.com>
 <2lfTFUOng4BYDuAgAfu-dbp_hdmqQslwhMdFr2QDU2E=.26eadf0d-537c-4fe5-b525-8f1efdb5888b@github.com>
Message-ID: <h7gfREzxgxTpHUfcNv84dSf9ZB7fegmD6mYsdasQanY=.0e1a4f53-46f9-40ce-8299-16db9f6fdc2d@github.com>

On Wed, 21 Sep 2022 15:09:21 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> `legal` is initially set to false, so leading `/` is also rejected
>
> Doh! Could you add a comment with the case block, something like?
> // Rejects a leading `/`, any "//", and a trailing '/' (by exit from the loop)

I've added the comments, thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10358

From naoto at openjdk.org  Wed Sep 21 16:52:45 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 21 Sep 2022 16:52:45 GMT
Subject: RFR: 8289797: tools/launcher/I18NArgTest.java fails on Japanese
 Windows environment [v5]
In-Reply-To: <paq2Q8OefqqVpkogRRHxaV-WzGyb5mNMZ7xsn3uZURQ=.fb49c3f0-c160-40c3-a4fe-79576a0eba5b@github.com>
References: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
 <paq2Q8OefqqVpkogRRHxaV-WzGyb5mNMZ7xsn3uZURQ=.fb49c3f0-c160-40c3-a4fe-79576a0eba5b@github.com>
Message-ID: <Ijaev_hEXN91s0kyh3Wi_XwQ3WsGlEB7We1OnNppuko=.7f2ef9d8-a45e-41c1-9f3b-ba05e2cb4855@github.com>

On Wed, 21 Sep 2022 11:38:36 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

>> I removed a section of via JDK_JAVA_OPTIONS because including main class is not allowed in the specification.
>> This behavior is added in JDK-8170832, which add JAVA_OPTIONS environment variable. At this time, this test is mismatch with the specification.
>> I tried to test and get Passed on Japanese Windows environment.
>> Could you review this fix, please?
>
> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8289797: tools/launcher/I18NArgTest.java fails on Japanese Windows environment

Looks good. Please restore the newline at the end before integrating the changes

test/jdk/tools/launcher/I18NArgTest.java line 152:

> 150:         }
> 151:     }
> 152: }

Nit: don't remove the newline at the end

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9389

From psandoz at openjdk.org  Wed Sep 21 17:02:20 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 21 Sep 2022 17:02:20 GMT
Subject: RFR: 8294062: Improve parsing performance of j.l.c.MethodTypeDesc
 [v2]
In-Reply-To: <HbfbgXdG5xMYPMKm1oMcQw0cPjYvaUXsSbEdf9iDBog=.cc46ee9a-65cb-41b3-9a9d-15592ccdef57@github.com>
References: <Q0iEUit9CcB8dvFJUMCKQoSYx51BJ75Mejv-pGcl2OI=.f1a538b0-2d74-4c2c-a50d-ba70d64d84da@github.com>
 <HbfbgXdG5xMYPMKm1oMcQw0cPjYvaUXsSbEdf9iDBog=.cc46ee9a-65cb-41b3-9a9d-15592ccdef57@github.com>
Message-ID: <ThLRuKT_6dZi0Z-Us4zwUPUPEfgncJ9HNIfN6Gdv4I8=.269b886e-bd89-4c0f-96f2-843e358d4ec7@github.com>

On Wed, 21 Sep 2022 16:49:32 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Parsing performance of `j.l.c.MethodTypeDescriptor::ofDescriptor` can be significantly improved and add performance boost to intensive users.
>> 
>> Two main reasons have been identified and fixed in this patch:
>> 
>> First glitch is late insertion of return type to the first position of `j.u.ArrayList`, causing all previously parsed parameter types to shift using `System::arraycopy`.
>> 
>> Proposed patch inserts a placeholder for the return type first and replaces it with return type later.
>> 
>> Second performance degradation is in `MethodTypeDescriptor::skipOverFieldSignature`, where each identified class descriptor is exactly located by `String::indexOf`, extracted by `String::substring`, and passed for for the purpose of verification to `ConstantUtils::verifyUnqualifiedClassName`.
>> 
>> Proposed patch inlines the unqualified class name verification into `ConstantUtils::skipOverFieldSignature` parsing loop and so eliminates calls of `String::indexOf` and `String::substring`. Package private method `ConstantUtils::verifyUnqualifiedClassName` has no other use within the package, so it is removed.
>> 
>> Please review proposed performance improving patch.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added comments to j.l.ConstantUtils::skipOverFieldSignature parser loop

Looks good.

-------------

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10358

From cjplummer at openjdk.org  Wed Sep 21 17:15:19 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 21 Sep 2022 17:15:19 GMT
Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume
In-Reply-To: <l_lUEdZ-ORALa9ux2qu_PZZFm2IpIZs02kdC-tCQQBM=.e96f9fab-8d68-4ba1-b0f6-2b9b5c397226@github.com>
References: <l_lUEdZ-ORALa9ux2qu_PZZFm2IpIZs02kdC-tCQQBM=.e96f9fab-8d68-4ba1-b0f6-2b9b5c397226@github.com>
Message-ID: <_bEledEsS53FuI7oLyVxlCrmpLwJFQitD0uB320-tR8=.7c04ba0b-963b-4bdd-8972-14c0950751dd@github.com>

On Sun, 18 Sep 2022 16:32:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Degrade Thread.suspend/resume to throw UOE unconditionally.
> 
> Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive.
> 
> The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs.
> 
> Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread).

Changes look good.

-------------

Marked as reviewed by cjplummer (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10324

From cjplummer at openjdk.org  Wed Sep 21 17:29:23 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 21 Sep 2022 17:29:23 GMT
Subject: RFR: 8293613: need to properly handle and hide tmp VTMS
 transitions [v3]
In-Reply-To: <B6RFtDbP8hXLeKchONA5Oms2vNDsUU7EHV0wWotmayA=.726d876d-706b-4e70-ad7a-d49575796543@github.com>
References: <O_jzls_cv3HBC0NbzuYV2LXaW9VB2M18FroUfXWXd2w=.fa9d1f3c-40a2-42bd-a09b-dadd5032e513@github.com>
 <ve9g9LcSrawK3kb-TxKqxkSUOvkvnIsebd84GAub2DQ=.54a4a79b-be0a-47ef-99ba-63b93236cf08@github.com>
 <vMfCeRbX7oTnnv5-1PggLMUc1Q8MjZ0mnSFp5cutdTA=.08a9c27a-1bc2-4118-8f88-56c741df1435@github.com>
 <B6RFtDbP8hXLeKchONA5Oms2vNDsUU7EHV0wWotmayA=.726d876d-706b-4e70-ad7a-d49575796543@github.com>
Message-ID: <yvlbIRTOnKwybWVvpG0quuT0uGLMjRg0LhoiN5PC9xE=.7ba2eb86-4e60-42e2-a115-4ee9f94877dc@github.com>

On Tue, 20 Sep 2022 22:15:49 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 713:
>> 
>>> 711:   if (!jt->is_in_tmp_VTMS_transition()) {
>>> 712:     jvf = check_and_skip_hidden_frames(jt, jvf);
>>> 713:   }
>> 
>> I think this comment needs some help. It's hard to match it up with what the code is doing. I think you are saying you want to avoid skipping hidden frames when in transition, although if that's the case, it's not clear to me why not skipping is ok.
>> 
>> Also is skipping (or not skipping) ok regardless of the JvmtiEnvBase::is_cthread_with_continuation() result?
>
> Thank you for reviewing and the comment, Chris.
> I agree, this part and related comment is kind of obscure.
> I'll think how to make the comment better.
> In fact, all temporary VTMS transitions do temporary switch the `JavaThread` identity from virtual thread to carrier. There is no need to skip frames because there are no real carrier thread frames at the top. Moreover, any attempt to skip frames which are in transition works incorrectly and gives an empty stack. The check `JvmtiEnvBase::is_cthread_with_continuation()` is needed to make sure we have a deal with a continuation. There is no need to skip frames otherwise.

It's still not clear to me if the result of `JvmtiEnvBase::is_cthread_with_continuation()` impacts if you have to possibly skip hidden frames. In other words, do you always have to do the `if` block that follows, no matter what `JvmtiEnvBase::is_cthread_with_continuation()` returns? If you don't, then maybe instead of a "? :"  expression, an if/else would be better. I'm not sure if the following is correct, but something like:

    javaVFrame *jvf;
    if (JvmtiEnvBase::is_cthread_with_continuation(jt)) {
      jvf = jt->carrier_last_java_vframe(reg_map_p);
    } else {
      jvf - jt->last_java_vframe(reg_map_p);
      // Skipping hidden frames when jt->is_in_tmp_VTMS_transition()==true results
      // in returning jvf==NULL, and so, empty stack traces for carrier threads.
      if (!jt->is_in_tmp_VTMS_transition()) {
        jvf = check_and_skip_hidden_frames(jt, jvf);
      }
    }

-------------

PR: https://git.openjdk.org/jdk/pull/10321

From cjplummer at openjdk.org  Wed Sep 21 17:32:17 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 21 Sep 2022 17:32:17 GMT
Subject: RFR: 8293613: need to properly handle and hide tmp VTMS
 transitions [v3]
In-Reply-To: <dv7Njja_pwgsqGMUu9Te08dhKnFsk5wXPf3O2OT65ic=.55108dd8-03e3-4cc1-b858-183d415ca9fd@github.com>
References: <O_jzls_cv3HBC0NbzuYV2LXaW9VB2M18FroUfXWXd2w=.fa9d1f3c-40a2-42bd-a09b-dadd5032e513@github.com>
 <ve9g9LcSrawK3kb-TxKqxkSUOvkvnIsebd84GAub2DQ=.54a4a79b-be0a-47ef-99ba-63b93236cf08@github.com>
 <vMfCeRbX7oTnnv5-1PggLMUc1Q8MjZ0mnSFp5cutdTA=.08a9c27a-1bc2-4118-8f88-56c741df1435@github.com>
 <dv7Njja_pwgsqGMUu9Te08dhKnFsk5wXPf3O2OT65ic=.55108dd8-03e3-4cc1-b858-183d415ca9fd@github.com>
Message-ID: <N1Ers_8OPbyoEZgQUT3iEtaQ6nni7mTb6GQ5AYBPcoU=.0c069571-98d0-46cd-bcf6-75224188951d@github.com>

On Tue, 20 Sep 2022 22:41:50 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/runtime/javaThread.cpp line 1174:
>> 
>>> 1172: #if INCLUDE_JVMTI
>>> 1173:   // Suspending a JavaThread in VTMS transition or disabling VTMS transitions can cause deadlocks.
>>> 1174:   assert(!is_in_non_tmp_VTMS_transition(), "no suspend allowed in VTMS transition");
>> 
>> IMHO, a non tmp VTMS transition should be considered a type of VTMS transition, so the assert check here does not really match the assert text. Also see my related comments below on naming and use of these flags and APIs.
>
> Thanks. Accepted.

I thought I was pointing out a naming issue, but your change indicates that it was actually a bug, and it is ok to be in a tmp transition here. Is that correct?

-------------

PR: https://git.openjdk.org/jdk/pull/10321

From jbhateja at openjdk.org  Wed Sep 21 17:53:36 2022
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 21 Sep 2022 17:53:36 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v8]
In-Reply-To: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com>
Message-ID: <XbkYoySQ6LDlu44mOsg2Ok8DIoFeUMAndQOwfwSFA_E=.c5cb858f-8f8a-4d30-b263-de3c4c1c5da2@github.com>

On Fri, 2 Sep 2022 00:52:49 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> 8289552: Make intrinsic conversions between bit representations of half precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments

Hi Smita, Adding some review comments. 
Best Regards

src/hotspot/cpu/x86/assembler_x86.cpp line 1925:

> 1923: 
> 1924: void Assembler::vcvtps2ph(XMMRegister dst, XMMRegister src, int imm8, int vector_len) {
> 1925:   assert(VM_Version::supports_evex() || VM_Version::supports_f16c(), "");

Since you are accepting vector_len so adding a AVX512VL check will be more appropriate here.

src/hotspot/cpu/x86/assembler_x86.cpp line 1932:

> 1930: 
> 1931: void Assembler::evcvtps2ph(Address dst, KRegister mask, XMMRegister src, int imm8, int vector_len) {
> 1932:   assert(VM_Version::supports_evex(), "");

Same as above.

src/hotspot/cpu/x86/assembler_x86.cpp line 1946:

> 1944: 
> 1945: void Assembler::vcvtph2ps(XMMRegister dst, XMMRegister src, int vector_len) {
> 1946:   assert(VM_Version::supports_evex() || VM_Version::supports_f16c(), "");

same as above.

src/hotspot/cpu/x86/assembler_x86.cpp line 1949:

> 1947:   InstructionAttr attributes(vector_len, /* rex_w */ false, /* legacy_mode */false, /* no_mask_reg */ true, /* uses_vl */ true);
> 1948:   int encode = vex_prefix_and_encode(dst->encoding(), 0, src->encoding(), VEX_SIMD_66, VEX_OPCODE_0F_38, &attributes);
> 1949:   emit_int16((unsigned char)0x13, (0xC0 | encode));

Please rebase this patch, recently emit_int16 have starting accepting the unsigned char argument.

src/hotspot/cpu/x86/x86.ad line 1686:

> 1684:     case Op_ConvHF2F:
> 1685:       if (!VM_Version::supports_f16c() && !(VM_Version::supports_evex() &&
> 1686:           VM_Version::supports_avx512vl())) {

Redundant evex check can be removed.

src/hotspot/cpu/x86/x86_64.ad line 11309:

> 11307: %}
> 11308: 
> 11309: instruct convF2HF_reg_reg(rRegI dst, regF src, regF tmp) %{

You can move these patterns to common .ad file it will also handle 32 bit target.

src/hotspot/cpu/x86/x86_64.ad line 11329:

> 11327:   ins_encode %{
> 11328:      __ movl($rtmp$$Register, 0x1);
> 11329:      __ kmovdl($ktmp$$KRegister, $rtmp$$Register);

kmovdl needs AVX512BW, so there should a check for it in the predicate.

src/hotspot/share/opto/convertnode.cpp line 166:

> 164: //=============================================================================
> 165: //------------------------------Value------------------------------------------
> 166: const Type* ConvF2HFNode::Value(PhaseGVN* phase) const {

IR framework based test will compliment newly introduced IR nodes.

src/hotspot/share/opto/convertnode.hpp line 107:

> 105: class ConvF2HFNode : public Node {
> 106:   public:
> 107:   ConvF2HFNode( Node *in1 ) : Node(0,in1) {}

Additional space b/w , and in1

src/hotspot/share/opto/convertnode.hpp line 146:

> 144: class ConvHF2FNode : public Node {
> 145:   public:
> 146:   ConvHF2FNode( Node *in1 ) : Node(0,in1) {}

Space b/w , and in1

src/hotspot/share/runtime/sharedRuntime.cpp line 452:

> 450: // Reference implementation at src/java.base/share/classes/java/lang/Float.java:floatToFloat16
> 451: JRT_LEAF(jshort, SharedRuntime::f2hf(jfloat  x))
> 452:   jint doppel = SharedRuntime::f2i(x);

Newly added constant value computation runtime routines can be validated by a gtest.

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From jwaters at openjdk.org  Wed Sep 21 18:03:06 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 21 Sep 2022 18:03:06 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v13]
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <xjChtBUon9UjGtgHyH-VcWaDKtb5J4ja4hv-Bsp9BGk=.dfa98317-b2c3-4245-bdea-bcd8fbb18f16@github.com>

> Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time 
> 
> Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future.

Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision:

  Rework JLI_ReportErrorMessageSys

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9870/files
  - new: https://git.openjdk.org/jdk/pull/9870/files/ff398500..3303cbb8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=11-12

  Stats: 145921 lines in 2250 files changed: 67760 ins; 63795 del; 14366 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From asotona at openjdk.org  Wed Sep 21 18:05:46 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 21 Sep 2022 18:05:46 GMT
Subject: Integrated: 8294062: Improve parsing performance of
 j.l.c.MethodTypeDesc
In-Reply-To: <Q0iEUit9CcB8dvFJUMCKQoSYx51BJ75Mejv-pGcl2OI=.f1a538b0-2d74-4c2c-a50d-ba70d64d84da@github.com>
References: <Q0iEUit9CcB8dvFJUMCKQoSYx51BJ75Mejv-pGcl2OI=.f1a538b0-2d74-4c2c-a50d-ba70d64d84da@github.com>
Message-ID: <Iz9DvtkjkPNIBK5bK59hDKzaUYHVFy3yYZIs6u_6qno=.090a0aa0-c995-44ef-9740-dd2d7e1241b9@github.com>

On Tue, 20 Sep 2022 13:08:20 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Parsing performance of `j.l.c.MethodTypeDescriptor::ofDescriptor` can be significantly improved and add performance boost to intensive users.
> 
> Two main reasons have been identified and fixed in this patch:
> 
> First glitch is late insertion of return type to the first position of `j.u.ArrayList`, causing all previously parsed parameter types to shift using `System::arraycopy`.
> 
> Proposed patch inserts a placeholder for the return type first and replaces it with return type later.
> 
> Second performance degradation is in `MethodTypeDescriptor::skipOverFieldSignature`, where each identified class descriptor is exactly located by `String::indexOf`, extracted by `String::substring`, and passed for for the purpose of verification to `ConstantUtils::verifyUnqualifiedClassName`.
> 
> Proposed patch inlines the unqualified class name verification into `ConstantUtils::skipOverFieldSignature` parsing loop and so eliminates calls of `String::indexOf` and `String::substring`. Package private method `ConstantUtils::verifyUnqualifiedClassName` has no other use within the package, so it is removed.
> 
> Please review proposed performance improving patch.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 9f90eb05
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9f90eb0524aba7bc40c574a067ce37ccfd8753b1
Stats:     44 lines in 1 file changed: 13 ins; 22 del; 9 mod

8294062: Improve parsing performance of j.l.c.MethodTypeDesc

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/10358

From mchung at openjdk.org  Wed Sep 21 18:09:14 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 21 Sep 2022 18:09:14 GMT
Subject: RFR: JDK-8293701: jdeps InverseDepsAnalyzer runs into
 NoSuchElementException: No value present
In-Reply-To: <q3kxJJ2Nc09C47lndSw09Dk7iWzP_lVnF4gaEj9Z5sA=.9b796652-1afd-43b0-8ad2-b335e89c5e93@github.com>
References: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
 <q3kxJJ2Nc09C47lndSw09Dk7iWzP_lVnF4gaEj9Z5sA=.9b796652-1afd-43b0-8ad2-b335e89c5e93@github.com>
Message-ID: <qqokCZH03XvxbeYysfFRy1JkCw4Vdf2enrcZ1LF8SQI=.c5189016-c1f9-421b-8c4f-6db307d7851d@github.com>

On Wed, 21 Sep 2022 14:38:50 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We noticed that with certain jar file input, jdeps runs into the following exception, this happens with jdk11, 17 and 20.
>> 
>> jdeps.exe --multi-release 11 --module-path . --inverse --package com.sap.nw.performance.supa.client test.jar
>> 
>> Inverse transitive dependences matching packages [com.sap.nw.performance.supa.client]
>> Exception in thread "main" java.util.NoSuchElementException: No value present
>>         at java.base/java.util.Optional.get(Optional.java:148)
>>         at jdk.jdeps/com.sun.tools.jdeps.InverseDepsAnalyzer.lambda$inverseDependences$2(InverseDepsAnalyzer.java:150)
>>         at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>>         at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>>         at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
>>         at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>>         at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
>> 
>> So an additional  check might be a good idea.
>
> One additional comment about the jdeps --help output 
> https://github.com/openjdk/jdk/blob/master/src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties#L139
> 
> 
> main.opt.I=\
> \  -I\n\
> \  --inverse                     Analyzes the dependences per other given options\n\
> \                                and then find all artifacts that directly\n\
> \                                and indirectly depend on the matching nodes.\n\
> \                                This is equivalent to the inverse of\n\
> \                                compile-time view analysis and print\n\
> \                                dependency summary.  This option must use\n\
> \                                with --require, --package or --regex option.
> 
> Should this be better  'This option must be used . . .' ?  And what about a sentence explaining what 'nodes' you are talking about ?
> 
> Btw is there some trace mode telling me more where exactly the jdeps tool fails in this particular case ?

@MBaesken I move the debugging discussion to the JBS issue (https://bugs.openjdk.org/browse/JDK-8293701).   We should resume this PR once the cause of the problem is understood.

-------------

PR: https://git.openjdk.org/jdk/pull/10300

From rriggs at openjdk.org  Wed Sep 21 20:39:17 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 21 Sep 2022 20:39:17 GMT
Subject: RFR: 8234262: Unmask SIGQUIT in a child process
Message-ID: <QhoJ88tNkPq3N9ybNwnEEHnpPPiFfwhVtXqMTtRGk1o=.ab0b8831-16a1-4802-8730-708da809349e@github.com>

Clear the signal mask of the child when launching with posix_spawn.

SIGQUIT signals are handled on non-Java Threads by the VM.
For Java threads the signal mask blocks SIGQUIT.  
The ProcessBuilder uses posix_spawn on all platforms to create new processes.
Without a specific request, the child process inherits the signal masks from the parent.

-------------

Commit messages:
 - 8234262: Unmask the SIGQUIT in a child process

Changes: https://git.openjdk.org/jdk/pull/10379/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10379&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8234262
  Stats: 65 lines in 2 files changed: 63 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10379.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10379/head:pull/10379

PR: https://git.openjdk.org/jdk/pull/10379

From bpb at openjdk.org  Wed Sep 21 20:55:16 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 21 Sep 2022 20:55:16 GMT
Subject: RFR: 8234262: Unmask SIGQUIT in a child process
In-Reply-To: <QhoJ88tNkPq3N9ybNwnEEHnpPPiFfwhVtXqMTtRGk1o=.ab0b8831-16a1-4802-8730-708da809349e@github.com>
References: <QhoJ88tNkPq3N9ybNwnEEHnpPPiFfwhVtXqMTtRGk1o=.ab0b8831-16a1-4802-8730-708da809349e@github.com>
Message-ID: <rpcUWU2b9dd4DLWkdykC-Y-InB4stasqCbEZkBiUF6o=.d5601ec6-925b-4cea-9bbc-bdd427e45a6d@github.com>

On Wed, 21 Sep 2022 20:30:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Clear the signal mask of the child when launching with posix_spawn.
> 
> SIGQUIT signals are handled on non-Java Threads by the VM.
> For Java threads the signal mask blocks SIGQUIT.  
> The ProcessBuilder uses posix_spawn on all platforms to create new processes.
> Without a specific request, the child process inherits the signal masks from the parent.

Looks correct.

-------------

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10379

From stuart.marks at oracle.com  Wed Sep 21 21:19:01 2022
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 21 Sep 2022 14:19:01 -0700
Subject: [BUG]Collections.unmodifiableMap(map).entrySet().iterator().forEachRemaining
 ismissing null check
In-Reply-To: <58d3e531-515b-2aa1-9f27-ffa8e5fc8fe6@icemanx.nl>
References: <ae963decc60341bcb6738169ee8509e3@vodafonemail.de>
 <58d3e531-515b-2aa1-9f27-ffa8e5fc8fe6@icemanx.nl>
Message-ID: <b3737bde-0498-c6d8-bcf9-9fbbc96dad0b@oracle.com>

Thanks for filing this. This was (some time ago) moved into the main bug database:

https://bugs.openjdk.org/browse/JDK-8292317

s'marks

On 8/12/22 7:05 AM, Rob Spoor wrote:
> I found one similar issue, https://bugs.openjdk.org/browse/JDK-8015008, but that was 
> for an empty primitive iterator. I've created a bug report with id 9073784.
> 
> 
> On 11/08/2022 01:24, some-java-user-99206970363698485155 at vodafonemail.de wrote:
>> Hi,
>> could you please report this at https://bugreport.java.com/bugreport/
>> (please also first search at 
>> https://bugs.openjdk.org/issues?jql=project%3DJDK%20AND%20issuetype%3DBug
>> whether it has already been reported).
>>
>> This also seems to affect the `CheckedEntrySet`; would be good if you could 
>> mention that
>> in your report as well.
>>
>> I think the easiest reproducers for this can be created with an empty map:
>> ```
>> Collections.unmodifiableMap(Map.of()).entrySet().iterator().forEachRemaining(null)
>> Collections.checkedMap(Map.of(), String.class, 
>> String.class).entrySet().iterator().forEachRemaining(null)
>> ```
>> Per specification both calls should throw a NullPointerException, but they don't 
>> throw it.
>>
>> Might also be worth recommending to the JDK authors to perform the null check in 
>> the internal
>> `entryConsumer` method to avoid having it repeated 4 times, once for each caller. 
>> The `CheckedEntrySet`
>> would still need a separate null check though.
>>
>> Kind regards
>>
> 

From rriggs at openjdk.org  Wed Sep 21 21:37:59 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 21 Sep 2022 21:37:59 GMT
Subject: RFR: 8234262: Unmask SIGQUIT in a child process [v2]
In-Reply-To: <QhoJ88tNkPq3N9ybNwnEEHnpPPiFfwhVtXqMTtRGk1o=.ab0b8831-16a1-4802-8730-708da809349e@github.com>
References: <QhoJ88tNkPq3N9ybNwnEEHnpPPiFfwhVtXqMTtRGk1o=.ab0b8831-16a1-4802-8730-708da809349e@github.com>
Message-ID: <QibEFnEJKf51oYAMrQ3Ti-NhVdGB60yfChCnOtlcWd8=.b9a6982a-edc4-4328-81d5-6510e2410e04@github.com>

> Clear the signal mask of the child when launching with posix_spawn.
> 
> SIGQUIT signals are handled on non-Java Threads by the VM.
> For Java threads the signal mask blocks SIGQUIT.  
> The ProcessBuilder uses posix_spawn on all platforms to create new processes.
> Without a specific request, the child process inherits the signal masks from the parent.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Test both with and without -Xrs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10379/files
  - new: https://git.openjdk.org/jdk/pull/10379/files/c3b8d950..e0e854bd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10379&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10379&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10379.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10379/head:pull/10379

PR: https://git.openjdk.org/jdk/pull/10379

From bpb at openjdk.org  Wed Sep 21 22:15:18 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 21 Sep 2022 22:15:18 GMT
Subject: RFR: 8234262: Unmask SIGQUIT in a child process [v2]
In-Reply-To: <QibEFnEJKf51oYAMrQ3Ti-NhVdGB60yfChCnOtlcWd8=.b9a6982a-edc4-4328-81d5-6510e2410e04@github.com>
References: <QhoJ88tNkPq3N9ybNwnEEHnpPPiFfwhVtXqMTtRGk1o=.ab0b8831-16a1-4802-8730-708da809349e@github.com>
 <QibEFnEJKf51oYAMrQ3Ti-NhVdGB60yfChCnOtlcWd8=.b9a6982a-edc4-4328-81d5-6510e2410e04@github.com>
Message-ID: <okdywBBKYkyMFEZcsj-Li4pmGgEUPxJ-3NKJfxJHRtg=.8430ba34-51e6-4ec5-93dc-5cdf88758115@github.com>

On Wed, 21 Sep 2022 21:37:59 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Clear the signal mask of the child when launching with posix_spawn.
>> 
>> SIGQUIT signals are handled on non-Java Threads by the VM.
>> For Java threads the signal mask blocks SIGQUIT.  
>> The ProcessBuilder uses posix_spawn on all platforms to create new processes.
>> Without a specific request, the child process inherits the signal masks from the parent.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test both with and without -Xrs

Update looks good.

-------------

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10379

From sspitsyn at openjdk.org  Wed Sep 21 22:18:22 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 21 Sep 2022 22:18:22 GMT
Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume
In-Reply-To: <l_lUEdZ-ORALa9ux2qu_PZZFm2IpIZs02kdC-tCQQBM=.e96f9fab-8d68-4ba1-b0f6-2b9b5c397226@github.com>
References: <l_lUEdZ-ORALa9ux2qu_PZZFm2IpIZs02kdC-tCQQBM=.e96f9fab-8d68-4ba1-b0f6-2b9b5c397226@github.com>
Message-ID: <o4fry_MZykGgDNEToz2DTvFMtXek58yGIppq-gb6hfk=.f5f7416b-969c-4fdc-a1a4-9fde7f6fa8a1@github.com>

On Sun, 18 Sep 2022 16:32:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Degrade Thread.suspend/resume to throw UOE unconditionally.
> 
> Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive.
> 
> The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs.
> 
> Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread).

Looks good.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10324

From jiefu at openjdk.org  Wed Sep 21 22:58:13 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Wed, 21 Sep 2022 22:58:13 GMT
Subject: RFR: 8293792: runtime/Dictionary/ProtectionDomainCacheTest.java
 fails with FileAlreadyExistsException: /tmp
In-Reply-To: <YId_n7sZfownuHpLtp7iC1FDTx9A4mzZ-eSQC40pilQ=.5c1e223f-3625-4a67-88d2-e099f3604946@github.com>
References: <Vfaxg8rSBOwZrJi22f0JlNCCmgohix2_LXoAUb9G0Io=.796dccd4-683c-4026-ba63-b1631d484085@github.com>
 <YId_n7sZfownuHpLtp7iC1FDTx9A4mzZ-eSQC40pilQ=.5c1e223f-3625-4a67-88d2-e099f3604946@github.com>
Message-ID: <wmyf5HGgZZnnk53ZdzqiZQi5xACHbkQYtLyjLzNhbWw=.8201e137-ea19-4d60-835a-209ed47bac3b@github.com>

On Wed, 21 Sep 2022 15:34:03 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Withdraw my approval per Alan's comment.

Okay.
Thanks @iklam and @AlanBateman .

-------------

PR: https://git.openjdk.org/jdk/pull/10266

From dholmes at openjdk.org  Wed Sep 21 23:14:18 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 21 Sep 2022 23:14:18 GMT
Subject: RFR: 8234262: Unmask SIGQUIT in a child process [v2]
In-Reply-To: <QibEFnEJKf51oYAMrQ3Ti-NhVdGB60yfChCnOtlcWd8=.b9a6982a-edc4-4328-81d5-6510e2410e04@github.com>
References: <QhoJ88tNkPq3N9ybNwnEEHnpPPiFfwhVtXqMTtRGk1o=.ab0b8831-16a1-4802-8730-708da809349e@github.com>
 <QibEFnEJKf51oYAMrQ3Ti-NhVdGB60yfChCnOtlcWd8=.b9a6982a-edc4-4328-81d5-6510e2410e04@github.com>
Message-ID: <RxgZaC-R0BjnATqBINLlCT6Xj9XpakZI2E8KR7hYWeQ=.8efaa74e-b2d5-4d4e-8b8c-b45903048dbf@github.com>

On Wed, 21 Sep 2022 21:37:59 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Clear the signal mask of the child when launching with posix_spawn.
>> 
>> SIGQUIT signals are handled on non-Java Threads by the VM.
>> For Java threads the signal mask blocks SIGQUIT.  
>> The ProcessBuilder uses posix_spawn on all platforms to create new processes.
>> Without a specific request, the child process inherits the signal masks from the parent.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test both with and without -Xrs

Hi Roger,
Using the spawn attributes seems more far reaching than simply temporarily changing the signal mask of the calling thread. I'd be concerned this has some unintended side-effects.

-------------

PR: https://git.openjdk.org/jdk/pull/10379

From stuart.marks at oracle.com  Thu Sep 22 00:38:42 2022
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 21 Sep 2022 17:38:42 -0700
Subject: Sequenced Collections
In-Reply-To: <024fe055-c94e-94e2-cf21-bca828304929@raelity.com>
References: <f6edafc8-03f1-4f3a-1382-592688785c6e@raelity.com>
 <06ca6cc9-4d35-e327-5d03-2378302f72dd@gmail.com>
 <024fe055-c94e-94e2-cf21-bca828304929@raelity.com>
Message-ID: <44ff182d-f251-e62f-9560-a7e8d325187e@oracle.com>

Hi, yes, this is the right place to discuss Sequenced Collections. I'm glad you find 
it promising.

Note that Sequenced Collections actually has very little implementation in it, aside 
from various reversed views of things. The actual data is still stored in existing 
concrete collections such as ArrayList, ArrayDeque, LinkedHashMap, and TreeMap.

I think Sequenced Collections has the right set of abstractions in it as it stands, 
and I don't want to expand its scope by talking about additional concepts like size 
limits or eviction policy.

However, those things are quite reasonable to discuss independently of the current 
Sequenced Collections proposal. Having a maximum size on a collection seems 
independent of sequencing. An eviction policy *might* be based on the sequence, but 
it might not; consider the various eviction policies available for a cache library 
such as Caffeine [1].

[1] https://github.com/ben-manes/caffeine/wiki

However, I'm somewhat skeptical of trying to build things like eviction policies 
directly into collections. It's tempting to add a simple thing like a size and just 
throw away things in some well-defined order whenever the size is exceeded. The 
problem is that if this policy doesn't do *exactly* what you want to do, then you're 
out of luck.

The current (pre Sequenced Collections) LinkedHashMap is a good example of this. 
It's suitable for a least-recently-inserted expiration policy; there's a method 
removeEldestEntry() that programs can use to implement a simple policy, size-based 
or otherwise. (Unfortunately they have to subclass-and-override, but whatever.) The 
problem is that it allows removal of only one element -- the eldest (first) element.

If you want to change the policy of insertion order of an LHM, you have only one 
alternative: access order. Enabling this has some weird side effects though. For 
example, get() now rearranges the order of entries in the map, and is thus a 
structural modification -- which means that it spoils any iterators over the map's 
views.

These are both fairly common cases, which is probably why they were added. But 
they're not very flexible, and if you want to do something slightly different, 
you're on your own -- and it's pretty hard to implement your own policy, because LHM 
lacks a bunch of essential operations.

Where the Sequenced Collections proposal helps is that instead of adding more 
policies, it adds the missing primitive operations. You can add/get/remove at either 
end, and you can reposition mappings to either end. If you have some different 
recent-usage policy or some unusual cache eviction policy that I've never heard of, 
you can use the primitives to implement it yourself. That's much better than trying 
to bake a few more specific cases into LinkedHashMap or other collections.

> Is there a discussion about making the SynchronizedCollection family of classes public? 

No. Synchronizing on every collection operation is the wrong level of abstraction. 
Typical collection usage involves too much external iteration and too much 
check-then-act logic. Callers would have to wrap those in synchronized blocks, and 
in general they don't know when that's necessary. Certain transaction-style 
operations (like Map::computeIfAbsent) can be made to work, but those are all pretty 
low level.

s'marks



On 9/21/22 9:32 AM, Ernie Rael wrote:
>  > I don't see why you think a general collection...
> 
> I thought the Subject would be sufficient to indicate that I was not talking about 
> collections in general. I should have been more precise with my words; guess I was 
> just excited by a bi-directional ordered set.
> 
> The MRU _example_ is useful; the current collections handle it poorly and Sequenced 
> Collections is ideal. Caches with an eviction policy are common; I suspect caches 
> will be a common use for SequencedSet family. Note there are fixed sized Collections 
> and SequencedCollection borrows heavily from that family. Perhaps this issue should 
> be considered in the context of adding an **Eviction Policy** to appropriate 
> collections.
> 
> MRU is a Collection; for example, I pass an MRU to a persistence mechanism that 
> takes a collection. Saying "all methods offered by `Collection` should [not] even be 
> part of an `MRU` interface" is innacurate, especially when considered in the context 
> of a SequencedCollection.
> 
> -ernie
> 
> PS - Loosely related is extending a Collection and providing a synchronized version. 
> Is there a discussion about making the SynchronizedCollection family of classes public?
> 
> 
> On 9/21/22 4:22 AM, John Hendrikx wrote:
>> I don't see why you think a general collection, that is in 99.9% of the cases not 
>> used to implement an MRU, should burden every call to #add with a check to see if 
>> it isn't exceeding its maximum size or to see if a maximum size has been set.
>>
>> This is much better done by composition, as I don't think all methods offered by 
>> `Collection` should even be part of an `MRU` interface.
>>
>> --John
>>
>> On 20/09/2022 21:08, Ernie Rael wrote:
>>> (There may be a better place to send this, let me know where)
>>>
>>> Suggesting an option to limit the size of the collection, e.g "setMaxSize(int)", 
>>> default of zero means no limit.
>>>
>>> I put together "interface MRU<E> extends Collection<E>" some months ago, it has 
>>> two implementations based on LinkedList and LinkedHashSet. The code can be seen 
>>> at 
>>> https://sourceforge.net/p/jvi/raelity-lib/ci/default/tree/lib/src/main/java/com/raelity/lib/ 
>>>
>>>
>>> A SequencedCollection, as outlined in the JEP draft 2020/09/01, would be almost 
>>> perfect to implement MRU; I've run into most of the problems/issues discussed in 
>>> the JEP draft.
>>>
>>> The MRU is a cache, as I use it; it typically has a max size for the collection. 
>>> Handling this natively in the collection would be ideal; if an add operation 
>>> would overflow, remove the item at the other end. Note that addAll() is used when 
>>> initializing from backing store.
>>>
>>> FYI, I use a "Supplier<Integer>" to the constructor to provide maxSize, but a 
>>> property makes much more sense. I'll make that change in MRU for sanity, and get 
>>> rid of the trim() method. setMaxSize can do the trim.
>>>
>>> -ernie
>>>
>>
> 

From darcy at openjdk.org  Thu Sep 22 04:38:30 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 22 Sep 2022 04:38:30 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v4]
In-Reply-To: <ZTzHjlUXhJf5U3PndgGMZUpwbIJhJ0kSxL2am_PfFT8=.4279d477-9a1e-4a2c-b334-90cc60b5592b@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <ZTzHjlUXhJf5U3PndgGMZUpwbIJhJ0kSxL2am_PfFT8=.4279d477-9a1e-4a2c-b334-90cc60b5592b@github.com>
Message-ID: <zjl7cwFlpwxgYjDbchAw8qBNLcLq5n4CP940XDIlq8s=.91594dec-7c4a-45b9-8cbe-ec7ec51dc74c@github.com>

On Sat, 17 Sep 2022 08:41:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
>> 
>> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
>> 
>> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
>> 
>> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.
>
> 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 12 additional commits since the last revision:
> 
>  - Merge
>  - Updates to Java Thread Primitive Deprecation page
>  - Repalce "it" with "victim thread"
>  - Merge
>  - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop
>  - become -> became in javadoc
>  - Merge
>  - Remove stopThread permission from RuntimePermission table, exclude jshell tests
>  - Deprecate for removal
>  - Next iteration, update dates in headers
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/c06e7ac5...93806f99

src/java.base/share/classes/java/lang/Thread.java line 1632:

> 1630: 
> 1631:     /**
> 1632:      * Throws {@code UnsupportedOperationException}.

Consider using an implSpec tag here.

-------------

PR: https://git.openjdk.org/jdk/pull/10230

From jiefu at openjdk.org  Thu Sep 22 06:05:25 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Thu, 22 Sep 2022 06:05:25 GMT
Subject: RFR: 8293792: runtime/Dictionary/ProtectionDomainCacheTest.java
 fails with FileAlreadyExistsException: /tmp
In-Reply-To: <U9sTPdjGaCvsM5-h9sa68p2kuyngnHbUaBlxsEyKQ9w=.ad22cf27-d2a1-4953-82cf-2a36f6c196cd@github.com>
References: <Vfaxg8rSBOwZrJi22f0JlNCCmgohix2_LXoAUb9G0Io=.796dccd4-683c-4026-ba63-b1631d484085@github.com>
 <U9sTPdjGaCvsM5-h9sa68p2kuyngnHbUaBlxsEyKQ9w=.ad22cf27-d2a1-4953-82cf-2a36f6c196cd@github.com>
Message-ID: <uqpQiF-Y4Bm0DiIDsmnnT5WxZ1_EepIGrK859NVgDOw=.4ab9af00-1356-4244-9220-1be2a738d34e@github.com>

On Wed, 14 Sep 2022 10:47:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hi all,
>> 
>> runtime/Dictionary/ProtectionDomainCacheTest.java fails on Linux if `/tmp` is a symbolic link directory.
>> The root cause is that `JarUtils.createJarFile` [1] will throw `FileAlreadyExistsException` if `parent` is a symbolic directory.
>> So it seems better to test the existance of `parent` before creation.
>> 
>> Testing:
>> - tier1~3 on Linux/x64 in progress, seems fine until now
>> 
>> Thanks.
>> Best regards,
>> Jie
>> 
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/util/JarUtils.java#L72
>
> I could reproduce the issue with `Files.createDirectories` on a macos with a trivial program. It appears to be because of the use of `NOFOLLOW_LINKS` here https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/file/Files.java#L808. To me this appears to be something that either needs to be clarified in the the `Files.createDirectories` API or addressed/fixed there. I have asked for inputs on this from others who have more knowledge of this area.

Close this one since it would be fixed by @jaikiran in a separate pr.
Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10266

From jiefu at openjdk.org  Thu Sep 22 06:05:25 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Thu, 22 Sep 2022 06:05:25 GMT
Subject: Withdrawn: 8293792: runtime/Dictionary/ProtectionDomainCacheTest.java
 fails with FileAlreadyExistsException: /tmp
In-Reply-To: <Vfaxg8rSBOwZrJi22f0JlNCCmgohix2_LXoAUb9G0Io=.796dccd4-683c-4026-ba63-b1631d484085@github.com>
References: <Vfaxg8rSBOwZrJi22f0JlNCCmgohix2_LXoAUb9G0Io=.796dccd4-683c-4026-ba63-b1631d484085@github.com>
Message-ID: <50hVfMNYSl_O0Hi_gHVcMRnA3n2hBKGZNRZUz0QGsfc=.cb306b35-c343-4d63-ba61-bc7aabf6b94a@github.com>

On Wed, 14 Sep 2022 09:42:37 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> runtime/Dictionary/ProtectionDomainCacheTest.java fails on Linux if `/tmp` is a symbolic link directory.
> The root cause is that `JarUtils.createJarFile` [1] will throw `FileAlreadyExistsException` if `parent` is a symbolic directory.
> So it seems better to test the existance of `parent` before creation.
> 
> Testing:
> - tier1~3 on Linux/x64 in progress, seems fine until now
> 
> Thanks.
> Best regards,
> Jie
> 
> 
> [1] https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/util/JarUtils.java#L72

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/10266

From rehn at openjdk.org  Thu Sep 22 06:13:21 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 22 Sep 2022 06:13:21 GMT
Subject: RFR: 8290482: Update JNI Specification of DestroyJavaVM for better
 alignment with JLS, JVMS, and Java SE API Specifications [v4]
In-Reply-To: <5LZVfXnTpbyr_NWeYid9qzKrnZ6t2b7ZL5BtHEZ4Syc=.bff15db2-726a-4976-89f1-edd826d75bf2@github.com>
References: <M2IRKiuONiNI45YTu9wdu1o8ZXJslnxRmgMvnlVU478=.4aa03d22-0395-4354-bf41-f11a74df791a@github.com>
 <5LZVfXnTpbyr_NWeYid9qzKrnZ6t2b7ZL5BtHEZ4Syc=.bff15db2-726a-4976-89f1-edd826d75bf2@github.com>
Message-ID: <vkwmx3eyXlWo55RjJjMZFRP9msoMZK-Ryw1AsWUxIuo=.27b93d97-8565-43a8-88fc-cb1ece45f741@github.com>

On Tue, 20 Sep 2022 10:37:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This update is primarily about changes to the JNI Invocation API specification, mainly in relation to `DestroyJavaVM`. The motivation for the changes is to align with changes being made to the JLS, JVMS and `java.lang.Runtime`, specifications in relation to VM termination - ref:
>> 
>> JDK-8290196 12.8: Clarify the definition of program exit
>> https://bugs.openjdk.org/browse/JDK-8290196
>> 
>> JDK-8290388 5.7: Clarify the definition of JVM termination
>> https://bugs.openjdk.org/browse/JDK-8290388
>> 
>> JDK-8290036 Define and specify Runtime shutdown sequence
>> https://bugs.openjdk.org/browse/JDK-8290036
>> 
>> Mostly these are just non-normative changes to the JNI spec prose but there are two actual specification changes:
>> 
>> 1.  The fact it is an error to detach a thread with active Java frames was only mentioned in the overview section, not in the actual `DetachCurrentThread` specification. (Just an oversight - the VM already checked this)
>> 
>> 2.  We need to make it an error to call `DestroyJavaVM` from an attached thread with active Java frames (as this can't work for the same reason we disallow `DetachCurrentThread`). This requires an implementation change in Hotspot.
>> 
>> Issue 2 covers the code change, and regression test, in this PR.
>> 
>> In addition the specification changes can be seen here:
>> 
>> - specdiff: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/diff.html
>> - original: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-original.html
>> - new: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-new.html
>> 
>> The specification itself is not open but comments on the spec changes are welcome - though please see the JBS issue and CSR request first. The revised wording has already been extensively reviewed/negotiated between Alex Buckley, Stuart Marks and myself, so any change must either be a glaring error/problem or else a trivial adjustment.
>> 
>> Thank you.
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix JniVersion test

Looks good, thank you!

-------------

Marked as reviewed by rehn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10352

From haosun at openjdk.org  Thu Sep 22 07:08:12 2022
From: haosun at openjdk.org (Hao Sun)
Date: Thu, 22 Sep 2022 07:08:12 GMT
Subject: RFR: 8293887: AArch64 build failure with GCC 12 due to
 maybe-uninitialized warning in libfdlibm k_rem_pio2.c
Message-ID: <UTaCIvPdArIMVc2jDoPYp72K5MelURpuipDuZigrDy0=.16cf4031-3791-4fd4-aeb3-598fa4faf4db@github.com>

This warning seems to be a false positive, because 1) array "fq" with elements from index 0 to "jz" has already been initialized as "fw" at line 290 [1], and 2) variable "jz" should be non-negative from the comment at line 99 [2].

Note-1: GCC warning option -Wmaybe-uninitialized is not a new one. Note-2: x86-64 build with GCC 12 on Ubuntu 22.04 passed in my local test.

This warning is raised only on GCC 12 + AArch64. I suspect it might be some GCC 12 bug, so I reported it to GCC community [3].

Since it involves third party code, I think it's better to suppress the warning by simply disabling this warning option in the makefile.

Testing: Release builds with GCC 9, GCC 11 and GCC 12 passed on Ubuntu 22.04/AArch64 system.

[1] https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libfdlibm/k_rem_pio2.c#L290 
[2] https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libfdlibm/k_rem_pio2.c#L99 
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106992

-------------

Commit messages:
 - 8293887: AArch64 build failure with GCC 12 due to maybe-uninitialized warning in libfdlibm k_rem_pio2.c

Changes: https://git.openjdk.org/jdk/pull/10386/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10386&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293887
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10386.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10386/head:pull/10386

PR: https://git.openjdk.org/jdk/pull/10386

From jpai at openjdk.org  Thu Sep 22 07:12:17 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 22 Sep 2022 07:12:17 GMT
Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume
In-Reply-To: <l_lUEdZ-ORALa9ux2qu_PZZFm2IpIZs02kdC-tCQQBM=.e96f9fab-8d68-4ba1-b0f6-2b9b5c397226@github.com>
References: <l_lUEdZ-ORALa9ux2qu_PZZFm2IpIZs02kdC-tCQQBM=.e96f9fab-8d68-4ba1-b0f6-2b9b5c397226@github.com>
Message-ID: <jPf2fQcE_hiBUSF6veHiGBrsrQBkgKJnWrHIOdJXzA4=.af43ed4c-6252-496a-9f20-b2706c36c9e1@github.com>

On Sun, 18 Sep 2022 16:32:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Degrade Thread.suspend/resume to throw UOE unconditionally.
> 
> Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive.
> 
> The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs.
> 
> Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread).

Hello Alan, this PR deletes the `CountStackFrames.java` test case. Is that intentional? Looking at that test case it doesn't have any `suspend`/`resume` related testing and instead is just verifying that `Thread.countStackFrames()` throws the expected `UnsupportedOperationException`.

Edit: Please ignore what I said - I now see that these tests have been moved to a new test file.

-------------

PR: https://git.openjdk.org/jdk/pull/10324

From alanb at openjdk.org  Thu Sep 22 07:12:29 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 Sep 2022 07:12:29 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v4]
In-Reply-To: <zjl7cwFlpwxgYjDbchAw8qBNLcLq5n4CP940XDIlq8s=.91594dec-7c4a-45b9-8cbe-ec7ec51dc74c@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <ZTzHjlUXhJf5U3PndgGMZUpwbIJhJ0kSxL2am_PfFT8=.4279d477-9a1e-4a2c-b334-90cc60b5592b@github.com>
 <zjl7cwFlpwxgYjDbchAw8qBNLcLq5n4CP940XDIlq8s=.91594dec-7c4a-45b9-8cbe-ec7ec51dc74c@github.com>
Message-ID: <vWJUYm6IkJ8IwojilwR4D6_uBXhPU6GsOAKgFZfG7XE=.6280413f-e994-4cad-a9e6-8d9eff0bf5dd@github.com>

On Thu, 22 Sep 2022 04:36:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Consider using an implSpec tag here.

implSpec is usually for default methods or overrideable methods. In this case, Thread.stop is final so code that extends Thread can't override and change the behavior. So it's not clear to me that implSpec would be useful as it would duplicate the description in the generated javadoc.

-------------

PR: https://git.openjdk.org/jdk/pull/10230

From dholmes at openjdk.org  Thu Sep 22 08:06:30 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 22 Sep 2022 08:06:30 GMT
Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume
In-Reply-To: <l_lUEdZ-ORALa9ux2qu_PZZFm2IpIZs02kdC-tCQQBM=.e96f9fab-8d68-4ba1-b0f6-2b9b5c397226@github.com>
References: <l_lUEdZ-ORALa9ux2qu_PZZFm2IpIZs02kdC-tCQQBM=.e96f9fab-8d68-4ba1-b0f6-2b9b5c397226@github.com>
Message-ID: <hR510ghPZtrXLiyLWPkCXdZ5SoDFCo7Kt7CzKJXZiJ8=.27945849-1d3e-4a62-b3dc-7834f88c016c@github.com>

On Sun, 18 Sep 2022 16:32:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Degrade Thread.suspend/resume to throw UOE unconditionally.
> 
> Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive.
> 
> The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs.
> 
> Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread).

One minor nit but otherwise looks good!

Thanks.

src/java.base/share/classes/java/lang/SecurityManager.java line 497:

> 495:      * <p>
> 496:      * This method is invoked for the current security manager by the
> 497:      * {@code stop}, {@code suspend}, {@code resume},

Why is stop being removed in this PR?

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10324

From alanb at openjdk.org  Thu Sep 22 08:25:22 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 Sep 2022 08:25:22 GMT
Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume
In-Reply-To: <hR510ghPZtrXLiyLWPkCXdZ5SoDFCo7Kt7CzKJXZiJ8=.27945849-1d3e-4a62-b3dc-7834f88c016c@github.com>
References: <l_lUEdZ-ORALa9ux2qu_PZZFm2IpIZs02kdC-tCQQBM=.e96f9fab-8d68-4ba1-b0f6-2b9b5c397226@github.com>
 <hR510ghPZtrXLiyLWPkCXdZ5SoDFCo7Kt7CzKJXZiJ8=.27945849-1d3e-4a62-b3dc-7834f88c016c@github.com>
Message-ID: <n1PGbaFmOKLdHMCvrCB5RqVrnvJflUSTzez7U1VlKI8=.e0b8632f-ca16-4cbb-8416-006ac4666c6a@github.com>

On Thu, 22 Sep 2022 07:57:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Why is stop being removed in this PR?

It's just the sequencing of the two PRs and avoid merge conflicts. The Thread.stop should really edit this sentence, then this PR will edit it again. It was simpler to just do the SM edits in one PR.

-------------

PR: https://git.openjdk.org/jdk/pull/10324

From jpai at openjdk.org  Thu Sep 22 08:33:21 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 22 Sep 2022 08:33:21 GMT
Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume
In-Reply-To: <l_lUEdZ-ORALa9ux2qu_PZZFm2IpIZs02kdC-tCQQBM=.e96f9fab-8d68-4ba1-b0f6-2b9b5c397226@github.com>
References: <l_lUEdZ-ORALa9ux2qu_PZZFm2IpIZs02kdC-tCQQBM=.e96f9fab-8d68-4ba1-b0f6-2b9b5c397226@github.com>
Message-ID: <vCSLVAUiBRyCBBSFKz28xferR4fUFQSCMMlAXuJtVts=.2702fbbe-82aa-48bf-88a5-74f2f960b855@github.com>

On Sun, 18 Sep 2022 16:32:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Degrade Thread.suspend/resume to throw UOE unconditionally.
> 
> Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive.
> 
> The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs.
> 
> Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread).

The `java.base` changes look fine to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10324

From sspitsyn at openjdk.org  Thu Sep 22 09:13:19 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 22 Sep 2022 09:13:19 GMT
Subject: RFR: 8293613: need to properly handle and hide tmp VTMS
 transitions [v3]
In-Reply-To: <yvlbIRTOnKwybWVvpG0quuT0uGLMjRg0LhoiN5PC9xE=.7ba2eb86-4e60-42e2-a115-4ee9f94877dc@github.com>
References: <O_jzls_cv3HBC0NbzuYV2LXaW9VB2M18FroUfXWXd2w=.fa9d1f3c-40a2-42bd-a09b-dadd5032e513@github.com>
 <ve9g9LcSrawK3kb-TxKqxkSUOvkvnIsebd84GAub2DQ=.54a4a79b-be0a-47ef-99ba-63b93236cf08@github.com>
 <vMfCeRbX7oTnnv5-1PggLMUc1Q8MjZ0mnSFp5cutdTA=.08a9c27a-1bc2-4118-8f88-56c741df1435@github.com>
 <B6RFtDbP8hXLeKchONA5Oms2vNDsUU7EHV0wWotmayA=.726d876d-706b-4e70-ad7a-d49575796543@github.com>
 <yvlbIRTOnKwybWVvpG0quuT0uGLMjRg0LhoiN5PC9xE=.7ba2eb86-4e60-42e2-a115-4ee9f94877dc@github.com>
Message-ID: <O-UosCqpnIrWGsHT4sCuxJ9MhZ9xOmjuf3HJ4vp3zBg=.4832d67c-b0b8-4753-bd70-7c8834438574@github.com>

On Wed, 21 Sep 2022 17:25:42 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Thank you for reviewing and the comment, Chris.
>> I agree, this part and related comment is kind of obscure.
>> I'll think how to make the comment better.
>> In fact, all temporary VTMS transitions do temporary switch the `JavaThread` identity from virtual thread to carrier. There is no need to skip frames because there are no real carrier thread frames at the top. Moreover, any attempt to skip frames which are in transition works incorrectly and gives an empty stack. The check `JvmtiEnvBase::is_cthread_with_continuation()` is needed to make sure we have a deal with a continuation. There is no need to skip frames otherwise.
>
> It's still not clear to me if the result of `JvmtiEnvBase::is_cthread_with_continuation()` impacts if you have to possibly skip hidden frames. In other words, do you always have to do the `if` block that follows, no matter what `JvmtiEnvBase::is_cthread_with_continuation()` returns? If you don't, then maybe instead of a "? :"  expression, an if/else would be better. I'm not sure if the following is correct, but something like:
> 
>     javaVFrame *jvf;
>     if (JvmtiEnvBase::is_cthread_with_continuation(jt)) {
>       jvf = jt->carrier_last_java_vframe(reg_map_p);
>     } else {
>       jvf - jt->last_java_vframe(reg_map_p);
>       // Skipping hidden frames when jt->is_in_tmp_VTMS_transition()==true results
>       // in returning jvf==NULL, and so, empty stack traces for carrier threads.
>       if (!jt->is_in_tmp_VTMS_transition()) {
>         jvf = check_and_skip_hidden_frames(jt, jvf);
>       }
>     }

I understand you question about `is_cthread_with_continuation(jt)` check.
And I've incorrectly answered you initial question about it.
It is much simpler to check if `jt->is_in_VTMS_transition()` but not tmp transition.
I've already updated this part with renaming. Could you, please, look at it and check if it is more clear this way?
I'll push my fix shortly.

-------------

PR: https://git.openjdk.org/jdk/pull/10321

From sspitsyn at openjdk.org  Thu Sep 22 09:16:28 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 22 Sep 2022 09:16:28 GMT
Subject: RFR: 8293613: need to properly handle and hide tmp VTMS
 transitions [v4]
In-Reply-To: <O_jzls_cv3HBC0NbzuYV2LXaW9VB2M18FroUfXWXd2w=.fa9d1f3c-40a2-42bd-a09b-dadd5032e513@github.com>
References: <O_jzls_cv3HBC0NbzuYV2LXaW9VB2M18FroUfXWXd2w=.fa9d1f3c-40a2-42bd-a09b-dadd5032e513@github.com>
Message-ID: <OyzEjJjgvDVNRlKMONSVBtpcnVBJ9QPHdV2LqfcuTSc=.3810b0d9-3ce3-47f6-9662-6a91514efa05@github.com>

> There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update.
> 
> There are a couple of details of this fix to highlight:
> -  A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`.
> - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored.
> - Suspending threads in temporary transition is allowed.
> 
> The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6.

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  1. addressed review comments from Chris; added VirtualThread.java update from Alan

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10321/files
  - new: https://git.openjdk.org/jdk/pull/10321/files/551d8d32..48f827fe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10321&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10321&range=02-03

  Stats: 99 lines in 8 files changed: 19 ins; 5 del; 75 mod
  Patch: https://git.openjdk.org/jdk/pull/10321.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10321/head:pull/10321

PR: https://git.openjdk.org/jdk/pull/10321

From aph at openjdk.org  Thu Sep 22 09:39:19 2022
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 22 Sep 2022 09:39:19 GMT
Subject: RFR: 8293887: AArch64 build failure with GCC 12 due to
 maybe-uninitialized warning in libfdlibm k_rem_pio2.c
In-Reply-To: <UTaCIvPdArIMVc2jDoPYp72K5MelURpuipDuZigrDy0=.16cf4031-3791-4fd4-aeb3-598fa4faf4db@github.com>
References: <UTaCIvPdArIMVc2jDoPYp72K5MelURpuipDuZigrDy0=.16cf4031-3791-4fd4-aeb3-598fa4faf4db@github.com>
Message-ID: <11i9FwYPL2nt-RHe135PRcOFcZdo_RsIFHxHw8AgYqw=.a17c8166-3077-40bb-836b-2e3112b280e4@github.com>

On Thu, 22 Sep 2022 07:02:16 GMT, Hao Sun <haosun at openjdk.org> wrote:

> This warning seems to be a false positive, because 1) array "fq" with elements from index 0 to "jz" has already been initialized as "fw" at line 290 [1], and 2) variable "jz" should be non-negative from the comment at line 99 [2].
> 
> Note-1: GCC warning option -Wmaybe-uninitialized is not a new one. Note-2: x86-64 build with GCC 12 on Ubuntu 22.04 passed in my local test.
> 
> This warning is raised only on GCC 12 + AArch64. I suspect it might be some GCC 12 bug, so I reported it to GCC community [3].
> 
> Since it involves third party code, I think it's better to suppress the warning by simply disabling this warning option in the makefile.
> 
> Testing: Release builds with GCC 9, GCC 11 and GCC 12 passed on Ubuntu 22.04/AArch64 system.
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libfdlibm/k_rem_pio2.c#L290 
> [2] https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libfdlibm/k_rem_pio2.c#L99 
> [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106992

make/modules/java.base/lib/CoreLibraries.gmk line 52:

> 50:     CFLAGS_aix := -qfloat=nomaf, \
> 51:     DISABLED_WARNINGS_gcc := sign-compare misleading-indentation \
> 52:         array-bounds maybe-uninitialized, \

Something like this would be better:

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
    write(foo, bar, baz);
#pragma GCC diagnostic pop

-------------

PR: https://git.openjdk.org/jdk/pull/10386

From sspitsyn at openjdk.org  Thu Sep 22 09:43:18 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 22 Sep 2022 09:43:18 GMT
Subject: RFR: 8293613: need to properly handle and hide tmp VTMS
 transitions [v4]
In-Reply-To: <OyzEjJjgvDVNRlKMONSVBtpcnVBJ9QPHdV2LqfcuTSc=.3810b0d9-3ce3-47f6-9662-6a91514efa05@github.com>
References: <O_jzls_cv3HBC0NbzuYV2LXaW9VB2M18FroUfXWXd2w=.fa9d1f3c-40a2-42bd-a09b-dadd5032e513@github.com>
 <OyzEjJjgvDVNRlKMONSVBtpcnVBJ9QPHdV2LqfcuTSc=.3810b0d9-3ce3-47f6-9662-6a91514efa05@github.com>
Message-ID: <8lGsnac-zbc4jYW4ebQZxCVvYtEBYBcZNeQLBx4Hueg=.6cc8ec9c-0010-49ad-abc7-cd8bbec6a1a7@github.com>

On Thu, 22 Sep 2022 09:16:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update.
>> 
>> There are a couple of details of this fix to highlight:
>> -  A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`.
>> - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored.
>> - Suspending threads in temporary transition is allowed.
>> 
>> The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   1. addressed review comments from Chris; added VirtualThread.java update from Alan

Alan is currently investigating and testing his approach to get rid of temporary transitions.
If it comes to be successful then I'll close this PR.
Getting rid of temporary transitions is preferable as it will simplify the code a lot.

However, I've pushed an update to complete my current chunk of work for safety.
It includes two items:
- an update from Alan, to get rid of some lambda form classes loading in context of temporary VTMS transition
- update which address comments from Chris:
   - renaming of Thread class functions
   - changes in the function: `JvmtiEnvBase::get_cthread_last_java_vframe()`

-------------

PR: https://git.openjdk.org/jdk/pull/10321

From duke at openjdk.org  Thu Sep 22 10:22:40 2022
From: duke at openjdk.org (Raffaello Giulietti)
Date: Thu, 22 Sep 2022 10:22:40 GMT
Subject: RFR: 8065554: MatchResult should provide values of named-capturing
 groups [v7]
In-Reply-To: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
References: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
Message-ID: <42Ev9fkW6Eikmx176RXPOKvwIU30MbQR3upwFjdKJ6s=.6bb50e0f-d4f0-4285-9905-ef3d56b32ade@github.com>

> Add support for named groups to java.util.regex.MatchResult

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8065554: MatchResult should provide values of named-capturing groups

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10000/files
  - new: https://git.openjdk.org/jdk/pull/10000/files/c431a5f7..d4eaf51a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10000&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10000&range=05-06

  Stats: 18 lines in 1 file changed: 0 ins; 12 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10000.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10000/head:pull/10000

PR: https://git.openjdk.org/jdk/pull/10000

From avoitylov at openjdk.org  Thu Sep 22 13:05:00 2022
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Thu, 22 Sep 2022 13:05:00 GMT
Subject: RFR: 8294198: Implement isFinite intrinsic for RISC-V
Message-ID: <R4tlj4gD-vO5BzJKgAx9-O4s7BD7q6NlLhMhl6PMUuc=.c67bb8fb-3bf1-4035-be21-cc873220bf70@github.com>

Unlike on x86 (see 8285868 and the discussion in review), isFinite intrinsic turned out to be profitable on RISC-V using the same fclass instruction as for 8293695 (isInfinite instrinsic). Therefore, I'm proposing to have it added on RISC-V in this PR.

benchmark results:

before:

Benchmark                              Mode  Cnt   Score   Error  Units
DoubleClassCheck.testIsFiniteBranch    avgt   15  52.824 ? 1.744  ns/op
DoubleClassCheck.testIsFiniteCMov      avgt   15  16.104 ? 0.358  ns/op
DoubleClassCheck.testIsFiniteStore     avgt   15  14.366 ? 2.174  ns/op
FloatClassCheck.testIsFiniteBranch     avgt   15  49.821 ? 0.330  ns/op
FloatClassCheck.testIsFiniteCMov       avgt   15  14.702 ? 0.335  ns/op
FloatClassCheck.testIsFiniteStore      avgt   15  14.749 ? 0.496  ns/op

after:

DoubleClassCheck.testIsFiniteBranch    avgt   15  48.921 ? 0.557  ns/op
DoubleClassCheck.testIsFiniteCMov      avgt   15  13.716 ? 0.304  ns/op
DoubleClassCheck.testIsFiniteStore     avgt   15   9.152 ? 0.158  ns/op
FloatClassCheck.testIsFiniteBranch     avgt   15  47.740 ? 2.028  ns/op
FloatClassCheck.testIsFiniteCMov       avgt   15  13.299 ? 0.282  ns/op
FloatClassCheck.testIsFiniteStore      avgt   15   9.185 ? 0.396  ns/op

Existing isInfinite jtreg test was altered to be able to use common code for isFinite test and fine-grained requires tag filtering. Existing benchmark was modified to include isFinite case. A typo ("Atleast" -> "At least") was fixed on the way.

Test passed on both release and fastdebug builds. Hotspot tier1 tests were run on x86_64 and RISC-V with no issues.

-------------

Commit messages:
 - JDK-8294198 implementation

Changes: https://git.openjdk.org/jdk/pull/10391/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10391&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294198
  Stats: 363 lines in 17 files changed: 315 ins; 47 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10391.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10391/head:pull/10391

PR: https://git.openjdk.org/jdk/pull/10391

From jwaters at openjdk.org  Thu Sep 22 13:25:35 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Sep 2022 13:25:35 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v14]
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <JbI1BiWFapKawbiQUC3Bdfs5bgnuy63wrMajaccg7XM=.cbea56bc-65fa-450f-a31c-916584e059ad@github.com>

> Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time 
> 
> Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Use format specifier for differentiating Windows API errors

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9870/files
  - new: https://git.openjdk.org/jdk/pull/9870/files/3303cbb8..b169fba9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=12-13

  Stats: 32 lines in 2 files changed: 11 ins; 9 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From jwaters at openjdk.org  Thu Sep 22 13:29:40 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Sep 2022 13:29:40 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v15]
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <6HmPsNZip67Ipu7i1egXPJOTc16Est66en_Fsy_fZaY=.655485e8-31cb-4ec3-8a4d-0390cef05899@github.com>

> Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time 
> 
> Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future.

Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into rework
 - Use format specifier for differentiating Windows API errors
 - Rework JLI_ReportErrorMessageSys

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9870/files
  - new: https://git.openjdk.org/jdk/pull/9870/files/b169fba9..04223d42

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=13-14

  Stats: 4371 lines in 148 files changed: 2527 ins; 1357 del; 487 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From duke at openjdk.org  Thu Sep 22 13:30:19 2022
From: duke at openjdk.org (Raffaello Giulietti)
Date: Thu, 22 Sep 2022 13:30:19 GMT
Subject: RFR: 8293991: java/lang/Float/Binary16ConversionNaN.java fails on
 silent NaN conversions
In-Reply-To: <afYfFbJj3gshaWbUks0uVsHBJLFkND1vY1ccwSpFW60=.6b0b7208-c02c-4fe5-808f-6f9f4dc13ac5@github.com>
References: <afYfFbJj3gshaWbUks0uVsHBJLFkND1vY1ccwSpFW60=.6b0b7208-c02c-4fe5-808f-6f9f4dc13ac5@github.com>
Message-ID: <8il12yYqUDZI6mdriRhVewVbm7DsjymQm-nYpcmpw9I=.4485ccfa-2dfb-494b-b0e0-5ed2640bc2f0@github.com>

On Mon, 19 Sep 2022 10:25:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Reliably reproduces on x86-32 with FPU:
> 
> 
> $ CONF=linux-x86-server-fastdebug make test TEST=java/lang/Float/Binary16ConversionNaN.java TEST_VM_OPTS="-XX:UseAVX=0 -XX:UseSSE=0"
> ...
> Roundtrip failure on NaN value 7de2 got back 7fe2
> Roundtrip failure on NaN value fde2 got back ffe2
> 
> 
> Since there are many NaN values in FP16 -- basically any non-zero significand works, we should probably just relax the test a bit.
> 
> Attn @jddarcy ;)
> 
> Additional testing:
>  - [x] Linux x86_32 fastdebug, `-XX:UseAVX=0 -XX:UseSSE=0`, affected test now passes
>  - [x]  Linux x86_64 fastdebug, affected test still passes

test/jdk/java/lang/Float/Binary16ConversionNaN.java line 81:

> 79: 
> 80:     private static int sign(short binary16) {
> 81:         return (binary16 & 0xf000);

I think this should read
`return binary16 & 0x8000;`

-------------

PR: https://git.openjdk.org/jdk/pull/10333

From duke at openjdk.org  Thu Sep 22 13:30:19 2022
From: duke at openjdk.org (Raffaello Giulietti)
Date: Thu, 22 Sep 2022 13:30:19 GMT
Subject: RFR: 8293991: java/lang/Float/Binary16ConversionNaN.java fails on
 silent NaN conversions
In-Reply-To: <8il12yYqUDZI6mdriRhVewVbm7DsjymQm-nYpcmpw9I=.4485ccfa-2dfb-494b-b0e0-5ed2640bc2f0@github.com>
References: <afYfFbJj3gshaWbUks0uVsHBJLFkND1vY1ccwSpFW60=.6b0b7208-c02c-4fe5-808f-6f9f4dc13ac5@github.com>
 <8il12yYqUDZI6mdriRhVewVbm7DsjymQm-nYpcmpw9I=.4485ccfa-2dfb-494b-b0e0-5ed2640bc2f0@github.com>
Message-ID: <9i6TWtmKFZ1CYR7UFaBYGI32-ssXk7Hvey29lLyAB7U=.dc85fcab-93e8-480d-8c07-49551952ebea@github.com>

On Thu, 22 Sep 2022 13:23:23 GMT, Raffaello Giulietti <duke at openjdk.org> wrote:

>> Reliably reproduces on x86-32 with FPU:
>> 
>> 
>> $ CONF=linux-x86-server-fastdebug make test TEST=java/lang/Float/Binary16ConversionNaN.java TEST_VM_OPTS="-XX:UseAVX=0 -XX:UseSSE=0"
>> ...
>> Roundtrip failure on NaN value 7de2 got back 7fe2
>> Roundtrip failure on NaN value fde2 got back ffe2
>> 
>> 
>> Since there are many NaN values in FP16 -- basically any non-zero significand works, we should probably just relax the test a bit.
>> 
>> Attn @jddarcy ;)
>> 
>> Additional testing:
>>  - [x] Linux x86_32 fastdebug, `-XX:UseAVX=0 -XX:UseSSE=0`, affected test now passes
>>  - [x]  Linux x86_64 fastdebug, affected test still passes
>
> test/jdk/java/lang/Float/Binary16ConversionNaN.java line 81:
> 
>> 79: 
>> 80:     private static int sign(short binary16) {
>> 81:         return (binary16 & 0xf000);
> 
> I think this should read
> `return binary16 & 0x8000;`

Further, if the only modified bit is the quier/signaling bit the test could be more specific

-------------

PR: https://git.openjdk.org/jdk/pull/10333

From jwaters at openjdk.org  Thu Sep 22 13:32:35 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Sep 2022 13:32:35 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v16]
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <jwlIEuBfdDp-ReuZHnqdFInKyTSJ4o2sj4L3M_veBp0=.aaa0dd60-8d59-40d2-8180-601fad51f787@github.com>

> Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time 
> 
> Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Don't forget the null terminator!

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9870/files
  - new: https://git.openjdk.org/jdk/pull/9870/files/04223d42..39ba8c2d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=14-15

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From jwaters at openjdk.org  Thu Sep 22 13:35:05 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Sep 2022 13:35:05 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v17]
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <9UILvQvJKaoq_jTCPbzvzJXVyC_W1xRVqj52V-tYTHU=.7f7f86a3-250c-4807-aff5-8fb099040a6f@github.com>

> Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time 
> 
> Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Fix whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9870/files
  - new: https://git.openjdk.org/jdk/pull/9870/files/39ba8c2d..681a92e1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=15-16

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From jwaters at openjdk.org  Thu Sep 22 13:46:40 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Sep 2022 13:46:40 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v18]
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <TPOWAu-RnYdT-6J6j7HL4G5xkJ_eQjin1PN4BrNzNbw=.20840428-67ee-4722-b787-1f3ffa48d963@github.com>

> Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time 
> 
> Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Proper WINAPI for getErrorString and getLastErrorString too

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9870/files
  - new: https://git.openjdk.org/jdk/pull/9870/files/681a92e1..8a6f7f08

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=16-17

  Stats: 81 lines in 3 files changed: 34 ins; 39 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From jwaters at openjdk.org  Thu Sep 22 13:49:10 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Sep 2022 13:49:10 GMT
Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v19]
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <114IePkCV0wTJaVyJo0C2_wX6_ZyjPgiWItdcgwdF44=.63175b59-ef69-4494-864c-355d5c6c62e7@github.com>

> Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time 
> 
> Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  getLastWinErrorString calls wrong handler

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9870/files
  - new: https://git.openjdk.org/jdk/pull/9870/files/8a6f7f08..6c6290e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=17-18

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From jwaters at openjdk.org  Thu Sep 22 13:54:55 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Sep 2022 13:54:55 GMT
Subject: RFR: 8292016: Better handle intermingling WINAPI and C Runtime
 errors in the JDK [v20]
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <DbubBLJEIfA9msGedUusojf6Qd0qavDr2f9RkGS50l8=.06da4038-d56c-4acf-8c88-8075b8c35703@github.com>

> Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time 
> 
> Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Fix whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9870/files
  - new: https://git.openjdk.org/jdk/pull/9870/files/6c6290e9..3fb2fcc9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=18-19

  Stats: 20 lines in 1 file changed: 0 ins; 0 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From coffeys at openjdk.org  Thu Sep 22 13:57:48 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 22 Sep 2022 13:57:48 GMT
Subject: Integrated: 8254711: Add java.security.Provider.getService JFR Event
In-Reply-To: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
References: <I3o1nxh_9vdGRxZLhrok1D1iUa89_f9VdkmnlkxqkFI=.de31e6c3-2732-4f21-9fbc-4aeec49a3762@github.com>
Message-ID: <H5DcOov8QfSxCYzSQ4cUHe0k01vfkRkkJgFL-VdjlQ8=.c292a3b0-f170-47b2-ab7f-55b8c8a083bc@github.com>

On Wed, 27 Jul 2022 13:14:39 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls.

This pull request has now been integrated.

Changeset: bc2af47e
Author:    Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bc2af47e1e4e6e96020e03a60ce098ddd17f63ba
Stats:     280 lines in 9 files changed: 271 ins; 1 del; 8 mod

8254711: Add java.security.Provider.getService JFR Event

Reviewed-by: mullan, valeriep, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/9657

From rriggs at openjdk.org  Thu Sep 22 14:30:12 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 22 Sep 2022 14:30:12 GMT
Subject: RFR: 8234262: Unmask SIGQUIT in a child process [v2]
In-Reply-To: <RxgZaC-R0BjnATqBINLlCT6Xj9XpakZI2E8KR7hYWeQ=.8efaa74e-b2d5-4d4e-8b8c-b45903048dbf@github.com>
References: <QhoJ88tNkPq3N9ybNwnEEHnpPPiFfwhVtXqMTtRGk1o=.ab0b8831-16a1-4802-8730-708da809349e@github.com>
 <QibEFnEJKf51oYAMrQ3Ti-NhVdGB60yfChCnOtlcWd8=.b9a6982a-edc4-4328-81d5-6510e2410e04@github.com>
 <RxgZaC-R0BjnATqBINLlCT6Xj9XpakZI2E8KR7hYWeQ=.8efaa74e-b2d5-4d4e-8b8c-b45903048dbf@github.com>
Message-ID: <E5y01rJdXNtr5slCIvBK2uowkpfRdM1qhjXYEZMeuqM=.750bc9d6-4304-411c-91e1-1f7a5b7e4680@github.com>

On Wed, 21 Sep 2022 23:12:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi Roger, Using the spawn attributes seems more far reaching than simply temporarily changing the signal mask of the calling thread. I'd be concerned this has some unintended side-effects.

@dholmes-ora The signal masks for threads are currently initialized and managed by the VM. I was concerned about application actions and Java code changing and then restoring the mask in the face of possible async behaviors. It seemed cleaner for the changes to affect only the child.

Posix_spawn is used on all platforms and is very specific about its actions.
I considered just resetting the mask for SIGQUIT, copying the rest of the signal mask from the parent, but then it might come up that some other signal was masked and should not be.

The launching of a new executable is a two+ step process. A small executable (jspawnhelper) is spawned and it does the exec of the requested executable. 
An alternate implementation is to have jspawnhelper reset its own signal mask before exec'ing the target application.

-------------

PR: https://git.openjdk.org/jdk/pull/10379

From alanb at openjdk.org  Thu Sep 22 16:00:20 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 Sep 2022 16:00:20 GMT
Subject: RFR: 8234262: Unmask SIGQUIT in a child process [v2]
In-Reply-To: <E5y01rJdXNtr5slCIvBK2uowkpfRdM1qhjXYEZMeuqM=.750bc9d6-4304-411c-91e1-1f7a5b7e4680@github.com>
References: <QhoJ88tNkPq3N9ybNwnEEHnpPPiFfwhVtXqMTtRGk1o=.ab0b8831-16a1-4802-8730-708da809349e@github.com>
 <QibEFnEJKf51oYAMrQ3Ti-NhVdGB60yfChCnOtlcWd8=.b9a6982a-edc4-4328-81d5-6510e2410e04@github.com>
 <RxgZaC-R0BjnATqBINLlCT6Xj9XpakZI2E8KR7hYWeQ=.8efaa74e-b2d5-4d4e-8b8c-b45903048dbf@github.com>
 <E5y01rJdXNtr5slCIvBK2uowkpfRdM1qhjXYEZMeuqM=.750bc9d6-4304-411c-91e1-1f7a5b7e4680@github.com>
Message-ID: <q2zaDtMvQMAbbTrBH6g91eLO1ZX5MxZb9psDHu_6M9o=.b7a1ac11-eb16-4bbc-ad2b-4b228ae1778b@github.com>

On Thu, 22 Sep 2022 14:26:51 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The launching of a new executable is a two+ step process. A small executable (jspawnhelper) is spawned and it does the exec of the requested executable. An alternate implementation is to have jspawnhelper reset its own signal mask before exec'ing the target application.

Doing this in jspawnhelper would be good to try.

-------------

PR: https://git.openjdk.org/jdk/pull/10379

From coffeys at openjdk.org  Thu Sep 22 16:11:02 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 22 Sep 2022 16:11:02 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event
Message-ID: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>

New JFR event to record state of initial security properties.
 
Debug output is also now added for these properties via -Djava.security.debug=properties

-------------

Commit messages:
 - merge with master
 - Correct test bug ids
 - fix up imports
 - Add security debug test logic
 - Add JFR testcase
 - remove mirror event
 - 8292177 initial commit

Changes: https://git.openjdk.org/jdk/pull/10394/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10394&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292177
  Stats: 200 lines in 11 files changed: 196 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10394.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10394/head:pull/10394

PR: https://git.openjdk.org/jdk/pull/10394

From stuefe at openjdk.org  Thu Sep 22 16:22:22 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 22 Sep 2022 16:22:22 GMT
Subject: RFR: 8234262: Unmask SIGQUIT in a child process [v2]
In-Reply-To: <E5y01rJdXNtr5slCIvBK2uowkpfRdM1qhjXYEZMeuqM=.750bc9d6-4304-411c-91e1-1f7a5b7e4680@github.com>
References: <QhoJ88tNkPq3N9ybNwnEEHnpPPiFfwhVtXqMTtRGk1o=.ab0b8831-16a1-4802-8730-708da809349e@github.com>
 <QibEFnEJKf51oYAMrQ3Ti-NhVdGB60yfChCnOtlcWd8=.b9a6982a-edc4-4328-81d5-6510e2410e04@github.com>
 <RxgZaC-R0BjnATqBINLlCT6Xj9XpakZI2E8KR7hYWeQ=.8efaa74e-b2d5-4d4e-8b8c-b45903048dbf@github.com>
 <E5y01rJdXNtr5slCIvBK2uowkpfRdM1qhjXYEZMeuqM=.750bc9d6-4304-411c-91e1-1f7a5b7e4680@github.com>
Message-ID: <9WU9ppqWwehwe8GX4d7QSTHptOlcXnrOCyUxFR-c2rc=.dac6f35f-a597-4625-9d8b-c91dde2b2a33@github.com>

On Thu, 22 Sep 2022 14:26:51 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Hi Roger, Using the spawn attributes seems more far reaching than simply temporarily changing the signal mask of the calling thread. I'd be concerned this has some unintended side-effects.

I don't think that is a good idea. If the thread receives a SIGQUIT in the time it takes to fire up posix_spawn, will it be prepared to handle the signal? Using a pthread spawn attribute is much less intrusive, since it only affects the child process.

> > The launching of a new executable is a two+ step process. A small executable (jspawnhelper) is spawned and it does the exec of the requested executable. An alternate implementation is to have jspawnhelper reset its own signal mask before exec'ing the target application.
> 
> Doing this in jspawnhelper would be good to try.

I think using posix_spawn attributes is fine. It does what you would do manually in jspawnhelper: calling sigprocmask in the child process: https://github.com/lattera/glibc/blob/master/sysdeps/posix/spawni.c#L218 .

-------------

PR: https://git.openjdk.org/jdk/pull/10379

From darcy at openjdk.org  Thu Sep 22 16:45:27 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 22 Sep 2022 16:45:27 GMT
Subject: RFR: 8293991: java/lang/Float/Binary16ConversionNaN.java fails on
 silent NaN conversions
In-Reply-To: <afYfFbJj3gshaWbUks0uVsHBJLFkND1vY1ccwSpFW60=.6b0b7208-c02c-4fe5-808f-6f9f4dc13ac5@github.com>
References: <afYfFbJj3gshaWbUks0uVsHBJLFkND1vY1ccwSpFW60=.6b0b7208-c02c-4fe5-808f-6f9f4dc13ac5@github.com>
Message-ID: <50OaRprgZCiwVqKOOGsB6epc1Ci5Kt74nKfjUlFfjfM=.80cc8601-032f-4b01-a14a-c5cc5a6fc38f@github.com>

On Mon, 19 Sep 2022 10:25:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Reliably reproduces on x86-32 with FPU:
> 
> 
> $ CONF=linux-x86-server-fastdebug make test TEST=java/lang/Float/Binary16ConversionNaN.java TEST_VM_OPTS="-XX:UseAVX=0 -XX:UseSSE=0"
> ...
> Roundtrip failure on NaN value 7de2 got back 7fe2
> Roundtrip failure on NaN value fde2 got back ffe2
> 
> 
> Since there are many NaN values in FP16 -- basically any non-zero significand works, we should probably just relax the test a bit.
> 
> Attn @jddarcy ;)
> 
> Additional testing:
>  - [x] Linux x86_32 fastdebug, `-XX:UseAVX=0 -XX:UseSSE=0`, affected test now passes
>  - [x]  Linux x86_64 fastdebug, affected test still passes

test/jdk/java/lang/Float/Binary16ConversionNaN.java line 27:

> 25:  * @test
> 26:  * @bug 8289551
> 27:  * @library /test/lib

If we want to simply not run this test on x87, that could be done using jtreg @requires tags. For example

* @requires vm.bits == "64"

if this is only an issue for 32-bit x86 or something based on requiring os.arch values.

The companion test [Binary16Conversion.java](https://github.com/openjdk/jdk/blob/master/test/jdk/java/lang/Float/Binary16Conversion.java) tests the NaN handling contract required by the specification.

-------------

PR: https://git.openjdk.org/jdk/pull/10333

From hannesw at openjdk.org  Thu Sep 22 17:16:55 2022
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 22 Sep 2022 17:16:55 GMT
Subject: RFR: JDK-8287597: List all preview features on the javadoc PREVIEW
 page [v2]
In-Reply-To: <0UfKceKzCT3_exJ2vDs5y7IeroB2IHU8kHPO7b46KDY=.bbc662cb-5bd9-4205-acc2-3025ad1a5ab1@github.com>
References: <0UfKceKzCT3_exJ2vDs5y7IeroB2IHU8kHPO7b46KDY=.bbc662cb-5bd9-4205-acc2-3025ad1a5ab1@github.com>
Message-ID: <8hGpf_u-OQIkMw633kNwPy8oTTz6TMxudmlaWemS_3U=.9b7791eb-c12a-4b2e-baac-7b5a020e44fc@github.com>

> Please review an enhancement to the preview page to add a list of preview features and allow users to explore the preview APIs by feature. 
> 
> While the changes for the enhancement itself are not overly complex, the work entailed a moderate cleanup of other summary API lists (Deprecated and New API pages) as well as a few unrelated summary pages that happened to share some of the CSS classes and HTML structure.
> 
> The change itself starts with a new internal `jdk.internal.javac.PreviewFeature.JEP` annotation interface to add JEP information to the nearby `jdk.internal.javac.PreviewFeature.Feature` enum. This JEP information is retrieved by new methods in the javadoc `Utils` class and then fetched by `PreviewAPIListBuilder` which passes it on to `PreviewListWriter`. 
> 
> The superclass of `PreviewListWriter` and other API summary writer classes, `SummaryListWriter`, gets a new `addContentSelectors(Content)` method to add the checkboxes to show/hide various parts of the page content. The class is also now abstract as this and other methods do not have useful implementations in the base class. 
> 
> Another change to `SummaryListWriter` is that `pageMode`, `description`, `headContent` and `titleKey` are no longer fields in the class but rather sent to the `generateSummaryListFile` method as parameters since they are mostly just used locally in that method. On the other hand, the associated Builder is used in many places and previously had to be retrieved from the configuration object or passed around as parameter, so that is now set as a final field in `SummaryListWriter`. 
> 
> Finally, a few words about changes in CSS and HTML: The "Contents" list containing various kinds of elements in the API list was previously contained in the `<div class="header">` element that also contains the page header, and the stylesheet used the `.header ul`  selector to style the list. Now that the checkboxes separate the page header from the contents list it felt wrong to put all this in the header div (most other pages only use the div for the header itself). I also didn't like the indirect CSS selector too much, `.header ul` is not very indicative of what it applies to.
> 
> I therefore decided to create a new dedicated CSS class for the contents list called `contents-list`, and move the `<ul>` element out of the header div. Apart from the summary API pages, this change also affects the "Constant Values"  page as well as the top and package level "Tree" (class hierarchy) pages. I made sure the contents list in these pages look the same as before.
> 
> The list items in the contents list now each have an `id` attribute to allow hiding the list item if no content for the element kind is currently selected/visible. The value of the `id` attribute uses the format `contents-<element-kind>`.
> 
> There is one additional CSS class called `preview-feature-list` used for the list of preview feature JEPs. 
> 
> Demo output for the new preview page as well as other pages is available here:
> http://cr.openjdk.java.net/~hannesw/8287597/api.03/preview-list.html

Hannes Walln?fer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into JDK-8287597
 - JDK-8287597: List all preview features on the javadoc PREVIEW page

-------------

Changes: https://git.openjdk.org/jdk/pull/9336/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9336&range=01
  Stats: 461 lines in 22 files changed: 291 ins; 66 del; 104 mod
  Patch: https://git.openjdk.org/jdk/pull/9336.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9336/head:pull/9336

PR: https://git.openjdk.org/jdk/pull/9336

From darcy at openjdk.org  Thu Sep 22 17:22:17 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 22 Sep 2022 17:22:17 GMT
Subject: RFR: 8294198: Implement isFinite intrinsic for RISC-V
In-Reply-To: <R4tlj4gD-vO5BzJKgAx9-O4s7BD7q6NlLhMhl6PMUuc=.c67bb8fb-3bf1-4035-be21-cc873220bf70@github.com>
References: <R4tlj4gD-vO5BzJKgAx9-O4s7BD7q6NlLhMhl6PMUuc=.c67bb8fb-3bf1-4035-be21-cc873220bf70@github.com>
Message-ID: <WBWuthkb8Xz_Grgclr3TeGV9_NON6G2JL9HE-8CXGHk=.f79dbfe4-8472-49e3-b5ad-3acd8ae42ce8@github.com>

On Thu, 22 Sep 2022 12:56:49 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

> Unlike on x86 (see 8285868 and the discussion in review), isFinite intrinsic turned out to be profitable on RISC-V using the same fclass instruction as for 8293695 (isInfinite instrinsic). Therefore, I'm proposing to have it added on RISC-V in this PR.
> 
> benchmark results:
> 
> before:
> 
> Benchmark                              Mode  Cnt   Score   Error  Units
> DoubleClassCheck.testIsFiniteBranch    avgt   15  52.824 ? 1.744  ns/op
> DoubleClassCheck.testIsFiniteCMov      avgt   15  16.104 ? 0.358  ns/op
> DoubleClassCheck.testIsFiniteStore     avgt   15  14.366 ? 2.174  ns/op
> FloatClassCheck.testIsFiniteBranch     avgt   15  49.821 ? 0.330  ns/op
> FloatClassCheck.testIsFiniteCMov       avgt   15  14.702 ? 0.335  ns/op
> FloatClassCheck.testIsFiniteStore      avgt   15  14.749 ? 0.496  ns/op
> 
> after:
> 
> DoubleClassCheck.testIsFiniteBranch    avgt   15  48.921 ? 0.557  ns/op
> DoubleClassCheck.testIsFiniteCMov      avgt   15  13.716 ? 0.304  ns/op
> DoubleClassCheck.testIsFiniteStore     avgt   15   9.152 ? 0.158  ns/op
> FloatClassCheck.testIsFiniteBranch     avgt   15  47.740 ? 2.028  ns/op
> FloatClassCheck.testIsFiniteCMov       avgt   15  13.299 ? 0.282  ns/op
> FloatClassCheck.testIsFiniteStore      avgt   15   9.185 ? 0.396  ns/op
> 
> Existing isInfinite jtreg test was altered to be able to use common code for isFinite test and fine-grained requires tag filtering. Existing benchmark was modified to include isFinite case. A typo ("Atleast" -> "At least") was fixed on the way.
> 
> Test passed on both release and fastdebug builds. Hotspot tier1 tests were run on x86_64 and RISC-V with no issues.

The java.lang.* changes look fine if the rest of the work proceeds.

-------------

PR: https://git.openjdk.org/jdk/pull/10391

From hannesw at openjdk.org  Thu Sep 22 17:28:26 2022
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 22 Sep 2022 17:28:26 GMT
Subject: RFR: JDK-8287597: List all preview features on the javadoc PREVIEW
 page [v2]
In-Reply-To: <m5ZXX1-S8ASHLOSqlv_dPHspsLNhNeNt8VbMmAfaeqQ=.f10b2608-7801-4a16-94d6-c0da06aa15d4@github.com>
References: <0UfKceKzCT3_exJ2vDs5y7IeroB2IHU8kHPO7b46KDY=.bbc662cb-5bd9-4205-acc2-3025ad1a5ab1@github.com>
 <m5ZXX1-S8ASHLOSqlv_dPHspsLNhNeNt8VbMmAfaeqQ=.f10b2608-7801-4a16-94d6-c0da06aa15d4@github.com>
Message-ID: <J2Jo4F0psvC15SDWaPagPoDxgM7IzPTQl_YnIxxO6jQ=.491695a6-10e9-4a93-8c92-cc028b3545ba@github.com>

On Thu, 18 Aug 2022 21:42:04 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Hannes Walln?fer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge branch 'master' into JDK-8287597
>>  - JDK-8287597: List all preview features on the javadoc PREVIEW page
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SummaryListWriter.java line 164:
> 
>> 162:     protected void addIndexLink(HtmlId id, String headingKey, Content content) {
>> 163:         var li = HtmlTree.LI(links.createLink(id,
>> 164:                 contents.getContent(headingKey))).setId(HtmlId.of("contents-" + id.name()));
> 
> Suggest adding a comment that `"contents-" + id` appears in the JavaScript code as well. You presumably can't change one without the other (and can't use a common function across the language barrier.)

Excellent point.

-------------

PR: https://git.openjdk.org/jdk/pull/9336

From hannesw at openjdk.org  Thu Sep 22 17:39:21 2022
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 22 Sep 2022 17:39:21 GMT
Subject: RFR: JDK-8287597: List all preview features on the javadoc PREVIEW
 page [v3]
In-Reply-To: <0UfKceKzCT3_exJ2vDs5y7IeroB2IHU8kHPO7b46KDY=.bbc662cb-5bd9-4205-acc2-3025ad1a5ab1@github.com>
References: <0UfKceKzCT3_exJ2vDs5y7IeroB2IHU8kHPO7b46KDY=.bbc662cb-5bd9-4205-acc2-3025ad1a5ab1@github.com>
Message-ID: <-ytPBhsDhgoJXtVZqXSRIlPy7tnQxJOVmWcS1ptfCzs=.9d066937-8b00-4aea-a0b4-76e1dc28df6c@github.com>

> Please review an enhancement to the preview page to add a list of preview features and allow users to explore the preview APIs by feature. 
> 
> While the changes for the enhancement itself are not overly complex, the work entailed a moderate cleanup of other summary API lists (Deprecated and New API pages) as well as a few unrelated summary pages that happened to share some of the CSS classes and HTML structure.
> 
> The change itself starts with a new internal `jdk.internal.javac.PreviewFeature.JEP` annotation interface to add JEP information to the nearby `jdk.internal.javac.PreviewFeature.Feature` enum. This JEP information is retrieved by new methods in the javadoc `Utils` class and then fetched by `PreviewAPIListBuilder` which passes it on to `PreviewListWriter`. 
> 
> The superclass of `PreviewListWriter` and other API summary writer classes, `SummaryListWriter`, gets a new `addContentSelectors(Content)` method to add the checkboxes to show/hide various parts of the page content. The class is also now abstract as this and other methods do not have useful implementations in the base class. 
> 
> Another change to `SummaryListWriter` is that `pageMode`, `description`, `headContent` and `titleKey` are no longer fields in the class but rather sent to the `generateSummaryListFile` method as parameters since they are mostly just used locally in that method. On the other hand, the associated Builder is used in many places and previously had to be retrieved from the configuration object or passed around as parameter, so that is now set as a final field in `SummaryListWriter`. 
> 
> Finally, a few words about changes in CSS and HTML: The "Contents" list containing various kinds of elements in the API list was previously contained in the `<div class="header">` element that also contains the page header, and the stylesheet used the `.header ul`  selector to style the list. Now that the checkboxes separate the page header from the contents list it felt wrong to put all this in the header div (most other pages only use the div for the header itself). I also didn't like the indirect CSS selector too much, `.header ul` is not very indicative of what it applies to.
> 
> I therefore decided to create a new dedicated CSS class for the contents list called `contents-list`, and move the `<ul>` element out of the header div. Apart from the summary API pages, this change also affects the "Constant Values"  page as well as the top and package level "Tree" (class hierarchy) pages. I made sure the contents list in these pages look the same as before.
> 
> The list items in the contents list now each have an `id` attribute to allow hiding the list item if no content for the element kind is currently selected/visible. The value of the `id` attribute uses the format `contents-<element-kind>`.
> 
> There is one additional CSS class called `preview-feature-list` used for the list of preview feature JEPs. 
> 
> Demo output for the new preview page as well as other pages is available here:
> http://cr.openjdk.java.net/~hannesw/8287597/api.03/preview-list.html

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  Address review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9336/files
  - new: https://git.openjdk.org/jdk/pull/9336/files/87ceb3a2..1187024b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9336&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9336&range=01-02

  Stats: 52 lines in 7 files changed: 26 ins; 22 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9336.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9336/head:pull/9336

PR: https://git.openjdk.org/jdk/pull/9336

From hannesw at openjdk.org  Thu Sep 22 17:40:47 2022
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 22 Sep 2022 17:40:47 GMT
Subject: RFR: JDK-8287597: List all preview features on the javadoc PREVIEW
 page [v2]
In-Reply-To: <8hGpf_u-OQIkMw633kNwPy8oTTz6TMxudmlaWemS_3U=.9b7791eb-c12a-4b2e-baac-7b5a020e44fc@github.com>
References: <0UfKceKzCT3_exJ2vDs5y7IeroB2IHU8kHPO7b46KDY=.bbc662cb-5bd9-4205-acc2-3025ad1a5ab1@github.com>
 <8hGpf_u-OQIkMw633kNwPy8oTTz6TMxudmlaWemS_3U=.9b7791eb-c12a-4b2e-baac-7b5a020e44fc@github.com>
Message-ID: <w39xzpXYbK_uZkgPSYy9sSXzzALOXJL7yfUjkboCc2c=.2eff439a-1bf6-4b36-ab6f-ae9d03810082@github.com>

On Thu, 22 Sep 2022 17:16:55 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review an enhancement to the preview page to add a list of preview features and allow users to explore the preview APIs by feature. 
>> 
>> While the changes for the enhancement itself are not overly complex, the work entailed a moderate cleanup of other summary API lists (Deprecated and New API pages) as well as a few unrelated summary pages that happened to share some of the CSS classes and HTML structure.
>> 
>> The change itself starts with a new internal `jdk.internal.javac.PreviewFeature.JEP` annotation interface to add JEP information to the nearby `jdk.internal.javac.PreviewFeature.Feature` enum. This JEP information is retrieved by new methods in the javadoc `Utils` class and then fetched by `PreviewAPIListBuilder` which passes it on to `PreviewListWriter`. 
>> 
>> The superclass of `PreviewListWriter` and other API summary writer classes, `SummaryListWriter`, gets a new `addContentSelectors(Content)` method to add the checkboxes to show/hide various parts of the page content. The class is also now abstract as this and other methods do not have useful implementations in the base class. 
>> 
>> Another change to `SummaryListWriter` is that `pageMode`, `description`, `headContent` and `titleKey` are no longer fields in the class but rather sent to the `generateSummaryListFile` method as parameters since they are mostly just used locally in that method. On the other hand, the associated Builder is used in many places and previously had to be retrieved from the configuration object or passed around as parameter, so that is now set as a final field in `SummaryListWriter`. 
>> 
>> Finally, a few words about changes in CSS and HTML: The "Contents" list containing various kinds of elements in the API list was previously contained in the `<div class="header">` element that also contains the page header, and the stylesheet used the `.header ul`  selector to style the list. Now that the checkboxes separate the page header from the contents list it felt wrong to put all this in the header div (most other pages only use the div for the header itself). I also didn't like the indirect CSS selector too much, `.header ul` is not very indicative of what it applies to.
>> 
>> I therefore decided to create a new dedicated CSS class for the contents list called `contents-list`, and move the `<ul>` element out of the header div. Apart from the summary API pages, this change also affects the "Constant Values"  page as well as the top and package level "Tree" (class hierarchy) pages. I made sure the contents list in these pages look the same as before.
>> 
>> The list items in the contents list now each have an `id` attribute to allow hiding the list item if no content for the element kind is currently selected/visible. The value of the `id` attribute uses the format `contents-<element-kind>`.
>> 
>> There is one additional CSS class called `preview-feature-list` used for the list of preview feature JEPs. 
>> 
>> Demo output for the new preview page as well as other pages is available here:
>> http://cr.openjdk.java.net/~hannesw/8287597/api.03/preview-list.html
>
> Hannes Walln?fer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into JDK-8287597
>  - JDK-8287597: List all preview features on the javadoc PREVIEW page

This pull request has been reopened, brought up to date with master and updated to address review feedback.

-------------

PR: https://git.openjdk.org/jdk/pull/9336

From shade at openjdk.org  Thu Sep 22 18:48:41 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 22 Sep 2022 18:48:41 GMT
Subject: RFR: 8293991: java/lang/Float/Binary16ConversionNaN.java fails on
 silent NaN conversions [v2]
In-Reply-To: <afYfFbJj3gshaWbUks0uVsHBJLFkND1vY1ccwSpFW60=.6b0b7208-c02c-4fe5-808f-6f9f4dc13ac5@github.com>
References: <afYfFbJj3gshaWbUks0uVsHBJLFkND1vY1ccwSpFW60=.6b0b7208-c02c-4fe5-808f-6f9f4dc13ac5@github.com>
Message-ID: <HbgXns2WQaRVbYA_L3z1L83q3ieUBc7sMIIR1QK597Q=.e9bd69bf-19f1-498a-ae1b-a118ec27620a@github.com>

> Reliably reproduces on x86-32 with FPU:
> 
> 
> $ CONF=linux-x86-server-fastdebug make test TEST=java/lang/Float/Binary16ConversionNaN.java TEST_VM_OPTS="-XX:UseAVX=0 -XX:UseSSE=0"
> ...
> Roundtrip failure on NaN value 7de2 got back 7fe2
> Roundtrip failure on NaN value fde2 got back ffe2
> 
> 
> Since there are many NaN values in FP16 -- basically any non-zero significand works, we should probably just relax the test a bit.
> 
> Attn @jddarcy ;)
> 
> Additional testing:
>  - [x] Linux x86_32 fastdebug, `-XX:UseAVX=0 -XX:UseSSE=0`, affected test now passes
>  - [x] Linux x86_32 fastdebug, `-XX:UseAVX=0 -XX:UseSSE=1`, affected test still passes
>  - [x]  Linux x86_64 fastdebug, affected test still passes

Aleksey Shipilev 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:

 - Just exclude the test with x87
 - Revert test
 - Merge branch 'master' into JDK-8293991-x86-32-fp16
 - Indenting
 - Fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10333/files
  - new: https://git.openjdk.org/jdk/pull/10333/files/6d101550..d8019dcc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10333&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10333&range=00-01

  Stats: 8561 lines in 331 files changed: 5037 ins; 2476 del; 1048 mod
  Patch: https://git.openjdk.org/jdk/pull/10333.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10333/head:pull/10333

PR: https://git.openjdk.org/jdk/pull/10333

From shade at openjdk.org  Thu Sep 22 18:48:41 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 22 Sep 2022 18:48:41 GMT
Subject: RFR: 8293991: java/lang/Float/Binary16ConversionNaN.java fails on
 silent NaN conversions [v2]
In-Reply-To: <50OaRprgZCiwVqKOOGsB6epc1Ci5Kt74nKfjUlFfjfM=.80cc8601-032f-4b01-a14a-c5cc5a6fc38f@github.com>
References: <afYfFbJj3gshaWbUks0uVsHBJLFkND1vY1ccwSpFW60=.6b0b7208-c02c-4fe5-808f-6f9f4dc13ac5@github.com>
 <50OaRprgZCiwVqKOOGsB6epc1Ci5Kt74nKfjUlFfjfM=.80cc8601-032f-4b01-a14a-c5cc5a6fc38f@github.com>
Message-ID: <-yDgz3tXA7uPj0mCfkx7eHGGsVqEePFpkh2dj6uCfz8=.65a81e45-83a2-472d-ace1-4ee3ebdff573@github.com>

On Thu, 22 Sep 2022 16:41:53 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Aleksey Shipilev 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:
>> 
>>  - Just exclude the test with x87
>>  - Revert test
>>  - Merge branch 'master' into JDK-8293991-x86-32-fp16
>>  - Indenting
>>  - Fix
>
> test/jdk/java/lang/Float/Binary16ConversionNaN.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 8289551
>> 27:  * @library /test/lib
> 
> If we want to simply not run this test on x87, that could be done using jtreg @requires tags. For example
> 
> * @requires vm.bits == "64"
> 
> if this is only an issue for 32-bit x86 or something based on requiring os.arch values.
> 
> The companion test [Binary16Conversion.java](https://github.com/openjdk/jdk/blob/master/test/jdk/java/lang/Float/Binary16Conversion.java) tests the NaN handling contract required by the specification.

Oh, I did not realize other tests verify `NaN` works. I tried to salvage this test thinking we still need to test at least some `NaN`-s. Since there is no apparent need for that, let's just exclude the test on x87. See new commit.

-------------

PR: https://git.openjdk.org/jdk/pull/10333

From shade at openjdk.org  Thu Sep 22 18:48:41 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 22 Sep 2022 18:48:41 GMT
Subject: RFR: 8293991: java/lang/Float/Binary16ConversionNaN.java fails on
 silent NaN conversions [v2]
In-Reply-To: <9i6TWtmKFZ1CYR7UFaBYGI32-ssXk7Hvey29lLyAB7U=.dc85fcab-93e8-480d-8c07-49551952ebea@github.com>
References: <afYfFbJj3gshaWbUks0uVsHBJLFkND1vY1ccwSpFW60=.6b0b7208-c02c-4fe5-808f-6f9f4dc13ac5@github.com>
 <8il12yYqUDZI6mdriRhVewVbm7DsjymQm-nYpcmpw9I=.4485ccfa-2dfb-494b-b0e0-5ed2640bc2f0@github.com>
 <9i6TWtmKFZ1CYR7UFaBYGI32-ssXk7Hvey29lLyAB7U=.dc85fcab-93e8-480d-8c07-49551952ebea@github.com>
Message-ID: <VTJK-JFxONA8F4z0qdrnjd5waVMnq_bYX7PECB_464c=.2c8d9c56-fe15-40b7-89a7-fed9d6d8b135@github.com>

On Thu, 22 Sep 2022 13:26:17 GMT, Raffaello Giulietti <duke at openjdk.org> wrote:

>> test/jdk/java/lang/Float/Binary16ConversionNaN.java line 81:
>> 
>>> 79: 
>>> 80:     private static int sign(short binary16) {
>>> 81:         return (binary16 & 0xf000);
>> 
>> I think this should read
>> `return binary16 & 0x8000;`
>
> Further, if the only modified bit is the quier/signaling bit the test could be more specific

Test is reverted, so there is nothing to be done here :)

-------------

PR: https://git.openjdk.org/jdk/pull/10333

From darcy at openjdk.org  Thu Sep 22 20:14:21 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 22 Sep 2022 20:14:21 GMT
Subject: RFR: 8293991: java/lang/Float/Binary16ConversionNaN.java fails on
 silent NaN conversions [v2]
In-Reply-To: <-yDgz3tXA7uPj0mCfkx7eHGGsVqEePFpkh2dj6uCfz8=.65a81e45-83a2-472d-ace1-4ee3ebdff573@github.com>
References: <afYfFbJj3gshaWbUks0uVsHBJLFkND1vY1ccwSpFW60=.6b0b7208-c02c-4fe5-808f-6f9f4dc13ac5@github.com>
 <50OaRprgZCiwVqKOOGsB6epc1Ci5Kt74nKfjUlFfjfM=.80cc8601-032f-4b01-a14a-c5cc5a6fc38f@github.com>
 <-yDgz3tXA7uPj0mCfkx7eHGGsVqEePFpkh2dj6uCfz8=.65a81e45-83a2-472d-ace1-4ee3ebdff573@github.com>
Message-ID: <Y2WiV2R-Z3iYRlvYAzbXk3alNTrvnkErKsjgRHzclhs=.287db0a3-dcc7-4909-8de3-5eb18e9bb2b1@github.com>

On Thu, 22 Sep 2022 18:43:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> test/jdk/java/lang/Float/Binary16ConversionNaN.java line 27:
>> 
>>> 25:  * @test
>>> 26:  * @bug 8289551
>>> 27:  * @library /test/lib
>> 
>> If we want to simply not run this test on x87, that could be done using jtreg @requires tags. For example
>> 
>> * @requires vm.bits == "64"
>> 
>> if this is only an issue for 32-bit x86 or something based on requiring os.arch values.
>> 
>> The companion test [Binary16Conversion.java](https://github.com/openjdk/jdk/blob/master/test/jdk/java/lang/Float/Binary16Conversion.java) tests the NaN handling contract required by the specification.
>
> Oh, I did not realize other tests verify `NaN` works. I tried to salvage this test thinking we still need to test at least some `NaN`-s. Since there is no apparent need for that, let's just exclude the test on x87. See new commit.

Right; anticipating the possibility of platform-specific NaN handling, I split out the bit-specific NaN tests into a separate file so just those NaN bit could have @requires tags while keeping most of the float16 conversion tests running on all platforms :-)

-------------

PR: https://git.openjdk.org/jdk/pull/10333

From cjplummer at openjdk.org  Thu Sep 22 20:15:29 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 22 Sep 2022 20:15:29 GMT
Subject: RFR: 8293613: need to properly handle and hide tmp VTMS
 transitions [v4]
In-Reply-To: <OyzEjJjgvDVNRlKMONSVBtpcnVBJ9QPHdV2LqfcuTSc=.3810b0d9-3ce3-47f6-9662-6a91514efa05@github.com>
References: <O_jzls_cv3HBC0NbzuYV2LXaW9VB2M18FroUfXWXd2w=.fa9d1f3c-40a2-42bd-a09b-dadd5032e513@github.com>
 <OyzEjJjgvDVNRlKMONSVBtpcnVBJ9QPHdV2LqfcuTSc=.3810b0d9-3ce3-47f6-9662-6a91514efa05@github.com>
Message-ID: <AfgR97-WxKBpt0uuUTijy4rnpXY_XjVqXbJRSEdV0hw=.5e4c6cd6-de28-4fc1-ab1b-681be92a512b@github.com>

On Thu, 22 Sep 2022 09:16:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update.
>> 
>> There are a couple of details of this fix to highlight:
>> -  A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`.
>> - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored.
>> - Suspending threads in temporary transition is allowed.
>> 
>> The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   1. addressed review comments from Chris; added VirtualThread.java update from Alan

src/hotspot/share/runtime/javaThread.hpp line 652:

> 650:   void set_is_in_VTMS_transition(bool val);
> 651:   void toggle_is_in_tmp_VTMS_transition()        { _is_in_tmp_VTMS_transition = !_is_in_tmp_VTMS_transition; };
> 652: 

My suggestion was to have the term "in VTMS transition" be inclusive of temp transitions. So based on your current names I would suggest:

- is_in_VTMS_transition -> is_in_non_tmp_VTMS_transition
- is_in_any_VTMS_transition -> is_in_VTMS_transition

But that becomes a problem for `set_is_in_VTMS_transition`, which would need to be renamed `set_is_in_non_tmp_VTMS_transition`, which I'm guessing you don't want to do. So let's instead just hope this all goes away before thinking about it any more.

-------------

PR: https://git.openjdk.org/jdk/pull/10321

From darcy at openjdk.org  Thu Sep 22 20:18:17 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 22 Sep 2022 20:18:17 GMT
Subject: RFR: 8293991: java/lang/Float/Binary16ConversionNaN.java fails on
 silent NaN conversions [v2]
In-Reply-To: <HbgXns2WQaRVbYA_L3z1L83q3ieUBc7sMIIR1QK597Q=.e9bd69bf-19f1-498a-ae1b-a118ec27620a@github.com>
References: <afYfFbJj3gshaWbUks0uVsHBJLFkND1vY1ccwSpFW60=.6b0b7208-c02c-4fe5-808f-6f9f4dc13ac5@github.com>
 <HbgXns2WQaRVbYA_L3z1L83q3ieUBc7sMIIR1QK597Q=.e9bd69bf-19f1-498a-ae1b-a118ec27620a@github.com>
Message-ID: <ViplAxBOLKAcGuLsD5N5laP27-X9qqKTrfeG9tG_Wzw=.f2cd403f-afb2-4dda-ae56-80419c97ccad@github.com>

On Thu, 22 Sep 2022 18:48:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Reliably reproduces on x86-32 with FPU:
>> 
>> 
>> $ CONF=linux-x86-server-fastdebug make test TEST=java/lang/Float/Binary16ConversionNaN.java TEST_VM_OPTS="-XX:UseAVX=0 -XX:UseSSE=0"
>> ...
>> Roundtrip failure on NaN value 7de2 got back 7fe2
>> Roundtrip failure on NaN value fde2 got back ffe2
>> 
>> 
>> Since there are many NaN values in FP16 -- basically any non-zero significand works, we should probably just relax the test a bit.
>> 
>> Attn @jddarcy ;)
>> 
>> Additional testing:
>>  - [x] Linux x86_32 fastdebug, `-XX:UseAVX=0 -XX:UseSSE=0`, affected test now passes
>>  - [x] Linux x86_32 fastdebug, `-XX:UseAVX=0 -XX:UseSSE=1`, affected test still passes
>>  - [x]  Linux x86_64 fastdebug, affected test still passes
>
> Aleksey Shipilev 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:
> 
>  - Just exclude the test with x87
>  - Revert test
>  - Merge branch 'master' into JDK-8293991-x86-32-fp16
>  - Indenting
>  - Fix

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10333

From mchung at openjdk.org  Thu Sep 22 21:14:12 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 22 Sep 2022 21:14:12 GMT
Subject: RFR: JDK-8293701: jdeps InverseDepsAnalyzer runs into
 NoSuchElementException: No value present
In-Reply-To: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
References: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
Message-ID: <mInhKbLzPXGIgs29wJaJPDqXYGM0jx00xNojnpOA-sc=.2973f676-0a47-4201-b5b0-6967f98521ae@github.com>

On Fri, 16 Sep 2022 08:26:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We noticed that with certain jar file input, jdeps runs into the following exception, this happens with jdk11, 17 and 20.
> 
> jdeps.exe --multi-release 11 --module-path . --inverse --package com.sap.nw.performance.supa.client test.jar
> 
> Inverse transitive dependences matching packages [com.sap.nw.performance.supa.client]
> Exception in thread "main" java.util.NoSuchElementException: No value present
>         at java.base/java.util.Optional.get(Optional.java:148)
>         at jdk.jdeps/com.sun.tools.jdeps.InverseDepsAnalyzer.lambda$inverseDependences$2(InverseDepsAnalyzer.java:150)
>         at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>         at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>         at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
>         at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>         at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> 
> So an additional  check might be a good idea.

I created a reproducible test case attached in the JBS issue.   This is caused by the optional dependency `requires static M;`  which is not resolved in the runtime configuration even if it's observable.   


diff --git a/src/jdk.jdeps/share/classes/com/sun/tools/jdeps/InverseDepsAnalyzer.java b/src/jdk.jdeps/share/classes/com/sun/tools/jdeps/InverseDepsAnalyzer.java
index 5720fe7f60a..18ef9af3422 100644
--- a/src/jdk.jdeps/share/classes/com/sun/tools/jdeps/InverseDepsAnalyzer.java
+++ b/src/jdk.jdeps/share/classes/com/sun/tools/jdeps/InverseDepsAnalyzer.java
@@ -145,6 +145,9 @@ public class InverseDepsAnalyzer extends DepsAnalyzer {
                 .forEach(m -> {
                     builder.addNode(m);
                     m.descriptor().requires().stream()
+                        // filter "requires static" if the module is not resolved in the configuration
+                        .filter(req -> !req.modifiers().contains(Requires.Modifier.STATIC)
+                                           || configuration.findModule(req.name()).isPresent())
                         .map(Requires::name)
                         .map(configuration::findModule)  // must be present
                         .forEach(v -> builder.addEdge(v.get(), m));

-------------

PR: https://git.openjdk.org/jdk/pull/10300

From dholmes at openjdk.org  Thu Sep 22 21:52:19 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 22 Sep 2022 21:52:19 GMT
Subject: RFR: 8234262: Unmask SIGQUIT in a child process [v2]
In-Reply-To: <QibEFnEJKf51oYAMrQ3Ti-NhVdGB60yfChCnOtlcWd8=.b9a6982a-edc4-4328-81d5-6510e2410e04@github.com>
References: <QhoJ88tNkPq3N9ybNwnEEHnpPPiFfwhVtXqMTtRGk1o=.ab0b8831-16a1-4802-8730-708da809349e@github.com>
 <QibEFnEJKf51oYAMrQ3Ti-NhVdGB60yfChCnOtlcWd8=.b9a6982a-edc4-4328-81d5-6510e2410e04@github.com>
Message-ID: <Z9xFFn9nDNs6cflvaWljov-fxUz3ud2sxo62y6zPFjI=.232b55a3-a8f6-4c88-8cae-c795ffe3d481@github.com>

On Wed, 21 Sep 2022 21:37:59 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Clear the signal mask of the child when launching with posix_spawn.
>> 
>> SIGQUIT signals are handled on non-Java Threads by the VM.
>> For Java threads the signal mask blocks SIGQUIT.  
>> The ProcessBuilder uses posix_spawn on all platforms to create new processes.
>> Without a specific request, the child process inherits the signal masks from the parent.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test both with and without -Xrs

Not sure it makes any difference whether this happens in the initial spawn or in jspawnhelper. I agree it is nicer to not affect the calling thread/process at all. My concern is that unblocking all signals may have some unintended side-effect, versus just dealing with SIGQUIT i.e. take a minimalist approach.

-------------

PR: https://git.openjdk.org/jdk/pull/10379

From dholmes at openjdk.org  Thu Sep 22 21:55:17 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 22 Sep 2022 21:55:17 GMT
Subject: RFR: 8290482: Update JNI Specification of DestroyJavaVM for better
 alignment with JLS, JVMS, and Java SE API Specifications [v4]
In-Reply-To: <vkwmx3eyXlWo55RjJjMZFRP9msoMZK-Ryw1AsWUxIuo=.27b93d97-8565-43a8-88fc-cb1ece45f741@github.com>
References: <M2IRKiuONiNI45YTu9wdu1o8ZXJslnxRmgMvnlVU478=.4aa03d22-0395-4354-bf41-f11a74df791a@github.com>
 <5LZVfXnTpbyr_NWeYid9qzKrnZ6t2b7ZL5BtHEZ4Syc=.bff15db2-726a-4976-89f1-edd826d75bf2@github.com>
 <vkwmx3eyXlWo55RjJjMZFRP9msoMZK-Ryw1AsWUxIuo=.27b93d97-8565-43a8-88fc-cb1ece45f741@github.com>
Message-ID: <XvVAjAMOZwY6q4Q508S7Y0fDU3-zJ-AsE2Xcsipwf-I=.7e8b5721-48aa-430c-a000-51032a34fb08@github.com>

On Thu, 22 Sep 2022 06:09:46 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix JniVersion test
>
> Looks good, thank you!

Thanks @robehn !

-------------

PR: https://git.openjdk.org/jdk/pull/10352

From bpb at openjdk.org  Thu Sep 22 22:18:24 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 22 Sep 2022 22:18:24 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo
 [v11]
In-Reply-To: <_la5Co3yx5ik1wt7Y6Bi7MDC3MCVUxIKxz_iQQp2TT8=.1023ef6d-266f-45f5-aa93-7218d0d89c10@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <_la5Co3yx5ik1wt7Y6Bi7MDC3MCVUxIKxz_iQQp2TT8=.1023ef6d-266f-45f5-aa93-7218d0d89c10@github.com>
Message-ID: <czGSczxgHiOwVNNB1hdYQnO55orNICm9TvSN-kl7YKw=.3e51b917-0db4-46f5-b950-48e1fb1e439a@github.com>

On Fri, 9 Sep 2022 12:19:54 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Implementation of JDK-8279283
>
> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - corrected copyright
>  - testing transferTo() after reset()

test/jdk/java/io/BufferedInputStream/TransferTo.java line 40:

> 38: import java.nio.file.Files;
> 39: import java.nio.file.Path;
> 40: import java.nio.file.StandardOpenOption;

This import of `StandardOpenOption` is not needed due to line 55.

test/jdk/java/io/BufferedInputStream/TransferTo.java line 89:

> 87: 
> 88:         // tests empty input stream
> 89:         assertThrows(NullPointerException.class, () -> inputStreamProvider.input().transferTo(null));

A number of code lines in the test are too long and make it even harder to read.

test/jdk/java/io/BufferedInputStream/TransferTo.java line 162:

> 160:             out.write(new byte[posOut]);
> 161: 
> 162:             // fill buffer by reading some bytes before transformTo

transformTo -> transferTo

-------------

PR: https://git.openjdk.org/jdk/pull/6935

From rriggs at openjdk.org  Thu Sep 22 22:41:21 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 22 Sep 2022 22:41:21 GMT
Subject: RFR: 8234262: Unmask SIGQUIT in a child process [v3]
In-Reply-To: <QhoJ88tNkPq3N9ybNwnEEHnpPPiFfwhVtXqMTtRGk1o=.ab0b8831-16a1-4802-8730-708da809349e@github.com>
References: <QhoJ88tNkPq3N9ybNwnEEHnpPPiFfwhVtXqMTtRGk1o=.ab0b8831-16a1-4802-8730-708da809349e@github.com>
Message-ID: <w56hDjzb11ooJgZGHNnQaSuCtIrJi-igrgIhZOUyalY=.ea945f12-2df3-43a3-b825-047a52595dcb@github.com>

> Clear the signal mask of the child when launching with posix_spawn.
> 
> SIGQUIT signals are handled on non-Java Threads by the VM.
> For Java threads the signal mask blocks SIGQUIT.  
> The ProcessBuilder uses posix_spawn on all platforms to create new processes.
> Without a specific request, the child process inherits the signal masks from the parent.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Move clearing of the signal mask to jspawnhelper so the launched
  process gets a clear signal mask.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10379/files
  - new: https://git.openjdk.org/jdk/pull/10379/files/e0e854bd..dc56e0d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10379&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10379&range=01-02

  Stats: 20 lines in 2 files changed: 7 ins; 12 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10379.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10379/head:pull/10379

PR: https://git.openjdk.org/jdk/pull/10379

From rriggs at openjdk.org  Thu Sep 22 22:41:22 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 22 Sep 2022 22:41:22 GMT
Subject: RFR: 8234262: Unmask SIGQUIT in a child process [v2]
In-Reply-To: <QibEFnEJKf51oYAMrQ3Ti-NhVdGB60yfChCnOtlcWd8=.b9a6982a-edc4-4328-81d5-6510e2410e04@github.com>
References: <QhoJ88tNkPq3N9ybNwnEEHnpPPiFfwhVtXqMTtRGk1o=.ab0b8831-16a1-4802-8730-708da809349e@github.com>
 <QibEFnEJKf51oYAMrQ3Ti-NhVdGB60yfChCnOtlcWd8=.b9a6982a-edc4-4328-81d5-6510e2410e04@github.com>
Message-ID: <Wmr4uEfbm_Bn3SR2VP5BuUFxEKFU-LwWqzKAbxlCCTw=.7af766e5-bf76-4b0c-8bab-61e13456fda1@github.com>

On Wed, 21 Sep 2022 21:37:59 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Clear the signal mask of the child when launching with posix_spawn.
>> 
>> SIGQUIT signals are handled on non-Java Threads by the VM.
>> For Java threads the signal mask blocks SIGQUIT.  
>> The ProcessBuilder uses posix_spawn on all platforms to create new processes.
>> Without a specific request, the child process inherits the signal masks from the parent.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test both with and without -Xrs

Putting the fix in jspawnhelper will address the problem in the other launch modes fork and vfork, so it not just posix_spawn fix.
SigQuit is only a problem because its one that the VM sets up to manage within the Java process.
Normal launching by the shell doesn't set any signals and I would not think a launched program would expect any masking.

-------------

PR: https://git.openjdk.org/jdk/pull/10379

From dholmes at openjdk.org  Thu Sep 22 23:18:20 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 22 Sep 2022 23:18:20 GMT
Subject: RFR: 8234262: Unmask SIGQUIT in a child process [v3]
In-Reply-To: <w56hDjzb11ooJgZGHNnQaSuCtIrJi-igrgIhZOUyalY=.ea945f12-2df3-43a3-b825-047a52595dcb@github.com>
References: <QhoJ88tNkPq3N9ybNwnEEHnpPPiFfwhVtXqMTtRGk1o=.ab0b8831-16a1-4802-8730-708da809349e@github.com>
 <w56hDjzb11ooJgZGHNnQaSuCtIrJi-igrgIhZOUyalY=.ea945f12-2df3-43a3-b825-047a52595dcb@github.com>
Message-ID: <yP2ccgksQNP7jJkrLMYuxT3q9uNc-bMPxTofDlWhvKI=.d2e755ce-fa9b-484e-a788-113eef0aeecf@github.com>

On Thu, 22 Sep 2022 22:41:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Clear the signal mask of the child when launching with posix_spawn.
>> 
>> SIGQUIT signals are handled on non-Java Threads by the VM.
>> For Java threads the signal mask blocks SIGQUIT.  
>> The ProcessBuilder uses posix_spawn on all platforms to create new processes.
>> Without a specific request, the child process inherits the signal masks from the parent.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move clearing of the signal mask to jspawnhelper so the launched
>   process gets a clear signal mask.

Okay. Thanks for fixing this.

src/java.base/unix/native/libjava/ProcessImpl_md.c line 776:

> 774:     goto Finally;
> 775: }
> 776: 

Unintended change?

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10379

From svkamath at openjdk.org  Fri Sep 23 00:16:38 2022
From: svkamath at openjdk.org (Smita Kamath)
Date: Fri, 23 Sep 2022 00:16:38 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v9]
In-Reply-To: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
Message-ID: <EHIi76A30ww3BU34QdlQhfvBjKoyWlYwqd7KypjQZIs=.2ceba1e0-2eeb-4190-a51a-7d762e941928@github.com>

> 8289552: Make intrinsic conversions between bit representations of half precision values and floats

Smita Kamath has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:

 - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8289552
 - Addressed review comments
 - Added missing parantheses
 - Addressed review comments, updated microbenchmark
 - Updated copyright comment
 - Updated test cases as per review comments
 - Addressed review comments, updated test cases and microbenchmark
 - Added a jmh microbenchmark
 - Intrinsic conversions between halffloat and floats

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9781/files
  - new: https://git.openjdk.org/jdk/pull/9781/files/6b828e60..bd55803a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=07-08

  Stats: 162166 lines in 2652 files changed: 77056 ins; 68233 del; 16877 mod
  Patch: https://git.openjdk.org/jdk/pull/9781.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9781/head:pull/9781

PR: https://git.openjdk.org/jdk/pull/9781

From stuefe at openjdk.org  Fri Sep 23 03:28:37 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 23 Sep 2022 03:28:37 GMT
Subject: RFR: 8234262: Unmask SIGQUIT in a child process [v3]
In-Reply-To: <w56hDjzb11ooJgZGHNnQaSuCtIrJi-igrgIhZOUyalY=.ea945f12-2df3-43a3-b825-047a52595dcb@github.com>
References: <QhoJ88tNkPq3N9ybNwnEEHnpPPiFfwhVtXqMTtRGk1o=.ab0b8831-16a1-4802-8730-708da809349e@github.com>
 <w56hDjzb11ooJgZGHNnQaSuCtIrJi-igrgIhZOUyalY=.ea945f12-2df3-43a3-b825-047a52595dcb@github.com>
Message-ID: <ne2uzUhcZcN0YKcBkvdPyhLAnbOjPJpgtQ-B0DVTC7M=.873a6910-96b4-41cf-ae80-eaa37ca5cbce@github.com>

On Thu, 22 Sep 2022 22:41:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Clear the signal mask of the child when launching with posix_spawn.
>> 
>> SIGQUIT signals are handled on non-Java Threads by the VM.
>> For Java threads the signal mask blocks SIGQUIT.  
>> The ProcessBuilder uses posix_spawn on all platforms to create new processes.
>> Without a specific request, the child process inherits the signal masks from the parent.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move clearing of the signal mask to jspawnhelper so the launched
>   process gets a clear signal mask.

test/jdk/java/lang/ProcessBuilder/UnblockSignals.java line 37:

> 35:     public static void main(String[] args)  throws IOException, InterruptedException {
> 36:         // Check that SIGQUIT is not masked, in previous releases it was masked
> 37:         final ProcessBuilder pb = new ProcessBuilder("sleep", "30").inheritIO();

SIGQUITing the child may leave a core dump. You may want to wrap the sleep in a shell call with ulimit to prevent that, e.g. 

`new ProcessBuilder("sh", "-c", "ulimit -c 0 && sleep 30");`

-------------

PR: https://git.openjdk.org/jdk/pull/10379

From haosun at openjdk.org  Fri Sep 23 07:00:14 2022
From: haosun at openjdk.org (Hao Sun)
Date: Fri, 23 Sep 2022 07:00:14 GMT
Subject: RFR: 8293887: AArch64 build failure with GCC 12 due to
 maybe-uninitialized warning in libfdlibm k_rem_pio2.c
In-Reply-To: <11i9FwYPL2nt-RHe135PRcOFcZdo_RsIFHxHw8AgYqw=.a17c8166-3077-40bb-836b-2e3112b280e4@github.com>
References: <UTaCIvPdArIMVc2jDoPYp72K5MelURpuipDuZigrDy0=.16cf4031-3791-4fd4-aeb3-598fa4faf4db@github.com>
 <11i9FwYPL2nt-RHe135PRcOFcZdo_RsIFHxHw8AgYqw=.a17c8166-3077-40bb-836b-2e3112b280e4@github.com>
Message-ID: <vks8-99Oc6cfhJMPg67PEsIcwhrcwsmW73E38O6mjEo=.ebcbada9-95c3-49c2-8411-c221614345ca@github.com>

On Thu, 22 Sep 2022 09:35:47 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This warning seems to be a false positive, because 1) array "fq" with elements from index 0 to "jz" has already been initialized as "fw" at line 290 [1], and 2) variable "jz" should be non-negative from the comment at line 99 [2].
>> 
>> Note-1: GCC warning option -Wmaybe-uninitialized is not a new one. Note-2: x86-64 build with GCC 12 on Ubuntu 22.04 passed in my local test.
>> 
>> This warning is raised only on GCC 12 + AArch64. I suspect it might be some GCC 12 bug, so I reported it to GCC community [3].
>> 
>> Since it involves third party code, I think it's better to suppress the warning by simply disabling this warning option in the makefile.
>> 
>> Testing: Release builds with GCC 9, GCC 11 and GCC 12 passed on Ubuntu 22.04/AArch64 system.
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libfdlibm/k_rem_pio2.c#L290 
>> [2] https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libfdlibm/k_rem_pio2.c#L99 
>> [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106992
>
> make/modules/java.base/lib/CoreLibraries.gmk line 52:
> 
>> 50:     CFLAGS_aix := -qfloat=nomaf, \
>> 51:     DISABLED_WARNINGS_gcc := sign-compare misleading-indentation \
>> 52:         array-bounds maybe-uninitialized, \
> 
> Something like this would be better:
> 
> #pragma GCC diagnostic push
> #pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
>     write(foo, bar, baz);
> #pragma GCC diagnostic pop

Thanks for your review.

Your mentioned solution should work and we can also enable the pragma only for aarch64 + gcc>=12 condition.
I considered such a solution when preparing this patch.

But I personally prefer to suppress the waring in the makefile, mainly because fdlibm is 3rd party library and we'd better not changing the source code. I think it is a long-standing policy.

-------------

PR: https://git.openjdk.org/jdk/pull/10386

From alanb at openjdk.org  Fri Sep 23 07:59:16 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 23 Sep 2022 07:59:16 GMT
Subject: Integrated: 8289610: Degrade Thread.stop
In-Reply-To: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
Message-ID: <rApjpOiHjrtsAtbAXYhxuyOB3uAhSHS58h8VmrVi7BA=.53a55061-ea0c-4b9d-b57b-b72b34e0a0bd@github.com>

On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
> 
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
> 
> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
> 
> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.

This pull request has now been integrated.

Changeset: acd5bcfc
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/acd5bcfc8897908d82e9008ee2def9476f046a4d
Stats:     341 lines in 26 files changed: 115 ins; 162 del; 64 mod

8289610: Degrade Thread.stop

Reviewed-by: rriggs, cjplummer, jpai, mchung, prr, mullan

-------------

PR: https://git.openjdk.org/jdk/pull/10230

From dholmes at openjdk.org  Fri Sep 23 08:58:42 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 23 Sep 2022 08:58:42 GMT
Subject: RFR: 8293592: Remove JVM_StopThread, stillborn, and related cleanup
Message-ID: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>

Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610).

Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started.

Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same).

Testing: tiers 1-3

-------------

Commit messages:
 - Removal all special handling of ThreadDeath.
 - Remove all references to the stillborn field
 - Initial commit: remove JVM_StopThread
 - Merge
 - Updates to Java Thread Primitive Deprecation page
 - Repalce "it" with "victim thread"
 - Merge
 - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop
 - become -> became in javadoc
 - Merge
 - ... and 5 more: https://git.openjdk.org/jdk/compare/01e7b881...58bfb313

Changes: https://git.openjdk.org/jdk/pull/10400/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10400&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293592
  Stats: 549 lines in 43 files changed: 134 ins; 308 del; 107 mod
  Patch: https://git.openjdk.org/jdk/pull/10400.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10400/head:pull/10400

PR: https://git.openjdk.org/jdk/pull/10400

From shade at openjdk.org  Fri Sep 23 08:59:04 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 23 Sep 2022 08:59:04 GMT
Subject: RFR: 8293991: java/lang/Float/Binary16ConversionNaN.java fails on
 silent NaN conversions [v2]
In-Reply-To: <HbgXns2WQaRVbYA_L3z1L83q3ieUBc7sMIIR1QK597Q=.e9bd69bf-19f1-498a-ae1b-a118ec27620a@github.com>
References: <afYfFbJj3gshaWbUks0uVsHBJLFkND1vY1ccwSpFW60=.6b0b7208-c02c-4fe5-808f-6f9f4dc13ac5@github.com>
 <HbgXns2WQaRVbYA_L3z1L83q3ieUBc7sMIIR1QK597Q=.e9bd69bf-19f1-498a-ae1b-a118ec27620a@github.com>
Message-ID: <NsXaCiutnCKR7Nl3df7Wb7R8nk2Gm2clrIGsWYDzpeI=.cf57a8aa-1bb5-4d7e-add0-e9e1554ea35f@github.com>

On Thu, 22 Sep 2022 18:48:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Reliably reproduces on x86-32 with FPU:
>> 
>> 
>> $ CONF=linux-x86-server-fastdebug make test TEST=java/lang/Float/Binary16ConversionNaN.java TEST_VM_OPTS="-XX:UseAVX=0 -XX:UseSSE=0"
>> ...
>> Roundtrip failure on NaN value 7de2 got back 7fe2
>> Roundtrip failure on NaN value fde2 got back ffe2
>> 
>> 
>> Since there are many NaN values in FP16 -- basically any non-zero significand works, we should probably just relax the test a bit.
>> 
>> Attn @jddarcy ;)
>> 
>> Additional testing:
>>  - [x] Linux x86_32 fastdebug, `-XX:UseAVX=0 -XX:UseSSE=0`, affected test now passes
>>  - [x] Linux x86_32 fastdebug, `-XX:UseAVX=0 -XX:UseSSE=1`, affected test still passes
>>  - [x]  Linux x86_64 fastdebug, affected test still passes
>
> Aleksey Shipilev 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:
> 
>  - Just exclude the test with x87
>  - Revert test
>  - Merge branch 'master' into JDK-8293991-x86-32-fp16
>  - Indenting
>  - Fix

Ok, I am integrating to unbreak this test on x86_32.

-------------

PR: https://git.openjdk.org/jdk/pull/10333

From shade at openjdk.org  Fri Sep 23 09:07:49 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 23 Sep 2022 09:07:49 GMT
Subject: Integrated: 8293991: java/lang/Float/Binary16ConversionNaN.java fails
 on silent NaN conversions
In-Reply-To: <afYfFbJj3gshaWbUks0uVsHBJLFkND1vY1ccwSpFW60=.6b0b7208-c02c-4fe5-808f-6f9f4dc13ac5@github.com>
References: <afYfFbJj3gshaWbUks0uVsHBJLFkND1vY1ccwSpFW60=.6b0b7208-c02c-4fe5-808f-6f9f4dc13ac5@github.com>
Message-ID: <BVrJWHwHtUhzuO2xkuD5HQOahx9BonGZUSEeN30LG9Y=.735691c4-23a9-4a46-b698-cb5ead7bac8c@github.com>

On Mon, 19 Sep 2022 10:25:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Reliably reproduces on x86-32 with FPU:
> 
> 
> $ CONF=linux-x86-server-fastdebug make test TEST=java/lang/Float/Binary16ConversionNaN.java TEST_VM_OPTS="-XX:UseAVX=0 -XX:UseSSE=0"
> ...
> Roundtrip failure on NaN value 7de2 got back 7fe2
> Roundtrip failure on NaN value fde2 got back ffe2
> 
> 
> Since there are many NaN values in FP16 -- basically any non-zero significand works, we should probably just relax the test a bit.
> 
> Attn @jddarcy ;)
> 
> Additional testing:
>  - [x] Linux x86_32 fastdebug, `-XX:UseAVX=0 -XX:UseSSE=0`, affected test now passes
>  - [x] Linux x86_32 fastdebug, `-XX:UseAVX=0 -XX:UseSSE=1`, affected test still passes
>  - [x]  Linux x86_64 fastdebug, affected test still passes

This pull request has now been integrated.

Changeset: 0b56b822
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0b56b822436a0662170c11777ff0009b89a667eb
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8293991: java/lang/Float/Binary16ConversionNaN.java fails on silent NaN conversions

Reviewed-by: darcy

-------------

PR: https://git.openjdk.org/jdk/pull/10333

From sspitsyn at openjdk.org  Fri Sep 23 09:37:18 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 23 Sep 2022 09:37:18 GMT
Subject: RFR: 8293613: need to properly handle and hide tmp VTMS
 transitions [v3]
In-Reply-To: <dv7Njja_pwgsqGMUu9Te08dhKnFsk5wXPf3O2OT65ic=.55108dd8-03e3-4cc1-b858-183d415ca9fd@github.com>
References: <O_jzls_cv3HBC0NbzuYV2LXaW9VB2M18FroUfXWXd2w=.fa9d1f3c-40a2-42bd-a09b-dadd5032e513@github.com>
 <ve9g9LcSrawK3kb-TxKqxkSUOvkvnIsebd84GAub2DQ=.54a4a79b-be0a-47ef-99ba-63b93236cf08@github.com>
 <vMfCeRbX7oTnnv5-1PggLMUc1Q8MjZ0mnSFp5cutdTA=.08a9c27a-1bc2-4118-8f88-56c741df1435@github.com>
 <dv7Njja_pwgsqGMUu9Te08dhKnFsk5wXPf3O2OT65ic=.55108dd8-03e3-4cc1-b858-183d415ca9fd@github.com>
Message-ID: <w1KFr1pze66tEuITC_7bjT2YzmUcASQ5dsq2yVv8iP0=.650ff62d-cdb4-4c1b-b773-d29cd8f5e949@github.com>

On Tue, 20 Sep 2022 22:41:50 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/runtime/javaThread.cpp line 1174:
>> 
>>> 1172: #if INCLUDE_JVMTI
>>> 1173:   // Suspending a JavaThread in VTMS transition or disabling VTMS transitions can cause deadlocks.
>>> 1174:   assert(!is_in_non_tmp_VTMS_transition(), "no suspend allowed in VTMS transition");
>> 
>> IMHO, a non tmp VTMS transition should be considered a type of VTMS transition, so the assert check here does not really match the assert text. Also see my related comments below on naming and use of these flags and APIs.
>
> Thanks. Accepted.

Chris, I believe, this comment is resolved. Please, let me know if you disagree.

>> src/hotspot/share/runtime/javaThread.hpp line 650:
>> 
>>> 648:   void set_is_in_VTMS_transition(bool val);
>>> 649:   bool is_in_tmp_VTMS_transition() const         { return _is_in_tmp_VTMS_transition; }
>>> 650:   void toggle_is_in_tmp_VTMS_transition()        { _is_in_tmp_VTMS_transition = !_is_in_tmp_VTMS_transition; };
>> 
>> The naming of the flags does not match up with the naming of the APIs, which is confusing.  An API named  is_in_VTMS_transition() should return _is_in_VTMS_transition. I think part of problem is that _is_in_VTMS_transition is not a superset of _is_in_tmp_VTMS_transition. The flags are never both set true, although both can be false. Maybe this should be changed to make it an invariant that if _is_in_tmp_VTMS_transit is true, then _is_in_tmp_VTMS_transition is true.
>
> I agree, this naming is not good. However, I was reluctant to do required renaming because it can potentially impact many spots and make review harder. Let me think a little bit more on this.

I've simplified this naming but, probably, not in a way your were expecting. Please, see my comment below.

-------------

PR: https://git.openjdk.org/jdk/pull/10321

From sspitsyn at openjdk.org  Fri Sep 23 09:37:21 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 23 Sep 2022 09:37:21 GMT
Subject: RFR: 8293613: need to properly handle and hide tmp VTMS
 transitions [v4]
In-Reply-To: <AfgR97-WxKBpt0uuUTijy4rnpXY_XjVqXbJRSEdV0hw=.5e4c6cd6-de28-4fc1-ab1b-681be92a512b@github.com>
References: <O_jzls_cv3HBC0NbzuYV2LXaW9VB2M18FroUfXWXd2w=.fa9d1f3c-40a2-42bd-a09b-dadd5032e513@github.com>
 <OyzEjJjgvDVNRlKMONSVBtpcnVBJ9QPHdV2LqfcuTSc=.3810b0d9-3ce3-47f6-9662-6a91514efa05@github.com>
 <AfgR97-WxKBpt0uuUTijy4rnpXY_XjVqXbJRSEdV0hw=.5e4c6cd6-de28-4fc1-ab1b-681be92a512b@github.com>
Message-ID: <Go_cGPWr-ZcCoaoqf-IDanhNNuUR6YlNOwJ4dtv-3no=.a3ac3bd1-cc36-456c-8b39-39c0cdbd5bc0@github.com>

On Thu, 22 Sep 2022 20:09:21 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   1. addressed review comments from Chris; added VirtualThread.java update from Alan
>
> src/hotspot/share/runtime/javaThread.hpp line 652:
> 
>> 650:   void set_is_in_VTMS_transition(bool val);
>> 651:   void toggle_is_in_tmp_VTMS_transition()        { _is_in_tmp_VTMS_transition = !_is_in_tmp_VTMS_transition; };
>> 652: 
> 
> My suggestion was to have the term "in VTMS transition" be inclusive of temp transitions. So based on your current names I would suggest:
> 
> - is_in_VTMS_transition -> is_in_non_tmp_VTMS_transition
> - is_in_any_VTMS_transition -> is_in_VTMS_transition
> 
> But that becomes a problem for `set_is_in_VTMS_transition`, which would need to be renamed `set_is_in_non_tmp_VTMS_transition`, which I'm guessing you don't want to do. So let's instead just hope this all goes away before thinking about it any more.

Thank you for sharing your suggestion.
To be honest, I'm inclined to keep the two as simple as possible, independent end mutually exclusive.
Temporary transitions have big difference comparing to normal transitions.
They are allowed to be suspended and do not clash with VTMS disablers.
Please, let me know if are okay with this.

Unfortunately, it seems, Alan got some difficulties in getting rid of temporary transitions.
I'll double check on it just to be sure I understand it correctly.

-------------

PR: https://git.openjdk.org/jdk/pull/10321

From sspitsyn at openjdk.org  Fri Sep 23 09:42:15 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 23 Sep 2022 09:42:15 GMT
Subject: RFR: 8293613: need to properly handle and hide tmp VTMS
 transitions [v3]
In-Reply-To: <SCb5RSNqx8_VOEBt85tDwnCH9r36GOK_-nE3WvyPwD0=.40baa8e2-4997-4534-8fe3-2274b206f8a5@github.com>
References: <O_jzls_cv3HBC0NbzuYV2LXaW9VB2M18FroUfXWXd2w=.fa9d1f3c-40a2-42bd-a09b-dadd5032e513@github.com>
 <ve9g9LcSrawK3kb-TxKqxkSUOvkvnIsebd84GAub2DQ=.54a4a79b-be0a-47ef-99ba-63b93236cf08@github.com>
 <vMfCeRbX7oTnnv5-1PggLMUc1Q8MjZ0mnSFp5cutdTA=.08a9c27a-1bc2-4118-8f88-56c741df1435@github.com>
 <SCb5RSNqx8_VOEBt85tDwnCH9r36GOK_-nE3WvyPwD0=.40baa8e2-4997-4534-8fe3-2274b206f8a5@github.com>
Message-ID: <CDZqZwpAJWYs_xuWAmc0XgmVHb6eMGoW2onZm1_sSmo=.12e6a0d5-c002-4b83-932c-e2cb37473410@github.com>

On Tue, 20 Sep 2022 22:34:59 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiExport.cpp line 1055:
>> 
>>> 1053:   if (JavaThread::current()->is_in_tmp_VTMS_transition()) {
>>> 1054:     return false;
>>> 1055:   }
>> 
>> You mentioned this in the PR description. However, it's not clear to me why this is ok.  Also, it should be commented.
>> 
>> Same thing for changes in JvmtiExport::post_class_load() and JvmtiExport::post_class_prepare().
>
> I initially wanted to consult on this with Alan. It feels like it'd be better if I did it before posting this PR.
> We have just two possible approaches here. The best approach is to move any class loading out of the temporary transition code path. Then we already have the relevant asserts in place. However, this is not that easy to solve. Alan already suggested a couple of patches which I've tested but new places with class loads were discovered. Another approach is to skip all ClassLoad, ClassPrepare and CFLH events in context of temporary transitions. It is hard to estimate how acceptable it is. At least, I've not found any failing tests because of it which means it most likely does not impact the debugger. My current suggestion is to file a bug and try to address it later as Alan may need more time for analysis.

We touched this issue with Alan and made a couple of updates. However, it occurred much harder to get rid of all class loading in context of temporary transitions. My current suggestion is still on the table. It is to file a separate bug and attempt to fix it later. NO test failures were discovered because of the skipped ClassLoad, ClassPrepare and CFLH events.

-------------

PR: https://git.openjdk.org/jdk/pull/10321

From fyang at openjdk.org  Fri Sep 23 09:42:22 2022
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 23 Sep 2022 09:42:22 GMT
Subject: RFR: 8294198: Implement isFinite intrinsic for RISC-V
In-Reply-To: <R4tlj4gD-vO5BzJKgAx9-O4s7BD7q6NlLhMhl6PMUuc=.c67bb8fb-3bf1-4035-be21-cc873220bf70@github.com>
References: <R4tlj4gD-vO5BzJKgAx9-O4s7BD7q6NlLhMhl6PMUuc=.c67bb8fb-3bf1-4035-be21-cc873220bf70@github.com>
Message-ID: <TkoMbqMVOh_xZ0pgkb3aPhjRUHpXwNL4B4yFw6kVl7c=.3a718afa-d12f-4fc6-9db8-dfe3aa4a6cce@github.com>

On Thu, 22 Sep 2022 12:56:49 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

> Unlike on x86 (see 8285868 and the discussion in review), isFinite intrinsic turned out to be profitable on RISC-V using the same fclass instruction as for 8293695 (isInfinite instrinsic). Therefore, I'm proposing to have it added on RISC-V in this PR.
> 
> benchmark results:
> 
> before:
> 
> Benchmark                              Mode  Cnt   Score   Error  Units
> DoubleClassCheck.testIsFiniteBranch    avgt   15  52.824 ? 1.744  ns/op
> DoubleClassCheck.testIsFiniteCMov      avgt   15  16.104 ? 0.358  ns/op
> DoubleClassCheck.testIsFiniteStore     avgt   15  14.366 ? 2.174  ns/op
> FloatClassCheck.testIsFiniteBranch     avgt   15  49.821 ? 0.330  ns/op
> FloatClassCheck.testIsFiniteCMov       avgt   15  14.702 ? 0.335  ns/op
> FloatClassCheck.testIsFiniteStore      avgt   15  14.749 ? 0.496  ns/op
> 
> after:
> 
> DoubleClassCheck.testIsFiniteBranch    avgt   15  48.921 ? 0.557  ns/op
> DoubleClassCheck.testIsFiniteCMov      avgt   15  13.716 ? 0.304  ns/op
> DoubleClassCheck.testIsFiniteStore     avgt   15   9.152 ? 0.158  ns/op
> FloatClassCheck.testIsFiniteBranch     avgt   15  47.740 ? 2.028  ns/op
> FloatClassCheck.testIsFiniteCMov       avgt   15  13.299 ? 0.282  ns/op
> FloatClassCheck.testIsFiniteStore      avgt   15   9.185 ? 0.396  ns/op
> 
> Existing isInfinite jtreg test was altered to be able to use common code for isFinite test and fine-grained requires tag filtering. Existing benchmark was modified to include isFinite case. A typo ("Atleast" -> "At least") was fixed on the way.
> 
> Test passed on both release and fastdebug builds. Hotspot tier1 tests were run on x86_64 and RISC-V with no issues.

May I ask on which platform was the JMH test performed? I see some fluctuations for 'testIsFiniteBranch' on SiFive Unmatched board:

Before:
Benchmark                              Mode  Cnt   Score   Error  Units
DoubleClassCheck.testIsFiniteBranch    avgt   15  32.114 ? 3.514  ns/op
DoubleClassCheck.testIsFiniteCMov      avgt   15   8.656 ? 0.023  ns/op
DoubleClassCheck.testIsFiniteStore     avgt   15   7.757 ? 1.691  ns/op
FloatClassCheck.testIsFiniteBranch     avgt   15  32.446 ? 3.130  ns/op
FloatClassCheck.testIsFiniteCMov       avgt   15   7.801 ? 0.011  ns/op
FloatClassCheck.testIsFiniteStore      avgt   15   7.279 ? 1.483  ns/op

Benchmark                              Mode  Cnt   Score   Error  Units
DoubleClassCheck.testIsFiniteBranch    avgt   15  33.724 ? 5.157  ns/op
DoubleClassCheck.testIsFiniteCMov      avgt   15   8.642 ? 0.012  ns/op
DoubleClassCheck.testIsFiniteStore     avgt   15   7.765 ? 1.711  ns/op
FloatClassCheck.testIsFiniteBranch     avgt   15  31.401 ? 4.104  ns/op
FloatClassCheck.testIsFiniteCMov       avgt   15   7.799 ? 0.014  ns/op
FloatClassCheck.testIsFiniteStore      avgt   15   8.234 ? 0.023  ns/op

Benchmark                              Mode  Cnt   Score   Error  Units
DoubleClassCheck.testIsFiniteBranch    avgt   15  32.461 ? 3.688  ns/op
DoubleClassCheck.testIsFiniteCMov      avgt   15   8.643 ? 0.007  ns/op
DoubleClassCheck.testIsFiniteStore     avgt   15   7.772 ? 1.701  ns/op
FloatClassCheck.testIsFiniteBranch     avgt   15  33.258 ? 3.131  ns/op
FloatClassCheck.testIsFiniteCMov       avgt   15   7.815 ? 0.014  ns/op
FloatClassCheck.testIsFiniteStore      avgt   15   6.343 ? 1.475  ns/op

After:
Benchmark                              Mode  Cnt   Score   Error  Units
DoubleClassCheck.testIsFiniteBranch    avgt   15  33.915 ? 4.193  ns/op
DoubleClassCheck.testIsFiniteCMov      avgt   15   7.736 ? 0.012  ns/op
DoubleClassCheck.testIsFiniteStore     avgt   15   5.931 ? 0.007  ns/op
FloatClassCheck.testIsFiniteBranch     avgt   15  33.845 ? 3.449  ns/op
FloatClassCheck.testIsFiniteCMov       avgt   15   7.543 ? 0.013  ns/op
FloatClassCheck.testIsFiniteStore      avgt   15   6.035 ? 0.006  ns/op

Benchmark                              Mode  Cnt   Score   Error  Units
DoubleClassCheck.testIsFiniteBranch    avgt   15  33.421 ? 4.262  ns/op
DoubleClassCheck.testIsFiniteCMov      avgt   15   7.734 ? 0.012  ns/op
DoubleClassCheck.testIsFiniteStore     avgt   15   5.940 ? 0.010  ns/op
FloatClassCheck.testIsFiniteBranch     avgt   15  33.348 ? 2.656  ns/op
FloatClassCheck.testIsFiniteCMov       avgt   15   7.542 ? 0.013  ns/op
FloatClassCheck.testIsFiniteStore      avgt   15   6.040 ? 0.004  ns/op

Benchmark                              Mode  Cnt   Score   Error  Units
DoubleClassCheck.testIsFiniteBranch    avgt   15  31.669 ? 2.517  ns/op
DoubleClassCheck.testIsFiniteCMov      avgt   15   7.761 ? 0.092  ns/op
DoubleClassCheck.testIsFiniteStore     avgt   15   5.940 ? 0.007  ns/op
FloatClassCheck.testIsFiniteBranch     avgt   15  33.508 ? 3.680  ns/op
FloatClassCheck.testIsFiniteCMov       avgt   15   7.534 ? 0.009  ns/op
FloatClassCheck.testIsFiniteStore      avgt   15   6.031 ? 0.007  ns/op

-------------

PR: https://git.openjdk.org/jdk/pull/10391

From alanb at openjdk.org  Fri Sep 23 11:12:24 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 23 Sep 2022 11:12:24 GMT
Subject: RFR: 8293592: Remove JVM_StopThread, stillborn,
 and related cleanup
In-Reply-To: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
References: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
Message-ID: <Bfq-Tx0S9oPszwvfoUkCtVd16ARxYp6c8Y1Oe9S1_y4=.1b7e4278-2ba0-455e-9cd8-2d0b27f49d70@github.com>

On Fri, 23 Sep 2022 06:17:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610).
> 
> Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started.
> 
> Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same).
> 
> Testing: tiers 1-3

(JDK-8289610 is integrated now so once you sync up it should remove the changes from the dependent PR once the list of changed files. You should be able to trim down the labels too.)

I did a pass over the src/hotspot change and didn't spot any issues. It's good that stillborn can go away. The removal of the special-casing of ThreadDeath is consistent with the libs side of the change, including the change to ExceptionDescribe.

-------------

PR: https://git.openjdk.org/jdk/pull/10400

From jiefu at openjdk.org  Fri Sep 23 11:23:03 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Fri, 23 Sep 2022 11:23:03 GMT
Subject: RFR: 8294271: make bootcycle-images fails after JDK-8289610
Message-ID: <ysUMbEypmBqaqHXRIipqu2XF_s7tbExRhYA2etsZz04=.102cf369-437b-4cfc-89ef-0a90eaaccdb5@github.com>

Hi all,

Since `ThreadDeath` would be deprecated soon, I assume it's fine to just remove it.

Thanks.
Best regards,
Jie

-------------

Commit messages:
 - 8294271: make bootcycle-images fails after JDK-8289610

Changes: https://git.openjdk.org/jdk/pull/10406/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10406&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294271
  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10406.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10406/head:pull/10406

PR: https://git.openjdk.org/jdk/pull/10406

From shade at openjdk.org  Fri Sep 23 11:38:13 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 23 Sep 2022 11:38:13 GMT
Subject: RFR: 8294271: make bootcycle-images fails after JDK-8289610
In-Reply-To: <ysUMbEypmBqaqHXRIipqu2XF_s7tbExRhYA2etsZz04=.102cf369-437b-4cfc-89ef-0a90eaaccdb5@github.com>
References: <ysUMbEypmBqaqHXRIipqu2XF_s7tbExRhYA2etsZz04=.102cf369-437b-4cfc-89ef-0a90eaaccdb5@github.com>
Message-ID: <_LQAybGlBaOVXSdSG0XX-z3-pg8ELO5LAFOsdZ9oSxI=.6531e26e-1c47-425f-b4c9-e435c118ad6e@github.com>

On Fri, 23 Sep 2022 11:03:52 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Since `ThreadDeath` would be deprecated soon, I assume it's fine to just remove it.
> 
> Thanks.
> Best regards,
> Jie

This looks fine, and the current use of `ThreadDeath` does not even seem correct (you have to rethrow it). But I wonder if this should be the subtask of https://bugs.openjdk.org/browse/JDK-8289610, like "Remove use of ThreadDeath from make utilities"?

-------------

PR: https://git.openjdk.org/jdk/pull/10406

From ihse at openjdk.org  Fri Sep 23 12:04:22 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 23 Sep 2022 12:04:22 GMT
Subject: RFR: 8294271: make bootcycle-images fails after JDK-8289610
In-Reply-To: <_LQAybGlBaOVXSdSG0XX-z3-pg8ELO5LAFOsdZ9oSxI=.6531e26e-1c47-425f-b4c9-e435c118ad6e@github.com>
References: <ysUMbEypmBqaqHXRIipqu2XF_s7tbExRhYA2etsZz04=.102cf369-437b-4cfc-89ef-0a90eaaccdb5@github.com>
 <_LQAybGlBaOVXSdSG0XX-z3-pg8ELO5LAFOsdZ9oSxI=.6531e26e-1c47-425f-b4c9-e435c118ad6e@github.com>
Message-ID: <nE4NmmmHJSWuTPUR1Gu6ToZGjq3gJ6uOqBIsxMltn4Y=.5a3cfa79-f7af-43cc-9488-af08dede66da@github.com>

On Fri, 23 Sep 2022 11:34:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Hi all,
>> 
>> Since `ThreadDeath` would be deprecated soon, I assume it's fine to just remove it.
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> This looks fine, and the current use of `ThreadDeath` does not even seem correct (you have to rethrow it). But I wonder if this should be the subtask of https://bugs.openjdk.org/browse/JDK-8289610, like "Remove use of ThreadDeath from make utilities"?

The fix looks good. @shipilev, what would the benefit be of having this as a subtask? To me it sounds just like additional bureaucracy, at least given the fact that this was now in fact created as a separate bug report.

-------------

PR: https://git.openjdk.org/jdk/pull/10406

From shade at openjdk.org  Fri Sep 23 12:08:27 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 23 Sep 2022 12:08:27 GMT
Subject: RFR: 8294271: make bootcycle-images fails after JDK-8289610
In-Reply-To: <_LQAybGlBaOVXSdSG0XX-z3-pg8ELO5LAFOsdZ9oSxI=.6531e26e-1c47-425f-b4c9-e435c118ad6e@github.com>
References: <ysUMbEypmBqaqHXRIipqu2XF_s7tbExRhYA2etsZz04=.102cf369-437b-4cfc-89ef-0a90eaaccdb5@github.com>
 <_LQAybGlBaOVXSdSG0XX-z3-pg8ELO5LAFOsdZ9oSxI=.6531e26e-1c47-425f-b4c9-e435c118ad6e@github.com>
Message-ID: <9cjkWuB7NeOq0abdQhb3IAlluzUK5bxI13y_XqORBCU=.84bf8ea7-9d2a-4837-9509-66e251832304@github.com>

On Fri, 23 Sep 2022 11:34:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Hi all,
>> 
>> Since `ThreadDeath` would be deprecated soon, I assume it's fine to just remove it.
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> This looks fine, and the current use of `ThreadDeath` does not even seem correct (you have to rethrow it). But I wonder if this should be the subtask of https://bugs.openjdk.org/browse/JDK-8289610, like "Remove use of ThreadDeath from make utilities"?

> The fix looks good. @shipilev, what would the benefit be of having this as a subtask? To me it sounds just like additional bureaucracy, at least given the fact that this was now in fact created as a separate bug report.

Ordnung muss sein, yes. The subtasks on original issues track the cleanups in particular parts of JDK. Having effectively a missing cleanup masquerading as build fix irks me a bit. You can convert the issue to the subtask with one button click, if I remember correctly. That should not change the issue ID or have implications other implications for this PR, apart from renaming it a bit.

-------------

PR: https://git.openjdk.org/jdk/pull/10406

From ihse at openjdk.org  Fri Sep 23 12:13:21 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 23 Sep 2022 12:13:21 GMT
Subject: RFR: 8294271: make bootcycle-images fails after JDK-8289610
In-Reply-To: <ysUMbEypmBqaqHXRIipqu2XF_s7tbExRhYA2etsZz04=.102cf369-437b-4cfc-89ef-0a90eaaccdb5@github.com>
References: <ysUMbEypmBqaqHXRIipqu2XF_s7tbExRhYA2etsZz04=.102cf369-437b-4cfc-89ef-0a90eaaccdb5@github.com>
Message-ID: <bNjCkpNgZzUw62oeLo5bAdj6c6MwupKVj1notP9UQuY=.dd8db1bf-59a3-426d-958c-1adadc7fb73d@github.com>

On Fri, 23 Sep 2022 11:03:52 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Since `ThreadDeath` would be deprecated soon, I assume it's fine to just remove it.
> 
> Thanks.
> Best regards,
> Jie

Fix is good but change bug type to subtask as Shipilev says.

In that case it sounds fine. I was worried you'd have to close and re-create the entire issue.

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10406

From jiefu at openjdk.org  Fri Sep 23 12:22:34 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Fri, 23 Sep 2022 12:22:34 GMT
Subject: RFR: 8294271: make bootcycle-images fails after JDK-8289610
In-Reply-To: <bNjCkpNgZzUw62oeLo5bAdj6c6MwupKVj1notP9UQuY=.dd8db1bf-59a3-426d-958c-1adadc7fb73d@github.com>
References: <ysUMbEypmBqaqHXRIipqu2XF_s7tbExRhYA2etsZz04=.102cf369-437b-4cfc-89ef-0a90eaaccdb5@github.com>
 <bNjCkpNgZzUw62oeLo5bAdj6c6MwupKVj1notP9UQuY=.dd8db1bf-59a3-426d-958c-1adadc7fb73d@github.com>
Message-ID: <st_gDmjgG5SV8cqylFfNMRh2PZMMSliKH0CTgdfWLMQ=.995ad27e-8faa-4b1a-b837-5cda8c8ba771@github.com>

On Fri, 23 Sep 2022 12:09:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Fix is good but change bug type to subtask as Shipilev says.

Done.
Thanks @magicus and @shipilev .

-------------

PR: https://git.openjdk.org/jdk/pull/10406

From shade at openjdk.org  Fri Sep 23 12:27:19 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 23 Sep 2022 12:27:19 GMT
Subject: RFR: 8294271: make bootcycle-images fails after JDK-8289610
In-Reply-To: <st_gDmjgG5SV8cqylFfNMRh2PZMMSliKH0CTgdfWLMQ=.995ad27e-8faa-4b1a-b837-5cda8c8ba771@github.com>
References: <ysUMbEypmBqaqHXRIipqu2XF_s7tbExRhYA2etsZz04=.102cf369-437b-4cfc-89ef-0a90eaaccdb5@github.com>
 <bNjCkpNgZzUw62oeLo5bAdj6c6MwupKVj1notP9UQuY=.dd8db1bf-59a3-426d-958c-1adadc7fb73d@github.com>
 <st_gDmjgG5SV8cqylFfNMRh2PZMMSliKH0CTgdfWLMQ=.995ad27e-8faa-4b1a-b837-5cda8c8ba771@github.com>
Message-ID: <XxkmhM2ItddtOI_365vsamZYa72S8W2YHusKuO8lJHo=.71b6c28b-d6bd-47f6-98f6-488cbd1efb69@github.com>

On Fri, 23 Sep 2022 12:20:09 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> > Fix is good but change bug type to subtask as Shipilev says.
> 
> Done. Thanks @magicus and @shipilev .

I think it is also better be named "Remove use of ThreadDeath from make utilities" :)

-------------

PR: https://git.openjdk.org/jdk/pull/10406

From jiefu at openjdk.org  Fri Sep 23 12:30:10 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Fri, 23 Sep 2022 12:30:10 GMT
Subject: RFR: 8294271: Remove use of ThreadDeath from make utilities
In-Reply-To: <XxkmhM2ItddtOI_365vsamZYa72S8W2YHusKuO8lJHo=.71b6c28b-d6bd-47f6-98f6-488cbd1efb69@github.com>
References: <ysUMbEypmBqaqHXRIipqu2XF_s7tbExRhYA2etsZz04=.102cf369-437b-4cfc-89ef-0a90eaaccdb5@github.com>
 <bNjCkpNgZzUw62oeLo5bAdj6c6MwupKVj1notP9UQuY=.dd8db1bf-59a3-426d-958c-1adadc7fb73d@github.com>
 <st_gDmjgG5SV8cqylFfNMRh2PZMMSliKH0CTgdfWLMQ=.995ad27e-8faa-4b1a-b837-5cda8c8ba771@github.com>
 <XxkmhM2ItddtOI_365vsamZYa72S8W2YHusKuO8lJHo=.71b6c28b-d6bd-47f6-98f6-488cbd1efb69@github.com>
Message-ID: <Agg-Cuuo9i-L0LWNsD_xmh5sWhFjbxPfYHGNn8icxp4=.c1cf2a75-91d2-4b95-a269-6fb81179f0bf@github.com>

On Fri, 23 Sep 2022 12:23:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I think it is also better be named "Remove use of ThreadDeath from make utilities" :)

Done.
Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10406

From ihse at openjdk.org  Fri Sep 23 12:38:09 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 23 Sep 2022 12:38:09 GMT
Subject: RFR: 8294271: Remove use of ThreadDeath from make utilities
In-Reply-To: <ysUMbEypmBqaqHXRIipqu2XF_s7tbExRhYA2etsZz04=.102cf369-437b-4cfc-89ef-0a90eaaccdb5@github.com>
References: <ysUMbEypmBqaqHXRIipqu2XF_s7tbExRhYA2etsZz04=.102cf369-437b-4cfc-89ef-0a90eaaccdb5@github.com>
Message-ID: <KssLH8qiwfkBVh3lCaytir5syPGzNY6LPnb1i_BqKH4=.dc3b4db5-c74d-44f0-8a5c-94d72f891a24@github.com>

On Fri, 23 Sep 2022 11:03:52 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Since `ThreadDeath` would be deprecated soon, I assume it's fine to just remove it.
> 
> Thanks.
> Best regards,
> Jie

?

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10406

From shade at openjdk.org  Fri Sep 23 12:43:09 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 23 Sep 2022 12:43:09 GMT
Subject: RFR: 8294271: Remove use of ThreadDeath from make utilities
In-Reply-To: <ysUMbEypmBqaqHXRIipqu2XF_s7tbExRhYA2etsZz04=.102cf369-437b-4cfc-89ef-0a90eaaccdb5@github.com>
References: <ysUMbEypmBqaqHXRIipqu2XF_s7tbExRhYA2etsZz04=.102cf369-437b-4cfc-89ef-0a90eaaccdb5@github.com>
Message-ID: <e9Wkxs2Mn2bTZho5W_SXc83eJIRIKx0VJikSY8y6Qq4=.52568ed3-edbc-48cb-93a5-263d0239fc42@github.com>

On Fri, 23 Sep 2022 11:03:52 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Since `ThreadDeath` would be deprecated soon, I assume it's fine to just remove it.
> 
> Thanks.
> Best regards,
> Jie

Good!

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10406

From coleenp at openjdk.org  Fri Sep 23 12:43:15 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 23 Sep 2022 12:43:15 GMT
Subject: RFR: 8290482: Update JNI Specification of DestroyJavaVM for better
 alignment with JLS, JVMS, and Java SE API Specifications [v4]
In-Reply-To: <5LZVfXnTpbyr_NWeYid9qzKrnZ6t2b7ZL5BtHEZ4Syc=.bff15db2-726a-4976-89f1-edd826d75bf2@github.com>
References: <M2IRKiuONiNI45YTu9wdu1o8ZXJslnxRmgMvnlVU478=.4aa03d22-0395-4354-bf41-f11a74df791a@github.com>
 <5LZVfXnTpbyr_NWeYid9qzKrnZ6t2b7ZL5BtHEZ4Syc=.bff15db2-726a-4976-89f1-edd826d75bf2@github.com>
Message-ID: <7uEEjcCVoEfGK2L99QCHvzy9OWzl2I-4P_AelvyhvTc=.04adb658-216b-4811-a7a8-173a6786a44b@github.com>

On Tue, 20 Sep 2022 10:37:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This update is primarily about changes to the JNI Invocation API specification, mainly in relation to `DestroyJavaVM`. The motivation for the changes is to align with changes being made to the JLS, JVMS and `java.lang.Runtime`, specifications in relation to VM termination - ref:
>> 
>> JDK-8290196 12.8: Clarify the definition of program exit
>> https://bugs.openjdk.org/browse/JDK-8290196
>> 
>> JDK-8290388 5.7: Clarify the definition of JVM termination
>> https://bugs.openjdk.org/browse/JDK-8290388
>> 
>> JDK-8290036 Define and specify Runtime shutdown sequence
>> https://bugs.openjdk.org/browse/JDK-8290036
>> 
>> Mostly these are just non-normative changes to the JNI spec prose but there are two actual specification changes:
>> 
>> 1.  The fact it is an error to detach a thread with active Java frames was only mentioned in the overview section, not in the actual `DetachCurrentThread` specification. (Just an oversight - the VM already checked this)
>> 
>> 2.  We need to make it an error to call `DestroyJavaVM` from an attached thread with active Java frames (as this can't work for the same reason we disallow `DetachCurrentThread`). This requires an implementation change in Hotspot.
>> 
>> Issue 2 covers the code change, and regression test, in this PR.
>> 
>> In addition the specification changes can be seen here:
>> 
>> - specdiff: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/diff.html
>> - original: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-original.html
>> - new: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-new.html
>> 
>> The specification itself is not open but comments on the spec changes are welcome - though please see the JBS issue and CSR request first. The revised wording has already been extensively reviewed/negotiated between Alex Buckley, Stuart Marks and myself, so any change must either be a glaring error/problem or else a trivial adjustment.
>> 
>> Thank you.
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix JniVersion test

This seems good.  I looked at the specification changes and they looked okay also.

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10352

From ihse at openjdk.org  Fri Sep 23 12:51:28 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 23 Sep 2022 12:51:28 GMT
Subject: RFR: 8293887: AArch64 build failure with GCC 12 due to
 maybe-uninitialized warning in libfdlibm k_rem_pio2.c
In-Reply-To: <vks8-99Oc6cfhJMPg67PEsIcwhrcwsmW73E38O6mjEo=.ebcbada9-95c3-49c2-8411-c221614345ca@github.com>
References: <UTaCIvPdArIMVc2jDoPYp72K5MelURpuipDuZigrDy0=.16cf4031-3791-4fd4-aeb3-598fa4faf4db@github.com>
 <11i9FwYPL2nt-RHe135PRcOFcZdo_RsIFHxHw8AgYqw=.a17c8166-3077-40bb-836b-2e3112b280e4@github.com>
 <vks8-99Oc6cfhJMPg67PEsIcwhrcwsmW73E38O6mjEo=.ebcbada9-95c3-49c2-8411-c221614345ca@github.com>
Message-ID: <KTSgkRQE2fW5gvHESx2BdgeWZ0q0UoZnwOnfqsMkvuY=.184101d1-71e9-44c7-a8e0-112f1d75569b@github.com>

On Fri, 23 Sep 2022 06:56:20 GMT, Hao Sun <haosun at openjdk.org> wrote:

>> make/modules/java.base/lib/CoreLibraries.gmk line 52:
>> 
>>> 50:     CFLAGS_aix := -qfloat=nomaf, \
>>> 51:     DISABLED_WARNINGS_gcc := sign-compare misleading-indentation \
>>> 52:         array-bounds maybe-uninitialized, \
>> 
>> Something like this would be better:
>> 
>> #pragma GCC diagnostic push
>> #pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
>>     write(foo, bar, baz);
>> #pragma GCC diagnostic pop
>
> Thanks for your review.
> 
> Your mentioned solution should work and we can also enable the pragma only for aarch64 + gcc>=12 condition.
> I considered such a solution when preparing this patch.
> 
> But I personally prefer to suppress the waring in the makefile, mainly because fdlibm is 3rd party library and we'd better not changing the source code. I think it is a long-standing policy.

Yes, we should not modify 3rd party code.

What you would need is [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281). If you can hold back this patch for a little while, you'll be able to utilize it instead.

-------------

PR: https://git.openjdk.org/jdk/pull/10386

From alanb at openjdk.org  Fri Sep 23 13:24:19 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 23 Sep 2022 13:24:19 GMT
Subject: RFR: 8294271: Remove use of ThreadDeath from make utilities
In-Reply-To: <ysUMbEypmBqaqHXRIipqu2XF_s7tbExRhYA2etsZz04=.102cf369-437b-4cfc-89ef-0a90eaaccdb5@github.com>
References: <ysUMbEypmBqaqHXRIipqu2XF_s7tbExRhYA2etsZz04=.102cf369-437b-4cfc-89ef-0a90eaaccdb5@github.com>
Message-ID: <84HTQcEzqk2jsuxaf4YwhmiWnF7dKB6c3yTQ-mBMjh0=.92782043-97bf-4fab-8eaf-7bad5aec7f8a@github.com>

On Fri, 23 Sep 2022 11:03:52 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Since `ThreadDeath` would be deprecated soon, I assume it's fine to just remove it.
> 
> Thanks.
> Best regards,
> Jie

Sorry for this, the change to this tool used in the make file ended up with the cleanups to tests. Doing it now, to get boot cycle builds working again is fine.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10406

From avoitylov at openjdk.org  Fri Sep 23 13:29:21 2022
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Fri, 23 Sep 2022 13:29:21 GMT
Subject: RFR: 8294198: Implement isFinite intrinsic for RISC-V
In-Reply-To: <R4tlj4gD-vO5BzJKgAx9-O4s7BD7q6NlLhMhl6PMUuc=.c67bb8fb-3bf1-4035-be21-cc873220bf70@github.com>
References: <R4tlj4gD-vO5BzJKgAx9-O4s7BD7q6NlLhMhl6PMUuc=.c67bb8fb-3bf1-4035-be21-cc873220bf70@github.com>
Message-ID: <1pLzhhwS9UM_pIlsDwEUAhgYhgoM-bEmEVhiU52-SgQ=.765d106a-f996-4953-8e2e-5dd6219db87e@github.com>

On Thu, 22 Sep 2022 12:56:49 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

> Unlike on x86 (see 8285868 and the discussion in review), isFinite intrinsic turned out to be profitable on RISC-V using the same fclass instruction as for 8293695 (isInfinite instrinsic). Therefore, I'm proposing to have it added on RISC-V in this PR.
> 
> benchmark results:
> 
> before:
> 
> Benchmark                              Mode  Cnt   Score   Error  Units
> DoubleClassCheck.testIsFiniteBranch    avgt   15  52.824 ? 1.744  ns/op
> DoubleClassCheck.testIsFiniteCMov      avgt   15  16.104 ? 0.358  ns/op
> DoubleClassCheck.testIsFiniteStore     avgt   15  14.366 ? 2.174  ns/op
> FloatClassCheck.testIsFiniteBranch     avgt   15  49.821 ? 0.330  ns/op
> FloatClassCheck.testIsFiniteCMov       avgt   15  14.702 ? 0.335  ns/op
> FloatClassCheck.testIsFiniteStore      avgt   15  14.749 ? 0.496  ns/op
> 
> after:
> 
> DoubleClassCheck.testIsFiniteBranch    avgt   15  48.921 ? 0.557  ns/op
> DoubleClassCheck.testIsFiniteCMov      avgt   15  13.716 ? 0.304  ns/op
> DoubleClassCheck.testIsFiniteStore     avgt   15   9.152 ? 0.158  ns/op
> FloatClassCheck.testIsFiniteBranch     avgt   15  47.740 ? 2.028  ns/op
> FloatClassCheck.testIsFiniteCMov       avgt   15  13.299 ? 0.282  ns/op
> FloatClassCheck.testIsFiniteStore      avgt   15   9.185 ? 0.396  ns/op
> 
> Existing isInfinite jtreg test was altered to be able to use common code for isFinite test and fine-grained requires tag filtering. Existing benchmark was modified to include isFinite case. A typo ("Atleast" -> "At least") was fixed on the way.
> 
> Test passed on both release and fastdebug builds. Hotspot tier1 tests were run on x86_64 and RISC-V with no issues.

Good you checked on SiFive HW, as I could only check their cookbook for instruction costs. I was using C906.

You're not observing any statistically significant difference in the first benchmark from this change due to higher latency of fclass instruction on SiFive CPU (4 cycles, while C906 has 3 cycles latency for fclass). However, it is still profitable in general as we replace 2 relatively expensive FP instructions with 1 FP + 2 cheap GPR instructions. That's what the rest of the cases demonstrate on both SiFive and C906.

Overall, as the platform matures the instructions costs tend to decrease, so I'd assume fclass will take less cycles in most future implementations.

-------------

PR: https://git.openjdk.org/jdk/pull/10391

From jiefu at openjdk.org  Fri Sep 23 13:53:25 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Fri, 23 Sep 2022 13:53:25 GMT
Subject: RFR: 8294271: Remove use of ThreadDeath from make utilities
In-Reply-To: <ysUMbEypmBqaqHXRIipqu2XF_s7tbExRhYA2etsZz04=.102cf369-437b-4cfc-89ef-0a90eaaccdb5@github.com>
References: <ysUMbEypmBqaqHXRIipqu2XF_s7tbExRhYA2etsZz04=.102cf369-437b-4cfc-89ef-0a90eaaccdb5@github.com>
Message-ID: <Sv8ELbsv-28LsMbSd02B8gYzA5dvu-cOfpGl40SX_B8=.f3e3b593-e62f-4d08-a486-364314dcf0f3@github.com>

On Fri, 23 Sep 2022 11:03:52 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Since `ThreadDeath` would be deprecated soon, I assume it's fine to just remove it.
> 
> Thanks.
> Best regards,
> Jie

Thank you all for the review.

-------------

PR: https://git.openjdk.org/jdk/pull/10406

From jiefu at openjdk.org  Fri Sep 23 13:57:46 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Fri, 23 Sep 2022 13:57:46 GMT
Subject: Integrated: 8294271: Remove use of ThreadDeath from make utilities
In-Reply-To: <ysUMbEypmBqaqHXRIipqu2XF_s7tbExRhYA2etsZz04=.102cf369-437b-4cfc-89ef-0a90eaaccdb5@github.com>
References: <ysUMbEypmBqaqHXRIipqu2XF_s7tbExRhYA2etsZz04=.102cf369-437b-4cfc-89ef-0a90eaaccdb5@github.com>
Message-ID: <t8fkITn5TCUFOYhEYL7dySX8b48lR4f3X5uWthoL7us=.3f36d20f-cf96-4135-8cf5-75d1c792c358@github.com>

On Fri, 23 Sep 2022 11:03:52 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Since `ThreadDeath` would be deprecated soon, I assume it's fine to just remove it.
> 
> Thanks.
> Best regards,
> Jie

This pull request has now been integrated.

Changeset: 2e20e7ec
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2e20e7ec0fd1dbf96c88b7ef70e017506c28e14f
Stats:     3 lines in 1 file changed: 0 ins; 2 del; 1 mod

8294271: Remove use of ThreadDeath from make utilities

Reviewed-by: ihse, shade, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/10406

From alanb at openjdk.org  Fri Sep 23 13:57:56 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 23 Sep 2022 13:57:56 GMT
Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume [v2]
In-Reply-To: <l_lUEdZ-ORALa9ux2qu_PZZFm2IpIZs02kdC-tCQQBM=.e96f9fab-8d68-4ba1-b0f6-2b9b5c397226@github.com>
References: <l_lUEdZ-ORALa9ux2qu_PZZFm2IpIZs02kdC-tCQQBM=.e96f9fab-8d68-4ba1-b0f6-2b9b5c397226@github.com>
Message-ID: <YIEgjELWIYv07Pxr45KcQMW7H9ZlaMF1fcZ6b5UEmJs=.28703156-ff74-4450-9553-d6c24af04a32@github.com>

> Degrade Thread.suspend/resume to throw UOE unconditionally.
> 
> Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive.
> 
> The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs.
> 
> Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread).

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Update DegradedMethodsThrowUOE to test Thread.stop
 - Merge
 - Update modifyThread and modifyThreadGroup targets
 - Merge
 - Fix typo in test comment
 - Keep link to threadPrimitiveDeprecation.html
 - Merge
 - Tests
 - Initial commit

-------------

Changes: https://git.openjdk.org/jdk/pull/10324/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10324&range=01
  Stats: 466 lines in 17 files changed: 148 ins; 255 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/10324.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10324/head:pull/10324

PR: https://git.openjdk.org/jdk/pull/10324

From rriggs at openjdk.org  Fri Sep 23 15:41:05 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 23 Sep 2022 15:41:05 GMT
Subject: RFR: 8234262: Unmask SIGQUIT in a child process [v3]
In-Reply-To: <yP2ccgksQNP7jJkrLMYuxT3q9uNc-bMPxTofDlWhvKI=.d2e755ce-fa9b-484e-a788-113eef0aeecf@github.com>
References: <QhoJ88tNkPq3N9ybNwnEEHnpPPiFfwhVtXqMTtRGk1o=.ab0b8831-16a1-4802-8730-708da809349e@github.com>
 <w56hDjzb11ooJgZGHNnQaSuCtIrJi-igrgIhZOUyalY=.ea945f12-2df3-43a3-b825-047a52595dcb@github.com>
 <yP2ccgksQNP7jJkrLMYuxT3q9uNc-bMPxTofDlWhvKI=.d2e755ce-fa9b-484e-a788-113eef0aeecf@github.com>
Message-ID: <aKB37x3fmvlAdfv5UZgH3l0f-okRPRCFmBrDye9BIXE=.b6ff17d7-055b-4d34-96a9-9134f68289dc@github.com>

On Thu, 22 Sep 2022 23:13:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move clearing of the signal mask to jspawnhelper so the launched
>>   process gets a clear signal mask.
>
> src/java.base/unix/native/libjava/ProcessImpl_md.c line 776:
> 
>> 774:     goto Finally;
>> 775: }
>> 776: 
> 
> Unintended change?

IntelliJ removed a blank line at the end of the file.  I think it's ok to make permanent (in this PR).

-------------

PR: https://git.openjdk.org/jdk/pull/10379

From rriggs at openjdk.org  Fri Sep 23 15:48:05 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 23 Sep 2022 15:48:05 GMT
Subject: RFR: 8234262: Unmask SIGQUIT in a child process [v3]
In-Reply-To: <ne2uzUhcZcN0YKcBkvdPyhLAnbOjPJpgtQ-B0DVTC7M=.873a6910-96b4-41cf-ae80-eaa37ca5cbce@github.com>
References: <QhoJ88tNkPq3N9ybNwnEEHnpPPiFfwhVtXqMTtRGk1o=.ab0b8831-16a1-4802-8730-708da809349e@github.com>
 <w56hDjzb11ooJgZGHNnQaSuCtIrJi-igrgIhZOUyalY=.ea945f12-2df3-43a3-b825-047a52595dcb@github.com>
 <ne2uzUhcZcN0YKcBkvdPyhLAnbOjPJpgtQ-B0DVTC7M=.873a6910-96b4-41cf-ae80-eaa37ca5cbce@github.com>
Message-ID: <0xKQujs2wBHZgZeQe2_FQtnM4jkbYBF8eqgeKD3BB9U=.abd71c9b-52b8-4adf-8370-2b9816b0a309@github.com>

On Fri, 23 Sep 2022 03:25:49 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move clearing of the signal mask to jspawnhelper so the launched
>>   process gets a clear signal mask.
>
> test/jdk/java/lang/ProcessBuilder/UnblockSignals.java line 37:
> 
>> 35:     public static void main(String[] args)  throws IOException, InterruptedException {
>> 36:         // Check that SIGQUIT is not masked, in previous releases it was masked
>> 37:         final ProcessBuilder pb = new ProcessBuilder("sleep", "30").inheritIO();
> 
> SIGQUITing the child may leave a core dump. You may want to wrap the sleep in a shell call with ulimit to prevent that, e.g. 
> 
> `new ProcessBuilder("sh", "-c", "ulimit -c 0 && sleep 30");`

That doesn't work as intended; the `sh` is killed, not the sleep; and the core dump would be of `sh`.
The core dump of sleep will be small, I think it can be tolerated if it happens.

-------------

PR: https://git.openjdk.org/jdk/pull/10379

From mullan at openjdk.org  Fri Sep 23 17:42:23 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 23 Sep 2022 17:42:23 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v12]
In-Reply-To: <0wO5jFYhSTw702zqwi0_iLDgLcExZZZOuC5BQuCn4Z8=.4cab2b61-9156-4525-a787-a7dc75243ee2@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <0wO5jFYhSTw702zqwi0_iLDgLcExZZZOuC5BQuCn4Z8=.4cab2b61-9156-4525-a787-a7dc75243ee2@github.com>
Message-ID: <WonbnHQk5TGBKyMxvqFxU0RhfCCB6RQyVHXIvaiJ2XY=.5a23c4e4-691a-440a-805d-b166d5f11e0d@github.com>

On Tue, 20 Sep 2022 18:08:23 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
>> 
>> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
>> 
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added the verification note from JarFile

As a side comment, I notice that `JarInputStream` capitalizes "JAR", whereas `JarFile` does not ("jar"). We should really be consistent in our javadocs. I think "JAR" is more correct, mainly because that is what the Jar File specification uses. 

I am not suggesting you need to change `JarFile` though this as part of this PR. Mostly noting it for future reference.

-------------

PR: https://git.openjdk.org/jdk/pull/10045

From lancea at openjdk.org  Fri Sep 23 17:56:09 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 23 Sep 2022 17:56:09 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v12]
In-Reply-To: <WonbnHQk5TGBKyMxvqFxU0RhfCCB6RQyVHXIvaiJ2XY=.5a23c4e4-691a-440a-805d-b166d5f11e0d@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <0wO5jFYhSTw702zqwi0_iLDgLcExZZZOuC5BQuCn4Z8=.4cab2b61-9156-4525-a787-a7dc75243ee2@github.com>
 <WonbnHQk5TGBKyMxvqFxU0RhfCCB6RQyVHXIvaiJ2XY=.5a23c4e4-691a-440a-805d-b166d5f11e0d@github.com>
Message-ID: <Dze-3-lpP8WsOzOSOrcFmeTxCUgvF7MHedLpAgRaseU=.9929af01-0e38-4fd1-bf9e-95587dfaedc9@github.com>

On Fri, 23 Sep 2022 17:38:47 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> As a side comment, I notice that `JarInputStream` capitalizes "JAR", whereas `JarFile` does not ("jar"). We should really be consistent in our javadocs. I think "JAR" is more correct, mainly because that is what the Jar File specification uses.
> 
> I am not suggesting you need to change `JarFile` though this as part of this PR. Mostly noting it for future reference.

 I think you raise a fair point for a different set up updates.  there are places in the JAR File spec which also uses "jar file" vs "JAR file".  Similar conversation for "ZIP" vs "Zip" vs "zip".
 
 Too yes, lets agree on the preferred convention and update in one pass through java.util.jar.* and java.util.zip.* and the JAR file spec

-------------

PR: https://git.openjdk.org/jdk/pull/10045

From mullan at openjdk.org  Fri Sep 23 17:59:12 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 23 Sep 2022 17:59:12 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v12]
In-Reply-To: <0wO5jFYhSTw702zqwi0_iLDgLcExZZZOuC5BQuCn4Z8=.4cab2b61-9156-4525-a787-a7dc75243ee2@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <0wO5jFYhSTw702zqwi0_iLDgLcExZZZOuC5BQuCn4Z8=.4cab2b61-9156-4525-a787-a7dc75243ee2@github.com>
Message-ID: <bfiWxsz5ohoh3D5f1Sq4Pc1G48_tVhL0bQXLJfj0zEo=.180cd786-8b05-4a79-82fe-4a8ac786c806@github.com>

On Tue, 20 Sep 2022 18:08:23 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
>> 
>> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
>> 
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added the verification note from JarFile

Some minor comments. Consider it reviewed either way.

src/java.base/share/classes/java/util/jar/JarInputStream.java line 43:

> 41:  * <h2>Accessing the Manifest</h2>
> 42:  * <p>
> 43:  * The {@link #getManifest() getManifest} method is used to return the

I think this can be more simply said as "... method returns the ..."

src/java.base/share/classes/java/util/jar/JarInputStream.java line 47:

> 45:  * from the entry {@code META-INF/MANIFEST.MF} when it is the first entry
> 46:  * in the stream (or the second entry if the first entry in the stream is
> 47:  * {@code META-INF/} and the second entry is {@code META-INF/MANIFEST.MF}).

Do you also want to say "Otherwise, the method returns `null`."

src/java.base/share/classes/java/util/jar/JarInputStream.java line 50:

> 48:  * </p>
> 49:  * <p> The {@link #getNextJarEntry()} and {@link #getNextEntry()} methods are
> 50:  * used to read JAR file entries from the stream. These methods skip over the

Consider removing "are used to". Just say "... methods read ...".

-------------

Marked as reviewed by mullan (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10045

From cjplummer at openjdk.org  Fri Sep 23 18:31:23 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 23 Sep 2022 18:31:23 GMT
Subject: RFR: 8293592: Remove JVM_StopThread, stillborn,
 and related cleanup
In-Reply-To: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
References: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
Message-ID: <jPQnZdvskvzHDQZrF45DW8L9zsvSxiQKQHrODS2RAdk=.2fc75db3-f9d0-4bbb-8283-e387481cbc30@github.com>

On Fri, 23 Sep 2022 06:17:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610).
> 
> Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started.
> 
> Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same).
> 
> Testing: tiers 1-3

src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java line 102:

> 100:             try {
> 101:                 connector = connectors.next();
> 102:             } catch (Exception | Error x) {

Maybe this should just catch `Throwable`, although it is unclear to me why we would want to catch any exception here.

src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java line 126:

> 124:             try {
> 125:                 transportService = transportServices.next();
> 126:             } catch (Exception | Error x) {

Another that could be just catch `Throwable`

-------------

PR: https://git.openjdk.org/jdk/pull/10400

From cjplummer at openjdk.org  Fri Sep 23 18:39:19 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 23 Sep 2022 18:39:19 GMT
Subject: RFR: 8293613: need to properly handle and hide tmp VTMS
 transitions [v4]
In-Reply-To: <OyzEjJjgvDVNRlKMONSVBtpcnVBJ9QPHdV2LqfcuTSc=.3810b0d9-3ce3-47f6-9662-6a91514efa05@github.com>
References: <O_jzls_cv3HBC0NbzuYV2LXaW9VB2M18FroUfXWXd2w=.fa9d1f3c-40a2-42bd-a09b-dadd5032e513@github.com>
 <OyzEjJjgvDVNRlKMONSVBtpcnVBJ9QPHdV2LqfcuTSc=.3810b0d9-3ce3-47f6-9662-6a91514efa05@github.com>
Message-ID: <ytMlhBo3QYxpW4tLTGCF2vxfPhbmqR3auC9JHvUsJPA=.d28cd46c-8c14-457a-9878-9061dfdd9bb1@github.com>

On Thu, 22 Sep 2022 09:16:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update.
>> 
>> There are a couple of details of this fix to highlight:
>> -  A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`.
>> - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored.
>> - Suspending threads in temporary transition is allowed.
>> 
>> The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   1. addressed review comments from Chris; added VirtualThread.java update from Alan

src/hotspot/share/prims/jvmtiThreadState.cpp line 273:

> 271: 
> 272:     assert(!thread->is_in_tmp_VTMS_transition(), "sanity check");
> 273:     assert(!thread->is_in_VTMS_transition(), "VTMS_transition sanity check");

Why not cover both of these with `!thread->is_in_any_VTMS_transition()`?

-------------

PR: https://git.openjdk.org/jdk/pull/10321

From cjplummer at openjdk.org  Fri Sep 23 18:39:22 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 23 Sep 2022 18:39:22 GMT
Subject: RFR: 8293613: need to properly handle and hide tmp VTMS
 transitions [v4]
In-Reply-To: <Go_cGPWr-ZcCoaoqf-IDanhNNuUR6YlNOwJ4dtv-3no=.a3ac3bd1-cc36-456c-8b39-39c0cdbd5bc0@github.com>
References: <O_jzls_cv3HBC0NbzuYV2LXaW9VB2M18FroUfXWXd2w=.fa9d1f3c-40a2-42bd-a09b-dadd5032e513@github.com>
 <OyzEjJjgvDVNRlKMONSVBtpcnVBJ9QPHdV2LqfcuTSc=.3810b0d9-3ce3-47f6-9662-6a91514efa05@github.com>
 <AfgR97-WxKBpt0uuUTijy4rnpXY_XjVqXbJRSEdV0hw=.5e4c6cd6-de28-4fc1-ab1b-681be92a512b@github.com>
 <Go_cGPWr-ZcCoaoqf-IDanhNNuUR6YlNOwJ4dtv-3no=.a3ac3bd1-cc36-456c-8b39-39c0cdbd5bc0@github.com>
Message-ID: <RVtJAzYzvTAqngGBzbiurLBl_sPHCN0X7UaxxMWmIKo=.066cb8ab-24b5-4bc0-b94e-f14bae7fd57d@github.com>

On Fri, 23 Sep 2022 09:30:32 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/runtime/javaThread.hpp line 652:
>> 
>>> 650:   void set_is_in_VTMS_transition(bool val);
>>> 651:   void toggle_is_in_tmp_VTMS_transition()        { _is_in_tmp_VTMS_transition = !_is_in_tmp_VTMS_transition; };
>>> 652: 
>> 
>> My suggestion was to have the term "in VTMS transition" be inclusive of temp transitions. So based on your current names I would suggest:
>> 
>> - is_in_VTMS_transition -> is_in_non_tmp_VTMS_transition
>> - is_in_any_VTMS_transition -> is_in_VTMS_transition
>> 
>> But that becomes a problem for `set_is_in_VTMS_transition`, which would need to be renamed `set_is_in_non_tmp_VTMS_transition`, which I'm guessing you don't want to do. So let's instead just hope this all goes away before thinking about it any more.
>
> Thank you for sharing your suggestion.
> To be honest, I'm inclined to keep the two as simple as possible, independent end mutually exclusive.
> Temporary transitions have big difference comparing to normal transitions.
> They are allowed to be suspended and do not clash with VTMS disablers.
> Please, let me know if are okay with this.
> 
> Unfortunately, it seems, Alan got some difficulties in getting rid of temporary transitions.
> I'll double check on it just to be sure I understand it correctly.

ok

-------------

PR: https://git.openjdk.org/jdk/pull/10321

From sspitsyn at openjdk.org  Fri Sep 23 20:42:03 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 23 Sep 2022 20:42:03 GMT
Subject: RFR: 8293613: need to properly handle and hide tmp VTMS
 transitions [v4]
In-Reply-To: <ytMlhBo3QYxpW4tLTGCF2vxfPhbmqR3auC9JHvUsJPA=.d28cd46c-8c14-457a-9878-9061dfdd9bb1@github.com>
References: <O_jzls_cv3HBC0NbzuYV2LXaW9VB2M18FroUfXWXd2w=.fa9d1f3c-40a2-42bd-a09b-dadd5032e513@github.com>
 <OyzEjJjgvDVNRlKMONSVBtpcnVBJ9QPHdV2LqfcuTSc=.3810b0d9-3ce3-47f6-9662-6a91514efa05@github.com>
 <ytMlhBo3QYxpW4tLTGCF2vxfPhbmqR3auC9JHvUsJPA=.d28cd46c-8c14-457a-9878-9061dfdd9bb1@github.com>
Message-ID: <8XO95Zy9ZwaIiWxspJhRLwP9JdLM8sVpTyIoF3JKYOY=.a0320f59-6e1e-4c9d-ad2c-5b2b8b792529@github.com>

On Fri, 23 Sep 2022 18:32:57 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   1. addressed review comments from Chris; added VirtualThread.java update from Alan
>
> src/hotspot/share/prims/jvmtiThreadState.cpp line 273:
> 
>> 271: 
>> 272:     assert(!thread->is_in_tmp_VTMS_transition(), "sanity check");
>> 273:     assert(!thread->is_in_VTMS_transition(), "VTMS_transition sanity check");
> 
> Why not cover both of these with `!thread->is_in_any_VTMS_transition()`?

It is to be clear what condition caused the assert as they are different beasts.

-------------

PR: https://git.openjdk.org/jdk/pull/10321

From asemenyuk at openjdk.org  Fri Sep 23 20:43:48 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 23 Sep 2022 20:43:48 GMT
Subject: RFR: 8293462: [macos] app image signature invalid when creating
 DMG or PKG from post processed signed image [v2]
In-Reply-To: <rx7LwNB89Ka3Y8cEOnCaQ4-XvsJhJEfPcpigwprrLUY=.9eccee19-4fde-49f1-bcec-a7c0bddbbeab@github.com>
References: <-sMR9P3CEZeJ31UFe7bzIcnC86rSErUVbY0GOymUoo4=.7c954bca-25c7-4fa0-9e2a-076ce2a485d4@github.com>
 <rx7LwNB89Ka3Y8cEOnCaQ4-XvsJhJEfPcpigwprrLUY=.9eccee19-4fde-49f1-bcec-a7c0bddbbeab@github.com>
Message-ID: <3jNbc05RxRv96WDc9Dv_k9IN-BH0S5wNT_ND2gYC6UQ=.9f59df22-3dd1-42ab-a7ea-7d7eedd42776@github.com>

On Tue, 20 Sep 2022 04:05:56 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Problem is that [JDK-8286850](https://bugs.openjdk.org/browse/JDK-8286850) never set correct value in .jpackage.xml to mark image as signed. [JDK-8289030](https://bugs.openjdk.org/browse/JDK-8289030) reads this value to check if we can add per-user and system wide configuration to packaged app. Fixed by setting correct value in .jpackage.xml when we signing predefine application image.
>> 
>> Added tests to cover this case and added check for values inside .jpackage.xml to validate signed and Mac App Store values.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293462: [macos] app image signature invalid when creating DMG or PKG from post processed signed image [v2]

src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageBuilder.java line 286:

> 284:                 if (appImageFile != null) {
> 285:                     appImageFile.save(predefinedAppImage);
> 286:                 }

Wouldn't it make sense to rethrow caught exception after the file is restored?

-------------

PR: https://git.openjdk.org/jdk/pull/10316

From sspitsyn at openjdk.org  Fri Sep 23 20:48:02 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 23 Sep 2022 20:48:02 GMT
Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume [v2]
In-Reply-To: <YIEgjELWIYv07Pxr45KcQMW7H9ZlaMF1fcZ6b5UEmJs=.28703156-ff74-4450-9553-d6c24af04a32@github.com>
References: <l_lUEdZ-ORALa9ux2qu_PZZFm2IpIZs02kdC-tCQQBM=.e96f9fab-8d68-4ba1-b0f6-2b9b5c397226@github.com>
 <YIEgjELWIYv07Pxr45KcQMW7H9ZlaMF1fcZ6b5UEmJs=.28703156-ff74-4450-9553-d6c24af04a32@github.com>
Message-ID: <wChqwgjuGNJoWqNE7DcYXoJMmTnYxHmquwwb9khR1O0=.4ea7aa25-80ab-4a05-b3b2-19fd5e7ce817@github.com>

On Fri, 23 Sep 2022 13:57:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Degrade Thread.suspend/resume to throw UOE unconditionally.
>> 
>> Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive.
>> 
>> The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs.
>> 
>> Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread).
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Update DegradedMethodsThrowUOE to test Thread.stop
>  - Merge
>  - Update modifyThread and modifyThreadGroup targets
>  - Merge
>  - Fix typo in test comment
>  - Keep link to threadPrimitiveDeprecation.html
>  - Merge
>  - Tests
>  - Initial commit

Marked as reviewed by sspitsyn (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10324

From asemenyuk at openjdk.org  Fri Sep 23 20:54:17 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 23 Sep 2022 20:54:17 GMT
Subject: RFR: 8293462: [macos] app image signature invalid when creating
 DMG or PKG from post processed signed image [v2]
In-Reply-To: <rx7LwNB89Ka3Y8cEOnCaQ4-XvsJhJEfPcpigwprrLUY=.9eccee19-4fde-49f1-bcec-a7c0bddbbeab@github.com>
References: <-sMR9P3CEZeJ31UFe7bzIcnC86rSErUVbY0GOymUoo4=.7c954bca-25c7-4fa0-9e2a-076ce2a485d4@github.com>
 <rx7LwNB89Ka3Y8cEOnCaQ4-XvsJhJEfPcpigwprrLUY=.9eccee19-4fde-49f1-bcec-a7c0bddbbeab@github.com>
Message-ID: <kwX9up8ZVT-4TxtDbmI2YalvA_E6PO4Li4pHevCv2Ug=.4e6e2a22-4a86-4873-9d8b-f46d64b703c8@github.com>

On Tue, 20 Sep 2022 04:05:56 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Problem is that [JDK-8286850](https://bugs.openjdk.org/browse/JDK-8286850) never set correct value in .jpackage.xml to mark image as signed. [JDK-8289030](https://bugs.openjdk.org/browse/JDK-8289030) reads this value to check if we can add per-user and system wide configuration to packaged app. Fixed by setting correct value in .jpackage.xml when we signing predefine application image.
>> 
>> Added tests to cover this case and added check for values inside .jpackage.xml to validate signed and Mac App Store values.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293462: [macos] app image signature invalid when creating DMG or PKG from post processed signed image [v2]

Changes requested by asemenyuk (Reviewer).

src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageFile.java line 64:

> 62: 
> 63:     // These values will be loaded from AppImage xml file.
> 64:     private final Path appImageDir;

What this field is for? This property doesn't belong to the class.

-------------

PR: https://git.openjdk.org/jdk/pull/10316

From cjplummer at openjdk.org  Fri Sep 23 21:00:47 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 23 Sep 2022 21:00:47 GMT
Subject: RFR: 8293613: need to properly handle and hide tmp VTMS
 transitions [v4]
In-Reply-To: <OyzEjJjgvDVNRlKMONSVBtpcnVBJ9QPHdV2LqfcuTSc=.3810b0d9-3ce3-47f6-9662-6a91514efa05@github.com>
References: <O_jzls_cv3HBC0NbzuYV2LXaW9VB2M18FroUfXWXd2w=.fa9d1f3c-40a2-42bd-a09b-dadd5032e513@github.com>
 <OyzEjJjgvDVNRlKMONSVBtpcnVBJ9QPHdV2LqfcuTSc=.3810b0d9-3ce3-47f6-9662-6a91514efa05@github.com>
Message-ID: <VoRh6mXZl0mUtWgQanLHZ-hze6b9D5G5pr4CeIKc26Q=.c0809dd6-fd3c-43e3-865d-14f008f8e76d@github.com>

On Thu, 22 Sep 2022 09:16:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update.
>> 
>> There are a couple of details of this fix to highlight:
>> -  A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`.
>> - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored.
>> - Suspending threads in temporary transition is allowed.
>> 
>> The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   1. addressed review comments from Chris; added VirtualThread.java update from Alan

Marked as reviewed by cjplummer (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10321

From cjplummer at openjdk.org  Fri Sep 23 21:00:47 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 23 Sep 2022 21:00:47 GMT
Subject: RFR: 8293613: need to properly handle and hide tmp VTMS
 transitions [v4]
In-Reply-To: <8XO95Zy9ZwaIiWxspJhRLwP9JdLM8sVpTyIoF3JKYOY=.a0320f59-6e1e-4c9d-ad2c-5b2b8b792529@github.com>
References: <O_jzls_cv3HBC0NbzuYV2LXaW9VB2M18FroUfXWXd2w=.fa9d1f3c-40a2-42bd-a09b-dadd5032e513@github.com>
 <OyzEjJjgvDVNRlKMONSVBtpcnVBJ9QPHdV2LqfcuTSc=.3810b0d9-3ce3-47f6-9662-6a91514efa05@github.com>
 <ytMlhBo3QYxpW4tLTGCF2vxfPhbmqR3auC9JHvUsJPA=.d28cd46c-8c14-457a-9878-9061dfdd9bb1@github.com>
 <8XO95Zy9ZwaIiWxspJhRLwP9JdLM8sVpTyIoF3JKYOY=.a0320f59-6e1e-4c9d-ad2c-5b2b8b792529@github.com>
Message-ID: <K8Xrw6IHHVhPeQ8HqLqW1WO_F0uWJioTViDI_L46leQ=.57dcd983-46dd-4d55-b045-446fb5aa7e05@github.com>

On Fri, 23 Sep 2022 20:38:17 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiThreadState.cpp line 273:
>> 
>>> 271: 
>>> 272:     assert(!thread->is_in_tmp_VTMS_transition(), "sanity check");
>>> 273:     assert(!thread->is_in_VTMS_transition(), "VTMS_transition sanity check");
>> 
>> Why not cover both of these with `!thread->is_in_any_VTMS_transition()`?
>
> It is to be clear what condition caused the assert as they are different beasts.

ok

-------------

PR: https://git.openjdk.org/jdk/pull/10321

From dholmes at openjdk.org  Fri Sep 23 21:47:06 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 23 Sep 2022 21:47:06 GMT
Subject: RFR: 8293592: Remove JVM_StopThread, stillborn,
 and related cleanup [v2]
In-Reply-To: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
References: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
Message-ID: <BlMK7IMjTgIiiwSkkF_1-qLlM1AqaKAhLP55-Z1-eeI=.2383991e-22d3-4c0c-afab-353985e1f8fc@github.com>

> Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610).
> 
> Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started.
> 
> Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same).
> 
> Testing: tiers 1-3

David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge branch 'master' into 8293592-JVM_StopThread
 - Removal all special handling of ThreadDeath.
 - Remove all references to the stillborn field
 - Initial commit: remove JVM_StopThread
 - Merge
 - Updates to Java Thread Primitive Deprecation page
 - Repalce "it" with "victim thread"
 - Merge
 - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop
 - become -> became in javadoc
 - ... and 6 more: https://git.openjdk.org/jdk/compare/3675f4c2...4eb07903

-------------

Changes: https://git.openjdk.org/jdk/pull/10400/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10400&range=01
  Stats: 208 lines in 18 files changed: 19 ins; 146 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/10400.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10400/head:pull/10400

PR: https://git.openjdk.org/jdk/pull/10400

From dholmes at openjdk.org  Fri Sep 23 21:47:08 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 23 Sep 2022 21:47:08 GMT
Subject: RFR: 8293592: Remove JVM_StopThread, stillborn,
 and related cleanup
In-Reply-To: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
References: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
Message-ID: <pe2S9eAR6fAkhNMkE7zsvJjErBsmkHbm5PrW6Sm8jE4=.1c30dc46-dafb-4b16-be3f-73e27fc8e5fd@github.com>

On Fri, 23 Sep 2022 06:17:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610).
> 
> Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started.
> 
> Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same).
> 
> Testing: tiers 1-3

This PR is now back to its proper form after merging the upstream changes.  I can't say I like the "dependent PR" feature.

-------------

PR: https://git.openjdk.org/jdk/pull/10400

From dholmes at openjdk.org  Fri Sep 23 21:47:10 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 23 Sep 2022 21:47:10 GMT
Subject: RFR: 8293592: Remove JVM_StopThread, stillborn,
 and related cleanup [v2]
In-Reply-To: <jPQnZdvskvzHDQZrF45DW8L9zsvSxiQKQHrODS2RAdk=.2fc75db3-f9d0-4bbb-8283-e387481cbc30@github.com>
References: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
 <jPQnZdvskvzHDQZrF45DW8L9zsvSxiQKQHrODS2RAdk=.2fc75db3-f9d0-4bbb-8283-e387481cbc30@github.com>
Message-ID: <WlSewOOWwaXOlFuSI6NrOYXMvwwp1xvfYxpLZF4xAPE=.9efe45f9-a6df-4bd5-bece-7e349b092a9c@github.com>

On Fri, 23 Sep 2022 18:21:30 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
>> 
>>  - Merge branch 'master' into 8293592-JVM_StopThread
>>  - Removal all special handling of ThreadDeath.
>>  - Remove all references to the stillborn field
>>  - Initial commit: remove JVM_StopThread
>>  - Merge
>>  - Updates to Java Thread Primitive Deprecation page
>>  - Repalce "it" with "victim thread"
>>  - Merge
>>  - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop
>>  - become -> became in javadoc
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/3675f4c2...4eb07903
>
> src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java line 102:
> 
>> 100:             try {
>> 101:                 connector = connectors.next();
>> 102:             } catch (Exception | Error x) {
> 
> Maybe this should just catch `Throwable`, although it is unclear to me why we would want to catch any exception here.

@plummercj  these changes are not actually part of this PR but came from the upstream PR this was dependent on.

> src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java line 126:
> 
>> 124:             try {
>> 125:                 transportService = transportServices.next();
>> 126:             } catch (Exception | Error x) {
> 
> Another that could be just catch `Throwable`

@plummercj  these changes are not actually part of this PR but came from the upstream PR this was dependent on.

-------------

PR: https://git.openjdk.org/jdk/pull/10400

From naoto at openjdk.org  Fri Sep 23 22:40:54 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 23 Sep 2022 22:40:54 GMT
Subject: RFR: 8294317: Insufficient build rules for tzdb.dat
Message-ID: <WS7j8PLGWmQXKydFbhYDSic55ECn9p40NdRIcS7TRHs=.43ced95c-1843-4d3b-9cb1-d526618e0678@github.com>

The current makefile for `tzdb.dat` won't recompile if some dependent files (e.g. `VERSION`) are updated. Adding all files under the tzdb directory to the dependency will fix this issue.

-------------

Commit messages:
 - 8294317: Insufficient build rules for tzdb.dat

Changes: https://git.openjdk.org/jdk/pull/10415/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10415&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294317
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10415.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10415/head:pull/10415

PR: https://git.openjdk.org/jdk/pull/10415

From joehw at openjdk.org  Sat Sep 24 03:46:09 2022
From: joehw at openjdk.org (Joe Wang)
Date: Sat, 24 Sep 2022 03:46:09 GMT
Subject: RFR: 8294317: Insufficient build rules for tzdb.dat
In-Reply-To: <WS7j8PLGWmQXKydFbhYDSic55ECn9p40NdRIcS7TRHs=.43ced95c-1843-4d3b-9cb1-d526618e0678@github.com>
References: <WS7j8PLGWmQXKydFbhYDSic55ECn9p40NdRIcS7TRHs=.43ced95c-1843-4d3b-9cb1-d526618e0678@github.com>
Message-ID: <q89hIwht4-uwggr0bQG3lFh2PMZ5GTD0eJt6yRgOh08=.bc6b3d66-c917-4100-a8bc-9b693e4e48a0@github.com>

On Fri, 23 Sep 2022 22:10:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The current makefile for `tzdb.dat` won't recompile if some dependent files (e.g. `VERSION`) are updated. Adding all files under the tzdb directory to the dependency will fix this issue.

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10415

From vtewari at openjdk.org  Sat Sep 24 05:42:21 2022
From: vtewari at openjdk.org (Vyom Tewari)
Date: Sat, 24 Sep 2022 05:42:21 GMT
Subject: RFR: 8234262: Unmask SIGQUIT in a child process [v3]
In-Reply-To: <w56hDjzb11ooJgZGHNnQaSuCtIrJi-igrgIhZOUyalY=.ea945f12-2df3-43a3-b825-047a52595dcb@github.com>
References: <QhoJ88tNkPq3N9ybNwnEEHnpPPiFfwhVtXqMTtRGk1o=.ab0b8831-16a1-4802-8730-708da809349e@github.com>
 <w56hDjzb11ooJgZGHNnQaSuCtIrJi-igrgIhZOUyalY=.ea945f12-2df3-43a3-b825-047a52595dcb@github.com>
Message-ID: <5Ozt2uZx733VMz7k7SxY0sc1OR7E0D3LdjSassd--e4=.952bad61-6859-4e91-9eb9-7d7283cad1ed@github.com>

On Thu, 22 Sep 2022 22:41:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Clear the signal mask of the child when launching with posix_spawn.
>> 
>> SIGQUIT signals are handled on non-Java Threads by the VM.
>> For Java threads the signal mask blocks SIGQUIT.  
>> The ProcessBuilder uses posix_spawn on all platforms to create new processes.
>> Without a specific request, the child process inherits the signal masks from the parent.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move clearing of the signal mask to jspawnhelper so the launched
>   process gets a clear signal mask.

Looks OK to me.

test/jdk/java/lang/ProcessBuilder/UnblockSignals.java line 23:

> 21:  * questions.
> 22:  */
> 23: import java.lang.Process;

Do we explicitly need to import java.long.Process ?

-------------

Marked as reviewed by vtewari (Committer).

PR: https://git.openjdk.org/jdk/pull/10379

From stuefe at openjdk.org  Sat Sep 24 05:47:15 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 24 Sep 2022 05:47:15 GMT
Subject: RFR: 8234262: Unmask SIGQUIT in a child process [v3]
In-Reply-To: <w56hDjzb11ooJgZGHNnQaSuCtIrJi-igrgIhZOUyalY=.ea945f12-2df3-43a3-b825-047a52595dcb@github.com>
References: <QhoJ88tNkPq3N9ybNwnEEHnpPPiFfwhVtXqMTtRGk1o=.ab0b8831-16a1-4802-8730-708da809349e@github.com>
 <w56hDjzb11ooJgZGHNnQaSuCtIrJi-igrgIhZOUyalY=.ea945f12-2df3-43a3-b825-047a52595dcb@github.com>
Message-ID: <Y1c-R9DPEv9waiSisDwKlLBaqMy5T4xoKvdZXZWCZFQ=.9fb7e566-8fc4-4d26-bd08-2449a893819e@github.com>

On Thu, 22 Sep 2022 22:41:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Clear the signal mask of the child when launching with posix_spawn.
>> 
>> SIGQUIT signals are handled on non-Java Threads by the VM.
>> For Java threads the signal mask blocks SIGQUIT.  
>> The ProcessBuilder uses posix_spawn on all platforms to create new processes.
>> Without a specific request, the child process inherits the signal masks from the parent.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move clearing of the signal mask to jspawnhelper so the launched
>   process gets a clear signal mask.

+1

-------------

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10379

From alanb at openjdk.org  Sat Sep 24 06:43:17 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 24 Sep 2022 06:43:17 GMT
Subject: RFR: 8293592: Remove JVM_StopThread, stillborn,
 and related cleanup [v2]
In-Reply-To: <BlMK7IMjTgIiiwSkkF_1-qLlM1AqaKAhLP55-Z1-eeI=.2383991e-22d3-4c0c-afab-353985e1f8fc@github.com>
References: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
 <BlMK7IMjTgIiiwSkkF_1-qLlM1AqaKAhLP55-Z1-eeI=.2383991e-22d3-4c0c-afab-353985e1f8fc@github.com>
Message-ID: <PIoXRsp3LB9FHrn4fPmk8y2c_S8rtxGNZCS4VScJk9o=.0e5d13e4-19b8-46b3-8f84-649ae112a8f8@github.com>

On Fri, 23 Sep 2022 21:47:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610).
>> 
>> Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started.
>> 
>> Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same).
>> 
>> Testing: tiers 1-3
>
> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Merge branch 'master' into 8293592-JVM_StopThread
>  - Removal all special handling of ThreadDeath.
>  - Remove all references to the stillborn field
>  - Initial commit: remove JVM_StopThread
>  - Merge
>  - Updates to Java Thread Primitive Deprecation page
>  - Repalce "it" with "victim thread"
>  - Merge
>  - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop
>  - become -> became in javadoc
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/3675f4c2...4eb07903

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10400

From alanb at openjdk.org  Sat Sep 24 06:43:18 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 24 Sep 2022 06:43:18 GMT
Subject: RFR: 8293592: Remove JVM_StopThread, stillborn,
 and related cleanup [v2]
In-Reply-To: <WlSewOOWwaXOlFuSI6NrOYXMvwwp1xvfYxpLZF4xAPE=.9efe45f9-a6df-4bd5-bece-7e349b092a9c@github.com>
References: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
 <jPQnZdvskvzHDQZrF45DW8L9zsvSxiQKQHrODS2RAdk=.2fc75db3-f9d0-4bbb-8283-e387481cbc30@github.com>
 <WlSewOOWwaXOlFuSI6NrOYXMvwwp1xvfYxpLZF4xAPE=.9efe45f9-a6df-4bd5-bece-7e349b092a9c@github.com>
Message-ID: <-8imvtLKzzu_1t6YJsZYkxNbQ5JD1PaXXzK2O0nWc-s=.7c3843ad-c959-4a14-86c8-7b9722c3eb05@github.com>

On Fri, 23 Sep 2022 21:42:08 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java line 126:
>> 
>>> 124:             try {
>>> 125:                 transportService = transportServices.next();
>>> 126:             } catch (Exception | Error x) {
>> 
>> Another that could be just catch `Throwable`
>
> @plummercj  these changes are not actually part of this PR but came from the upstream PR this was dependent on.

I think this dates from JDK 5 when pluggable JDI connectors and transports were aded. VirtualMachineManager does specify that it tolerates configuration and deployment issues with:

"At start-up time the VirtualMachineManager attempts to load and instantiate (using the no-arg constructor) each class listed in the provider configuration file. Exceptions thrown when loading or creating the Connector are caught and ignored. In other words, the start-up process continues despite of errors."

Looking at it now, I think it should be catching ServiceConfigurationError as that is what the SL's iterator hasNext/next will throw if locating, loading or instantiating a Connector fails. This seems something for an another issue of course, just strange that the Skara bots included it.

-------------

PR: https://git.openjdk.org/jdk/pull/10400

From alanb at openjdk.org  Sat Sep 24 06:50:45 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 24 Sep 2022 06:50:45 GMT
Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume [v3]
In-Reply-To: <l_lUEdZ-ORALa9ux2qu_PZZFm2IpIZs02kdC-tCQQBM=.e96f9fab-8d68-4ba1-b0f6-2b9b5c397226@github.com>
References: <l_lUEdZ-ORALa9ux2qu_PZZFm2IpIZs02kdC-tCQQBM=.e96f9fab-8d68-4ba1-b0f6-2b9b5c397226@github.com>
Message-ID: <qCI92xJUfPZdfdgharNxiBnT2fv89IrS-02K4zJhQaA=.0d29302a-9603-490e-a28e-30861631c1ba@github.com>

> Degrade Thread.suspend/resume to throw UOE unconditionally.
> 
> Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive.
> 
> The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs.
> 
> Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread).

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Remove tests from exclude list
 - Merge
 - Update DegradedMethodsThrowUOE to test Thread.stop
 - Merge
 - Update modifyThread and modifyThreadGroup targets
 - Merge
 - Fix typo in test comment
 - Keep link to threadPrimitiveDeprecation.html
 - Merge
 - Tests
 - ... and 1 more: https://git.openjdk.org/jdk/compare/543851db...6aa38889

-------------

Changes: https://git.openjdk.org/jdk/pull/10324/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10324&range=02
  Stats: 454 lines in 16 files changed: 136 ins; 255 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/10324.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10324/head:pull/10324

PR: https://git.openjdk.org/jdk/pull/10324

From alanb at openjdk.org  Sat Sep 24 06:50:46 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 24 Sep 2022 06:50:46 GMT
Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume [v2]
In-Reply-To: <YIEgjELWIYv07Pxr45KcQMW7H9ZlaMF1fcZ6b5UEmJs=.28703156-ff74-4450-9553-d6c24af04a32@github.com>
References: <l_lUEdZ-ORALa9ux2qu_PZZFm2IpIZs02kdC-tCQQBM=.e96f9fab-8d68-4ba1-b0f6-2b9b5c397226@github.com>
 <YIEgjELWIYv07Pxr45KcQMW7H9ZlaMF1fcZ6b5UEmJs=.28703156-ff74-4450-9553-d6c24af04a32@github.com>
Message-ID: <bNiVR6zIfFSuHxBkDbVlO4zQAkONVWzaIRICRArQo3o=.54780317-af63-4d30-9b96-22ad97e644e6@github.com>

On Fri, 23 Sep 2022 13:57:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Degrade Thread.suspend/resume to throw UOE unconditionally.
>> 
>> Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive.
>> 
>> The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs.
>> 
>> Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread).
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Update DegradedMethodsThrowUOE to test Thread.stop
>  - Merge
>  - Update modifyThread and modifyThreadGroup targets
>  - Merge
>  - Fix typo in test comment
>  - Keep link to threadPrimitiveDeprecation.html
>  - Merge
>  - Tests
>  - Initial commit

Leonid has integrated JDK-8289607 to remove the last usages of Thread.suspend/resume from the hotspot tests so I've refreshed this PR to drop the temporary excluding of these tests.

-------------

PR: https://git.openjdk.org/jdk/pull/10324

From alanb at openjdk.org  Sat Sep 24 06:59:08 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 24 Sep 2022 06:59:08 GMT
Subject: RFR: 8234262: Unmask SIGQUIT in a child process [v3]
In-Reply-To: <w56hDjzb11ooJgZGHNnQaSuCtIrJi-igrgIhZOUyalY=.ea945f12-2df3-43a3-b825-047a52595dcb@github.com>
References: <QhoJ88tNkPq3N9ybNwnEEHnpPPiFfwhVtXqMTtRGk1o=.ab0b8831-16a1-4802-8730-708da809349e@github.com>
 <w56hDjzb11ooJgZGHNnQaSuCtIrJi-igrgIhZOUyalY=.ea945f12-2df3-43a3-b825-047a52595dcb@github.com>
Message-ID: <OIVw0KhbvwTLLNx23L9O9rKXX7P8p1OoVQ5WZ8wFSDs=.0d887f34-7300-4128-b202-b3052b020cc4@github.com>

On Thu, 22 Sep 2022 22:41:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Clear the signal mask of the child when launching with posix_spawn.
>> 
>> SIGQUIT signals are handled on non-Java Threads by the VM.
>> For Java threads the signal mask blocks SIGQUIT.  
>> The ProcessBuilder uses posix_spawn on all platforms to create new processes.
>> Without a specific request, the child process inherits the signal masks from the parent.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move clearing of the signal mask to jspawnhelper so the launched
>   process gets a clear signal mask.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10379

From sspitsyn at openjdk.org  Sat Sep 24 08:45:17 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 24 Sep 2022 08:45:17 GMT
Subject: RFR: 8293613: need to properly handle and hide tmp VTMS
 transitions [v4]
In-Reply-To: <OyzEjJjgvDVNRlKMONSVBtpcnVBJ9QPHdV2LqfcuTSc=.3810b0d9-3ce3-47f6-9662-6a91514efa05@github.com>
References: <O_jzls_cv3HBC0NbzuYV2LXaW9VB2M18FroUfXWXd2w=.fa9d1f3c-40a2-42bd-a09b-dadd5032e513@github.com>
 <OyzEjJjgvDVNRlKMONSVBtpcnVBJ9QPHdV2LqfcuTSc=.3810b0d9-3ce3-47f6-9662-6a91514efa05@github.com>
Message-ID: <bh3eIGJ0Uy61MfEV5f7xBiNrs8ZVy-fyfEk7NfeBcBs=.59b8d3f6-a341-4d37-adaa-5e408b29b085@github.com>

On Thu, 22 Sep 2022 09:16:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update.
>> 
>> There are a couple of details of this fix to highlight:
>> -  A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`.
>> - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored.
>> - Suspending threads in temporary transition is allowed.
>> 
>> The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   1. addressed review comments from Chris; added VirtualThread.java update from Alan

Thank you for review, Chris!

-------------

PR: https://git.openjdk.org/jdk/pull/10321

From jwaters at openjdk.org  Sun Sep 25 00:36:26 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 25 Sep 2022 00:36:26 GMT
Subject: RFR: 8291917: Windows - Improve error messages when the C Runtime
 Libraries or jvm.dll cannot be loaded [v5]
In-Reply-To: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
References: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
Message-ID: <bfO9aHPbIM_GvDOjTRkzZqxz2DYuFWgAbCuTPortlD8=.2a85c94d-192d-443f-9f8a-4c594b5d8669@github.com>

> Please review a small patch for dumping the failure reason when the MSVCRT libraries or the Java Virtual Machine fails to load on Windows, which can provide invaluable insight when debugging related launcher issues.

Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge branch 'openjdk:master' into patch-4
 - Back out change to DLL_ERROR4 for separate RFE
 - Missing spacing between errors
 - Introduce warning when system error cannot be determined
 - LoadLibrary checks should explicitly use NULL
 - Dump error (if any) when libraries fail to load
 - Prettify DLL_ERROR4

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9749/files
  - new: https://git.openjdk.org/jdk/pull/9749/files/990ee4fd..284ac2f4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9749&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9749&range=03-04

  Stats: 164674 lines in 2718 files changed: 78252 ins; 68762 del; 17660 mod
  Patch: https://git.openjdk.org/jdk/pull/9749.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9749/head:pull/9749

PR: https://git.openjdk.org/jdk/pull/9749

From duke at openjdk.org  Sun Sep 25 00:39:33 2022
From: duke at openjdk.org (Markus KARG)
Date: Sun, 25 Sep 2022 00:39:33 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo
 [v12]
In-Reply-To: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
Message-ID: <YrHWGaUCyTHHs-BnH7NR8LFTyM32euk89HzxZT3zXZM=.28bf954a-7d61-4526-824d-928a0cf273fa@github.com>

> Implementation of JDK-8279283

Markus KARG has updated the pull request incrementally with three additional commits since the last revision:

 - transformTo -> transferTo
 - wrapped long code lines
 - removed unused import

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/6935/files
  - new: https://git.openjdk.org/jdk/pull/6935/files/a4b6f913..c30ea5d2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=6935&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=6935&range=10-11

  Stats: 38 lines in 1 file changed: 18 ins; 1 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/6935.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/6935/head:pull/6935

PR: https://git.openjdk.org/jdk/pull/6935

From duke at openjdk.org  Sun Sep 25 00:39:33 2022
From: duke at openjdk.org (Markus KARG)
Date: Sun, 25 Sep 2022 00:39:33 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo
 [v11]
In-Reply-To: <_la5Co3yx5ik1wt7Y6Bi7MDC3MCVUxIKxz_iQQp2TT8=.1023ef6d-266f-45f5-aa93-7218d0d89c10@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <_la5Co3yx5ik1wt7Y6Bi7MDC3MCVUxIKxz_iQQp2TT8=.1023ef6d-266f-45f5-aa93-7218d0d89c10@github.com>
Message-ID: <VNT4kts7ahX1UIRRohyp7x9RSxrF0zslIE90yfJYYF0=.27ebea5e-1d31-4235-b3fa-0e2a2eb4d702@github.com>

On Fri, 9 Sep 2022 12:19:54 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Implementation of JDK-8279283
>
> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - corrected copyright
>  - testing transferTo() after reset()

@bplb Fixed the issues you pointed out. Kindly requesting approval. :-)

-------------

PR: https://git.openjdk.org/jdk/pull/6935

From duke at openjdk.org  Sun Sep 25 00:39:34 2022
From: duke at openjdk.org (Markus KARG)
Date: Sun, 25 Sep 2022 00:39:34 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo
 [v11]
In-Reply-To: <czGSczxgHiOwVNNB1hdYQnO55orNICm9TvSN-kl7YKw=.3e51b917-0db4-46f5-b950-48e1fb1e439a@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <_la5Co3yx5ik1wt7Y6Bi7MDC3MCVUxIKxz_iQQp2TT8=.1023ef6d-266f-45f5-aa93-7218d0d89c10@github.com>
 <czGSczxgHiOwVNNB1hdYQnO55orNICm9TvSN-kl7YKw=.3e51b917-0db4-46f5-b950-48e1fb1e439a@github.com>
Message-ID: <Cwo7q2keuzzrIRYfgP-3C5lA0aAiO-opHEeSZEfhSnA=.fe9c4e81-bad0-4719-8e90-b54dc98f6489@github.com>

On Thu, 22 Sep 2022 22:14:02 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - corrected copyright
>>  - testing transferTo() after reset()
>
> test/jdk/java/io/BufferedInputStream/TransferTo.java line 40:
> 
>> 38: import java.nio.file.Files;
>> 39: import java.nio.file.Path;
>> 40: import java.nio.file.StandardOpenOption;
> 
> This import of `StandardOpenOption` is not needed due to line 55.

Done :-)

> test/jdk/java/io/BufferedInputStream/TransferTo.java line 89:
> 
>> 87: 
>> 88:         // tests empty input stream
>> 89:         assertThrows(NullPointerException.class, () -> inputStreamProvider.input().transferTo(null));
> 
> A number of code lines in the test are too long and make it even harder to read.

Done :-)

> test/jdk/java/io/BufferedInputStream/TransferTo.java line 162:
> 
>> 160:             out.write(new byte[posOut]);
>> 161: 
>> 162:             // fill buffer by reading some bytes before transformTo
> 
> transformTo -> transferTo

Done :-)

-------------

PR: https://git.openjdk.org/jdk/pull/6935

From alanb at openjdk.org  Sun Sep 25 06:34:37 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 25 Sep 2022 06:34:37 GMT
Subject: RFR: 8293977: jdk/modules/etc/VerifyModuleDelegation.java fail
 with jfx
In-Reply-To: <K8keV23DhjOl2iAcpxEGUPEDKfRsrPMwVYf6ZvYV39M=.66a73163-007e-4951-a524-7cf8d5aa1f79@github.com>
References: <K8keV23DhjOl2iAcpxEGUPEDKfRsrPMwVYf6ZvYV39M=.66a73163-007e-4951-a524-7cf8d5aa1f79@github.com>
Message-ID: <ktvjNSp474FELm18d1A46AUdmt0h_tAowbm3jRJdcRI=.85c515a4-c1a1-4828-b807-ca2489983114@github.com>

On Mon, 19 Sep 2022 00:45:32 GMT, Leslie Zhai <lzhai at openjdk.org> wrote:

> Hi,
> 
> @dumasun reported the issue:
> 
> Configured with jfx-ls-modular-sdk:
> 
> 
> configure --with-import-modules=modular-sdk
> 
> 
> `make run-test CONF=fastdebug TEST="jdk/modules/etc/VerifyModuleDelegation.java"` failed:
> 
> 
> ----------System.out:(46/3114)----------
> test VerifyModuleDelegation.checkJavaBase(): success
> test VerifyModuleDelegation.checkLoaderDelegation(): failure
> java.lang.Error: platform/javafx.swing can't delegate to find classes from app/jdk.unsupported.desktop
>     at VerifyModuleDelegation.lambda$checkLoaderDelegation$1(VerifyModuleDelegation.java:77)
>     at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>     at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1921)
>     at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>     at VerifyModuleDelegation.lambda$checkLoaderDelegation$2(VerifyModuleDelegation.java:68)
>     at java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1715)
>     at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>     at VerifyModuleDelegation.checkLoaderDelegation(VerifyModuleDelegation.java:68)
>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>     at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>     at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>     at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>     at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>     at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>     at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>     at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>     at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>     at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
>     at org.testng.TestRunner.privateRun(TestRunner.java:764)
>     at org.testng.TestRunner.run(TestRunner.java:585)
>     at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
>     at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
>     at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
>     at org.testng.SuiteRunner.run(SuiteRunner.java:286)
>     at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
>     at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
>     at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
>     at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
>     at org.testng.TestNG.runSuites(TestNG.java:1069)
>     at org.testng.TestNG.run(TestNG.java:1037)
>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54)
>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>     at java.base/java.lang.Thread.run(Thread.java:1589)
> 
> ===============================================
> jdk/modules/etc/VerifyModuleDelegation.java
> Total tests run: 2, Passes: 1, Failures: 1, Skips: 0
> ===============================================
> 
> ----------System.err:(13/753)----------
> WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.concurrent
> java.lang.Exception: failures: 1
>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96)
>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54)
>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>     at java.base/java.lang.Thread.run(Thread.java:1589)
> 
> 
> Thanks,
> Leslie Zhai

configure --with-import-modules is of its time. It probably should have been removed in JDK 11 but there are people using it now so I think we are stuck with it. It's way more intrusive than it should be. JDK 9/10 had its need but things have moved on significantly. So if it stays then maybe it could be changed so that the imported modules do not participate in the mapping to class loaders or the hashing. Instead, the import could just provide input into the jlink command used to create the final images. That should be a lot less intrusive and would give us the nice property that it would be equivalent to running jlink outside of the JDK build that produces a run-time image that contains the JavaFX or other imported modules.

-------------

PR: https://git.openjdk.org/jdk/pull/10328

From alanb at openjdk.org  Sun Sep 25 07:32:36 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 25 Sep 2022 07:32:36 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo
 [v11]
In-Reply-To: <34XpvO2kWiaGOek0LRM_ZW5Wlkbp1pW5NzDaKZc3N1I=.93222a1d-3ed7-4700-9115-8bc47a077bbd@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <_la5Co3yx5ik1wt7Y6Bi7MDC3MCVUxIKxz_iQQp2TT8=.1023ef6d-266f-45f5-aa93-7218d0d89c10@github.com>
 <34XpvO2kWiaGOek0LRM_ZW5Wlkbp1pW5NzDaKZc3N1I=.93222a1d-3ed7-4700-9115-8bc47a077bbd@github.com>
Message-ID: <B81YmurPm0llMqhblhzz_c_uU0pKg5kfeITjelt3_SM=.72225b1a-6a58-4aaa-89b1-c022c21dc4b3@github.com>

On Sun, 11 Sep 2022 07:44:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - corrected copyright
>>  - testing transferTo() after reset()
>
>> I do not quite understand what would be wrong with the code below instead of falling back to the super implementation _in case of non-empty buffer_?
> 
> I think you are asking if is safe to leak a reference to the internal buffer. If there is no mark then it might be okay because there is no replay for an evil output stream to attack. However, I think it would require wider review to be confident that there aren't other interesting ways to break it; hence the suggestion in one of the earlier comments to keep it simple and limit it when there is no subclassing, no mark, and no bytes buffered. This does not prevent widening the conditions in the future.

> @AlanBateman Kindly requesting approval. :-)

I don't have any more comments, the recent test cleanups are good. I assume @bplb will sponsor.

-------------

PR: https://git.openjdk.org/jdk/pull/6935

From duke at openjdk.org  Sun Sep 25 08:00:38 2022
From: duke at openjdk.org (Markus KARG)
Date: Sun, 25 Sep 2022 08:00:38 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo
 [v11]
In-Reply-To: <B81YmurPm0llMqhblhzz_c_uU0pKg5kfeITjelt3_SM=.72225b1a-6a58-4aaa-89b1-c022c21dc4b3@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <_la5Co3yx5ik1wt7Y6Bi7MDC3MCVUxIKxz_iQQp2TT8=.1023ef6d-266f-45f5-aa93-7218d0d89c10@github.com>
 <34XpvO2kWiaGOek0LRM_ZW5Wlkbp1pW5NzDaKZc3N1I=.93222a1d-3ed7-4700-9115-8bc47a077bbd@github.com>
 <B81YmurPm0llMqhblhzz_c_uU0pKg5kfeITjelt3_SM=.72225b1a-6a58-4aaa-89b1-c022c21dc4b3@github.com>
Message-ID: <UMb9dk8zfToWjxU73OGobHZH_Jpuy7czFnDMVETpQZA=.83f6fcda-57bc-425f-8b97-95c82c766612@github.com>

On Sun, 25 Sep 2022 07:28:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > @AlanBateman Kindly requesting approval. :-)
> 
> I don't have any more comments, the recent test cleanups are good. I assume @bplb will sponsor.

Thanks a lot for all your kind help with this PR! :-)

-------------

PR: https://git.openjdk.org/jdk/pull/6935

From lbourges at openjdk.org  Sun Sep 25 08:58:45 2022
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Sun, 25 Sep 2022 08:58:45 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v16]
In-Reply-To: <vwMSsoJrQeIWTRaQfzAkWzYwpw5kGuLZkHKatFFL8pQ=.6a42b6eb-49c9-44a9-8f22-8bb305933403@github.com>
References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
 <vwMSsoJrQeIWTRaQfzAkWzYwpw5kGuLZkHKatFFL8pQ=.6a42b6eb-49c9-44a9-8f22-8bb305933403@github.com>
Message-ID: <sqbFVAuVlV_xV-2eAwRjNAUc3AWB9qJ3gjnWd1s9dCE=.ad29e6bc-4e16-43de-b67c-ebc7969fb0d4@github.com>

On Tue, 2 Aug 2022 13:57:03 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)
>   
>   * Optimized and unified buffer allocation
>   * Minor comment changes

Dear all,
As Vladimir's OCA is now cancelled, this pull request is dead.
I am taking over this effort, so I will start from last vladimir's patch in june or july.

This patch was the last with a valid OCA, so his IP was given to the openjdk community, under gpl2 license.

Starting from this code base, I will propose a new DPQS PR under my OCA and will take care of his review for OpenJDK 21.

Once new PR will be proposed, I will close this very-long one.

Agreed?

Laurent Bourg?s, France

-------------

PR: https://git.openjdk.org/jdk/pull/3938

From duke at openjdk.org  Sun Sep 25 10:22:24 2022
From: duke at openjdk.org (Markus KARG)
Date: Sun, 25 Sep 2022 10:22:24 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo
 [v11]
In-Reply-To: <B81YmurPm0llMqhblhzz_c_uU0pKg5kfeITjelt3_SM=.72225b1a-6a58-4aaa-89b1-c022c21dc4b3@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <_la5Co3yx5ik1wt7Y6Bi7MDC3MCVUxIKxz_iQQp2TT8=.1023ef6d-266f-45f5-aa93-7218d0d89c10@github.com>
 <34XpvO2kWiaGOek0LRM_ZW5Wlkbp1pW5NzDaKZc3N1I=.93222a1d-3ed7-4700-9115-8bc47a077bbd@github.com>
 <B81YmurPm0llMqhblhzz_c_uU0pKg5kfeITjelt3_SM=.72225b1a-6a58-4aaa-89b1-c022c21dc4b3@github.com>
Message-ID: <E3HO4qVX6keob7FGy5UCwetmiJwd3pF0Lt5B18Uw8GI=.4fcca86f-6846-4943-8142-27cb50a57fb4@github.com>

On Sun, 25 Sep 2022 07:28:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> I do not quite understand what would be wrong with the code below instead of falling back to the super implementation _in case of non-empty buffer_?
>> 
>> I think you are asking if is safe to leak a reference to the internal buffer. If there is no mark then it might be okay because there is no replay for an evil output stream to attack. However, I think it would require wider review to be confident that there aren't other interesting ways to break it; hence the suggestion in one of the earlier comments to keep it simple and limit it when there is no subclassing, no mark, and no bytes buffered. This does not prevent widening the conditions in the future.
>
>> @AlanBateman Kindly requesting approval. :-)
> 
> I don't have any more comments, the recent test cleanups are good. I assume @bplb will sponsor.

@AlanBateman Kindly asking for `/approve`. Thanks. :-)

-------------

PR: https://git.openjdk.org/jdk/pull/6935

From mernst at openjdk.org  Sun Sep 25 17:04:38 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 25 Sep 2022 17:04:38 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk,
 test/jdk/jni
Message-ID: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>

8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

-------------

Commit messages:
 - 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=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294321
  Stats: 317 lines in 108 files changed: 0 ins; 195 del; 122 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  Sun Sep 25 17:04:38 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 25 Sep 2022 17:04:38 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
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: <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com>

On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

> If you already are an OpenJDK [Author](https://openjdk.java.net/bylaws#author), [Committer](https://openjdk.java.net/bylaws#committer) or [Reviewer](https://openjdk.java.net/bylaws#reviewer), please click [here](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) to open a new issue so that we can record that fact. Please use "Add GitHub user mernst" as summary for the issue.

Done: https://bugs.openjdk.org/browse/SKARA-1566

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From jpai at openjdk.org  Sun Sep 25 17:04:38 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 25 Sep 2022 17:04:38 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com>
Message-ID: <K8T3oImMy9VcIl8ElWlAlzrcmuvBroDqBKkMx5FbfJ4=.a1015a8f-bd22-4780-8cdb-7ad1880a494a@github.com>

On Thu, 25 Aug 2022 19:55:47 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
>> If you already are an OpenJDK [Author](https://openjdk.java.net/bylaws#author), [Committer](https://openjdk.java.net/bylaws#committer) or [Reviewer](https://openjdk.java.net/bylaws#reviewer), please click [here](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) to open a new issue so that we can record that fact. Please use "Add GitHub user mernst" as summary for the issue.
> 
> Done: https://bugs.openjdk.org/browse/SKARA-1566

Hello Michael @mernst, these changes are mostly fine. However, they are spread across files which reside in different areas of the JDK. For changes like these, we usually split up the changes into different PRs to help reviewers of specific areas focus on the individual PRs.

Would you be willing to split this PR into separate ones. I would recommend starting with one PR which includes changes that are part of `test/jdk/java`, `test/jdk/jdk` and `test/jdk/jni`. If you can come up with that PR, then I'll go ahead and create a JBS issue for it and you can then link the PR against that issue.

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From mernst at openjdk.org  Sun Sep 25 17:04:38 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 25 Sep 2022 17:04:38 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <K8T3oImMy9VcIl8ElWlAlzrcmuvBroDqBKkMx5FbfJ4=.a1015a8f-bd22-4780-8cdb-7ad1880a494a@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com>
 <K8T3oImMy9VcIl8ElWlAlzrcmuvBroDqBKkMx5FbfJ4=.a1015a8f-bd22-4780-8cdb-7ad1880a494a@github.com>
Message-ID: <EP2u5O5H_olXmcotmpxlaoSoRHPs9N-3W2csNbysOm8=.6ad85587-573d-432d-89db-568989b754ec@github.com>

On Mon, 5 Sep 2022 06:32:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> these changes are mostly fine.

Can you be specific about the exact problems that you noticed that prevented you from saying "these changes are fine"?  It doesn't seem useful to make a pull request with known deficiencies.

> we usually split up the changes into different PRs to help reviewers of specific areas focus on the individual PRs.

Feel free to split up the pull request, if you feel that specific expertise in specific parts of the JDK is necessary to review these changes.

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From duke at openjdk.org  Sun Sep 25 17:04:39 2022
From: duke at openjdk.org (SWinxy)
Date: Sun, 25 Sep 2022 17:04:39 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <EP2u5O5H_olXmcotmpxlaoSoRHPs9N-3W2csNbysOm8=.6ad85587-573d-432d-89db-568989b754ec@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com>
 <K8T3oImMy9VcIl8ElWlAlzrcmuvBroDqBKkMx5FbfJ4=.a1015a8f-bd22-4780-8cdb-7ad1880a494a@github.com>
 <EP2u5O5H_olXmcotmpxlaoSoRHPs9N-3W2csNbysOm8=.6ad85587-573d-432d-89db-568989b754ec@github.com>
Message-ID: <RWGt4_adstjnxq1OHM-jBMqSjzlLdAqNrpTu3JozTYM=.36dbfb8e-bbfc-4853-ad43-dbeb78bfd92d@github.com>

On Mon, 5 Sep 2022 14:54:50 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> Can you be specific about the exact problems that you noticed that prevented you from saying "these changes are fine"?

These changes are fine. I don't see an instance where the duplicated words would mean a change in the specification.

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From jpai at openjdk.org  Sun Sep 25 17:04:39 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 25 Sep 2022 17:04:39 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
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: <wFLhEno6MEH32FbXeZfWC01cobBwRBW3LbKhMpnYA3A=.dd2199f0-5725-498c-bc6d-0b764ac8ec76@github.com>

On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

Hello Michael,

> > these changes are mostly fine.
> 
> Can you be specific about the exact problems that you noticed that prevented you from saying "these changes are fine"? It doesn't seem useful to make a pull request with known deficiencies.

I wasn't implying this PR had deficiencies. What I meant was, to be able to have this reviewed, in addition to code changes this will also need a issue to be created and linked to this PR (and the PR title changed to the form `<bugid>: <bug summary>`). 
I have now created https://bugs.openjdk.org/browse/JDK-8294321. Splitting these changes into smaller PRs instead of one big one that touches several different areas of the JDK and 108 files, will help reviewers.

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From mernst at openjdk.org  Sun Sep 25 17:04:39 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 25 Sep 2022 17:04:39 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <wFLhEno6MEH32FbXeZfWC01cobBwRBW3LbKhMpnYA3A=.dd2199f0-5725-498c-bc6d-0b764ac8ec76@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <wFLhEno6MEH32FbXeZfWC01cobBwRBW3LbKhMpnYA3A=.dd2199f0-5725-498c-bc6d-0b764ac8ec76@github.com>
Message-ID: <kqbMO6iHpa3xNDX1Ooa6zLtG9rZJK7mBogbO83RQQLs=.b1cb0e4a-032b-438e-b1a4-7644680ecd6b@github.com>

On Sat, 24 Sep 2022 10:41:05 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Splitting these changes into smaller PRs instead of one big one that touches several different areas of the JDK and 108 files, will help reviewers.

OK.  I'll repeat my comment from before:

> Feel free to split up the pull request, if you feel that specific expertise in specific parts of the JDK is necessary to review these changes.

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From duke at openjdk.org  Sun Sep 25 17:04:39 2022
From: duke at openjdk.org (SWinxy)
Date: Sun, 25 Sep 2022 17:04:39 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
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: <PeWYni0LXLnheHNkbRfnq4DWiKApuzSnPDLuo6_mXZA=.c01ed027-9462-404c-a6c6-2caff919d380@github.com>

On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

Oh no what happened
![image](https://user-images.githubusercontent.com/8303399/192155378-4bb439fa-d27a-417d-8a3c-cf7f7329458f.png)

src/java.xml/share/classes/com/sun/org/apache/xpath/internal/NodeSetDTM.java line 1053:

> 1051:    * fetch will take place at index 1.
> 1052:    *
> 1053:    * @return The current position index.

Note that there is an inconsistent change here, albeit insignificant. In `NodeSet`, the capital 'The' is removed after the `@return`, while the lowercase 'the' is removed here.

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From mernst at openjdk.org  Sun Sep 25 17:04:39 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 25 Sep 2022 17:04:39 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <PeWYni0LXLnheHNkbRfnq4DWiKApuzSnPDLuo6_mXZA=.c01ed027-9462-404c-a6c6-2caff919d380@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <PeWYni0LXLnheHNkbRfnq4DWiKApuzSnPDLuo6_mXZA=.c01ed027-9462-404c-a6c6-2caff919d380@github.com>
Message-ID: <MnLhhKzLqR1jb7PbtrJu2AlU4xQ5EolX_Zi7TUsJ96g=.e03c2f32-7815-40e8-9450-b66e425c31ef@github.com>

On Sun, 25 Sep 2022 16:51:27 GMT, SWinxy <duke at openjdk.org> wrote:

> Oh no what happened

Oops!  Thanks for pointing out the goof.  It seems to be fixed now.

It has now been a month since I opened the pull request, and I have responded to each substantive comment promptly.  It would be great to merge this pull request to avoid the need for more merges.

> src/java.xml/share/classes/com/sun/org/apache/xpath/internal/NodeSetDTM.java line 1053:
> 
>> 1051:    * fetch will take place at index 1.
>> 1052:    *
>> 1053:    * @return The current position index.
> 
> Note that there is an inconsistent change here, albeit insignificant. In `NodeSet`, the capital 'The' is removed after the `@return`, while the lowercase 'the' is removed here.

Thanks for pointing out the inconsistency.  I have fixed it.  (I noticed many violations of the official Javadoc style, but this is not the right pull request to fix them.)

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From alanb at openjdk.org  Sun Sep 25 17:04:40 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 25 Sep 2022 17:04:40 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
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: <R54YOofSpP6mkT2GyVD4iej7GhNlgZZsc9ryNTQDbNA=.0df12727-83ea-46fa-9a8c-9eacce5235e7@github.com>

On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

src/java.base/share/native/libzip/zlib/zlib.h line 756:

> 754:    If this is done, the old level and strategy will be applied to the data
> 755:    compressed before deflateParams(), and the new level and strategy will be
> 756:    applied to the data compressed after deflateParams().

This is an issue for the upstream zlib project, we probably don't want to change it here.

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From lancea at openjdk.org  Sun Sep 25 17:04:40 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Sun, 25 Sep 2022 17:04:40 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <R54YOofSpP6mkT2GyVD4iej7GhNlgZZsc9ryNTQDbNA=.0df12727-83ea-46fa-9a8c-9eacce5235e7@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <R54YOofSpP6mkT2GyVD4iej7GhNlgZZsc9ryNTQDbNA=.0df12727-83ea-46fa-9a8c-9eacce5235e7@github.com>
Message-ID: <x4W-bBcbveocGQIvbX-qnNqHrN7t7vh7ZFwtj-BVt2o=.5a11a98b-86b6-4cfb-82c5-a8809fbedf7f@github.com>

On Tue, 30 Aug 2022 09:31:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> src/java.base/share/native/libzip/zlib/zlib.h line 756:
> 
>> 754:    If this is done, the old level and strategy will be applied to the data
>> 755:    compressed before deflateParams(), and the new level and strategy will be
>> 756:    applied to the data compressed after deflateParams().
> 
> This is an issue for the upstream zlib project, we probably don't want to change it here.

Agree.  See https://github.com/madler/zlib/commit/5752b171fd4cc96b8d1f9526ec1940199c6e9740 which is in the zlib development branch and addresses a wide range of typos.

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From mernst at openjdk.org  Sun Sep 25 17:04:40 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 25 Sep 2022 17:04:40 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <x4W-bBcbveocGQIvbX-qnNqHrN7t7vh7ZFwtj-BVt2o=.5a11a98b-86b6-4cfb-82c5-a8809fbedf7f@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <R54YOofSpP6mkT2GyVD4iej7GhNlgZZsc9ryNTQDbNA=.0df12727-83ea-46fa-9a8c-9eacce5235e7@github.com>
 <x4W-bBcbveocGQIvbX-qnNqHrN7t7vh7ZFwtj-BVt2o=.5a11a98b-86b6-4cfb-82c5-a8809fbedf7f@github.com>
Message-ID: <rIuyz9yAlhyXwOpBnnAnmL0xQZbMk6bbr8QP4iogfzk=.33cce124-d245-46de-bb74-f3eaf9dbdfd8@github.com>

On Tue, 30 Aug 2022 09:55:18 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/java.base/share/native/libzip/zlib/zlib.h line 756:
>> 
>>> 754:    If this is done, the old level and strategy will be applied to the data
>>> 755:    compressed before deflateParams(), and the new level and strategy will be
>>> 756:    applied to the data compressed after deflateParams().
>> 
>> This is an issue for the upstream zlib project, we probably don't want to change it here.
>
> Agree.  See https://github.com/madler/zlib/commit/5752b171fd4cc96b8d1f9526ec1940199c6e9740 which is in the zlib development branch and addresses a wide range of typos.

OK.  I backed out the change to zlib.

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From duke at openjdk.org  Sun Sep 25 17:23:28 2022
From: duke at openjdk.org (SWinxy)
Date: Sun, 25 Sep 2022 17:23:28 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
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: <l_BuZBAL5oEJ3CbI12q_XE9gFcXd-qEwGsRrSaIJDd0=.dea17f4e-b629-43e4-bc7e-47fccac4cb3a@github.com>

On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

I'm not a committer (yet) so I can't [sponsor](https://openjdk.org/sponsor/) this PR, even though I would.

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From haosun at openjdk.org  Mon Sep 26 01:39:41 2022
From: haosun at openjdk.org (Hao Sun)
Date: Mon, 26 Sep 2022 01:39:41 GMT
Subject: RFR: 8293887: AArch64 build failure with GCC 12 due to
 maybe-uninitialized warning in libfdlibm k_rem_pio2.c [v2]
In-Reply-To: <UTaCIvPdArIMVc2jDoPYp72K5MelURpuipDuZigrDy0=.16cf4031-3791-4fd4-aeb3-598fa4faf4db@github.com>
References: <UTaCIvPdArIMVc2jDoPYp72K5MelURpuipDuZigrDy0=.16cf4031-3791-4fd4-aeb3-598fa4faf4db@github.com>
Message-ID: <ckVWsVK3EmbkP2Vc5GHn7RtRwg9-em0HFy_xwOXw5cA=.b3ce66d2-5491-45a6-8a87-75d98c699bb8@github.com>

> This warning seems to be a false positive, because 1) array "fq" with elements from index 0 to "jz" has already been initialized as "fw" at line 290 [1], and 2) variable "jz" should be non-negative from the comment at line 99 [2].
> 
> Note-1: GCC warning option -Wmaybe-uninitialized is not a new one. Note-2: x86-64 build with GCC 12 on Ubuntu 22.04 passed in my local test.
> 
> This warning is raised only on GCC 12 + AArch64. I suspect it might be some GCC 12 bug, so I reported it to GCC community [3].
> 
> Since it involves third party code, I think it's better to suppress the warning by simply disabling this warning option in the makefile.
> 
> Testing: Release builds with GCC 9, GCC 11 and GCC 12 passed on Ubuntu 22.04/AArch64 system.
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libfdlibm/k_rem_pio2.c#L290 
> [2] https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libfdlibm/k_rem_pio2.c#L99 
> [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106992

Hao Sun 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:

 - Disable the warning option per file
   
   After JDK-8294281, we can disable the warning options per file.
   
   Testing: Release builds with GCC 9, GCC 11 and GCC 12 passed on Ubuntu
   22.04/AArch64 system.
 - Merge branch 'master' into 8293887-gcc12-fdlibm
 - 8293887: AArch64 build failure with GCC 12 due to maybe-uninitialized warning in libfdlibm k_rem_pio2.c
   
   This warning seems to be a false positive, because 1) array "fq" with
   elements from index 0 to "jz" has already been initialized as "fw" at
   line 290 [1], and 2) variable "jz" should be non-negative from the
   comment at line 99 [2].
   
   Note-1: GCC warning option -Wmaybe-uninitialized is not a new one.
   Note-2: x86-64 build with GCC 12 on Ubuntu 22.04 passed in my local
   test.
   
   This warning is raised only on GCC 12 + AArch64. I suspect it might be
   some GCC 12 bug, so I reported it to GCC community [3].
   
   Since it involves third party code, I think it's better to suppress the
   warning by simply disabling this warning option in the makefile.
   
   Testing: Release builds with GCC 9, GCC 11 and GCC 12 passed on Ubuntu
   22.04/AArch64 system.
   
   [1] https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libfdlibm/k_rem_pio2.c#L290
   [2] https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libfdlibm/k_rem_pio2.c#L99
   [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106992

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10386/files
  - new: https://git.openjdk.org/jdk/pull/10386/files/f745d060..22355e68

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10386&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10386&range=00-01

  Stats: 5636 lines in 151 files changed: 3213 ins; 1665 del; 758 mod
  Patch: https://git.openjdk.org/jdk/pull/10386.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10386/head:pull/10386

PR: https://git.openjdk.org/jdk/pull/10386

From haosun at openjdk.org  Mon Sep 26 01:42:48 2022
From: haosun at openjdk.org (Hao Sun)
Date: Mon, 26 Sep 2022 01:42:48 GMT
Subject: RFR: 8293887: AArch64 build failure with GCC 12 due to
 maybe-uninitialized warning in libfdlibm k_rem_pio2.c [v2]
In-Reply-To: <KTSgkRQE2fW5gvHESx2BdgeWZ0q0UoZnwOnfqsMkvuY=.184101d1-71e9-44c7-a8e0-112f1d75569b@github.com>
References: <UTaCIvPdArIMVc2jDoPYp72K5MelURpuipDuZigrDy0=.16cf4031-3791-4fd4-aeb3-598fa4faf4db@github.com>
 <11i9FwYPL2nt-RHe135PRcOFcZdo_RsIFHxHw8AgYqw=.a17c8166-3077-40bb-836b-2e3112b280e4@github.com>
 <vks8-99Oc6cfhJMPg67PEsIcwhrcwsmW73E38O6mjEo=.ebcbada9-95c3-49c2-8411-c221614345ca@github.com>
 <KTSgkRQE2fW5gvHESx2BdgeWZ0q0UoZnwOnfqsMkvuY=.184101d1-71e9-44c7-a8e0-112f1d75569b@github.com>
Message-ID: <Ro7TAn8QGLO2lq36JfNv4D7H42pWJO1xzjYFBZ-bbkQ=.67a9f766-ae74-450c-864b-13f28e49732a@github.com>

On Fri, 23 Sep 2022 12:47:24 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Thanks for your review.
>> 
>> Your mentioned solution should work and we can also enable the pragma only for aarch64 + gcc>=12 condition.
>> I considered such a solution when preparing this patch.
>> 
>> But I personally prefer to suppress the waring in the makefile, mainly because fdlibm is 3rd party library and we'd better not changing the source code. I think it is a long-standing policy.
>
> Yes, we should not modify 3rd party code.
> 
> What you would need is [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281). If you can hold back this patch for a little while, you'll be able to utilize it instead.

Thanks for your info @magicus.

Updated the code using [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281) in the latest commit.
Would you mind taking another look? Thanks! @theRealAph  @magicus

-------------

PR: https://git.openjdk.org/jdk/pull/10386

From dholmes at openjdk.org  Mon Sep 26 07:19:27 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 26 Sep 2022 07:19:27 GMT
Subject: RFR: 8290482: Update JNI Specification of DestroyJavaVM for better
 alignment with JLS, JVMS, and Java SE API Specifications [v4]
In-Reply-To: <7uEEjcCVoEfGK2L99QCHvzy9OWzl2I-4P_AelvyhvTc=.04adb658-216b-4811-a7a8-173a6786a44b@github.com>
References: <M2IRKiuONiNI45YTu9wdu1o8ZXJslnxRmgMvnlVU478=.4aa03d22-0395-4354-bf41-f11a74df791a@github.com>
 <5LZVfXnTpbyr_NWeYid9qzKrnZ6t2b7ZL5BtHEZ4Syc=.bff15db2-726a-4976-89f1-edd826d75bf2@github.com>
 <7uEEjcCVoEfGK2L99QCHvzy9OWzl2I-4P_AelvyhvTc=.04adb658-216b-4811-a7a8-173a6786a44b@github.com>
Message-ID: <dGZQeQczpT7DZlKX2WXtHnzKa1U9Jz6C75fAwZRJ-CQ=.be9ff84a-bc34-4f4a-ab85-ba3c15aff500@github.com>

On Fri, 23 Sep 2022 12:41:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix JniVersion test
>
> This seems good.  I looked at the specification changes and they looked okay also.

Thanks @coleenp !

-------------

PR: https://git.openjdk.org/jdk/pull/10352

From dholmes at openjdk.org  Mon Sep 26 07:21:37 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 26 Sep 2022 07:21:37 GMT
Subject: RFR: 8293592: Remove JVM_StopThread, stillborn,
 and related cleanup
In-Reply-To: <Bfq-Tx0S9oPszwvfoUkCtVd16ARxYp6c8Y1Oe9S1_y4=.1b7e4278-2ba0-455e-9cd8-2d0b27f49d70@github.com>
References: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
 <Bfq-Tx0S9oPszwvfoUkCtVd16ARxYp6c8Y1Oe9S1_y4=.1b7e4278-2ba0-455e-9cd8-2d0b27f49d70@github.com>
Message-ID: <lAMbsZ-naq8on_kMxkC-GfplRU9Jv2K_X9h3bPXKz8c=.284b17da-d0bb-4c19-8a64-61943ba0ac53@github.com>

On Fri, 23 Sep 2022 11:10:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610).
>> 
>> Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started.
>> 
>> Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same).
>> 
>> Testing: tiers 1-3
>
> (JDK-8289610 is integrated now so once you sync up it should remove the changes from the dependent PR and reduce the list of changed files. You should be able to trim down the labels too.)
> 
> I did a pass over the src/hotspot change and didn't spot any issues. It's good that stillborn can go away. The removal of the special-casing of ThreadDeath is consistent with the libs side of the change, including the change to ExceptionDescribe.

Thanks @AlanBateman !

-------------

PR: https://git.openjdk.org/jdk/pull/10400

From duke at openjdk.org  Mon Sep 26 08:07:50 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Mon, 26 Sep 2022 08:07:50 GMT
Subject: RFR: 8289797: tools/launcher/I18NArgTest.java fails on Japanese
 Windows environment [v6]
In-Reply-To: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
References: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
Message-ID: <GJ_UOC5wgFeegmrbrsUPo1VeaFWDELQwkUZMv_CGVJo=.ff7721d2-c80c-4106-9dca-ca5c8140d104@github.com>

> I removed a section of via JDK_JAVA_OPTIONS because including main class is not allowed in the specification.
> This behavior is added in JDK-8170832, which add JAVA_OPTIONS environment variable. At this time, this test is mismatch with the specification.
> I tried to test and get Passed on Japanese Windows environment.
> Could you review this fix, please?

KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:

  8289797: tools/launcher/I18NArgTest.java fails on Japanese Windows environment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9389/files
  - new: https://git.openjdk.org/jdk/pull/9389/files/1149de31..73c99724

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9389&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9389&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9389.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9389/head:pull/9389

PR: https://git.openjdk.org/jdk/pull/9389

From duke at openjdk.org  Mon Sep 26 08:07:51 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Mon, 26 Sep 2022 08:07:51 GMT
Subject: RFR: 8289797: tools/launcher/I18NArgTest.java fails on Japanese
 Windows environment [v5]
In-Reply-To: <Ijaev_hEXN91s0kyh3Wi_XwQ3WsGlEB7We1OnNppuko=.7f2ef9d8-a45e-41c1-9f3b-ba05e2cb4855@github.com>
References: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
 <paq2Q8OefqqVpkogRRHxaV-WzGyb5mNMZ7xsn3uZURQ=.fb49c3f0-c160-40c3-a4fe-79576a0eba5b@github.com>
 <Ijaev_hEXN91s0kyh3Wi_XwQ3WsGlEB7We1OnNppuko=.7f2ef9d8-a45e-41c1-9f3b-ba05e2cb4855@github.com>
Message-ID: <_I0rVYnwm3aHArjqiTfgCviB1g1FAny6q0BabuLUKWg=.41255c7e-f0a0-4b62-95ed-2eb20430328a@github.com>

On Wed, 21 Sep 2022 16:49:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8289797: tools/launcher/I18NArgTest.java fails on Japanese Windows environment
>
> test/jdk/tools/launcher/I18NArgTest.java line 152:
> 
>> 150:         }
>> 151:     }
>> 152: }
> 
> Nit: don't remove the newline at the end

I am sorry for my mistake. I fixed it.

-------------

PR: https://git.openjdk.org/jdk/pull/9389

From dsamersoff at openjdk.org  Mon Sep 26 09:53:33 2022
From: dsamersoff at openjdk.org (Dmitry Samersoff)
Date: Mon, 26 Sep 2022 09:53:33 GMT
Subject: RFR: 8293806: JDK_JAVA_OPTIONS picked up twice if LD_LIBRARY_PATH is
 set
Message-ID: <8Qu9RzE7KHG2f0vshbUPpWYmHDmiGnYsw4DtXTd1gM4=.d2657bd6-11a8-44f1-aea7-23cefe914729@github.com>

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.

-------------

Commit messages:
 - 8293806: JDK_JAVA_OPTIONS picked up twice if LD_LIBRARY_PATH is set

Changes: https://git.openjdk.org/jdk/pull/10420/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10420&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293806
  Stats: 35 lines in 8 files changed: 11 ins; 12 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/10420.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10420/head:pull/10420

PR: https://git.openjdk.org/jdk/pull/10420

From dsamersoff at openjdk.org  Mon Sep 26 10:16:30 2022
From: dsamersoff at openjdk.org (Dmitry Samersoff)
Date: Mon, 26 Sep 2022 10:16:30 GMT
Subject: Withdrawn: 8293806: JDK_JAVA_OPTIONS picked up twice if
 LD_LIBRARY_PATH is set
In-Reply-To: <8Qu9RzE7KHG2f0vshbUPpWYmHDmiGnYsw4DtXTd1gM4=.d2657bd6-11a8-44f1-aea7-23cefe914729@github.com>
References: <8Qu9RzE7KHG2f0vshbUPpWYmHDmiGnYsw4DtXTd1gM4=.d2657bd6-11a8-44f1-aea7-23cefe914729@github.com>
Message-ID: <KKvYQL8HL5t6C6mH7i29RQPvfl8eb3CTeUft0x3DlUY=.de5873fc-3e11-4cf3-8f7b-93a37769ae24@github.com>

On Mon, 26 Sep 2022 09:46:36 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/10420

From aturbanov at openjdk.org  Mon Sep 26 10:20:11 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 26 Sep 2022 10:20:11 GMT
Subject: RFR: 8294361: Cleanup usages of StringBuffer in SQLOutputImpl
Message-ID: <q_2V_qZS-UHRrwlkokVHntWAjO1XwAxvle5UxkXvK2Q=.e07e382a-efe9-4ff5-80e3-7022100314d5@github.com>

There a few unnecessary usages of StringBuffer in SQLOutputImpl class.
All of them create StringBuffer from single character and then concatenate with String. Instead of this, we can concatenate character directly.

-------------

Commit messages:
 - [PATCH] Cleanup usages of StringBuffer in SQLOutputImpl

Changes: https://git.openjdk.org/jdk/pull/10320/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10320&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294361
  Stats: 36 lines in 1 file changed: 0 ins; 15 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/10320.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10320/head:pull/10320

PR: https://git.openjdk.org/jdk/pull/10320

From dholmes at openjdk.org  Mon Sep 26 10:32:40 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 26 Sep 2022 10:32:40 GMT
Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume [v3]
In-Reply-To: <qCI92xJUfPZdfdgharNxiBnT2fv89IrS-02K4zJhQaA=.0d29302a-9603-490e-a28e-30861631c1ba@github.com>
References: <l_lUEdZ-ORALa9ux2qu_PZZFm2IpIZs02kdC-tCQQBM=.e96f9fab-8d68-4ba1-b0f6-2b9b5c397226@github.com>
 <qCI92xJUfPZdfdgharNxiBnT2fv89IrS-02K4zJhQaA=.0d29302a-9603-490e-a28e-30861631c1ba@github.com>
Message-ID: <5FVc4-m-MyON0EHxtzwvuBFlwypdnhukQPk8lzYaA9Y=.85232874-19eb-4c1b-be85-9c6f37f7a20e@github.com>

On Sat, 24 Sep 2022 06:50:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Degrade Thread.suspend/resume to throw UOE unconditionally.
>> 
>> Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive.
>> 
>> The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs.
>> 
>> Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread).
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Remove tests from exclude list
>  - Merge
>  - Update DegradedMethodsThrowUOE to test Thread.stop
>  - Merge
>  - Update modifyThread and modifyThreadGroup targets
>  - Merge
>  - Fix typo in test comment
>  - Keep link to threadPrimitiveDeprecation.html
>  - Merge
>  - Tests
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/543851db...6aa38889

Marked as reviewed by dholmes (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10324

From erikj at openjdk.org  Mon Sep 26 12:57:24 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 26 Sep 2022 12:57:24 GMT
Subject: RFR: 8294317: Insufficient build rules for tzdb.dat
In-Reply-To: <WS7j8PLGWmQXKydFbhYDSic55ECn9p40NdRIcS7TRHs=.43ced95c-1843-4d3b-9cb1-d526618e0678@github.com>
References: <WS7j8PLGWmQXKydFbhYDSic55ECn9p40NdRIcS7TRHs=.43ced95c-1843-4d3b-9cb1-d526618e0678@github.com>
Message-ID: <9BNVIgTyNGZTEEiPrMeHBaDnSjfna0vPNx3uUy4MPac=.9227bda9-2a69-4ed8-adb8-0a49451569a1@github.com>

On Fri, 23 Sep 2022 22:10:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The current makefile for `tzdb.dat` won't recompile if some dependent files (e.g. `VERSION`) are updated. Adding all files under the tzdb directory to the dependency will fix this issue.

make/modules/java.base/gendata/GendataTZDB.gmk line 33:

> 31: TZDATA_DIR := $(MODULE_SRC)/share/data/tzdata
> 32: TZDATA_TZFILE := africa antarctica asia australasia europe northamerica southamerica backward etcetera gmt jdk11_backward
> 33: TZDATA_TZFILES := $(TZDATA_DIR)/*

Have you verified that this works? I would expect a wildcard call to be needed. 
Suggestion:

TZDATA_TZFILES := $(wildcard $(TZDATA_DIR)/*)

-------------

PR: https://git.openjdk.org/jdk/pull/10415

From erikj at openjdk.org  Mon Sep 26 13:02:11 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 26 Sep 2022 13:02:11 GMT
Subject: RFR: 8293887: AArch64 build failure with GCC 12 due to
 maybe-uninitialized warning in libfdlibm k_rem_pio2.c [v2]
In-Reply-To: <ckVWsVK3EmbkP2Vc5GHn7RtRwg9-em0HFy_xwOXw5cA=.b3ce66d2-5491-45a6-8a87-75d98c699bb8@github.com>
References: <UTaCIvPdArIMVc2jDoPYp72K5MelURpuipDuZigrDy0=.16cf4031-3791-4fd4-aeb3-598fa4faf4db@github.com>
 <ckVWsVK3EmbkP2Vc5GHn7RtRwg9-em0HFy_xwOXw5cA=.b3ce66d2-5491-45a6-8a87-75d98c699bb8@github.com>
Message-ID: <SeRTVAjfpjr-c_8Eq7EV8LyWCIDeiqk22h7afMI7W-s=.54262495-6743-41cd-b777-ce1539c70280@github.com>

On Mon, 26 Sep 2022 01:39:41 GMT, Hao Sun <haosun at openjdk.org> wrote:

>> This warning seems to be a false positive, because 1) array "fq" with elements from index 0 to "jz" has already been initialized as "fw" at line 290 [1], and 2) variable "jz" should be non-negative from the comment at line 99 [2].
>> 
>> Note-1: GCC warning option -Wmaybe-uninitialized is not a new one. Note-2: x86-64 build with GCC 12 on Ubuntu 22.04 passed in my local test.
>> 
>> This warning is raised only on GCC 12 + AArch64. I suspect it might be some GCC 12 bug, so I reported it to GCC community [3].
>> 
>> Since it involves third party code, I think it's better to suppress the warning by simply disabling this warning option in the makefile.
>> 
>> Testing: Release builds with GCC 9, GCC 11 and GCC 12 passed on Ubuntu 22.04/AArch64 system.
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libfdlibm/k_rem_pio2.c#L290 
>> [2] https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libfdlibm/k_rem_pio2.c#L99 
>> [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106992
>
> Hao Sun 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:
> 
>  - Disable the warning option per file
>    
>    After JDK-8294281, we can disable the warning options per file.
>    
>    Testing: Release builds with GCC 9, GCC 11 and GCC 12 passed on Ubuntu
>    22.04/AArch64 system.
>  - Merge branch 'master' into 8293887-gcc12-fdlibm
>  - 8293887: AArch64 build failure with GCC 12 due to maybe-uninitialized warning in libfdlibm k_rem_pio2.c
>    
>    This warning seems to be a false positive, because 1) array "fq" with
>    elements from index 0 to "jz" has already been initialized as "fw" at
>    line 290 [1], and 2) variable "jz" should be non-negative from the
>    comment at line 99 [2].
>    
>    Note-1: GCC warning option -Wmaybe-uninitialized is not a new one.
>    Note-2: x86-64 build with GCC 12 on Ubuntu 22.04 passed in my local
>    test.
>    
>    This warning is raised only on GCC 12 + AArch64. I suspect it might be
>    some GCC 12 bug, so I reported it to GCC community [3].
>    
>    Since it involves third party code, I think it's better to suppress the
>    warning by simply disabling this warning option in the makefile.
>    
>    Testing: Release builds with GCC 9, GCC 11 and GCC 12 passed on Ubuntu
>    22.04/AArch64 system.
>    
>    [1] https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libfdlibm/k_rem_pio2.c#L290
>    [2] https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libfdlibm/k_rem_pio2.c#L99
>    [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106992

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10386

From shade at openjdk.org  Mon Sep 26 13:07:23 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 26 Sep 2022 13:07:23 GMT
Subject: RFR: 8293887: AArch64 build failure with GCC 12 due to
 maybe-uninitialized warning in libfdlibm k_rem_pio2.c [v2]
In-Reply-To: <ckVWsVK3EmbkP2Vc5GHn7RtRwg9-em0HFy_xwOXw5cA=.b3ce66d2-5491-45a6-8a87-75d98c699bb8@github.com>
References: <UTaCIvPdArIMVc2jDoPYp72K5MelURpuipDuZigrDy0=.16cf4031-3791-4fd4-aeb3-598fa4faf4db@github.com>
 <ckVWsVK3EmbkP2Vc5GHn7RtRwg9-em0HFy_xwOXw5cA=.b3ce66d2-5491-45a6-8a87-75d98c699bb8@github.com>
Message-ID: <BK6A1yW-1RsYFpQ7vUqA4kTTlKGJuccgQFTTz-UBppA=.f9f6551e-dca7-4bba-9103-7591aef2bf24@github.com>

On Mon, 26 Sep 2022 01:39:41 GMT, Hao Sun <haosun at openjdk.org> wrote:

>> This warning seems to be a false positive, because 1) array "fq" with elements from index 0 to "jz" has already been initialized as "fw" at line 290 [1], and 2) variable "jz" should be non-negative from the comment at line 99 [2].
>> 
>> Note-1: GCC warning option -Wmaybe-uninitialized is not a new one. Note-2: x86-64 build with GCC 12 on Ubuntu 22.04 passed in my local test.
>> 
>> This warning is raised only on GCC 12 + AArch64. I suspect it might be some GCC 12 bug, so I reported it to GCC community [3].
>> 
>> Since it involves third party code, I think it's better to suppress the warning by simply disabling this warning option in the makefile.
>> 
>> Testing: Release builds with GCC 9, GCC 11 and GCC 12 passed on Ubuntu 22.04/AArch64 system.
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libfdlibm/k_rem_pio2.c#L290 
>> [2] https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libfdlibm/k_rem_pio2.c#L99 
>> [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106992
>
> Hao Sun 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:
> 
>  - Disable the warning option per file
>    
>    After JDK-8294281, we can disable the warning options per file.
>    
>    Testing: Release builds with GCC 9, GCC 11 and GCC 12 passed on Ubuntu
>    22.04/AArch64 system.
>  - Merge branch 'master' into 8293887-gcc12-fdlibm
>  - 8293887: AArch64 build failure with GCC 12 due to maybe-uninitialized warning in libfdlibm k_rem_pio2.c
>    
>    This warning seems to be a false positive, because 1) array "fq" with
>    elements from index 0 to "jz" has already been initialized as "fw" at
>    line 290 [1], and 2) variable "jz" should be non-negative from the
>    comment at line 99 [2].
>    
>    Note-1: GCC warning option -Wmaybe-uninitialized is not a new one.
>    Note-2: x86-64 build with GCC 12 on Ubuntu 22.04 passed in my local
>    test.
>    
>    This warning is raised only on GCC 12 + AArch64. I suspect it might be
>    some GCC 12 bug, so I reported it to GCC community [3].
>    
>    Since it involves third party code, I think it's better to suppress the
>    warning by simply disabling this warning option in the makefile.
>    
>    Testing: Release builds with GCC 9, GCC 11 and GCC 12 passed on Ubuntu
>    22.04/AArch64 system.
>    
>    [1] https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libfdlibm/k_rem_pio2.c#L290
>    [2] https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libfdlibm/k_rem_pio2.c#L99
>    [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106992

Looks fine to me.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10386

From dl at openjdk.org  Mon Sep 26 13:16:10 2022
From: dl at openjdk.org (Doug Lea)
Date: Mon, 26 Sep 2022 13:16:10 GMT
Subject: RFR: 8292969: Bad Thread Utilization in ForkJoinPool
Message-ID: <QzRti_crUWUQZ6PTLo0V-9YjIF40v0RDkS0E_4-anSc=.a68d897f-ac2c-4060-994c-3fb8b39d988e@github.com>

8292969: This small change in signal propagation rules improves utilization when entry queues are resized,

-------------

Commit messages:
 - Merge remote-tracking branch 'refs/remotes/origin/JDK-8292969' into JDK-8292969
 - Merge branch 'openjdk:master' into JDK-8292969
 - Update @preturn javadoc to reflect use of prevSrc
 - Improve signal propagation after queue resizing

Changes: https://git.openjdk.org/jdk/pull/10198/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10198&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292969
  Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/10198.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10198/head:pull/10198

PR: https://git.openjdk.org/jdk/pull/10198

From martin at openjdk.org  Mon Sep 26 13:16:11 2022
From: martin at openjdk.org (Martin Buchholz)
Date: Mon, 26 Sep 2022 13:16:11 GMT
Subject: RFR: 8292969: Bad Thread Utilization in ForkJoinPool
In-Reply-To: <QzRti_crUWUQZ6PTLo0V-9YjIF40v0RDkS0E_4-anSc=.a68d897f-ac2c-4060-994c-3fb8b39d988e@github.com>
References: <QzRti_crUWUQZ6PTLo0V-9YjIF40v0RDkS0E_4-anSc=.a68d897f-ac2c-4060-994c-3fb8b39d988e@github.com>
Message-ID: <ccE8ibAbkTJEYDR4hcVH7ITaVC4aP9-MUdr-BOf__jk=.1d122ca6-6303-4c35-8258-f3482f32ac4e@github.com>

On Wed, 7 Sep 2022 12:44:11 GMT, Doug Lea <dl at openjdk.org> wrote:

> 8292969: This small change in signal propagation rules improves utilization when entry queues are resized,

scan's @return needs to be changed to indicate it also now returns a packed int

-------------

Changes requested by martin (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10198

From dl at openjdk.org  Mon Sep 26 13:16:12 2022
From: dl at openjdk.org (Doug Lea)
Date: Mon, 26 Sep 2022 13:16:12 GMT
Subject: RFR: 8292969: Bad Thread Utilization in ForkJoinPool
In-Reply-To: <QzRti_crUWUQZ6PTLo0V-9YjIF40v0RDkS0E_4-anSc=.a68d897f-ac2c-4060-994c-3fb8b39d988e@github.com>
References: <QzRti_crUWUQZ6PTLo0V-9YjIF40v0RDkS0E_4-anSc=.a68d897f-ac2c-4060-994c-3fb8b39d988e@github.com>
Message-ID: <Mlnnj6Z3P9xCOeSIn4-8_GBqnWGjV_m95SG2G9XKCr4=.4fb7eb39-f646-48e3-b044-95ef85b7cbfc@github.com>

On Wed, 7 Sep 2022 12:44:11 GMT, Doug Lea <dl at openjdk.org> wrote:

> 8292969: This small change in signal propagation rules improves utilization when entry queues are resized,

Thanks. replaced with:
     * @return the next prevSrc value to use, or negative if none found

Thanks. I keep forgetting the required format for these.

-------------

PR: https://git.openjdk.org/jdk/pull/10198

From jpai at openjdk.org  Mon Sep 26 13:16:14 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 Sep 2022 13:16:14 GMT
Subject: RFR: 8292969: Bad Thread Utilization in ForkJoinPool
In-Reply-To: <QzRti_crUWUQZ6PTLo0V-9YjIF40v0RDkS0E_4-anSc=.a68d897f-ac2c-4060-994c-3fb8b39d988e@github.com>
References: <QzRti_crUWUQZ6PTLo0V-9YjIF40v0RDkS0E_4-anSc=.a68d897f-ac2c-4060-994c-3fb8b39d988e@github.com>
Message-ID: <G7df-Pa58ngdvaqKZC0BLlEAhPvqQ6Bjqp07AQvxdw4=.e89c1b9a-996f-44d7-a1a7-603e9caf02a9@github.com>

On Wed, 7 Sep 2022 12:44:11 GMT, Doug Lea <dl at openjdk.org> wrote:

> 8292969: This small change in signal propagation rules improves utilization when entry queues are resized,

Hello Doug, for the bots to trigger the review process, the title of this PR is expected to be `<bugid>: <bug summary>`, so in this case the title of this PR will have to be edited to `8292969: Bad Thread Utilization in ForkJoinPool`

-------------

PR: https://git.openjdk.org/jdk/pull/10198

From ihse at openjdk.org  Mon Sep 26 13:17:28 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 Sep 2022 13:17:28 GMT
Subject: RFR: 8293887: AArch64 build failure with GCC 12 due to
 maybe-uninitialized warning in libfdlibm k_rem_pio2.c [v2]
In-Reply-To: <ckVWsVK3EmbkP2Vc5GHn7RtRwg9-em0HFy_xwOXw5cA=.b3ce66d2-5491-45a6-8a87-75d98c699bb8@github.com>
References: <UTaCIvPdArIMVc2jDoPYp72K5MelURpuipDuZigrDy0=.16cf4031-3791-4fd4-aeb3-598fa4faf4db@github.com>
 <ckVWsVK3EmbkP2Vc5GHn7RtRwg9-em0HFy_xwOXw5cA=.b3ce66d2-5491-45a6-8a87-75d98c699bb8@github.com>
Message-ID: <rpKPYqVAnuY5S8gUzOSExN0kiWEaJ6A3At1q57v0WIA=.38a477ee-12cf-49a7-aaa9-88ad4f834e13@github.com>

On Mon, 26 Sep 2022 01:39:41 GMT, Hao Sun <haosun at openjdk.org> wrote:

>> This warning seems to be a false positive, because 1) array "fq" with elements from index 0 to "jz" has already been initialized as "fw" at line 290 [1], and 2) variable "jz" should be non-negative from the comment at line 99 [2].
>> 
>> Note-1: GCC warning option -Wmaybe-uninitialized is not a new one. Note-2: x86-64 build with GCC 12 on Ubuntu 22.04 passed in my local test.
>> 
>> This warning is raised only on GCC 12 + AArch64. I suspect it might be some GCC 12 bug, so I reported it to GCC community [3].
>> 
>> Since it involves third party code, I think it's better to suppress the warning by simply disabling this warning option in the makefile.
>> 
>> Testing: Release builds with GCC 9, GCC 11 and GCC 12 passed on Ubuntu 22.04/AArch64 system.
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libfdlibm/k_rem_pio2.c#L290 
>> [2] https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libfdlibm/k_rem_pio2.c#L99 
>> [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106992
>
> Hao Sun 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:
> 
>  - Disable the warning option per file
>    
>    After JDK-8294281, we can disable the warning options per file.
>    
>    Testing: Release builds with GCC 9, GCC 11 and GCC 12 passed on Ubuntu
>    22.04/AArch64 system.
>  - Merge branch 'master' into 8293887-gcc12-fdlibm
>  - 8293887: AArch64 build failure with GCC 12 due to maybe-uninitialized warning in libfdlibm k_rem_pio2.c
>    
>    This warning seems to be a false positive, because 1) array "fq" with
>    elements from index 0 to "jz" has already been initialized as "fw" at
>    line 290 [1], and 2) variable "jz" should be non-negative from the
>    comment at line 99 [2].
>    
>    Note-1: GCC warning option -Wmaybe-uninitialized is not a new one.
>    Note-2: x86-64 build with GCC 12 on Ubuntu 22.04 passed in my local
>    test.
>    
>    This warning is raised only on GCC 12 + AArch64. I suspect it might be
>    some GCC 12 bug, so I reported it to GCC community [3].
>    
>    Since it involves third party code, I think it's better to suppress the
>    warning by simply disabling this warning option in the makefile.
>    
>    Testing: Release builds with GCC 9, GCC 11 and GCC 12 passed on Ubuntu
>    22.04/AArch64 system.
>    
>    [1] https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libfdlibm/k_rem_pio2.c#L290
>    [2] https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libfdlibm/k_rem_pio2.c#L99
>    [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106992

LGTM

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10386

From shade at openjdk.org  Mon Sep 26 13:25:17 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 26 Sep 2022 13:25:17 GMT
Subject: RFR: 8292969: Bad Thread Utilization in ForkJoinPool
In-Reply-To: <QzRti_crUWUQZ6PTLo0V-9YjIF40v0RDkS0E_4-anSc=.a68d897f-ac2c-4060-994c-3fb8b39d988e@github.com>
References: <QzRti_crUWUQZ6PTLo0V-9YjIF40v0RDkS0E_4-anSc=.a68d897f-ac2c-4060-994c-3fb8b39d988e@github.com>
Message-ID: <zqmxz9kadoxjbQl3FfBhcp2VCa2ecczTohWrL2OQiDI=.caf04588-c7f0-481c-9fb5-bf5c25687ff7@github.com>

On Wed, 7 Sep 2022 12:44:11 GMT, Doug Lea <dl at openjdk.org> wrote:

> 8292969: This small change in signal propagation rules improves utilization when entry queues are resized,

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1842:

> 1840:                         signalWork();           // propagate at most twice/run
> 1841:                     w.topLevelExec(t, q);
> 1842:                     return src + (prevSrc << SWIDTH);

Are all of these values (`src`, `prevSrc`) less or equal `0x7FFF`? Otherwise we are playing with sign bits here.

-------------

PR: https://git.openjdk.org/jdk/pull/10198

From shade at openjdk.org  Mon Sep 26 13:34:24 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 26 Sep 2022 13:34:24 GMT
Subject: RFR: 8292969: Bad Thread Utilization in ForkJoinPool
In-Reply-To: <QzRti_crUWUQZ6PTLo0V-9YjIF40v0RDkS0E_4-anSc=.a68d897f-ac2c-4060-994c-3fb8b39d988e@github.com>
References: <QzRti_crUWUQZ6PTLo0V-9YjIF40v0RDkS0E_4-anSc=.a68d897f-ac2c-4060-994c-3fb8b39d988e@github.com>
Message-ID: <DsKASvst_gh6JAZKaT92qIgUvuHWyWMdvwl9ap1BmDY=.bdd8b403-003d-4581-85bc-c6761d7c1079@github.com>

On Wed, 7 Sep 2022 12:44:11 GMT, Doug Lea <dl at openjdk.org> wrote:

> 8292969: This small change in signal propagation rules improves utilization when entry queues are resized,

Marked as reviewed by shade (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10198

From dl at openjdk.org  Mon Sep 26 13:34:27 2022
From: dl at openjdk.org (Doug Lea)
Date: Mon, 26 Sep 2022 13:34:27 GMT
Subject: RFR: 8292969: Bad Thread Utilization in ForkJoinPool
In-Reply-To: <zqmxz9kadoxjbQl3FfBhcp2VCa2ecczTohWrL2OQiDI=.caf04588-c7f0-481c-9fb5-bf5c25687ff7@github.com>
References: <QzRti_crUWUQZ6PTLo0V-9YjIF40v0RDkS0E_4-anSc=.a68d897f-ac2c-4060-994c-3fb8b39d988e@github.com>
 <zqmxz9kadoxjbQl3FfBhcp2VCa2ecczTohWrL2OQiDI=.caf04588-c7f0-481c-9fb5-bf5c25687ff7@github.com>
Message-ID: <TsN23RHf_BFAPX_9Cudm6l2zVdx6LIxwwkPgj2rIkGs=.cf1853b9-d93a-4fe8-ae56-de7851d376b0@github.com>

On Mon, 26 Sep 2022 13:21:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> 8292969: This small change in signal propagation rules improves utilization when entry queues are resized,
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1842:
> 
>> 1840:                         signalWork();           // propagate at most twice/run
>> 1841:                     w.topLevelExec(t, q);
>> 1842:                     return src + (prevSrc << SWIDTH);
> 
> Are all of these values (`src`, `prevSrc`) less or equal `0x7FFF`? Otherwise we are playing with sign bits here.

Yes, see the discussions around line 391 of internal docs.

-------------

PR: https://git.openjdk.org/jdk/pull/10198

From shade at openjdk.org  Mon Sep 26 13:34:27 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 26 Sep 2022 13:34:27 GMT
Subject: RFR: 8292969: Bad Thread Utilization in ForkJoinPool
In-Reply-To: <TsN23RHf_BFAPX_9Cudm6l2zVdx6LIxwwkPgj2rIkGs=.cf1853b9-d93a-4fe8-ae56-de7851d376b0@github.com>
References: <QzRti_crUWUQZ6PTLo0V-9YjIF40v0RDkS0E_4-anSc=.a68d897f-ac2c-4060-994c-3fb8b39d988e@github.com>
 <zqmxz9kadoxjbQl3FfBhcp2VCa2ecczTohWrL2OQiDI=.caf04588-c7f0-481c-9fb5-bf5c25687ff7@github.com>
 <TsN23RHf_BFAPX_9Cudm6l2zVdx6LIxwwkPgj2rIkGs=.cf1853b9-d93a-4fe8-ae56-de7851d376b0@github.com>
Message-ID: <J4bmsiQGIhMB7QCo2gQjhQtl-2Lr7jaMNLtbSRr2h_M=.bdb317be-7f8f-4ca7-979b-9114ccaf0ade@github.com>

On Mon, 26 Sep 2022 13:29:51 GMT, Doug Lea <dl at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1842:
>> 
>>> 1840:                         signalWork();           // propagate at most twice/run
>>> 1841:                     w.topLevelExec(t, q);
>>> 1842:                     return src + (prevSrc << SWIDTH);
>> 
>> Are all of these values (`src`, `prevSrc`) less or equal `0x7FFF`? Otherwise we are playing with sign bits here.
>
> Yes, see the discussions around line 391 of internal docs.

Ah, all right then.

-------------

PR: https://git.openjdk.org/jdk/pull/10198

From jlaskey at openjdk.org  Mon Sep 26 13:45:26 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 26 Sep 2022 13:45:26 GMT
Subject: RFR: 8293567: AbstractSplittableWithBrineGenerator: salt has
 digits that duplicate the marker
In-Reply-To: <cc1EW7QQpAv3nrKfgTDc-5EzhkGzgp6iHlhbk0-KknM=.b326cd49-179b-4b59-afbe-9bffb8610e9a@github.com>
References: <cc1EW7QQpAv3nrKfgTDc-5EzhkGzgp6iHlhbk0-KknM=.b326cd49-179b-4b59-afbe-9bffb8610e9a@github.com>
Message-ID: <Tq9a3LyTry0QvKKuMjhD-THbWwdDMRSkkAwtN69K-2I=.5a0e7e6c-ad18-4b83-a911-3d8fc3a33307@github.com>

On Mon, 19 Sep 2022 15:32:34 GMT, Raffaello Giulietti <duke at openjdk.org> wrote:

> 8293567: AbstractSplittableWithBrineGenerator: salt has digits that duplicate the marker

Marked as reviewed by jlaskey (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10345

From alanb at openjdk.org  Mon Sep 26 13:48:18 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 Sep 2022 13:48:18 GMT
Subject: RFR: 8292969: Bad Thread Utilization in ForkJoinPool
In-Reply-To: <QzRti_crUWUQZ6PTLo0V-9YjIF40v0RDkS0E_4-anSc=.a68d897f-ac2c-4060-994c-3fb8b39d988e@github.com>
References: <QzRti_crUWUQZ6PTLo0V-9YjIF40v0RDkS0E_4-anSc=.a68d897f-ac2c-4060-994c-3fb8b39d988e@github.com>
Message-ID: <SuAWOEceVbj06n16iitq0YojxM2b6vRTkZAaTmfnsoU=.05862d3e-25d3-4c10-b1d1-d3d65b54f634@github.com>

On Wed, 7 Sep 2022 12:44:11 GMT, Doug Lea <dl at openjdk.org> wrote:

> 8292969: This small change in signal propagation rules improves utilization when entry queues are resized,

I've been testing with this change for some time and it has worked well.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10198

From fyang at openjdk.org  Mon Sep 26 14:25:21 2022
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 26 Sep 2022 14:25:21 GMT
Subject: RFR: 8294198: Implement isFinite intrinsic for RISC-V
In-Reply-To: <R4tlj4gD-vO5BzJKgAx9-O4s7BD7q6NlLhMhl6PMUuc=.c67bb8fb-3bf1-4035-be21-cc873220bf70@github.com>
References: <R4tlj4gD-vO5BzJKgAx9-O4s7BD7q6NlLhMhl6PMUuc=.c67bb8fb-3bf1-4035-be21-cc873220bf70@github.com>
Message-ID: <wQ4SFSUbIykH6UatJMYIp8dl7snwwRnDqU1jVfB6XIg=.22a50d63-94c5-46f5-89a9-e2439b7a555b@github.com>

On Thu, 22 Sep 2022 12:56:49 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

> Unlike on x86 (see 8285868 and the discussion in review), isFinite intrinsic turned out to be profitable on RISC-V using the same fclass instruction as for 8293695 (isInfinite instrinsic). Therefore, I'm proposing to have it added on RISC-V in this PR.
> 
> benchmark results:
> 
> before:
> 
> Benchmark                              Mode  Cnt   Score   Error  Units
> DoubleClassCheck.testIsFiniteBranch    avgt   15  52.824 ? 1.744  ns/op
> DoubleClassCheck.testIsFiniteCMov      avgt   15  16.104 ? 0.358  ns/op
> DoubleClassCheck.testIsFiniteStore     avgt   15  14.366 ? 2.174  ns/op
> FloatClassCheck.testIsFiniteBranch     avgt   15  49.821 ? 0.330  ns/op
> FloatClassCheck.testIsFiniteCMov       avgt   15  14.702 ? 0.335  ns/op
> FloatClassCheck.testIsFiniteStore      avgt   15  14.749 ? 0.496  ns/op
> 
> after:
> 
> DoubleClassCheck.testIsFiniteBranch    avgt   15  48.921 ? 0.557  ns/op
> DoubleClassCheck.testIsFiniteCMov      avgt   15  13.716 ? 0.304  ns/op
> DoubleClassCheck.testIsFiniteStore     avgt   15   9.152 ? 0.158  ns/op
> FloatClassCheck.testIsFiniteBranch     avgt   15  47.740 ? 2.028  ns/op
> FloatClassCheck.testIsFiniteCMov       avgt   15  13.299 ? 0.282  ns/op
> FloatClassCheck.testIsFiniteStore      avgt   15   9.185 ? 0.396  ns/op
> 
> Existing isInfinite jtreg test was altered to be able to use common code for isFinite test and fine-grained requires tag filtering. Existing benchmark was modified to include isFinite case. A typo ("Atleast" -> "At least") was fixed on the way.
> 
> Test passed on both release and fastdebug builds. Hotspot tier1 tests were run on x86_64 and RISC-V with no issues.

I find the cause of the fluctuations for 'testIsFiniteBranch' lies in randomness of the input.

    @Benchmark
    @OperationsPerInvocation(BUFFER_SIZE)
    public void testIsFiniteBranch() {
        for (int i = 0; i < BUFFER_SIZE; i++) {
            cmovOutputs[i] = Float.isFinite(inputs[i]) ? call() : 7;
        }
    }

Here the C2 JIT code for invoking 'call()' has changed with this patch. The register allocation is
different and hence the difference of saving and restoring of live registers around the method call. So the probability of invoking this method call will affect the JMH result, which is not the case for the other two JMH tests.

For the other two JMH tests, I see the performance gain on SiFive platform comes from C2 loop unrolling. Since your change benefit the other two JMH tests on both SiFive and C906 platforms, looks good to me.

-------------

Marked as reviewed by fyang (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10391

From rriggs at openjdk.org  Mon Sep 26 15:03:21 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 26 Sep 2022 15:03:21 GMT
Subject: RFR: 8294361: Cleanup usages of StringBuffer in SQLOutputImpl
In-Reply-To: <q_2V_qZS-UHRrwlkokVHntWAjO1XwAxvle5UxkXvK2Q=.e07e382a-efe9-4ff5-80e3-7022100314d5@github.com>
References: <q_2V_qZS-UHRrwlkokVHntWAjO1XwAxvle5UxkXvK2Q=.e07e382a-efe9-4ff5-80e3-7022100314d5@github.com>
Message-ID: <LPX0QI0s79mhtcHEZkhdi15lcd5JzLOT35SOZ5uEWQA=.5fdd25d2-bd7b-49c8-bb2a-59b47ea5d447@github.com>

On Sat, 17 Sep 2022 21:43:04 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There a few unnecessary usages of StringBuffer in SQLOutputImpl class.
> All of them create StringBuffer from single character and then concatenate with String. Instead of this, we can concatenate character directly.

src/java.sql.rowset/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java line 328:

> 326:         try {
> 327:             int i;
> 328:             while ((i = bufReader.read()) != -1) {

Is the single character read really necessary?
BufferedReader.readLine() returns null on EOF.
It seems plausable that only the readLine and writeString are needed in the loop.

Similarly, for the read loops below for InputStreams and binary stream.
The BufferedReader and readline can be used for the binary streams by constructing with the ASCII Charset.

-------------

PR: https://git.openjdk.org/jdk/pull/10320

From ihse at openjdk.org  Mon Sep 26 15:38:21 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 Sep 2022 15:38:21 GMT
Subject: RFR: 8294376: Minimize disabled warnings in java.base
Message-ID: <R7_lfTjzEBkN-TAZxMd75nnuJ2_ZwAJfcqq-Z1Erhk0=.2aa5ecbd-14bb-4808-9087-21d084c77f8a@github.com>

After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in java.base native libraries.

Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.

Some warnings didn't trigger in any file anymore, and could just be removed.

-------------

Commit messages:
 - Fixes for linux
 - Fix windows
 - Fix macos/aarch64

Changes: https://git.openjdk.org/jdk/pull/10426/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10426&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294376
  Stats: 26 lines in 2 files changed: 9 ins; 4 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/10426.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10426/head:pull/10426

PR: https://git.openjdk.org/jdk/pull/10426

From jwaters at openjdk.org  Mon Sep 26 15:38:52 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 26 Sep 2022 15:38:52 GMT
Subject: RFR: 8292016: Split Windows API error handling from errors passed
 through the runtime in the JDK [v21]
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <fBElB0AKfPc8ebC_4Yl_ipc1deFvDHcoSGOigFHBfQ8=.523a682e-5b40-4f19-a233-c43e72de242a@github.com>

> Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time 
> 
> Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future.

Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  Split Windows API error handling from errors passed through the runtime

-------------

Changes: https://git.openjdk.org/jdk/pull/9870/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=20
  Stats: 160 lines in 14 files changed: 67 ins; 33 del; 60 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From jwaters at openjdk.org  Mon Sep 26 15:47:51 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 26 Sep 2022 15:47:51 GMT
Subject: RFR: 8292016: Split Windows API error handling from errors passed
 through the runtime in the JDK [v22]
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <S3foO_lw8Qp5f1NosQ8cx1v96miI57hdDTQ4FIOlYbo=.26b894ca-3505-46e9-9c43-d381e2d4e1bc@github.com>

> Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time 
> 
> Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9870/files
  - new: https://git.openjdk.org/jdk/pull/9870/files/43744e90..622af5c6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=20-21

  Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From rgiulietti at openjdk.org  Mon Sep 26 15:50:57 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 26 Sep 2022 15:50:57 GMT
Subject: Integrated: 8293567: AbstractSplittableWithBrineGenerator: salt has
 digits that duplicate the marker
In-Reply-To: <cc1EW7QQpAv3nrKfgTDc-5EzhkGzgp6iHlhbk0-KknM=.b326cd49-179b-4b59-afbe-9bffb8610e9a@github.com>
References: <cc1EW7QQpAv3nrKfgTDc-5EzhkGzgp6iHlhbk0-KknM=.b326cd49-179b-4b59-afbe-9bffb8610e9a@github.com>
Message-ID: <88zAfe2Y2bsIBE2Dab-n-s_kdiMvH9BWHcEde5qC7I0=.9233ced5-02a4-45a7-be28-53e88347b8cd@github.com>

On Mon, 19 Sep 2022 15:32:34 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> 8293567: AbstractSplittableWithBrineGenerator: salt has digits that duplicate the marker

This pull request has now been integrated.

Changeset: 968af74d
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/968af74de4307a05e45f0bee32fa9120e39faf09
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8293567: AbstractSplittableWithBrineGenerator: salt has digits that duplicate the marker

Reviewed-by: jlaskey

-------------

PR: https://git.openjdk.org/jdk/pull/10345

From rriggs at openjdk.org  Mon Sep 26 15:55:52 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 26 Sep 2022 15:55:52 GMT
Subject: RFR: 8234262: Unmask SIGQUIT in a child process [v4]
In-Reply-To: <QhoJ88tNkPq3N9ybNwnEEHnpPPiFfwhVtXqMTtRGk1o=.ab0b8831-16a1-4802-8730-708da809349e@github.com>
References: <QhoJ88tNkPq3N9ybNwnEEHnpPPiFfwhVtXqMTtRGk1o=.ab0b8831-16a1-4802-8730-708da809349e@github.com>
Message-ID: <Zg56WZEwR2V9cFGsaAxGl2_DwDbMvQnh3fp8Zcj6pQs=.75970bde-304b-4248-b6f7-8408a407c63b@github.com>

> Clear the signal mask of the child when launching with posix_spawn.
> 
> SIGQUIT signals are handled on non-Java Threads by the VM.
> For Java threads the signal mask blocks SIGQUIT.  
> The ProcessBuilder uses posix_spawn on all platforms to create new processes.
> Without a specific request, the child process inherits the signal masks from the parent.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Remove unnecessary java.lang imports

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10379/files
  - new: https://git.openjdk.org/jdk/pull/10379/files/dc56e0d8..727b0b2a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10379&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10379&range=02-03

  Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10379.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10379/head:pull/10379

PR: https://git.openjdk.org/jdk/pull/10379

From rriggs at openjdk.org  Mon Sep 26 15:58:38 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 26 Sep 2022 15:58:38 GMT
Subject: Integrated: 8234262: Unmask SIGQUIT in a child process
In-Reply-To: <QhoJ88tNkPq3N9ybNwnEEHnpPPiFfwhVtXqMTtRGk1o=.ab0b8831-16a1-4802-8730-708da809349e@github.com>
References: <QhoJ88tNkPq3N9ybNwnEEHnpPPiFfwhVtXqMTtRGk1o=.ab0b8831-16a1-4802-8730-708da809349e@github.com>
Message-ID: <N29VhoKiFD_ycEQkm-9fmstTIN8STSROcYv0ncRwzxY=.9df1fd6d-b232-494e-b543-7deda568d466@github.com>

On Wed, 21 Sep 2022 20:30:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Clear the signal mask of the child when launching with posix_spawn.
> 
> SIGQUIT signals are handled on non-Java Threads by the VM.
> For Java threads the signal mask blocks SIGQUIT.  
> The ProcessBuilder uses posix_spawn on all platforms to create new processes.
> Without a specific request, the child process inherits the signal masks from the parent.

This pull request has now been integrated.

Changeset: 5ae6bc23
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5ae6bc23e857535532b59aae674e2b917bbf7284
Stats:     60 lines in 3 files changed: 59 ins; 1 del; 0 mod

8234262: Unmask SIGQUIT in a child process

Reviewed-by: bpb, dholmes, vtewari, stuefe, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/10379

From aturbanov at openjdk.org  Mon Sep 26 16:12:19 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 26 Sep 2022 16:12:19 GMT
Subject: RFR: 8294361: Cleanup usages of StringBuffer in SQLOutputImpl
In-Reply-To: <LPX0QI0s79mhtcHEZkhdi15lcd5JzLOT35SOZ5uEWQA=.5fdd25d2-bd7b-49c8-bb2a-59b47ea5d447@github.com>
References: <q_2V_qZS-UHRrwlkokVHntWAjO1XwAxvle5UxkXvK2Q=.e07e382a-efe9-4ff5-80e3-7022100314d5@github.com>
 <LPX0QI0s79mhtcHEZkhdi15lcd5JzLOT35SOZ5uEWQA=.5fdd25d2-bd7b-49c8-bb2a-59b47ea5d447@github.com>
Message-ID: <B7lU1t0KzkHel_gbmrkUz1GMFa7373KA217RQXgwxa0=.7163d803-98ab-4a5d-8791-11b72936e387@github.com>

On Mon, 26 Sep 2022 14:53:24 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> There a few unnecessary usages of StringBuffer in SQLOutputImpl class.
>> All of them create StringBuffer from single character and then concatenate with String. Instead of this, we can concatenate character directly.
>
> src/java.sql.rowset/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java line 328:
> 
>> 326:         try {
>> 327:             int i;
>> 328:             while ((i = bufReader.read()) != -1) {
> 
> Is the single character read really necessary?
> BufferedReader.readLine() returns null on EOF.
> It seems plausable that only the readLine and writeString are needed in the loop.
> 
> Similarly, for the read loops below for InputStreams and binary stream.
> The BufferedReader and readline can be used for the binary streams by constructing with the ASCII Charset.

If this single character is `\n`, then direct replacing with `readLine` would change behavior of the method.

-------------

PR: https://git.openjdk.org/jdk/pull/10320

From joehw at openjdk.org  Mon Sep 26 16:16:34 2022
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 26 Sep 2022 16:16:34 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
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: <pGtnJ74g_UpsFiU5TaZ6E9jk1p0koWYtWUaoecRoxxk=.e98efc77-50d4-4959-a289-23e6a54380b8@github.com>

On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

We have discussed several times in the past that we don't touch upstream (in this case, Apache) code unless the change is essential. In general, if you fix a bug in a class, it's fine to fix other non-essential things within the class, such as code styles, javadocs, typos as in this case, etc.  Otherwise, I would suggest you contribute such changes to the upstream projects.  Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From naoto at openjdk.org  Mon Sep 26 16:28:21 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 26 Sep 2022 16:28:21 GMT
Subject: RFR: 8289797: tools/launcher/I18NArgTest.java fails on Japanese
 Windows environment [v6]
In-Reply-To: <GJ_UOC5wgFeegmrbrsUPo1VeaFWDELQwkUZMv_CGVJo=.ff7721d2-c80c-4106-9dca-ca5c8140d104@github.com>
References: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
 <GJ_UOC5wgFeegmrbrsUPo1VeaFWDELQwkUZMv_CGVJo=.ff7721d2-c80c-4106-9dca-ca5c8140d104@github.com>
Message-ID: <Kp_wtPAgXKa12VIwJt5bxUzoArDcUGWEdDhA-3Emm8E=.0a8678a9-1334-49d5-93b2-d8f2280fa80b@github.com>

On Mon, 26 Sep 2022 08:07:50 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

>> I removed a section of via JDK_JAVA_OPTIONS because including main class is not allowed in the specification.
>> This behavior is added in JDK-8170832, which add JAVA_OPTIONS environment variable. At this time, this test is mismatch with the specification.
>> I tried to test and get Passed on Japanese Windows environment.
>> Could you review this fix, please?
>
> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8289797: tools/launcher/I18NArgTest.java fails on Japanese Windows environment

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9389

From erikj at openjdk.org  Mon Sep 26 16:32:22 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 26 Sep 2022 16:32:22 GMT
Subject: RFR: 8294376: Minimize disabled warnings in java.base
In-Reply-To: <R7_lfTjzEBkN-TAZxMd75nnuJ2_ZwAJfcqq-Z1Erhk0=.2aa5ecbd-14bb-4808-9087-21d084c77f8a@github.com>
References: <R7_lfTjzEBkN-TAZxMd75nnuJ2_ZwAJfcqq-Z1Erhk0=.2aa5ecbd-14bb-4808-9087-21d084c77f8a@github.com>
Message-ID: <XVTTiLPrCILQMTMOVvdIzGVxNAD5_seXtxzmc7FRsZo=.744ffbfe-2d72-44c1-ad5d-33c1c4ec6bae@github.com>

On Mon, 26 Sep 2022 15:31:53 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in java.base native libraries.
> 
> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.
> 
> Some warnings didn't trigger in any file anymore, and could just be removed.

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10426

From naoto at openjdk.org  Mon Sep 26 16:37:33 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 26 Sep 2022 16:37:33 GMT
Subject: RFR: 8294317: Insufficient build rules for tzdb.dat [v2]
In-Reply-To: <WS7j8PLGWmQXKydFbhYDSic55ECn9p40NdRIcS7TRHs=.43ced95c-1843-4d3b-9cb1-d526618e0678@github.com>
References: <WS7j8PLGWmQXKydFbhYDSic55ECn9p40NdRIcS7TRHs=.43ced95c-1843-4d3b-9cb1-d526618e0678@github.com>
Message-ID: <-ipAVj6BgGHIPHV45qV9zdGJsj8SiGAZ2Oybv7TD1RY=.5135fa0e-8a35-437d-88fa-9e55764da02f@github.com>

> The current makefile for `tzdb.dat` won't recompile if some dependent files (e.g. `VERSION`) are updated. Adding all files under the tzdb directory to the dependency will fix this issue.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Use wildcard function

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10415/files
  - new: https://git.openjdk.org/jdk/pull/10415/files/8e260f28..a1687575

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10415&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10415&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10415.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10415/head:pull/10415

PR: https://git.openjdk.org/jdk/pull/10415

From naoto at openjdk.org  Mon Sep 26 16:37:34 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 26 Sep 2022 16:37:34 GMT
Subject: RFR: 8294317: Insufficient build rules for tzdb.dat [v2]
In-Reply-To: <9BNVIgTyNGZTEEiPrMeHBaDnSjfna0vPNx3uUy4MPac=.9227bda9-2a69-4ed8-adb8-0a49451569a1@github.com>
References: <WS7j8PLGWmQXKydFbhYDSic55ECn9p40NdRIcS7TRHs=.43ced95c-1843-4d3b-9cb1-d526618e0678@github.com>
 <9BNVIgTyNGZTEEiPrMeHBaDnSjfna0vPNx3uUy4MPac=.9227bda9-2a69-4ed8-adb8-0a49451569a1@github.com>
Message-ID: <Ijwa2WfHaQErPkzjIEz1vyyDvaTYq-2hSHYViD3E4j8=.f1f5a71c-ec50-4a45-aa22-aaa2f336377c@github.com>

On Mon, 26 Sep 2022 12:53:49 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use wildcard function
>
> make/modules/java.base/gendata/GendataTZDB.gmk line 33:
> 
>> 31: TZDATA_DIR := $(MODULE_SRC)/share/data/tzdata
>> 32: TZDATA_TZFILE := africa antarctica asia australasia europe northamerica southamerica backward etcetera gmt jdk11_backward
>> 33: TZDATA_TZFILES := $(TZDATA_DIR)/*
> 
> Have you verified that this works? I would expect a wildcard call to be needed. 
> Suggestion:
> 
> TZDATA_TZFILES := $(wildcard $(TZDATA_DIR)/*)

I confirmed the fix worked, on my local mac and mach5. However, your suggestion does seem the right way. Modified the fix as suggested.

-------------

PR: https://git.openjdk.org/jdk/pull/10415

From mernst at openjdk.org  Mon Sep 26 16:51:36 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Mon, 26 Sep 2022 16:51:36 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
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: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@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 six commits:

 - 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=01
  Stats: 85 lines in 76 files changed: 0 ins; 0 del; 85 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 joehw at openjdk.org  Mon Sep 26 17:04:25 2022
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 26 Sep 2022 17:04:25 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <tTqHK2uU740KHuTMKapHnLcgfUbNs-4NqM-tQpds9HQ=.ba0b289d-011f-4f84-beeb-e20dd15a7d67@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 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 six commits:
> 
>  - 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

Thanks for the update!

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From shade at openjdk.org  Mon Sep 26 17:07:17 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 26 Sep 2022 17:07:17 GMT
Subject: RFR: 8294376: Minimize disabled warnings in java.base
In-Reply-To: <R7_lfTjzEBkN-TAZxMd75nnuJ2_ZwAJfcqq-Z1Erhk0=.2aa5ecbd-14bb-4808-9087-21d084c77f8a@github.com>
References: <R7_lfTjzEBkN-TAZxMd75nnuJ2_ZwAJfcqq-Z1Erhk0=.2aa5ecbd-14bb-4808-9087-21d084c77f8a@github.com>
Message-ID: <0R2PwBaaBOUMBU-Po3uIlwg5CeIxiixdmMAuQaGRoXg=.bbaab7fa-9696-456a-8a0f-2428374f0799@github.com>

On Mon, 26 Sep 2022 15:31:53 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in java.base native libraries.
> 
> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.
> 
> Some warnings didn't trigger in any file anymore, and could just be removed.

Hold on, I'll test these on various Linux-es.

-------------

PR: https://git.openjdk.org/jdk/pull/10426

From duke at openjdk.org  Mon Sep 26 17:10:27 2022
From: duke at openjdk.org (Aryan Patil)
Date: Mon, 26 Sep 2022 17:10:27 GMT
Subject: RFR: 8294198: Implement isFinite intrinsic for RISC-V
In-Reply-To: <R4tlj4gD-vO5BzJKgAx9-O4s7BD7q6NlLhMhl6PMUuc=.c67bb8fb-3bf1-4035-be21-cc873220bf70@github.com>
References: <R4tlj4gD-vO5BzJKgAx9-O4s7BD7q6NlLhMhl6PMUuc=.c67bb8fb-3bf1-4035-be21-cc873220bf70@github.com>
Message-ID: <m7aZ0tfhZgOoKNjX8xHwo_rafDjPY7VugmrV69nLD6c=.f402e6b6-87fe-4a6a-aaff-dac69c11b90a@github.com>

On Thu, 22 Sep 2022 12:56:49 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

> Unlike on x86 (see 8285868 and the discussion in review), isFinite intrinsic turned out to be profitable on RISC-V using the same fclass instruction as for 8293695 (isInfinite instrinsic). Therefore, I'm proposing to have it added on RISC-V in this PR.
> 
> benchmark results:
> 
> before:
> 
> Benchmark                              Mode  Cnt   Score   Error  Units
> DoubleClassCheck.testIsFiniteBranch    avgt   15  52.824 ? 1.744  ns/op
> DoubleClassCheck.testIsFiniteCMov      avgt   15  16.104 ? 0.358  ns/op
> DoubleClassCheck.testIsFiniteStore     avgt   15  14.366 ? 2.174  ns/op
> FloatClassCheck.testIsFiniteBranch     avgt   15  49.821 ? 0.330  ns/op
> FloatClassCheck.testIsFiniteCMov       avgt   15  14.702 ? 0.335  ns/op
> FloatClassCheck.testIsFiniteStore      avgt   15  14.749 ? 0.496  ns/op
> 
> after:
> 
> DoubleClassCheck.testIsFiniteBranch    avgt   15  48.921 ? 0.557  ns/op
> DoubleClassCheck.testIsFiniteCMov      avgt   15  13.716 ? 0.304  ns/op
> DoubleClassCheck.testIsFiniteStore     avgt   15   9.152 ? 0.158  ns/op
> FloatClassCheck.testIsFiniteBranch     avgt   15  47.740 ? 2.028  ns/op
> FloatClassCheck.testIsFiniteCMov       avgt   15  13.299 ? 0.282  ns/op
> FloatClassCheck.testIsFiniteStore      avgt   15   9.185 ? 0.396  ns/op
> 
> Existing isInfinite jtreg test was altered to be able to use common code for isFinite test and fine-grained requires tag filtering. Existing benchmark was modified to include isFinite case. A typo ("Atleast" -> "At least") was fixed on the way.
> 
> Test passed on both release and fastdebug builds. Hotspot tier1 tests were run on x86_64 and RISC-V with no issues.

LGTM

-------------

Marked as reviewed by AryanP45 at github.com (no known OpenJDK username).

PR: https://git.openjdk.org/jdk/pull/10391

From ihse at openjdk.org  Mon Sep 26 18:18:19 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 Sep 2022 18:18:19 GMT
Subject: RFR: 8294376: Minimize disabled warnings in java.base
In-Reply-To: <0R2PwBaaBOUMBU-Po3uIlwg5CeIxiixdmMAuQaGRoXg=.bbaab7fa-9696-456a-8a0f-2428374f0799@github.com>
References: <R7_lfTjzEBkN-TAZxMd75nnuJ2_ZwAJfcqq-Z1Erhk0=.2aa5ecbd-14bb-4808-9087-21d084c77f8a@github.com>
 <0R2PwBaaBOUMBU-Po3uIlwg5CeIxiixdmMAuQaGRoXg=.bbaab7fa-9696-456a-8a0f-2428374f0799@github.com>
Message-ID: <flrMwBRZS7huGNhF7V5w3eb5Drn-DhxcnyNwwOhrAHA=.1e41c994-5706-4be7-8c92-5e6f40b384f2@github.com>

On Mon, 26 Sep 2022 17:03:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in java.base native libraries.
>> 
>> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.
>> 
>> Some warnings didn't trigger in any file anymore, and could just be removed.
>
> Hold on, I'll test these on various Linux-es.

@shipilev Thanks. I will also wait for someone from core-libs to chime in.

-------------

PR: https://git.openjdk.org/jdk/pull/10426

From dsamersoff at openjdk.org  Mon Sep 26 18:21:59 2022
From: dsamersoff at openjdk.org (Dmitry Samersoff)
Date: Mon, 26 Sep 2022 18:21:59 GMT
Subject: RFR: 8293806: JDK_JAVA_OPTIONS picked up twice if LD_LIBRARY_PATH is
 set
Message-ID: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>

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.

-------------

Commit messages:
 - 8293806: JDK_JAVA_OPTIONS picked up twice if LD_LIBRARY_PATH is set

Changes: https://git.openjdk.org/jdk/pull/10430/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10430&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293806
  Stats: 35 lines in 8 files changed: 11 ins; 12 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/10430.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10430/head:pull/10430

PR: https://git.openjdk.org/jdk/pull/10430

From errael at raelity.com  Mon Sep 26 18:31:34 2022
From: errael at raelity.com (Ernie Rael)
Date: Mon, 26 Sep 2022 11:31:34 -0700
Subject: Sequenced Collections
In-Reply-To: <44ff182d-f251-e62f-9560-a7e8d325187e@oracle.com>
References: <f6edafc8-03f1-4f3a-1382-592688785c6e@raelity.com>
 <06ca6cc9-4d35-e327-5d03-2378302f72dd@gmail.com>
 <024fe055-c94e-94e2-cf21-bca828304929@raelity.com>
 <44ff182d-f251-e62f-9560-a7e8d325187e@oracle.com>
Message-ID: <c2dbf1a8-c772-0568-f428-8b0b71557818@raelity.com>

A SequencedCollection listIterator() is missed; it's useful for 
List.equals, or to implement a List in general. LinkedHashSet seems 
incomplete without it. Even something like "ListIterator 
Collections.forwardListIterator(int index, iterator)", if compatible 
with equals() of the various list types, would be handy. Doesn't forward 
only work for sublist?. Only traversal, optional modification. 
Modification is tricky; an add might have an implicit remove for a Set. 
If not part of SequencedCollection, maybe "interface 
ListIteratorProvider { ListIterator listIterator(int index); }" to tag 
as needed.

This message is primarily about "definition of change and equals" and 
"pluggable eviction policy"; they're discussed through a simple MRU 
example implemented with a SequencedSet and a capacity limit. The 
'changed' concept comes from Collection<>.

// MRU implementation recommendations:
//????? - implement List<> for equals
//????? - modifications only permitted through direct MRU methods
public interface MRU<E> extends Collection<E> {
 ??? boolean addItem(E key);??????? // return changed
 ??? boolean removeItem(E key);???? // remove(E) contract
 ??? boolean setCapacity(int size); // return changed
 ??? int getCapacity();
 ??? void clear();
 ??? boolean addAll(Collection< ? extends E> c);
 ??? public static <E> MRU<E> synchronizedMRU(MRU<E> mru) {...}
}

To check out SequencedCollection I sketched out an implementation of 
MRU, see below. Currently I have two implementations based on LinkedList 
and LinkedHashSet, each has some ugly stuff. The implementation based on 
SequencedSet below is clean. All the MRU methods are easily implemented 
without consideration of the actual implementation, but AddAll() is 
problematic. removeItem() is included to allow external EvictionPolicy.

Is there a preferred direction for performance? I'm guessing the only 
difference might be going through a "reversed()" view.

Definition of "change" and "equals()" in a SequencedCollection
==============================================================
The SequencedCollection uses "void addFirst(e)", there's no indication 
if the collection is changed; this is the only place I'm aware of in the 
Collections universe where a functional add operation does not indicate 
changed when it may or may not change the collection (I didn't look, 
just guessing). List and Set both have "changed" consistent with their 
"equals()".

Consistent with List equals, the MRU addItem() implementation returns 
changed true if either sequence or content changed.

The MRU implementation as shown may have an inaccurate return from 
addAll(); it's possible that "changed == true && before.equals(after)". 
Collection specifies the addAll() return. It's expensive to produce an 
accurate result from addAll(). I suppose it could be argued that the 
definition of changed is ambiguous in this case. Document that AddAll() 
may return a false positive.

Thinking out loud... In SequencedSet a method getChanged() returning an 
EnumSet with SEQUENCE_CHANGED, CONTENTS_CHANGED bits. Could 
automatically clear the bits on every operation or require an explicit 
call to clear the bits. This wouldn't help the addAll() problem, but 
supports a workaround for addFirst/addLast.

pluggable Eviction Policy
=========================
In my earlier message, when I shifted to refer to an eviction policy, I 
acknowledge that even a simple builtin policy was inappropriate. While 
this thread may not be the best place to discuss it, I'll make this 
comment here; can start another thread if there's reason.

It's tricky to extend a Collection and implement an Eviction Policy 
without support from the collection. For example, if there are several 
ways to add to the collection, then in general each must be intercepted 
and handled. It may be that simply overriding add(E) is sufficient, but 
the source for the implementation must be examined for each 
implementation and on every release.

This suggests an "interface EvictionPolicy" (or EvictionPolicySupport) 
which, at a minimum, is invoked whenever the collection's size 
increases; could be invoked whenever the collection is modified. 
Something like an optional setEvictionPolicy(ep), or solely by 
implementation.

MRU implementation example
==========================

/** MRU SequenceSet implementation. Newest/mru at start of list */
public abstract class AbstractMRU<E>
extends AbstractSequentialList<E> implements MRU<E> {
 ??? protected final SequencedSet<E> seqset;
 ??? protected int capacity = Integer.MAX_VALUE;

 ??? public AbstractMRU(SequencedSet<E> c, int capacity) {
 ??????? this.seqset = c;
 ??????? setCapacity(capacity);
 ??? }

 ??? @Override public int size() { return seqset.size(); }
 ??? @Override public Iterator() { return seqset.iterator(); }
 ??? @Override public boolean addAll(Collection<? extends E> c) { 
addAllInFront(c); }
 ??? @Override public void clear() { seqset.clear(); }
 ??? @Override public boolean addItem(E key) {
 ??????? if(key == null)
 ??????????? throw new IllegalArgExcept();
 ??????? if(Objects.equals(key, peekMRU())) return false; // no change
 ??????? seqset.addFirst(key);
 ??????? evict();
 ??????? return true; // must have changed since not early return
 ??? }
 ??? @Override public boolean removeItem(E key) { return 
seqset.remove(key); }

 ??? @Override boolean setCapacity(int capacity) { // return changed
 ??????? if(capacity < 0)
 ??????????? throw new IllegalArgumentException("Size must be >= 0");
 ??????? this.capacity = capacity;
 ??????? return evict();
 ??? }
 ??? @Override public int getCapacity() { return capacity; }

 ??? protected E peekMRU() { return seqset.isEmpty ? null : 
seqset.getFirst(); }
 ??? protected boolean evict() { // return true if size changed
 ??????? int extra = size() - capacity;
 ??????? if(extra <= 0)
 ??????????? return false;
 ??????? while(--extra >= 0) seqset.removeLast();
 ??????? return true;
 ??? }
 ??? protectd abstract boolean addAllInFront(Collection<? extends E> c);
}

/**
 ?* Newest at the front of the list (opposite of LinkedHashset defaults).
 ?* This is not dependent on how SeqSet is implemented,
 ?* but just put it down here to get the mess out of the way.
 ?*/
public LinkedHashSetMRU<E> extends AbstractMRU<E> {
 ??? public LinkedHashSetMRU(int numElements) {
super(LinkedHashSet.newLinkedHashSet<E>(numElements), numElements);
 ??? }

 ??? protected boolean addAllInFront(Collection<? extends E> c) {
 ??????? // TODO: check null item
 ??????? boolean modified;
 ??????? if(c instanceof SequencedCollection sq) {
 ??????????? for(e : sq.reversed())
 ??????????????? modified |= seqset.addFirst(e);
 ??????? } else {
 ??????????? // lazy
 ??????????? for(e : new ArrayList(c).reversed())
 ??????????????? modified |= seqset.addFirst(e);
 ??????? }
 ??????? return evict() || modified;
 ??? }

 ??? // TODO:??? implement ListIterator's iterator(index),
 ??? //????????? only forward iteration should be OK for equals.
 ??? // ListIterator listIterator(int index)
 ??? //???? { return Collections.forwardListIterator(index, 
seqset.iterator()); }

 ??? // Could handle equals for both List,Set.
 ??? // Just List equals seems OK. Use MRU.containsAll directly for Set 
equals.
 ??? @Override public boolean equals(Object o) {
 ??????? if (o == this)
 ??????????? return true;
 ??????? if (!(o instanceof List))
 ??????????? return false;
 ??????? Iterator<E> e1 = seqset.iterator();
 ??????? Iterator<?> e2 = ((List<?>) o).iterator();
 ??????? while (e1.hasNext() && e2.hasNext())
 ??????????? if(!Objects.equals(e1.next(), e2.next())
 ??????????????? return false;
 ??????? return !(e1.hasNext() || e2.hasNext());
 ??? }
}


On 9/21/22 5:38 PM, Stuart Marks wrote:
> Hi, yes, this is the right place to discuss Sequenced Collections. I'm 
> glad you find it promising.
>
> Note that Sequenced Collections actually has very little 
> implementation in it, aside from various reversed views of things. The 
> actual data is still stored in existing concrete collections such as 
> ArrayList, ArrayDeque, LinkedHashMap, and TreeMap.
>
> I think Sequenced Collections has the right set of abstractions in it 
> as it stands, and I don't want to expand its scope by talking about 
> additional concepts like size limits or eviction policy.
>
> However, those things are quite reasonable to discuss independently of 
> the current Sequenced Collections proposal. Having a maximum size on a 
> collection seems independent of sequencing. An eviction policy *might* 
> be based on the sequence, but it might not; consider the various 
> eviction policies available for a cache library such as Caffeine [1].
>
> [1] https://github.com/ben-manes/caffeine/wiki
>
> However, I'm somewhat skeptical of trying to build things like 
> eviction policies directly into collections. It's tempting to add a 
> simple thing like a size and just throw away things in some 
> well-defined order whenever the size is exceeded. The problem is that 
> if this policy doesn't do *exactly* what you want to do, then you're 
> out of luck.
>
> The current (pre Sequenced Collections) LinkedHashMap is a good 
> example of this. It's suitable for a least-recently-inserted 
> expiration policy; there's a method removeEldestEntry() that programs 
> can use to implement a simple policy, size-based or otherwise. 
> (Unfortunately they have to subclass-and-override, but whatever.) The 
> problem is that it allows removal of only one element -- the eldest 
> (first) element.
>
> If you want to change the policy of insertion order of an LHM, you 
> have only one alternative: access order. Enabling this has some weird 
> side effects though. For example, get() now rearranges the order of 
> entries in the map, and is thus a structural modification -- which 
> means that it spoils any iterators over the map's views.
>
> These are both fairly common cases, which is probably why they were 
> added. But they're not very flexible, and if you want to do something 
> slightly different, you're on your own -- and it's pretty hard to 
> implement your own policy, because LHM lacks a bunch of essential 
> operations.
>
> Where the Sequenced Collections proposal helps is that instead of 
> adding more policies, it adds the missing primitive operations. You 
> can add/get/remove at either end, and you can reposition mappings to 
> either end. If you have some different recent-usage policy or some 
> unusual cache eviction policy that I've never heard of, you can use 
> the primitives to implement it yourself. That's much better than 
> trying to bake a few more specific cases into LinkedHashMap or other 
> collections.
>
>> Is there a discussion about making the SynchronizedCollection family 
>> of classes public? 
>
> No. Synchronizing on every collection operation is the wrong level of 
> abstraction. Typical collection usage involves too much external 
> iteration and too much check-then-act logic. Callers would have to 
> wrap those in synchronized blocks, and in general they don't know when 
> that's necessary. Certain transaction-style operations (like 
> Map::computeIfAbsent) can be made to work, but those are all pretty 
> low level.
>
> s'marks
>
>
>
> On 9/21/22 9:32 AM, Ernie Rael wrote:
>> ?> I don't see why you think a general collection...
>>
>> I thought the Subject would be sufficient to indicate that I was not 
>> talking about collections in general. I should have been more precise 
>> with my words; guess I was just excited by a bi-directional ordered set.
>>
>> The MRU _example_ is useful; the current collections handle it poorly 
>> and Sequenced Collections is ideal. Caches with an eviction policy 
>> are common; I suspect caches will be a common use for SequencedSet 
>> family. Note there are fixed sized Collections and 
>> SequencedCollection borrows heavily from that family. Perhaps this 
>> issue should be considered in the context of adding an **Eviction 
>> Policy** to appropriate collections.
>>
>> MRU is a Collection; for example, I pass an MRU to a persistence 
>> mechanism that takes a collection. Saying "all methods offered by 
>> `Collection` should [not] even be part of an `MRU` interface" is 
>> innacurate, especially when considered in the context of a 
>> SequencedCollection.
>>
>> -ernie
>>
>> PS - Loosely related is extending a Collection and providing a 
>> synchronized version. Is there a discussion about making the 
>> SynchronizedCollection family of classes public?
>>
>>
>> On 9/21/22 4:22 AM, John Hendrikx wrote:
>>> I don't see why you think a general collection, that is in 99.9% of 
>>> the cases not used to implement an MRU, should burden every call to 
>>> #add with a check to see if it isn't exceeding its maximum size or 
>>> to see if a maximum size has been set.
>>>
>>> This is much better done by composition, as I don't think all 
>>> methods offered by `Collection` should even be part of an `MRU` 
>>> interface.
>>>
>>> --John
>>>
>>> On 20/09/2022 21:08, Ernie Rael wrote:
>>>> (There may be a better place to send this, let me know where)
>>>>
>>>> Suggesting an option to limit the size of the collection, e.g 
>>>> "setMaxSize(int)", default of zero means no limit.
>>>>
>>>> I put together "interface MRU<E> extends Collection<E>" some months 
>>>> ago, it has two implementations based on LinkedList and 
>>>> LinkedHashSet. The code can be seen at 
>>>> https://sourceforge.net/p/jvi/raelity-lib/ci/default/tree/lib/src/main/java/com/raelity/lib/ 
>>>>
>>>>
>>>> A SequencedCollection, as outlined in the JEP draft 2020/09/01, 
>>>> would be almost perfect to implement MRU; I've run into most of the 
>>>> problems/issues discussed in the JEP draft.
>>>>
>>>> The MRU is a cache, as I use it; it typically has a max size for 
>>>> the collection. Handling this natively in the collection would be 
>>>> ideal; if an add operation would overflow, remove the item at the 
>>>> other end. Note that addAll() is used when initializing from 
>>>> backing store.
>>>>
>>>> FYI, I use a "Supplier<Integer>" to the constructor to provide 
>>>> maxSize, but a property makes much more sense. I'll make that 
>>>> change in MRU for sanity, and get rid of the trim() method. 
>>>> setMaxSize can do the trim.
>>>>
>>>> -ernie
>>>>
>>>
>>
>


From sgehwolf at openjdk.org  Mon Sep 26 18:36:22 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 26 Sep 2022 18:36:22 GMT
Subject: RFR: 8293540: [Metrics] Incorrectly detected resource limits with
 additional cgroup fs mounts [v3]
In-Reply-To: <-GC6RSB-rnXjie1pCd0k7bzPNbGlmyRbR6xyNNJNWzU=.c428b704-c7e6-450f-8107-63ce417e6408@github.com>
References: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
 <-GC6RSB-rnXjie1pCd0k7bzPNbGlmyRbR6xyNNJNWzU=.c428b704-c7e6-450f-8107-63ce417e6408@github.com>
Message-ID: <ygZLBTXC9VQXcAHTUPenyCWOiCbUBcdWIpa54mNJtxc=.bae5600c-d005-4997-8da6-fba098790434@github.com>

On Thu, 15 Sep 2022 08:55:41 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Similar issue to the hotspot change discussed in https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation may get the resource limits wrong if there are additional cgroup fs mounts. Apparently that's more common than one might think. I've reproduced this with these existing tests on cg v2:
>> 
>> 
>> test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java
>> test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java
>> test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java 
>> 
>> 
>> I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` and amended `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which unconditionally fails (irrespective of cgroup version in use). The fix is fairly straight forward and is an extension which we already do for the `cpuset` controller: Allow duplicates, and if there are any prefer those mounted at `/sys/fs/cgroup`.
>> 
>> Testing:
>> - [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the product fix)
>> - [x] added tests fail before, pass after the product fix.
>> - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still pass. 
>> - [x] GHA all pass.
>> 
>> Please review! Many thanks in advance.
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8293540: [Metrics] Potentially incorrectly detected resource limits with additional cgroup fs mounts

@iklam Could you help me getting this reviewed, please?

-------------

PR: https://git.openjdk.org/jdk/pull/10248

From rriggs at openjdk.org  Mon Sep 26 18:45:37 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 26 Sep 2022 18:45:37 GMT
Subject: RFR: 8294361: Cleanup usages of StringBuffer in SQLOutputImpl
In-Reply-To: <q_2V_qZS-UHRrwlkokVHntWAjO1XwAxvle5UxkXvK2Q=.e07e382a-efe9-4ff5-80e3-7022100314d5@github.com>
References: <q_2V_qZS-UHRrwlkokVHntWAjO1XwAxvle5UxkXvK2Q=.e07e382a-efe9-4ff5-80e3-7022100314d5@github.com>
Message-ID: <duKkfWkbi_Z9iqlK0RrVh3bh8060XNxH_LKF73cpyGw=.9d6341ba-84dc-4911-a250-785d54b55741@github.com>

On Sat, 17 Sep 2022 21:43:04 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There a few unnecessary usages of StringBuffer in SQLOutputImpl class.
> All of them create StringBuffer from single character and then concatenate with String. Instead of this, we can concatenate character directly.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10320

From rriggs at openjdk.org  Mon Sep 26 18:45:37 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 26 Sep 2022 18:45:37 GMT
Subject: RFR: 8294361: Cleanup usages of StringBuffer in SQLOutputImpl
In-Reply-To: <B7lU1t0KzkHel_gbmrkUz1GMFa7373KA217RQXgwxa0=.7163d803-98ab-4a5d-8791-11b72936e387@github.com>
References: <q_2V_qZS-UHRrwlkokVHntWAjO1XwAxvle5UxkXvK2Q=.e07e382a-efe9-4ff5-80e3-7022100314d5@github.com>
 <LPX0QI0s79mhtcHEZkhdi15lcd5JzLOT35SOZ5uEWQA=.5fdd25d2-bd7b-49c8-bb2a-59b47ea5d447@github.com>
 <B7lU1t0KzkHel_gbmrkUz1GMFa7373KA217RQXgwxa0=.7163d803-98ab-4a5d-8791-11b72936e387@github.com>
Message-ID: <51kixivfGgQFfZgZg1Zii4Mh7ymSjFNHd4PRESxgfzg=.8be94e13-9831-4c62-958c-92f72f0d84e2@github.com>

On Mon, 26 Sep 2022 16:08:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> src/java.sql.rowset/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java line 328:
>> 
>>> 326:         try {
>>> 327:             int i;
>>> 328:             while ((i = bufReader.read()) != -1) {
>> 
>> Is the single character read really necessary?
>> BufferedReader.readLine() returns null on EOF.
>> It seems plausable that only the readLine and writeString are needed in the loop.
>> 
>> Similarly, for the read loops below for InputStreams and binary stream.
>> The BufferedReader and readline can be used for the binary streams by constructing with the ASCII Charset.
>
> If this single character is `\n`, then direct replacing with `readLine` would change behavior of the method.

I see your point and this PR isn't the place to figure out why a single newline in the attributes Vector would be significant vs an empty string or no entry.

-------------

PR: https://git.openjdk.org/jdk/pull/10320

From erikj at openjdk.org  Mon Sep 26 19:07:57 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 26 Sep 2022 19:07:57 GMT
Subject: RFR: 8294317: Insufficient build rules for tzdb.dat [v2]
In-Reply-To: <-ipAVj6BgGHIPHV45qV9zdGJsj8SiGAZ2Oybv7TD1RY=.5135fa0e-8a35-437d-88fa-9e55764da02f@github.com>
References: <WS7j8PLGWmQXKydFbhYDSic55ECn9p40NdRIcS7TRHs=.43ced95c-1843-4d3b-9cb1-d526618e0678@github.com>
 <-ipAVj6BgGHIPHV45qV9zdGJsj8SiGAZ2Oybv7TD1RY=.5135fa0e-8a35-437d-88fa-9e55764da02f@github.com>
Message-ID: <eZjXJAP-bMlldnk3XtZqRX-_rH6jBV9Xw0KtUXIh3Is=.794b5af0-867f-46d7-a026-fb4ee36b150a@github.com>

On Mon, 26 Sep 2022 16:37:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The current makefile for `tzdb.dat` won't recompile if some dependent files (e.g. `VERSION`) are updated. Adding all files under the tzdb directory to the dependency will fix this issue.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use wildcard function

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10415

From erikj at openjdk.org  Mon Sep 26 19:07:58 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 26 Sep 2022 19:07:58 GMT
Subject: RFR: 8294317: Insufficient build rules for tzdb.dat [v2]
In-Reply-To: <Ijwa2WfHaQErPkzjIEz1vyyDvaTYq-2hSHYViD3E4j8=.f1f5a71c-ec50-4a45-aa22-aaa2f336377c@github.com>
References: <WS7j8PLGWmQXKydFbhYDSic55ECn9p40NdRIcS7TRHs=.43ced95c-1843-4d3b-9cb1-d526618e0678@github.com>
 <9BNVIgTyNGZTEEiPrMeHBaDnSjfna0vPNx3uUy4MPac=.9227bda9-2a69-4ed8-adb8-0a49451569a1@github.com>
 <Ijwa2WfHaQErPkzjIEz1vyyDvaTYq-2hSHYViD3E4j8=.f1f5a71c-ec50-4a45-aa22-aaa2f336377c@github.com>
Message-ID: <9WcY9iFmmjerrR-pnH_NtLYiN128Vb9HllZzTAIgAV0=.7bb90d76-6289-4d1d-8878-500ff9383c6d@github.com>

On Mon, 26 Sep 2022 16:32:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> make/modules/java.base/gendata/GendataTZDB.gmk line 33:
>> 
>>> 31: TZDATA_DIR := $(MODULE_SRC)/share/data/tzdata
>>> 32: TZDATA_TZFILE := africa antarctica asia australasia europe northamerica southamerica backward etcetera gmt jdk11_backward
>>> 33: TZDATA_TZFILES := $(TZDATA_DIR)/*
>> 
>> Have you verified that this works? I would expect a wildcard call to be needed. 
>> Suggestion:
>> 
>> TZDATA_TZFILES := $(wildcard $(TZDATA_DIR)/*)
>
> I confirmed the fix worked, on my local mac and mach5. However, your suggestion does seem the right way. Modified the fix as suggested.

Hm, yes, I think there are some cases where wildcards will be resolved without a call to wildcard. I'm also not sure that kind of expansion works the same across make versions, and if you ever needed to use that file list for anything else, it would be easy to trip up. I think this was expanded in the rule evaluation itself, not in the assignment. By being explicit with the call, we know what we are getting.

-------------

PR: https://git.openjdk.org/jdk/pull/10415

From almatvee at openjdk.org  Mon Sep 26 19:35:29 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 26 Sep 2022 19:35:29 GMT
Subject: RFR: 8293462: [macos] app image signature invalid when creating
 DMG or PKG from post processed signed image [v3]
In-Reply-To: <-sMR9P3CEZeJ31UFe7bzIcnC86rSErUVbY0GOymUoo4=.7c954bca-25c7-4fa0-9e2a-076ce2a485d4@github.com>
References: <-sMR9P3CEZeJ31UFe7bzIcnC86rSErUVbY0GOymUoo4=.7c954bca-25c7-4fa0-9e2a-076ce2a485d4@github.com>
Message-ID: <_J0WmuoSu9hYsGm6-dtKGoFSW8cNwqlT0J4XIqPeuyE=.55cd205e-d7f4-4fe3-b74b-004fa541ba36@github.com>

> Problem is that [JDK-8286850](https://bugs.openjdk.org/browse/JDK-8286850) never set correct value in .jpackage.xml to mark image as signed. [JDK-8289030](https://bugs.openjdk.org/browse/JDK-8289030) reads this value to check if we can add per-user and system wide configuration to packaged app. Fixed by setting correct value in .jpackage.xml when we signing predefine application image.
> 
> Added tests to cover this case and added check for values inside .jpackage.xml to validate signed and Mac App Store values.

Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:

  8293462: [macos] app image signature invalid when creating DMG or PKG from post processed signed image [v3]

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10316/files
  - new: https://git.openjdk.org/jdk/pull/10316/files/19d4981d..5598345c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10316&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10316&range=01-02

  Stats: 20 lines in 2 files changed: 5 ins; 14 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10316.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10316/head:pull/10316

PR: https://git.openjdk.org/jdk/pull/10316

From almatvee at openjdk.org  Mon Sep 26 19:35:32 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 26 Sep 2022 19:35:32 GMT
Subject: RFR: 8293462: [macos] app image signature invalid when creating
 DMG or PKG from post processed signed image [v2]
In-Reply-To: <3jNbc05RxRv96WDc9Dv_k9IN-BH0S5wNT_ND2gYC6UQ=.9f59df22-3dd1-42ab-a7ea-7d7eedd42776@github.com>
References: <-sMR9P3CEZeJ31UFe7bzIcnC86rSErUVbY0GOymUoo4=.7c954bca-25c7-4fa0-9e2a-076ce2a485d4@github.com>
 <rx7LwNB89Ka3Y8cEOnCaQ4-XvsJhJEfPcpigwprrLUY=.9eccee19-4fde-49f1-bcec-a7c0bddbbeab@github.com>
 <3jNbc05RxRv96WDc9Dv_k9IN-BH0S5wNT_ND2gYC6UQ=.9f59df22-3dd1-42ab-a7ea-7d7eedd42776@github.com>
Message-ID: <KNEaiZZmkzPFRgU0AUp_9DJq1ajx8kKijTLKt5-V_5Y=.4071b4dc-3666-437c-9f10-92b74c347397@github.com>

On Fri, 23 Sep 2022 20:40:29 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8293462: [macos] app image signature invalid when creating DMG or PKG from post processed signed image [v2]
>
> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageBuilder.java line 286:
> 
>> 284:                 if (appImageFile != null) {
>> 285:                     appImageFile.save(predefinedAppImage);
>> 286:                 }
> 
> Wouldn't it make sense to rethrow caught exception after the file is restored?

Fixed.

> src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageFile.java line 64:
> 
>> 62: 
>> 63:     // These values will be loaded from AppImage xml file.
>> 64:     private final Path appImageDir;
> 
> What this field is for? This property doesn't belong to the class.

It was used to show path to .jpackage.xml file in case of error from copyAsSigned(), but it is actually not needed, since copyAsSigned() should not produce invalid app image file.

-------------

PR: https://git.openjdk.org/jdk/pull/10316

From asemenyuk at openjdk.org  Mon Sep 26 19:35:33 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 26 Sep 2022 19:35:33 GMT
Subject: RFR: 8293462: [macos] app image signature invalid when creating
 DMG or PKG from post processed signed image [v2]
In-Reply-To: <KNEaiZZmkzPFRgU0AUp_9DJq1ajx8kKijTLKt5-V_5Y=.4071b4dc-3666-437c-9f10-92b74c347397@github.com>
References: <-sMR9P3CEZeJ31UFe7bzIcnC86rSErUVbY0GOymUoo4=.7c954bca-25c7-4fa0-9e2a-076ce2a485d4@github.com>
 <rx7LwNB89Ka3Y8cEOnCaQ4-XvsJhJEfPcpigwprrLUY=.9eccee19-4fde-49f1-bcec-a7c0bddbbeab@github.com>
 <3jNbc05RxRv96WDc9Dv_k9IN-BH0S5wNT_ND2gYC6UQ=.9f59df22-3dd1-42ab-a7ea-7d7eedd42776@github.com>
 <KNEaiZZmkzPFRgU0AUp_9DJq1ajx8kKijTLKt5-V_5Y=.4071b4dc-3666-437c-9f10-92b74c347397@github.com>
Message-ID: <UiD1PaGaXfG6sLQZhkttpCrWCy3lS3jES9Vk6E4vocg=.672b6d55-f0ef-4101-99e5-0e2d36ac6085@github.com>

On Mon, 26 Sep 2022 19:28:38 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageFile.java line 64:
>> 
>>> 62: 
>>> 63:     // These values will be loaded from AppImage xml file.
>>> 64:     private final Path appImageDir;
>> 
>> What this field is for? This property doesn't belong to the class.
>
> It was used to show path to .jpackage.xml file in case of error from copyAsSigned(), but it is actually not needed, since copyAsSigned() should not produce invalid app image file.

If not used, then I'd remove it.

-------------

PR: https://git.openjdk.org/jdk/pull/10316

From lancea at openjdk.org  Mon Sep 26 19:38:20 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 26 Sep 2022 19:38:20 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 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 six commits:
> 
>  - 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

Thank you for your efforts on the cleaning up these typos

I would suggest breaking these changes into separate PRs by team as there seems to be changes to hotspot, core-libs, and client to make it easier to review.  

I realize the changes are fairly trivial but this will most likely expedite getting your changes back

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From lancea at openjdk.org  Mon Sep 26 19:41:14 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 26 Sep 2022 19:41:14 GMT
Subject: RFR: 8294361: Cleanup usages of StringBuffer in SQLOutputImpl
In-Reply-To: <q_2V_qZS-UHRrwlkokVHntWAjO1XwAxvle5UxkXvK2Q=.e07e382a-efe9-4ff5-80e3-7022100314d5@github.com>
References: <q_2V_qZS-UHRrwlkokVHntWAjO1XwAxvle5UxkXvK2Q=.e07e382a-efe9-4ff5-80e3-7022100314d5@github.com>
Message-ID: <j5EQ2d8jlCgKBj9BGmp2JW86CpbnV3VQZhMic0A2eg0=.fb16fc85-cfac-4346-b066-a8c7a40fbd51@github.com>

On Sat, 17 Sep 2022 21:43:04 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There a few unnecessary usages of StringBuffer in SQLOutputImpl class.
> All of them create StringBuffer from single character and then concatenate with String. Instead of this, we can concatenate character directly.

The changes seem fine based on what your goal was.

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10320

From asemenyuk at openjdk.org  Mon Sep 26 20:17:29 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 26 Sep 2022 20:17:29 GMT
Subject: RFR: 8293462: [macos] app image signature invalid when creating
 DMG or PKG from post processed signed image [v3]
In-Reply-To: <_J0WmuoSu9hYsGm6-dtKGoFSW8cNwqlT0J4XIqPeuyE=.55cd205e-d7f4-4fe3-b74b-004fa541ba36@github.com>
References: <-sMR9P3CEZeJ31UFe7bzIcnC86rSErUVbY0GOymUoo4=.7c954bca-25c7-4fa0-9e2a-076ce2a485d4@github.com>
 <_J0WmuoSu9hYsGm6-dtKGoFSW8cNwqlT0J4XIqPeuyE=.55cd205e-d7f4-4fe3-b74b-004fa541ba36@github.com>
Message-ID: <lxyxjY8hElrVQ76WjkcnHWwcE5wSju2unRcbKyRNtXs=.52c6ec13-a049-4e86-af37-b2f3d61f6de1@github.com>

On Mon, 26 Sep 2022 19:35:29 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Problem is that [JDK-8286850](https://bugs.openjdk.org/browse/JDK-8286850) never set correct value in .jpackage.xml to mark image as signed. [JDK-8289030](https://bugs.openjdk.org/browse/JDK-8289030) reads this value to check if we can add per-user and system wide configuration to packaged app. Fixed by setting correct value in .jpackage.xml when we signing predefine application image.
>> 
>> Added tests to cover this case and added check for values inside .jpackage.xml to validate signed and Mac App Store values.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293462: [macos] app image signature invalid when creating DMG or PKG from post processed signed image [v3]

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10316

From bpb at openjdk.org  Mon Sep 26 21:41:30 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 26 Sep 2022 21:41:30 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo
 [v12]
In-Reply-To: <YrHWGaUCyTHHs-BnH7NR8LFTyM32euk89HzxZT3zXZM=.28bf954a-7d61-4526-824d-928a0cf273fa@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <YrHWGaUCyTHHs-BnH7NR8LFTyM32euk89HzxZT3zXZM=.28bf954a-7d61-4526-824d-928a0cf273fa@github.com>
Message-ID: <8QR2SzlTH9gYgXi7nkm3_YDEu7xEwuyhAiFkrb-8Q-w=.bff03517-1e75-452e-891f-2d1980888a78@github.com>

On Sun, 25 Sep 2022 00:39:33 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Implementation of JDK-8279283
>
> Markus KARG has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - transformTo -> transferTo
>  - wrapped long code lines
>  - removed unused import

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/6935

From bpb at openjdk.org  Mon Sep 26 21:41:32 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 26 Sep 2022 21:41:32 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo
 [v11]
In-Reply-To: <VNT4kts7ahX1UIRRohyp7x9RSxrF0zslIE90yfJYYF0=.27ebea5e-1d31-4235-b3fa-0e2a2eb4d702@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <_la5Co3yx5ik1wt7Y6Bi7MDC3MCVUxIKxz_iQQp2TT8=.1023ef6d-266f-45f5-aa93-7218d0d89c10@github.com>
 <VNT4kts7ahX1UIRRohyp7x9RSxrF0zslIE90yfJYYF0=.27ebea5e-1d31-4235-b3fa-0e2a2eb4d702@github.com>
Message-ID: <dNsTYdjKRFlt9jQxc3o_WX_ZMivOZOgy4SEhYWqsFhE=.9099bfb2-f5d2-4135-96c9-0b02fea75e22@github.com>

On Sat, 24 Sep 2022 12:14:49 GMT, Markus KARG <duke at openjdk.org> wrote:

> @bplb Fixed the issues you pointed out.

@mkarg You are welcome.

-------------

PR: https://git.openjdk.org/jdk/pull/6935

From duke at openjdk.org  Mon Sep 26 22:17:41 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 26 Sep 2022 22:17:41 GMT
Subject: RFR: 8272687: Replace StringBuffer with StringBuilder in
 RuleBasedCollator
Message-ID: <6FHBd4vRdnguVSgq1IM3wg569qKcwmgUyPFSDGTDfdU=.9591d145-88c4-4d57-bb34-5b0a12b5e46c@github.com>

Problem: Unnecessary instances of StringBuffer + .toString()

Fix: StringBuffer Replaced with StringBuilder, and .toString() removed when possible

Other: Line 698 in RuleBasedCollator.java also uses a .toString() conversion, but removing that instance requires changing the RuleBasedCollationKey constructor's second parameter type from String to StringBuilder

automated testing run passed cleanly

-------------

Commit messages:
 - Copyright update for fix
 - Merge master into fix branch
 - Fix: replace instances of StringBuffer with StringBuilder, drop String conversion

Changes: https://git.openjdk.org/jdk/pull/10432/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10432&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8272687
  Stats: 10 lines in 2 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/10432.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10432/head:pull/10432

PR: https://git.openjdk.org/jdk/pull/10432

From lancea at openjdk.org  Mon Sep 26 22:17:41 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 26 Sep 2022 22:17:41 GMT
Subject: RFR: 8272687: Replace StringBuffer with StringBuilder in
 RuleBasedCollator
In-Reply-To: <6FHBd4vRdnguVSgq1IM3wg569qKcwmgUyPFSDGTDfdU=.9591d145-88c4-4d57-bb34-5b0a12b5e46c@github.com>
References: <6FHBd4vRdnguVSgq1IM3wg569qKcwmgUyPFSDGTDfdU=.9591d145-88c4-4d57-bb34-5b0a12b5e46c@github.com>
Message-ID: <LBRXLw0d5JKs6r5PnXvmh1CAWTdMFwHaXwFpD9WiqCY=.41629ae8-8ba3-4eef-a35a-f4f96e22c71e@github.com>

On Mon, 26 Sep 2022 18:25:34 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Unnecessary instances of StringBuffer + .toString()
> 
> Fix: StringBuffer Replaced with StringBuilder, and .toString() removed when possible
> 
> Other: Line 698 in RuleBasedCollator.java also uses a .toString() conversion, but removing that instance requires changing the RuleBasedCollationKey constructor's second parameter type from String to StringBuilder
> 
> automated testing run passed cleanly

The changes look good Justin.

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10432

From naoto at openjdk.org  Mon Sep 26 22:17:41 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 26 Sep 2022 22:17:41 GMT
Subject: RFR: 8272687: Replace StringBuffer with StringBuilder in
 RuleBasedCollator
In-Reply-To: <6FHBd4vRdnguVSgq1IM3wg569qKcwmgUyPFSDGTDfdU=.9591d145-88c4-4d57-bb34-5b0a12b5e46c@github.com>
References: <6FHBd4vRdnguVSgq1IM3wg569qKcwmgUyPFSDGTDfdU=.9591d145-88c4-4d57-bb34-5b0a12b5e46c@github.com>
Message-ID: <9wwdMSrZ0ie0sGXoxDcX9XWLL7Syb-Z2jqvaj3qlTwE=.a2cc6270-a657-4aa2-97ff-4f91925de043@github.com>

On Mon, 26 Sep 2022 18:25:34 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Unnecessary instances of StringBuffer + .toString()
> 
> Fix: StringBuffer Replaced with StringBuilder, and .toString() removed when possible
> 
> Other: Line 698 in RuleBasedCollator.java also uses a .toString() conversion, but removing that instance requires changing the RuleBasedCollationKey constructor's second parameter type from String to StringBuilder
> 
> automated testing run passed cleanly

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10432

From bchristi at openjdk.org  Mon Sep 26 22:17:41 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 26 Sep 2022 22:17:41 GMT
Subject: RFR: 8272687: Replace StringBuffer with StringBuilder in
 RuleBasedCollator
In-Reply-To: <6FHBd4vRdnguVSgq1IM3wg569qKcwmgUyPFSDGTDfdU=.9591d145-88c4-4d57-bb34-5b0a12b5e46c@github.com>
References: <6FHBd4vRdnguVSgq1IM3wg569qKcwmgUyPFSDGTDfdU=.9591d145-88c4-4d57-bb34-5b0a12b5e46c@github.com>
Message-ID: <HBcmRAAZJ8EBhtr5yIbdSfpoUDo_rnG3Ja3SCn_SG-o=.8f435d77-d8a0-4c13-84e0-0bb6e65778f1@github.com>

On Mon, 26 Sep 2022 18:25:34 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Unnecessary instances of StringBuffer + .toString()
> 
> Fix: StringBuffer Replaced with StringBuilder, and .toString() removed when possible
> 
> Other: Line 698 in RuleBasedCollator.java also uses a .toString() conversion, but removing that instance requires changing the RuleBasedCollationKey constructor's second parameter type from String to StringBuilder
> 
> automated testing run passed cleanly

Looks good!

-------------

Marked as reviewed by bchristi (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10432

From haosun at openjdk.org  Mon Sep 26 22:22:20 2022
From: haosun at openjdk.org (Hao Sun)
Date: Mon, 26 Sep 2022 22:22:20 GMT
Subject: RFR: 8293887: AArch64 build failure with GCC 12 due to
 maybe-uninitialized warning in libfdlibm k_rem_pio2.c [v2]
In-Reply-To: <ckVWsVK3EmbkP2Vc5GHn7RtRwg9-em0HFy_xwOXw5cA=.b3ce66d2-5491-45a6-8a87-75d98c699bb8@github.com>
References: <UTaCIvPdArIMVc2jDoPYp72K5MelURpuipDuZigrDy0=.16cf4031-3791-4fd4-aeb3-598fa4faf4db@github.com>
 <ckVWsVK3EmbkP2Vc5GHn7RtRwg9-em0HFy_xwOXw5cA=.b3ce66d2-5491-45a6-8a87-75d98c699bb8@github.com>
Message-ID: <1K_pgZ12i7LaglFfkfpqM1TexTYGFG-mFDCfR5qCA1E=.201bbb7d-11fc-4c1c-82f7-ccf7df1b1f8a@github.com>

On Mon, 26 Sep 2022 01:39:41 GMT, Hao Sun <haosun at openjdk.org> wrote:

>> This warning seems to be a false positive, because 1) array "fq" with elements from index 0 to "jz" has already been initialized as "fw" at line 290 [1], and 2) variable "jz" should be non-negative from the comment at line 99 [2].
>> 
>> Note-1: GCC warning option -Wmaybe-uninitialized is not a new one. Note-2: x86-64 build with GCC 12 on Ubuntu 22.04 passed in my local test.
>> 
>> This warning is raised only on GCC 12 + AArch64. I suspect it might be some GCC 12 bug, so I reported it to GCC community [3].
>> 
>> Since it involves third party code, I think it's better to suppress the warning by simply disabling this warning option in the makefile.
>> 
>> Testing: Release builds with GCC 9, GCC 11 and GCC 12 passed on Ubuntu 22.04/AArch64 system.
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libfdlibm/k_rem_pio2.c#L290 
>> [2] https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libfdlibm/k_rem_pio2.c#L99 
>> [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106992
>
> Hao Sun 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:
> 
>  - Disable the warning option per file
>    
>    After JDK-8294281, we can disable the warning options per file.
>    
>    Testing: Release builds with GCC 9, GCC 11 and GCC 12 passed on Ubuntu
>    22.04/AArch64 system.
>  - Merge branch 'master' into 8293887-gcc12-fdlibm
>  - 8293887: AArch64 build failure with GCC 12 due to maybe-uninitialized warning in libfdlibm k_rem_pio2.c
>    
>    This warning seems to be a false positive, because 1) array "fq" with
>    elements from index 0 to "jz" has already been initialized as "fw" at
>    line 290 [1], and 2) variable "jz" should be non-negative from the
>    comment at line 99 [2].
>    
>    Note-1: GCC warning option -Wmaybe-uninitialized is not a new one.
>    Note-2: x86-64 build with GCC 12 on Ubuntu 22.04 passed in my local
>    test.
>    
>    This warning is raised only on GCC 12 + AArch64. I suspect it might be
>    some GCC 12 bug, so I reported it to GCC community [3].
>    
>    Since it involves third party code, I think it's better to suppress the
>    warning by simply disabling this warning option in the makefile.
>    
>    Testing: Release builds with GCC 9, GCC 11 and GCC 12 passed on Ubuntu
>    22.04/AArch64 system.
>    
>    [1] https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libfdlibm/k_rem_pio2.c#L290
>    [2] https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libfdlibm/k_rem_pio2.c#L99
>    [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106992

Thanks for your review!

-------------

PR: https://git.openjdk.org/jdk/pull/10386

From bpb at openjdk.org  Mon Sep 26 22:23:45 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 26 Sep 2022 22:23:45 GMT
Subject: RFR: 8272687: Replace StringBuffer with StringBuilder in
 RuleBasedCollator
In-Reply-To: <6FHBd4vRdnguVSgq1IM3wg569qKcwmgUyPFSDGTDfdU=.9591d145-88c4-4d57-bb34-5b0a12b5e46c@github.com>
References: <6FHBd4vRdnguVSgq1IM3wg569qKcwmgUyPFSDGTDfdU=.9591d145-88c4-4d57-bb34-5b0a12b5e46c@github.com>
Message-ID: <bMCB2iteqxKE3HJR5TMEHkK_J3xkAUTR6YOTRkyywuQ=.b16d9182-0a81-4b90-963d-c359e9324bcb@github.com>

On Mon, 26 Sep 2022 18:25:34 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Unnecessary instances of StringBuffer + .toString()
> 
> Fix: StringBuffer Replaced with StringBuilder, and .toString() removed when possible
> 
> Other: Line 698 in RuleBasedCollator.java also uses a .toString() conversion, but removing that instance requires changing the RuleBasedCollationKey constructor's second parameter type from String to StringBuilder
> 
> automated testing run passed cleanly

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10432

From duke at openjdk.org  Mon Sep 26 22:34:40 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 26 Sep 2022 22:34:40 GMT
Subject: Integrated: 8272687: Replace StringBuffer with StringBuilder in
 RuleBasedCollator
In-Reply-To: <6FHBd4vRdnguVSgq1IM3wg569qKcwmgUyPFSDGTDfdU=.9591d145-88c4-4d57-bb34-5b0a12b5e46c@github.com>
References: <6FHBd4vRdnguVSgq1IM3wg569qKcwmgUyPFSDGTDfdU=.9591d145-88c4-4d57-bb34-5b0a12b5e46c@github.com>
Message-ID: <2R35rpu5H3silZ4Neb4dhA5qnS6y0PUivFH17OgYUTQ=.ffca51b2-95f8-48b2-acaa-c385b73216ec@github.com>

On Mon, 26 Sep 2022 18:25:34 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Unnecessary instances of StringBuffer + .toString()
> 
> Fix: StringBuffer Replaced with StringBuilder, and .toString() removed when possible
> 
> Other: Line 698 in RuleBasedCollator.java also uses a .toString() conversion, but removing that instance requires changing the RuleBasedCollationKey constructor's second parameter type from String to StringBuilder
> 
> automated testing run passed cleanly

This pull request has now been integrated.

Changeset: 43eff2b3
Author:    Justin Lu <justin.lu at oracle.com>
Committer: Brent Christian <bchristi at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/43eff2b309e2ef275bdd5adf196da81d4e23f535
Stats:     10 lines in 2 files changed: 0 ins; 0 del; 10 mod

8272687: Replace StringBuffer with StringBuilder in RuleBasedCollator

Reviewed-by: lancea, naoto, bchristi, bpb

-------------

PR: https://git.openjdk.org/jdk/pull/10432

From almatvee at openjdk.org  Mon Sep 26 22:52:31 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 26 Sep 2022 22:52:31 GMT
Subject: Integrated: 8293462: [macos] app image signature invalid when creating
 DMG or PKG from post processed signed image
In-Reply-To: <-sMR9P3CEZeJ31UFe7bzIcnC86rSErUVbY0GOymUoo4=.7c954bca-25c7-4fa0-9e2a-076ce2a485d4@github.com>
References: <-sMR9P3CEZeJ31UFe7bzIcnC86rSErUVbY0GOymUoo4=.7c954bca-25c7-4fa0-9e2a-076ce2a485d4@github.com>
Message-ID: <aWEmCMwQ_c9iMeonCk8y3pBoVJMnujIHhhxbI3D-FKs=.6a50248b-9911-4c81-9a16-abe14a896461@github.com>

On Fri, 16 Sep 2022 22:55:52 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Problem is that [JDK-8286850](https://bugs.openjdk.org/browse/JDK-8286850) never set correct value in .jpackage.xml to mark image as signed. [JDK-8289030](https://bugs.openjdk.org/browse/JDK-8289030) reads this value to check if we can add per-user and system wide configuration to packaged app. Fixed by setting correct value in .jpackage.xml when we signing predefine application image.
> 
> Added tests to cover this case and added check for values inside .jpackage.xml to validate signed and Mac App Store values.

This pull request has now been integrated.

Changeset: 1e222bcc
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1e222bccd3807c1be0d1d824e0ff9745751d8375
Stats:     423 lines in 12 files changed: 356 ins; 19 del; 48 mod

8293462: [macos] app image signature invalid when creating DMG or PKG from post processed signed image

Reviewed-by: asemenyuk

-------------

PR: https://git.openjdk.org/jdk/pull/10316

From errael at raelity.com  Mon Sep 26 23:01:18 2022
From: errael at raelity.com (Ernie Rael)
Date: Mon, 26 Sep 2022 16:01:18 -0700
Subject: Sequenced Collections
In-Reply-To: <c2dbf1a8-c772-0568-f428-8b0b71557818@raelity.com>
References: <f6edafc8-03f1-4f3a-1382-592688785c6e@raelity.com>
 <06ca6cc9-4d35-e327-5d03-2378302f72dd@gmail.com>
 <024fe055-c94e-94e2-cf21-bca828304929@raelity.com>
 <44ff182d-f251-e62f-9560-a7e8d325187e@oracle.com>
 <c2dbf1a8-c772-0568-f428-8b0b71557818@raelity.com>
Message-ID: <374f24af-9e79-94ec-751c-c769b23c3ef9@raelity.com>

On 9/26/22 11:31 AM, Ernie Rael wrote:
> maybe "interface ListIteratorProvider { ListIterator listIterator(int 
> index); }"

Doh! I guess that should be "interface ListIterable"


From sspitsyn at openjdk.org  Tue Sep 27 00:18:26 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 27 Sep 2022 00:18:26 GMT
Subject: RFR: 8293592: Remove JVM_StopThread, stillborn,
 and related cleanup [v2]
In-Reply-To: <BlMK7IMjTgIiiwSkkF_1-qLlM1AqaKAhLP55-Z1-eeI=.2383991e-22d3-4c0c-afab-353985e1f8fc@github.com>
References: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
 <BlMK7IMjTgIiiwSkkF_1-qLlM1AqaKAhLP55-Z1-eeI=.2383991e-22d3-4c0c-afab-353985e1f8fc@github.com>
Message-ID: <Vw7bLJXT5-uuBW8whIz4h64mx0uh6GtmyAYexmVeQd8=.6f9d8a00-5c53-4900-871a-c9fab0ef306e@github.com>

On Fri, 23 Sep 2022 21:47:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610).
>> 
>> Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started.
>> 
>> Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same).
>> 
>> Testing: tiers 1-3
>
> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Merge branch 'master' into 8293592-JVM_StopThread
>  - Removal all special handling of ThreadDeath.
>  - Remove all references to the stillborn field
>  - Initial commit: remove JVM_StopThread
>  - Merge
>  - Updates to Java Thread Primitive Deprecation page
>  - Repalce "it" with "victim thread"
>  - Merge
>  - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop
>  - become -> became in javadoc
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/3675f4c2...4eb07903

This looks good to me.
I do not see any issues.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10400

From mik3hall at gmail.com  Tue Sep 27 02:24:05 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 26 Sep 2022 21:24:05 -0500
Subject: RFR: 8293462: [macos] app image signature invalid when creating
 DMG or PKG from post processed signed image
In-Reply-To: <A80F3462-C69A-401D-BD23-26391CD96B8C@gmail.com>
References: <-sMR9P3CEZeJ31UFe7bzIcnC86rSErUVbY0GOymUoo4=.7c954bca-25c7-4fa0-9e2a-076ce2a485d4@github.com>
 <20F8AC2D-C71B-4892-A2F3-C9A07501046F@gmail.com>
 <707A13E7-9047-428B-86FA-C4DFA047146C@oracle.com>
 <D847BFBF-6DEE-4F39-8EF8-5E1CF3CE3453@gmail.com>
 <A80F3462-C69A-401D-BD23-26391CD96B8C@gmail.com>
Message-ID: <9CC241FC-952A-46D6-BBF7-FC1CBE094AE0@gmail.com>



> On Sep 20, 2022, at 5:50 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> Still you could use post-processing to add whatever java binary executable commands you wanted. This again would mean changes to the embedded jdk that might have signing side effects. I haven?t tested.  

Thinking about this I looked at my application that includes java commands and saw that currently I include all. And all appear to be of fixed size. So I assume some kind of launcher stub?

I then remembered 

[macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe
https://bugs.openjdk.org/browse/JDK-8286122 <https://bugs.openjdk.org/browse/JDK-8286122>

The bug being due?
> ITMS-90511: CFBundleIdentifier Collision - The Info.plist CFBundleIdentifier value 'net.java.openjdk.java' of 'java' is already in use by another application. 
This because the launcher stub includes it?s own Info.pliat?s always using the same CFBundleIdentifier

If I understand the resolution correctly?
https://github.com/openjdk/jdk17u-dev/commit/6a4b6220f8dc184f408f1295865ed0ad2e3710ca <https://github.com/openjdk/jdk17u-dev/commit/6a4b6220f8dc184f408f1295865ed0ad2e3710ca>

This effectively prohibits jpackage applications going to the App Store from using java native commands by disallowing the jlink option.
I realize this issue is closed and probably not yours to resolve.

But wouldn?t it be possible to simply make the CFBundleIdentifier unique?
Maybe a hash of command name and application name, something like?
Hash(?java?+?MyCommandUsingMacAppStoreApp?)

I don?t think the identifiers for the embedded commands need to be meaningful to the developer or anyone else. A good hash should pretty much eliminate collisions.

My apologies if I?m simply repeating something dismissed in prior discussion.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220926/401611f4/attachment-0001.htm>

From haosun at openjdk.org  Tue Sep 27 03:13:21 2022
From: haosun at openjdk.org (Hao Sun)
Date: Tue, 27 Sep 2022 03:13:21 GMT
Subject: Integrated: 8293887: AArch64 build failure with GCC 12 due to
 maybe-uninitialized warning in libfdlibm k_rem_pio2.c
In-Reply-To: <UTaCIvPdArIMVc2jDoPYp72K5MelURpuipDuZigrDy0=.16cf4031-3791-4fd4-aeb3-598fa4faf4db@github.com>
References: <UTaCIvPdArIMVc2jDoPYp72K5MelURpuipDuZigrDy0=.16cf4031-3791-4fd4-aeb3-598fa4faf4db@github.com>
Message-ID: <2qGVL86Uuk9DvFTEnd4KupYTmxwm16q75xnHfbUf7ns=.4365a99a-a07e-4366-a74a-4e31a14e26e4@github.com>

On Thu, 22 Sep 2022 07:02:16 GMT, Hao Sun <haosun at openjdk.org> wrote:

> This warning seems to be a false positive, because 1) array "fq" with elements from index 0 to "jz" has already been initialized as "fw" at line 290 [1], and 2) variable "jz" should be non-negative from the comment at line 99 [2].
> 
> Note-1: GCC warning option -Wmaybe-uninitialized is not a new one. Note-2: x86-64 build with GCC 12 on Ubuntu 22.04 passed in my local test.
> 
> This warning is raised only on GCC 12 + AArch64. I suspect it might be some GCC 12 bug, so I reported it to GCC community [3].
> 
> Since it involves third party code, I think it's better to suppress the warning by simply disabling this warning option in the makefile.
> 
> Testing: Release builds with GCC 9, GCC 11 and GCC 12 passed on Ubuntu 22.04/AArch64 system.
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libfdlibm/k_rem_pio2.c#L290 
> [2] https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libfdlibm/k_rem_pio2.c#L99 
> [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106992

This pull request has now been integrated.

Changeset: 02ea3381
Author:    Hao Sun <haosun at openjdk.org>
Committer: Ningsheng Jian <njian at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/02ea338177df781912dc782e32200eaf4731a0da
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8293887: AArch64 build failure with GCC 12 due to maybe-uninitialized warning in libfdlibm k_rem_pio2.c

Reviewed-by: erikj, shade, ihse

-------------

PR: https://git.openjdk.org/jdk/pull/10386

From dholmes at openjdk.org  Tue Sep 27 04:25:18 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 27 Sep 2022 04:25:18 GMT
Subject: RFR: 8292016: Split Windows API error handling from errors passed
 through the runtime in the JDK [v22]
In-Reply-To: <S3foO_lw8Qp5f1NosQ8cx1v96miI57hdDTQ4FIOlYbo=.26b894ca-3505-46e9-9c43-d381e2d4e1bc@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
 <S3foO_lw8Qp5f1NosQ8cx1v96miI57hdDTQ4FIOlYbo=.26b894ca-3505-46e9-9c43-d381e2d4e1bc@github.com>
Message-ID: <OjGBI4cbdqxyuIjruGTV3GXkajZgbVfAgNKakOnIMnk=.d27dc4fc-ec28-4f4b-b19c-37d9e496c126@github.com>

On Mon, 26 Sep 2022 15:47:51 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> EDIT: Cave and add the ErrorOrigin enum, to differentiate which error type the error reporting functions in libjava will look up. RUNTIME refers to errors passed through the runtime via errno, and SYSTEM is for native errors not visible to the runtime.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Whitespace

This seems to be trying to future-proof the reporting code by introducing a duality that is not actually needed at present in some cases. That means the code is untested. Are there planned uses of `RUNTIME` in the very near future?

src/java.base/share/native/libjava/jni_util.h line 339:

> 337:                           char *jniEntryName);
> 338: 
> 339: // RUNTIME - Errors that were passed through the runtime

If "runtime" means "C runtime" (as the system description suggests) then please say that.

src/java.base/share/native/libjava/jni_util.h line 348:

> 346: 
> 347: JNIEXPORT size_t JNICALL
> 348: getLastErrorString(char *buf, size_t len, ErrorOrigin origin);

AFAICS we never pass RUNTIME to `getLastErrorString`

src/java.base/share/native/libjli/java.h line 145:

> 143:  */
> 144: JNIEXPORT void JNICALL
> 145: JLI_ReportErrorMessageSys(ErrorOrigin origin, const char * message, ...);

AFAICS we never pass RUNTIME to `JLI_ReportErrorMessageSys`.

src/java.base/unix/native/libjli/java_md_common.c line 207:

> 205:     va_start(vl, fmt);
> 206:     vfprintf(stderr, fmt, vl);
> 207:     if (errno != 0) {

Is `vfprintf` guaranteed to not set `errno`?

-------------

PR: https://git.openjdk.org/jdk/pull/9870

From dholmes at openjdk.org  Tue Sep 27 05:00:24 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 27 Sep 2022 05:00:24 GMT
Subject: RFR: 8293592: Remove JVM_StopThread, stillborn,
 and related cleanup [v2]
In-Reply-To: <Vw7bLJXT5-uuBW8whIz4h64mx0uh6GtmyAYexmVeQd8=.6f9d8a00-5c53-4900-871a-c9fab0ef306e@github.com>
References: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
 <BlMK7IMjTgIiiwSkkF_1-qLlM1AqaKAhLP55-Z1-eeI=.2383991e-22d3-4c0c-afab-353985e1f8fc@github.com>
 <Vw7bLJXT5-uuBW8whIz4h64mx0uh6GtmyAYexmVeQd8=.6f9d8a00-5c53-4900-871a-c9fab0ef306e@github.com>
Message-ID: <HGdnSIhKVmqai7HINBaQS6P6P7Kuz3Pk_skyx-W3QWE=.7d399889-5230-4cba-a159-1aff502c02ce@github.com>

On Tue, 27 Sep 2022 00:15:17 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
>> 
>>  - Merge branch 'master' into 8293592-JVM_StopThread
>>  - Removal all special handling of ThreadDeath.
>>  - Remove all references to the stillborn field
>>  - Initial commit: remove JVM_StopThread
>>  - Merge
>>  - Updates to Java Thread Primitive Deprecation page
>>  - Repalce "it" with "victim thread"
>>  - Merge
>>  - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop
>>  - become -> became in javadoc
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/3675f4c2...4eb07903
>
> This looks good to me.
> I do not see any issues.
> Thanks,
> Serguei

Thanks @sspitsyn !

-------------

PR: https://git.openjdk.org/jdk/pull/10400

From dholmes at openjdk.org  Tue Sep 27 06:04:21 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 27 Sep 2022 06:04:21 GMT
Subject: RFR: 8293806: JDK_JAVA_OPTIONS picked up twice if LD_LIBRARY_PATH
 is set
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: <kXAQlXcudZELC5v1_dgJmccwdTwUPaXtBfz25rxNtd0=.e7c2815c-9b48-4314-aae5-53dabdaf8274@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.

Sorry @dsamersoff but I don't understand how this arises - can you explain in more detail please? I'm not seeing the connection between setting `LD_LIBRARY_PATH` and reading an env var twice. Thanks

-------------

PR: https://git.openjdk.org/jdk/pull/10430

From xgong at openjdk.org  Tue Sep 27 06:15:17 2022
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 27 Sep 2022 06:15:17 GMT
Subject: RFR: 8293409: [vectorapi] Intrinsify VectorSupport.indexVector
In-Reply-To: <CES8kmi34gT8zSdoc2iBcgAGeOMDvOnZJrCsjU-9xaA=.091a5ad1-55a4-41c4-9e8c-192a0bca47e4@github.com>
References: <CES8kmi34gT8zSdoc2iBcgAGeOMDvOnZJrCsjU-9xaA=.091a5ad1-55a4-41c4-9e8c-192a0bca47e4@github.com>
Message-ID: <kV57DGTCtN3AIjX0Ux3Yj2WadJhW4RKsqSoUm5wkubE=.e0feb05d-9274-4608-aafc-5cfbfa17e5f6@github.com>

On Mon, 19 Sep 2022 08:51:24 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> "`VectorSupport.indexVector()`" is used to compute a vector that contains the index values based on a given vector and a scale value (`i.e. index = vec + iota * scale`). This function is widely used in other APIs like "`VectorMask.indexInRange`" which is useful to the tail loop vectorization. And it can be easily implemented with the vector instructions.
> 
> This patch adds the vector intrinsic implementation of it. The steps are:
> 
>   1) Load the const "iota" vector.
> 
>   We extend the "`vector_iota_indices`" stubs from byte to other integral types. For floating point vectors, it needs an additional vector cast to get the right iota values.
> 
>   2) Compute indexes with "`vec + iota * scale`"
> 
> Here is the performance result to the new added micro benchmark on ARM NEON:
> 
> Benchmark                              Gain
> IndexVectorBenchmark.byteIndexVector   1.477
> IndexVectorBenchmark.doubleIndexVector 5.031
> IndexVectorBenchmark.floatIndexVector  5.342
> IndexVectorBenchmark.intIndexVector    5.529
> IndexVectorBenchmark.longIndexVector   3.177
> IndexVectorBenchmark.shortIndexVector  5.841
> 
> 
> Please help to review and share the feedback! Thanks in advance!

Hi, could anyone please help to take a look at this PR? Thanks in advance for your time!

-------------

PR: https://git.openjdk.org/jdk/pull/10332

From shade at openjdk.org  Tue Sep 27 06:28:25 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 27 Sep 2022 06:28:25 GMT
Subject: RFR: 8294376: Minimize disabled warnings in java.base
In-Reply-To: <0R2PwBaaBOUMBU-Po3uIlwg5CeIxiixdmMAuQaGRoXg=.bbaab7fa-9696-456a-8a0f-2428374f0799@github.com>
References: <R7_lfTjzEBkN-TAZxMd75nnuJ2_ZwAJfcqq-Z1Erhk0=.2aa5ecbd-14bb-4808-9087-21d084c77f8a@github.com>
 <0R2PwBaaBOUMBU-Po3uIlwg5CeIxiixdmMAuQaGRoXg=.bbaab7fa-9696-456a-8a0f-2428374f0799@github.com>
Message-ID: <z01zsmB4gofgy-j0dLXKAiI_LXARd0dzOrY30OnZxUI=.0c459671-e5a8-47e8-8894-43b559f8202d@github.com>

On Mon, 26 Sep 2022 17:03:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in java.base native libraries.
>> 
>> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.
>> 
>> Some warnings didn't trigger in any file anymore, and could just be removed.
>
> Hold on, I'll test these on various Linux-es.

> @shipilev Thanks. I will also wait for someone from core-libs to chime in.

GCC 10 in various arches/modes is fine.

-------------

PR: https://git.openjdk.org/jdk/pull/10426

From svkamath at openjdk.org  Tue Sep 27 07:40:19 2022
From: svkamath at openjdk.org (Smita Kamath)
Date: Tue, 27 Sep 2022 07:40:19 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v10]
In-Reply-To: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
Message-ID: <lLRsBGcVOaOTQ8-yuv7AoTMeQEdtXjU3QQVSIzVdRms=.7d0d1d6c-39c8-4136-9d98-db71bc862256@github.com>

> 8289552: Make intrinsic conversions between bit representations of half precision values and floats

Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:

  Addressed review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9781/files
  - new: https://git.openjdk.org/jdk/pull/9781/files/bd55803a..c6128b1b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=08-09

  Stats: 83 lines in 5 files changed: 37 ins; 38 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/9781.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9781/head:pull/9781

PR: https://git.openjdk.org/jdk/pull/9781

From svkamath at openjdk.org  Tue Sep 27 07:40:24 2022
From: svkamath at openjdk.org (Smita Kamath)
Date: Tue, 27 Sep 2022 07:40:24 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v8]
In-Reply-To: <XbkYoySQ6LDlu44mOsg2Ok8DIoFeUMAndQOwfwSFA_E=.c5cb858f-8f8a-4d30-b263-de3c4c1c5da2@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com>
 <XbkYoySQ6LDlu44mOsg2Ok8DIoFeUMAndQOwfwSFA_E=.c5cb858f-8f8a-4d30-b263-de3c4c1c5da2@github.com>
Message-ID: <mmNLR6G7FcMTmQavlfyBYn7uqgawkedj3LauR2TITr0=.4b654e5f-0d28-425e-8930-b7898d1d4391@github.com>

On Wed, 21 Sep 2022 17:49:51 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressed review comments
>
> src/hotspot/share/opto/convertnode.cpp line 166:
> 
>> 164: //=============================================================================
>> 165: //------------------------------Value------------------------------------------
>> 166: const Type* ConvF2HFNode::Value(PhaseGVN* phase) const {
> 
> IR framework based test will compliment newly introduced IR nodes.

Will add IR framework based test in addition to the gtest.

> src/hotspot/share/opto/convertnode.hpp line 107:
> 
>> 105: class ConvF2HFNode : public Node {
>> 106:   public:
>> 107:   ConvF2HFNode( Node *in1 ) : Node(0,in1) {}
> 
> Additional space b/w , and in1

Hi Jatin, this spacing is similar to other class declarations in the file. So I will keep it consistent. Thanks.

> src/hotspot/share/opto/convertnode.hpp line 146:
> 
>> 144: class ConvHF2FNode : public Node {
>> 145:   public:
>> 146:   ConvHF2FNode( Node *in1 ) : Node(0,in1) {}
> 
> Space b/w , and in1

Same reasoning as above.

> src/hotspot/share/runtime/sharedRuntime.cpp line 452:
> 
>> 450: // Reference implementation at src/java.base/share/classes/java/lang/Float.java:floatToFloat16
>> 451: JRT_LEAF(jshort, SharedRuntime::f2hf(jfloat  x))
>> 452:   jint doppel = SharedRuntime::f2i(x);
> 
> Newly added constant value computation runtime routines can be validated by a gtest.

I have created a bug entry for the gtest. Will add it in a separate PR.

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From svkamath at openjdk.org  Tue Sep 27 07:46:19 2022
From: svkamath at openjdk.org (Smita Kamath)
Date: Tue, 27 Sep 2022 07:46:19 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v8]
In-Reply-To: <QdS7Tx2gk2HR7Y-qe6Ig8_QgyGRi5i3k14aERVEHTs4=.b5839efb-e45f-4700-b9d6-7fca6d61cd77@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com>
 <QdS7Tx2gk2HR7Y-qe6Ig8_QgyGRi5i3k14aERVEHTs4=.b5839efb-e45f-4700-b9d6-7fca6d61cd77@github.com>
Message-ID: <MCn1UrHOgzqBwRlcO0sivlgWOU4tuT1Aj_vW88lXAg4=.8e733f67-27a8-4289-a3f1-ad18944e054b@github.com>

On Wed, 21 Sep 2022 16:41:19 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressed review comments
>
> tier2 and 3 passed. I will wait update with test and JVMCI fix before doing more testing.

@vnkozlov I have made the requested changes. Thanks a lot for your help.

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From rehn at openjdk.org  Tue Sep 27 08:05:19 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 27 Sep 2022 08:05:19 GMT
Subject: RFR: 8293592: Remove JVM_StopThread, stillborn,
 and related cleanup [v2]
In-Reply-To: <BlMK7IMjTgIiiwSkkF_1-qLlM1AqaKAhLP55-Z1-eeI=.2383991e-22d3-4c0c-afab-353985e1f8fc@github.com>
References: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
 <BlMK7IMjTgIiiwSkkF_1-qLlM1AqaKAhLP55-Z1-eeI=.2383991e-22d3-4c0c-afab-353985e1f8fc@github.com>
Message-ID: <-5Dm6rla6Uq1BWSlvsaVKXwLsbd0c2tgewPhpygfqZ0=.283a80a5-5025-4460-8ede-68a37e668764@github.com>

On Fri, 23 Sep 2022 21:47:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610).
>> 
>> Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started.
>> 
>> Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same).
>> 
>> Testing: tiers 1-3
>
> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Merge branch 'master' into 8293592-JVM_StopThread
>  - Removal all special handling of ThreadDeath.
>  - Remove all references to the stillborn field
>  - Initial commit: remove JVM_StopThread
>  - Merge
>  - Updates to Java Thread Primitive Deprecation page
>  - Repalce "it" with "victim thread"
>  - Merge
>  - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop
>  - become -> became in javadoc
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/3675f4c2...4eb07903

Looks good, thank for fixing.

-------------

Marked as reviewed by rehn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10400

From ihse at openjdk.org  Tue Sep 27 08:32:09 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 Sep 2022 08:32:09 GMT
Subject: RFR: 8294376: Minimize disabled warnings in java.base [v2]
In-Reply-To: <R7_lfTjzEBkN-TAZxMd75nnuJ2_ZwAJfcqq-Z1Erhk0=.2aa5ecbd-14bb-4808-9087-21d084c77f8a@github.com>
References: <R7_lfTjzEBkN-TAZxMd75nnuJ2_ZwAJfcqq-Z1Erhk0=.2aa5ecbd-14bb-4808-9087-21d084c77f8a@github.com>
Message-ID: <J0i4MkHp8BBQ1Y-OdyH-9OSrhNk648A4x04A2aF45Rs=.adc4b0aa-dd51-42fe-ba79-b1336fd98043@github.com>

> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in java.base native libraries.
> 
> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.
> 
> Some warnings didn't trigger in any file anymore, and could just be removed.

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge branch 'master' into java.base-warnings-per-file
 - Fixes for linux
 - Fix windows
 - Fix macos/aarch64

-------------

Changes: https://git.openjdk.org/jdk/pull/10426/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10426&range=01
  Stats: 26 lines in 2 files changed: 8 ins; 4 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/10426.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10426/head:pull/10426

PR: https://git.openjdk.org/jdk/pull/10426

From amaembo at gmail.com  Tue Sep 27 10:11:35 2022
From: amaembo at gmail.com (Tagir Valeev)
Date: Tue, 27 Sep 2022 12:11:35 +0200
Subject: Collections.shuffle to accept RandomGenerator
Message-ID: <CAE+3fjasa2Y8qZQiYNE8Dw2G8iXFmR9z3LruksGOiFMHEKeEiQ@mail.gmail.com>

Hello!

Currently, Collections.shuffle(List, Random) accepts an outdated
Random class instead of RandomGenerator interface. It looks like,
RandomGenerator would suffice. The code change looks trivial (aside
from documentation and testing), as shuffle() implementation does not
need anything except nextInt:

diff --git a/src/java.base/share/classes/java/util/Collections.java
b/src/java.base/share/classes/java/util/Collections.java
--- a/src/java.base/share/classes/java/util/Collections.java (revision
cab590517bf705418c7376edd5d7066b13b6dde8)
+++ b/src/java.base/share/classes/java/util/Collections.java (date
1664273240190)
@@ -37,6 +37,7 @@
 import java.util.function.IntFunction;
 import java.util.function.Predicate;
 import java.util.function.UnaryOperator;
+import java.util.random.RandomGenerator;
 import java.util.stream.IntStream;
 import java.util.stream.Stream;
 import java.util.stream.StreamSupport;
@@ -454,8 +455,12 @@
      * @throws UnsupportedOperationException if the specified list or its
      *         list-iterator does not support the {@code set} operation.
      */
-    @SuppressWarnings({"rawtypes", "unchecked"})
     public static void shuffle(List<?> list, Random rnd) {
+        shuffle(list, (RandomGenerator) rnd);
+    }
+
+    @SuppressWarnings({"rawtypes", "unchecked"})
+    public static void shuffle(List<?> list, RandomGenerator rnd) {
         int size = list.size();
         if (size < SHUFFLE_THRESHOLD || list instanceof RandomAccess) {
             for (int i=size; i>1; i--)

What do you think? Should we implement this improvement? I think I can
contribute if there's a general agreement that such an enhancement
would be useful.

With best regards,
Tagir Valeev

From avoitylov at openjdk.org  Tue Sep 27 10:34:21 2022
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Tue, 27 Sep 2022 10:34:21 GMT
Subject: RFR: 8294198: Implement isFinite intrinsic for RISC-V
In-Reply-To: <R4tlj4gD-vO5BzJKgAx9-O4s7BD7q6NlLhMhl6PMUuc=.c67bb8fb-3bf1-4035-be21-cc873220bf70@github.com>
References: <R4tlj4gD-vO5BzJKgAx9-O4s7BD7q6NlLhMhl6PMUuc=.c67bb8fb-3bf1-4035-be21-cc873220bf70@github.com>
Message-ID: <8oUXKGdFua0Px3qX0MkyHaegyTk-hsah12SDmZiu_qk=.222f6369-d18a-4ccb-bf67-dd03d04eb0fc@github.com>

On Thu, 22 Sep 2022 12:56:49 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

> Unlike on x86 (see 8285868 and the discussion in review), isFinite intrinsic turned out to be profitable on RISC-V using the same fclass instruction as for 8293695 (isInfinite instrinsic). Therefore, I'm proposing to have it added on RISC-V in this PR.
> 
> benchmark results:
> 
> before:
> 
> Benchmark                              Mode  Cnt   Score   Error  Units
> DoubleClassCheck.testIsFiniteBranch    avgt   15  52.824 ? 1.744  ns/op
> DoubleClassCheck.testIsFiniteCMov      avgt   15  16.104 ? 0.358  ns/op
> DoubleClassCheck.testIsFiniteStore     avgt   15  14.366 ? 2.174  ns/op
> FloatClassCheck.testIsFiniteBranch     avgt   15  49.821 ? 0.330  ns/op
> FloatClassCheck.testIsFiniteCMov       avgt   15  14.702 ? 0.335  ns/op
> FloatClassCheck.testIsFiniteStore      avgt   15  14.749 ? 0.496  ns/op
> 
> after:
> 
> DoubleClassCheck.testIsFiniteBranch    avgt   15  48.921 ? 0.557  ns/op
> DoubleClassCheck.testIsFiniteCMov      avgt   15  13.716 ? 0.304  ns/op
> DoubleClassCheck.testIsFiniteStore     avgt   15   9.152 ? 0.158  ns/op
> FloatClassCheck.testIsFiniteBranch     avgt   15  47.740 ? 2.028  ns/op
> FloatClassCheck.testIsFiniteCMov       avgt   15  13.299 ? 0.282  ns/op
> FloatClassCheck.testIsFiniteStore      avgt   15   9.185 ? 0.396  ns/op
> 
> Existing isInfinite jtreg test was altered to be able to use common code for isFinite test and fine-grained requires tag filtering. Existing benchmark was modified to include isFinite case. A typo ("Atleast" -> "At least") was fixed on the way.
> 
> Test passed on both release and fastdebug builds. Hotspot tier1 tests were run on x86_64 and RISC-V with no issues.

@vnkozlov could you or someone familiar with C2 look at shared C2 HotSpot changes? I did test it on x86, but any extra testing could help as well.

-------------

PR: https://git.openjdk.org/jdk/pull/10391

From dl at openjdk.org  Tue Sep 27 10:55:30 2022
From: dl at openjdk.org (Doug Lea)
Date: Tue, 27 Sep 2022 10:55:30 GMT
Subject: Integrated: 8292969: Bad Thread Utilization in ForkJoinPool
In-Reply-To: <QzRti_crUWUQZ6PTLo0V-9YjIF40v0RDkS0E_4-anSc=.a68d897f-ac2c-4060-994c-3fb8b39d988e@github.com>
References: <QzRti_crUWUQZ6PTLo0V-9YjIF40v0RDkS0E_4-anSc=.a68d897f-ac2c-4060-994c-3fb8b39d988e@github.com>
Message-ID: <YTx59G0NS_1ggHUQxxdyULg6nlcYe3RxW5JSjgt9vtQ=.df8a4089-d9e3-4119-9f0b-ff6b2c44a63e@github.com>

On Wed, 7 Sep 2022 12:44:11 GMT, Doug Lea <dl at openjdk.org> wrote:

> 8292969: This small change in signal propagation rules improves utilization when entry queues are resized,

This pull request has now been integrated.

Changeset: bc12e955
Author:    Doug Lea <dl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bc12e9553d30fbf849b5a681137a231ff083d901
Stats:     6 lines in 1 file changed: 1 ins; 0 del; 5 mod

8292969: Bad Thread Utilization in ForkJoinPool

Reviewed-by: shade, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/10198

From hannesw at openjdk.org  Tue Sep 27 11:37:23 2022
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 27 Sep 2022 11:37:23 GMT
Subject: RFR: JDK-8287597: List all preview features on the javadoc PREVIEW
 page [v4]
In-Reply-To: <0UfKceKzCT3_exJ2vDs5y7IeroB2IHU8kHPO7b46KDY=.bbc662cb-5bd9-4205-acc2-3025ad1a5ab1@github.com>
References: <0UfKceKzCT3_exJ2vDs5y7IeroB2IHU8kHPO7b46KDY=.bbc662cb-5bd9-4205-acc2-3025ad1a5ab1@github.com>
Message-ID: <d-6h91d_CUceEHACGegid35NS2lNqSqoWOLPgDfCtkM=.1c4e879f-5860-4fab-b783-07381ffcfd31@github.com>

> Please review an enhancement to the preview page to add a list of preview features and allow users to explore the preview APIs by feature. 
> 
> While the changes for the enhancement itself are not overly complex, the work entailed a moderate cleanup of other summary API lists (Deprecated and New API pages) as well as a few unrelated summary pages that happened to share some of the CSS classes and HTML structure.
> 
> The change itself starts with a new internal `jdk.internal.javac.PreviewFeature.JEP` annotation interface to add JEP information to the nearby `jdk.internal.javac.PreviewFeature.Feature` enum. This JEP information is retrieved by new methods in the javadoc `Utils` class and then fetched by `PreviewAPIListBuilder` which passes it on to `PreviewListWriter`. 
> 
> The superclass of `PreviewListWriter` and other API summary writer classes, `SummaryListWriter`, gets a new `addContentSelectors(Content)` method to add the checkboxes to show/hide various parts of the page content. The class is also now abstract as this and other methods do not have useful implementations in the base class. 
> 
> Another change to `SummaryListWriter` is that `pageMode`, `description`, `headContent` and `titleKey` are no longer fields in the class but rather sent to the `generateSummaryListFile` method as parameters since they are mostly just used locally in that method. On the other hand, the associated Builder is used in many places and previously had to be retrieved from the configuration object or passed around as parameter, so that is now set as a final field in `SummaryListWriter`. 
> 
> Finally, a few words about changes in CSS and HTML: The "Contents" list containing various kinds of elements in the API list was previously contained in the `<div class="header">` element that also contains the page header, and the stylesheet used the `.header ul`  selector to style the list. Now that the checkboxes separate the page header from the contents list it felt wrong to put all this in the header div (most other pages only use the div for the header itself). I also didn't like the indirect CSS selector too much, `.header ul` is not very indicative of what it applies to.
> 
> I therefore decided to create a new dedicated CSS class for the contents list called `contents-list`, and move the `<ul>` element out of the header div. Apart from the summary API pages, this change also affects the "Constant Values"  page as well as the top and package level "Tree" (class hierarchy) pages. I made sure the contents list in these pages look the same as before.
> 
> The list items in the contents list now each have an `id` attribute to allow hiding the list item if no content for the element kind is currently selected/visible. The value of the `id` attribute uses the format `contents-<element-kind>`.
> 
> There is one additional CSS class called `preview-feature-list` used for the list of preview feature JEPs. 
> 
> Demo output for the new preview page as well as other pages is available here:
> http://cr.openjdk.java.net/~hannesw/8287597/api.03/preview-list.html

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  Fix URL in test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9336/files
  - new: https://git.openjdk.org/jdk/pull/9336/files/1187024b..94dc98c6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9336&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9336&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9336.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9336/head:pull/9336

PR: https://git.openjdk.org/jdk/pull/9336

From dnsimon at openjdk.org  Tue Sep 27 11:38:59 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 27 Sep 2022 11:38:59 GMT
Subject: RFR: 8237467: effect of jlink plugins for vendor information and
 command-line options should be sticky
Message-ID: <ol0heS5-LEFjuZkoFjkdraX-9tjEQ371Pii5KkYyO1c=.1cdd4b7d-426d-4075-ac99-9460d0200904@github.com>

This PR adds a new jlink plugin (`--save-jlink-argfiles=<filenames>`) to support persisting jlink options.


> echo "--add-modules jdk.internal.vm.ci --add-options=-Dfoo=xyzzy --vendor-version="XyzzyVM 3.14.15" --vendor-bug-url=https://bugs.xyzzy.com/" > my_image.argfile
> export ALL_MODULES=$(java --list-modules | sed 's:@.*::g' | tr '\n' ',')
> jlink --keep-packaged-modules=my_image/jmods --add-modules $ALL_MODULES --output=my_image --save-jlink-argfiles my_image.argfile
> my_image/bin/java -XshowSettings:properties --version 2>&1 | grep yzzy
> my_image/bin/jlink --add-modules=java.base --output=my_image2
> my_image2/bin/java -XshowSettings:properties --version 2>&1 | grep yzzy
    foo = xyzzy
    java.vendor.url.bug = https://bugs.xyzzy.com/
    java.vendor.version = XyzzyVM 3.14.15
OpenJDK Runtime Environment XyzzyVM 3.14.15 (build 20-internal-2022-09-22-0951036.dnsimon...)
OpenJDK 64-Bit Server VM XyzzyVM 3.14.15 (build 20-internal-2022-09-22-0951036.dnsimon..., mixed mode)
> my_image2/bin/java -d jdk.internal.vm.ci | head -1
jdk.internal.vm.ci at 20-internal

-------------

Commit messages:
 - add SaveJlinkArgfilesPlugin

Changes: https://git.openjdk.org/jdk/pull/10445/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10445&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8237467
  Stats: 419 lines in 6 files changed: 418 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10445.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10445/head:pull/10445

PR: https://git.openjdk.org/jdk/pull/10445

From dnsimon at openjdk.org  Tue Sep 27 11:39:44 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 27 Sep 2022 11:39:44 GMT
Subject: RFR: 8294394: running jlink in GraalVM must copy libgraal into the
 output image
Message-ID: <S3wMCKeiTrZJKxEPgpO2wy35kIipmSYnHeXYMzIIm7Q=.081f00f8-6c29-43d6-a685-e3fd048dfd55@github.com>

This PR adds a new jlink plugin (`--copy-files=<filenames>`) that copies specified files from the current image into the output image.
This is useful in the context of GraalVM where libgraal (e.g. `lib/libjvmcicompiler.so`) is produced after the final jlink step in the GraalVM JDK build process. The plugin makes it possible for jlink in a GraalVM JDK to propagate libgraal.

The advantages of this solution over packaging libgraal as a module are:
* No need to complicate and slow down the GraalVM JDK build process with an extra jlink step.
* No need to pay the footprint of libgraal twice in a GraalVM JDK (i.e., once in,`lib/libjvmcicompiler.so` and again in a jmod file).

-------------

Commit messages:
 - add CopyFilesPlugin

Changes: https://git.openjdk.org/jdk/pull/10448/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10448&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294394
  Stats: 205 lines in 4 files changed: 205 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10448.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10448/head:pull/10448

PR: https://git.openjdk.org/jdk/pull/10448

From alanb at openjdk.org  Tue Sep 27 11:40:30 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 27 Sep 2022 11:40:30 GMT
Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume [v3]
In-Reply-To: <qCI92xJUfPZdfdgharNxiBnT2fv89IrS-02K4zJhQaA=.0d29302a-9603-490e-a28e-30861631c1ba@github.com>
References: <l_lUEdZ-ORALa9ux2qu_PZZFm2IpIZs02kdC-tCQQBM=.e96f9fab-8d68-4ba1-b0f6-2b9b5c397226@github.com>
 <qCI92xJUfPZdfdgharNxiBnT2fv89IrS-02K4zJhQaA=.0d29302a-9603-490e-a28e-30861631c1ba@github.com>
Message-ID: <Xk2Pw2LHXKS22OYcjJ13HZ1zTpxcqwwA7ZdENN-7dkU=.985cd33f-5771-47e4-97fe-245459c5b6a7@github.com>

On Sat, 24 Sep 2022 06:50:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Degrade Thread.suspend/resume to throw UOE unconditionally.
>> 
>> Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive.
>> 
>> The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs.
>> 
>> Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread).
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Remove tests from exclude list
>  - Merge
>  - Update DegradedMethodsThrowUOE to test Thread.stop
>  - Merge
>  - Update modifyThread and modifyThreadGroup targets
>  - Merge
>  - Fix typo in test comment
>  - Keep link to threadPrimitiveDeprecation.html
>  - Merge
>  - Tests
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/543851db...6aa38889

Wakeup bot

-------------

PR: https://git.openjdk.org/jdk/pull/10324

From mik3hall at gmail.com  Tue Sep 27 11:44:01 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 27 Sep 2022 06:44:01 -0500
Subject: RFR: 8293462: [macos] app image signature invalid when creating
 DMG or PKG from post processed signed image
In-Reply-To: <9CC241FC-952A-46D6-BBF7-FC1CBE094AE0@gmail.com>
References: <-sMR9P3CEZeJ31UFe7bzIcnC86rSErUVbY0GOymUoo4=.7c954bca-25c7-4fa0-9e2a-076ce2a485d4@github.com>
 <20F8AC2D-C71B-4892-A2F3-C9A07501046F@gmail.com>
 <707A13E7-9047-428B-86FA-C4DFA047146C@oracle.com>
 <D847BFBF-6DEE-4F39-8EF8-5E1CF3CE3453@gmail.com>
 <A80F3462-C69A-401D-BD23-26391CD96B8C@gmail.com>
 <9CC241FC-952A-46D6-BBF7-FC1CBE094AE0@gmail.com>
Message-ID: <55C45641-6A82-4F9D-85DA-4A757AB209AD@gmail.com>



> On Sep 26, 2022, at 9:24 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> 
>> On Sep 20, 2022, at 5:50 PM, Michael Hall <mik3hall at gmail.com <mailto:mik3hall at gmail.com>> wrote:
>> 
>> Still you could use post-processing to add whatever java binary executable commands you wanted. This again would mean changes to the embedded jdk that might have signing side effects. I haven?t tested.  
> 
> Thinking about this I looked at my application that includes java commands and saw that currently I include all. And all appear to be of fixed size. So I assume some kind of launcher stub?
> 
> I then remembered 
> 
> [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe
> https://bugs.openjdk.org/browse/JDK-8286122 <https://bugs.openjdk.org/browse/JDK-8286122>
> 

It might be an idea, if coming up with a unique or hashed CFBundleIdentifier in the Info.plist isn?t seen as a workable alternative, for jpackage to issue a warning anytime jlink parameters are passed without ?strip-native-commands to issue a warning message that the application will not be eligible for the Mac App Store. 
So developers don?t develop applications with a dependency on native commands intending them for the Mac App Store only to find out when they attempt a final MAS version that they are prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220927/8afa5f23/attachment.htm>

From alanb at openjdk.org  Tue Sep 27 11:47:20 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 27 Sep 2022 11:47:20 GMT
Subject: Integrated: 8249627: Degrade Thread.suspend and Thread.resume
In-Reply-To: <l_lUEdZ-ORALa9ux2qu_PZZFm2IpIZs02kdC-tCQQBM=.e96f9fab-8d68-4ba1-b0f6-2b9b5c397226@github.com>
References: <l_lUEdZ-ORALa9ux2qu_PZZFm2IpIZs02kdC-tCQQBM=.e96f9fab-8d68-4ba1-b0f6-2b9b5c397226@github.com>
Message-ID: <hQyXm_7qyfPEvom20HL7JWXN1PFWcrw0I3oFvOTmkuU=.157e00a2-c2c0-473f-a3bb-720009b73878@github.com>

On Sun, 18 Sep 2022 16:32:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Degrade Thread.suspend/resume to throw UOE unconditionally.
> 
> Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive.
> 
> The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs.
> 
> Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread).

This pull request has now been integrated.

Changeset: 1abf971b
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1abf971b93222f422c0026cee944a6db214f955a
Stats:     454 lines in 16 files changed: 136 ins; 255 del; 63 mod

8249627: Degrade Thread.suspend and Thread.resume

Reviewed-by: cjplummer, sspitsyn, dholmes, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/10324

From prappo at openjdk.org  Tue Sep 27 11:52:57 2022
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 27 Sep 2022 11:52:57 GMT
Subject: RFR: 8294377: Prepare to stop auto-inheriting documentation for
 subclasses of exceptions whose documentation is inherited
Message-ID: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>

This adds exception documentation to JDK methods that would otherwise lose that documentation once JDK-8287796 is integrated. While adding this exception documentation now does not change [^1] the JDK API Documentation, it will automatically counterbalance the effect that JDK-8287796 will have.

JDK-8287796 seeks to remove an old, undocumented, and esoteric javadoc feature that cannot be suppressed [^2]. The feature is so little known about that IDEs either do not implement it correctly or do not implement it at all, thus rendering documentation differently from how the javadoc tool renders it.

That feature was introduced in JDK-4947455 and manifests as follows. If a method inherits documentation for an exception, along with that documentation the method automatically inherits documentation for all exceptions that are subclasses of that former exception and are documented in an overridden method.

To illustrate that behavior, consider the following example. A method `Subtype.m` inherits documentation for `SuperException`, while the overridden method `Supertype.m` documents `SuperException`, `SubExceptionA` and `SubExceptionB`, where the latter two exceptions are subclasses of the former exception:

    public class Subtype extends Supertype {

        @Override
        public void m() throws SuperException {
    ...

    public class Supertype {

        /**
         * @throws SuperException general problem
         * @throws SubExceptionA  specific problem A
         * @throws SubExceptionB  specific problem B
         */
        public void m() throws SuperException {
    ...

    public class SuperException extends Exception {
    ...

    public class SubExceptionA extends SuperException {
    ...

    public class SubExceptionB extends SuperException {
    ...

For the above example, the API Documentation for `Subtype.m` will contain documentation for all three exceptions; the page fragment for `Subtype.m` in "Method Details" will look like this:

    public void m()
           throws SuperException

    Overrides:
        m in class Supertype
    Throws:
        SuperException - general problem
        SubExceptionA - specific problem A
        SubExceptionB - specific problem B 

It works for checked and unchecked exceptions, for methods in classes and interfaces.


If it's the first time you hear about that behavior and this change affects your area, it's a good opportunity to reflect on whether the exception documentation this change adds is really needed or you were simply unaware of the fact that it was automatically added before. If exception documentation is not needed, please comment on this PR. Otherwise, consider approving it.

Keep in mind that if some exception documentation is not needed, **leaving it out** from this PR might require a CSR.


[^1]: Aside from insignificant changes on class-use and index pages. There's one relatively significant change. This change is in jdk.jshell, where some methods disappeared from "Methods declared in ..." section and other irregularities. We are aware of this and have filed JDK-8291803 to fix the root cause.
[^2]: In reality, the feature can be suppressed, but it looks like a bug rather than intentional design. If we legitimize the feature and its suppression behavior, the model for exception documentation inheritance might become much more complicated.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/10449/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10449&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294377
  Stats: 322 lines in 15 files changed: 311 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/10449.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10449/head:pull/10449

PR: https://git.openjdk.org/jdk/pull/10449

From prappo at openjdk.org  Tue Sep 27 12:14:23 2022
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 27 Sep 2022 12:14:23 GMT
Subject: RFR: 8294377: Prepare to stop auto-inheriting documentation for
 subclasses of exceptions whose documentation is inherited [v2]
In-Reply-To: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>
References: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>
Message-ID: <rZOv9leE3Krs9IA7nAMMZPVelsIgC5am13o1oU8BF8Y=.fe7d7524-1a12-4a38-aedb-f9dd60cdded8@github.com>

> This adds exception documentation to JDK methods that would otherwise lose that documentation once JDK-8287796 is integrated. While adding this exception documentation now does not change [^1] the JDK API Documentation, it will automatically counterbalance the effect that JDK-8287796 will have.
> 
> JDK-8287796 seeks to remove an old, undocumented, and esoteric javadoc feature that cannot be suppressed [^2]. The feature is so little known about that IDEs either do not implement it correctly or do not implement it at all, thus rendering documentation differently from how the javadoc tool renders it.
> 
> That feature was introduced in JDK-4947455 and manifests as follows. If a method inherits documentation for an exception, along with that documentation the method automatically inherits documentation for all exceptions that are subclasses of that former exception and are documented in an overridden method.
> 
> To illustrate that behavior, consider the following example. A method `Subtype.m` inherits documentation for `SuperException`, while the overridden method `Supertype.m` documents `SuperException`, `SubExceptionA` and `SubExceptionB`, where the latter two exceptions are subclasses of the former exception:
> 
>     public class Subtype extends Supertype {
> 
>         @Override
>         public void m() throws SuperException {
>     ...
> 
>     public class Supertype {
> 
>         /**
>          * @throws SuperException general problem
>          * @throws SubExceptionA  specific problem A
>          * @throws SubExceptionB  specific problem B
>          */
>         public void m() throws SuperException {
>     ...
> 
>     public class SuperException extends Exception {
>     ...
> 
>     public class SubExceptionA extends SuperException {
>     ...
> 
>     public class SubExceptionB extends SuperException {
>     ...
> 
> For the above example, the API Documentation for `Subtype.m` will contain documentation for all three exceptions; the page fragment for `Subtype.m` in "Method Details" will look like this:
> 
>     public void m()
>            throws SuperException
> 
>     Overrides:
>         m in class Supertype
>     Throws:
>         SuperException - general problem
>         SubExceptionA - specific problem A
>         SubExceptionB - specific problem B 
> 
> It works for checked and unchecked exceptions, for methods in classes and interfaces.
> 
> 
> If it's the first time you hear about that behavior and this change affects your area, it's a good opportunity to reflect on whether the exception documentation this change adds is really needed or you were simply unaware of the fact that it was automatically added before. If exception documentation is not needed, please comment on this PR. Otherwise, consider approving it.
> 
> Keep in mind that if some exception documentation is not needed, **leaving it out** from this PR might require a CSR.
> 
> 
> [^1]: Aside from insignificant changes on class-use and index pages. There's one relatively significant change. This change is in jdk.jshell, where some methods disappeared from "Methods declared in ..." section and other irregularities. We are aware of this and have filed JDK-8291803 to fix the root cause.
> [^2]: In reality, the feature can be suppressed, but it looks like a bug rather than intentional design. If we legitimize the feature and its suppression behavior, the model for exception documentation inheritance might become much more complicated.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  revert an extraneous change to jdk.javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10449/files
  - new: https://git.openjdk.org/jdk/pull/10449/files/87bdbff4..d303f5ec

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10449&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10449&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10449.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10449/head:pull/10449

PR: https://git.openjdk.org/jdk/pull/10449

From coleenp at openjdk.org  Tue Sep 27 12:40:26 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 27 Sep 2022 12:40:26 GMT
Subject: RFR: 8293592: Remove JVM_StopThread, stillborn,
 and related cleanup [v2]
In-Reply-To: <BlMK7IMjTgIiiwSkkF_1-qLlM1AqaKAhLP55-Z1-eeI=.2383991e-22d3-4c0c-afab-353985e1f8fc@github.com>
References: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
 <BlMK7IMjTgIiiwSkkF_1-qLlM1AqaKAhLP55-Z1-eeI=.2383991e-22d3-4c0c-afab-353985e1f8fc@github.com>
Message-ID: <ez7uXhuZsqOLlSjiBuXhtnTypzKqHqDyK5nMGZiOeXg=.1be905dd-e3b1-4d5d-bd79-8f3d8660fcbe@github.com>

On Fri, 23 Sep 2022 21:47:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610).
>> 
>> Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started.
>> 
>> Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same).
>> 
>> Testing: tiers 1-3
>
> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Merge branch 'master' into 8293592-JVM_StopThread
>  - Removal all special handling of ThreadDeath.
>  - Remove all references to the stillborn field
>  - Initial commit: remove JVM_StopThread
>  - Merge
>  - Updates to Java Thread Primitive Deprecation page
>  - Repalce "it" with "victim thread"
>  - Merge
>  - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop
>  - become -> became in javadoc
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/3675f4c2...4eb07903

Marked as reviewed by coleenp (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10400

From erikj at openjdk.org  Tue Sep 27 12:46:24 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 27 Sep 2022 12:46:24 GMT
Subject: RFR: 8294376: Minimize disabled warnings in java.base [v2]
In-Reply-To: <J0i4MkHp8BBQ1Y-OdyH-9OSrhNk648A4x04A2aF45Rs=.adc4b0aa-dd51-42fe-ba79-b1336fd98043@github.com>
References: <R7_lfTjzEBkN-TAZxMd75nnuJ2_ZwAJfcqq-Z1Erhk0=.2aa5ecbd-14bb-4808-9087-21d084c77f8a@github.com>
 <J0i4MkHp8BBQ1Y-OdyH-9OSrhNk648A4x04A2aF45Rs=.adc4b0aa-dd51-42fe-ba79-b1336fd98043@github.com>
Message-ID: <Sw2Aqu_gN1oIDs7Q-pSmX3AIUy5601PeUvFwVvl0Nnc=.96b55c7e-4188-4a77-9a25-110b33a623e2@github.com>

On Tue, 27 Sep 2022 08:32:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in java.base native libraries.
>> 
>> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.
>> 
>> Some warnings didn't trigger in any file anymore, and could just be removed.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'master' into java.base-warnings-per-file
>  - Fixes for linux
>  - Fix windows
>  - Fix macos/aarch64

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10426

From aturbanov at openjdk.org  Tue Sep 27 13:19:39 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 27 Sep 2022 13:19:39 GMT
Subject: Integrated: 8294361: Cleanup usages of StringBuffer in SQLOutputImpl
In-Reply-To: <q_2V_qZS-UHRrwlkokVHntWAjO1XwAxvle5UxkXvK2Q=.e07e382a-efe9-4ff5-80e3-7022100314d5@github.com>
References: <q_2V_qZS-UHRrwlkokVHntWAjO1XwAxvle5UxkXvK2Q=.e07e382a-efe9-4ff5-80e3-7022100314d5@github.com>
Message-ID: <BAcmk0aHBMhtZbeg7Q14W3Mt8xEL4KDLxyTHkEvAoTM=.e0b7eef7-c53e-4381-9dd8-03f9ad865355@github.com>

On Sat, 17 Sep 2022 21:43:04 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There a few unnecessary usages of StringBuffer in SQLOutputImpl class.
> All of them create StringBuffer from single character and then concatenate with String. Instead of this, we can concatenate character directly.

This pull request has now been integrated.

Changeset: 3419363e
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3419363e89eaeef61a44fa1ab12d6a355323eb68
Stats:     36 lines in 1 file changed: 0 ins; 15 del; 21 mod

8294361: Cleanup usages of StringBuffer in SQLOutputImpl

Reviewed-by: rriggs, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/10320

From jbhateja at openjdk.org  Tue Sep 27 13:20:12 2022
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 27 Sep 2022 13:20:12 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v10]
In-Reply-To: <lLRsBGcVOaOTQ8-yuv7AoTMeQEdtXjU3QQVSIzVdRms=.7d0d1d6c-39c8-4136-9d98-db71bc862256@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <lLRsBGcVOaOTQ8-yuv7AoTMeQEdtXjU3QQVSIzVdRms=.7d0d1d6c-39c8-4136-9d98-db71bc862256@github.com>
Message-ID: <FuE9fKcSMtBWqip4uqq9gS_I_1FuGY3QwLRgCTzdh90=.90c229da-0bb7-4a58-b3bc-99cecb217a6c@github.com>

On Tue, 27 Sep 2022 07:40:19 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> 8289552: Make intrinsic conversions between bit representations of half precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments

test/jdk/java/lang/Float/Binary16ConversionNaN.java line 30:

> 28:  * @run main Binary16ConversionNaN
> 29:  * @run main/othervm -XX:+UnlockDiagnosticVMOptions
> 30:  * -XX:DisableIntrinsic=_float16ToFloat,_floatToFloat16 Binary16ConversionNaN

Test is not excising newly added intrinsic code, you may need to adjust the compile threshold and disable tiered compilation.

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From jbhateja at openjdk.org  Tue Sep 27 13:24:27 2022
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 27 Sep 2022 13:24:27 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v10]
In-Reply-To: <lLRsBGcVOaOTQ8-yuv7AoTMeQEdtXjU3QQVSIzVdRms=.7d0d1d6c-39c8-4136-9d98-db71bc862256@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <lLRsBGcVOaOTQ8-yuv7AoTMeQEdtXjU3QQVSIzVdRms=.7d0d1d6c-39c8-4136-9d98-db71bc862256@github.com>
Message-ID: <Xm1jk2ueFwvkB_dCAefK5JgnWTpz18KZoxC0uTNmVxM=.df6b1b3e-4228-4d01-aa64-d9126cace89b@github.com>

On Tue, 27 Sep 2022 07:40:19 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> 8289552: Make intrinsic conversions between bit representations of half precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments

I have verified my other comments,  we can either handle auto-vectorization of newly added intrinsic in this patch of create a follow up PR.

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From duke at openjdk.org  Tue Sep 27 13:32:09 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 27 Sep 2022 13:32:09 GMT
Subject: RFR: 8292937: Improve performance of some read operations of
 RandomAccessFile [v5]
In-Reply-To: <TdC1g_NQiCSbDPsWbNARdSJsSduGZbhuEzCfKQRjm5U=.31e01d71-99c4-4a60-a38a-725aef49a1e2@github.com>
References: <8__MBgqmZ3VCnm2AIMjwSWk3Zk-cv1XSDpEg-iguvKs=.1b823502-0735-4ae8-bc7e-3ceb5e44f986@github.com>
 <TdC1g_NQiCSbDPsWbNARdSJsSduGZbhuEzCfKQRjm5U=.31e01d71-99c4-4a60-a38a-725aef49a1e2@github.com>
Message-ID: <PpkCxEtRcLn5UJ9Fas2YKHOGzwYWySnmFO-coZKr5J4=.0d0bb195-fe33-4490-ae04-1d95db2d0a1e@github.com>

On Fri, 26 Aug 2022 20:59:57 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> Currently some operations of RandomAccessFile are implemented with multiple read() invocations:
>> 
>> public final int readInt() throws IOException {
>>     int ch1 = this.read();
>>     int ch2 = this.read();
>>     int ch3 = this.read();
>>     int ch4 = this.read();
>>     if ((ch1 | ch2 | ch3 | ch4) < 0)
>>       throw new EOFException();
>>     return ((ch1 << 24) + (ch2 << 16) + (ch3 << 8) + (ch4 << 0));
>> }
>> 
>> This can be improved by using bulk reads:
>> 
>> public final int readInt() throws IOException {
>>   readFully(readBuffer, 0, 4);
>>   return Bits.getInt(readBuffer, 0);
>> }
>> 
>> Benchmarking:
>> 
>> baselile
>> Benchmark                                (kiloBytes)  Mode  Cnt     Score      Error  Units
>> RandomAccessFileReadBenchmark.readInt              1  avgt   10  1060,526 ?   62,036  us/op
>> RandomAccessFileReadBenchmark.readInt              5  avgt   10  5745,671 ? 1374,277  us/op
>> RandomAccessFileReadBenchmark.readLong             1  avgt   10  1399,494 ?  378,072  us/op
>> RandomAccessFileReadBenchmark.readLong             5  avgt   10  4864,425 ?  329,282  us/op
>> RandomAccessFileReadBenchmark.readShort            1  avgt   10  1111,163 ?   70,883  us/op
>> RandomAccessFileReadBenchmark.readShort            5  avgt   10  4933,058 ?  339,273  us/op
>> 
>> patch
>> Benchmark                                (kiloBytes)  Mode  Cnt     Score    Error  Units
>> RandomAccessFileReadBenchmark.readInt              1  avgt   10   311,404 ? 17,337  us/op
>> RandomAccessFileReadBenchmark.readInt              5  avgt   10  1210,381 ? 22,742  us/op
>> RandomAccessFileReadBenchmark.readLong             1  avgt   10   201,726 ?  8,885  us/op
>> RandomAccessFileReadBenchmark.readLong             5  avgt   10   667,117 ?  6,779  us/op
>> RandomAccessFileReadBenchmark.readShort            1  avgt   10   560,259 ? 16,783  us/op
>> RandomAccessFileReadBenchmark.readShort            5  avgt   10  2251,975 ? 54,533  us/op
>
> ?????? ??????? has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8292937: Fix error C2057
>  - 8292937: Remove unused method

Should I do anything about this?

-------------

PR: https://git.openjdk.org/jdk/pull/10031

From dsamersoff at openjdk.org  Tue Sep 27 14:51:23 2022
From: dsamersoff at openjdk.org (Dmitry Samersoff)
Date: Tue, 27 Sep 2022 14:51:23 GMT
Subject: RFR: 8293806: JDK_JAVA_OPTIONS picked up twice if LD_LIBRARY_PATH
 is set
In-Reply-To: <kXAQlXcudZELC5v1_dgJmccwdTwUPaXtBfz25rxNtd0=.e7c2815c-9b48-4314-aae5-53dabdaf8274@github.com>
References: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
 <kXAQlXcudZELC5v1_dgJmccwdTwUPaXtBfz25rxNtd0=.e7c2815c-9b48-4314-aae5-53dabdaf8274@github.com>
Message-ID: <UGrIzngLIULLl1fxU9PqMkm3Rocxn4qa4zD2Tz93JRU=.9b786a2d-c284-4c2d-97fd-2d3c8afb0303@github.com>

On Tue, 27 Sep 2022 06:00:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Sorry @dsamersoff but I don't understand how this arises - can you explain in more detail please? I'm not seeing the connection between setting `LD_LIBRARY_PATH` and reading an env var twice. Thanks

Linker read LD_LIBRARY_PATH only once, at the time of program loading, so if for some reason launcher need to update LD_LIBRARY_PATH, it creates a new environment and re-launch it self using execvp(). 

But the launcher is designed so that the decision to re-launch is made after all arguments from all sources have already been processed and copied to the argv array.

-------------

PR: https://git.openjdk.org/jdk/pull/10430

From alanb at openjdk.org  Tue Sep 27 14:58:30 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 27 Sep 2022 14:58:30 GMT
Subject: RFR: 8294394: running jlink in GraalVM must copy libgraal into the
 output image
In-Reply-To: <S3wMCKeiTrZJKxEPgpO2wy35kIipmSYnHeXYMzIIm7Q=.081f00f8-6c29-43d6-a685-e3fd048dfd55@github.com>
References: <S3wMCKeiTrZJKxEPgpO2wy35kIipmSYnHeXYMzIIm7Q=.081f00f8-6c29-43d6-a685-e3fd048dfd55@github.com>
Message-ID: <pXIp31O9gSt8pv7TW7lrQE0cCWVoRn8PA9h9DTneJK4=.f13d5863-cdeb-4da0-82dc-9432244e00fd@github.com>

On Tue, 27 Sep 2022 11:30:26 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR adds a new jlink plugin (`--copy-files=<filenames>`) that copies specified files from the current image into the output image.
> This is useful in the context of GraalVM where libgraal (e.g. `lib/libjvmcicompiler.so`) is produced after the final jlink step in the GraalVM JDK build process. The plugin makes it possible for jlink in a GraalVM JDK to propagate libgraal.
> 
> The advantages of this solution over packaging libgraal as a module are:
> * No need to complicate and slow down the GraalVM JDK build process with an extra jlink step.
> * No need to pay the footprint of libgraal twice in a GraalVM JDK (i.e., once in,`lib/libjvmcicompiler.so` and again in a jmod file).

@dougxc  As you know, the JDK moved to a modular run-image in JDK 9 with jlink generating a run-time image from a set of modules. Aside from src.zip, we've avoiding needing to overlay files that aren't coming from modules so it sets up jlink for possible optimizations in the future where it knows about all classes and resources. A general purpose CopyFiles plugin goes against that design/direction to some extent as it can be used to copy anything into the run-time image. The jlink tool may be doing the copying but the connection to any module is lost. So I think we need to be cautious and fully understand the problems. What are the complicates and performance issues when libjvmcicompiler.so is in a module? Is this a jmod or jlink performance issue that should be looked at?

-------------

PR: https://git.openjdk.org/jdk/pull/10448

From kvn at openjdk.org  Tue Sep 27 16:04:35 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 27 Sep 2022 16:04:35 GMT
Subject: RFR: 8294198: Implement isFinite intrinsic for RISC-V
In-Reply-To: <R4tlj4gD-vO5BzJKgAx9-O4s7BD7q6NlLhMhl6PMUuc=.c67bb8fb-3bf1-4035-be21-cc873220bf70@github.com>
References: <R4tlj4gD-vO5BzJKgAx9-O4s7BD7q6NlLhMhl6PMUuc=.c67bb8fb-3bf1-4035-be21-cc873220bf70@github.com>
Message-ID: <_srvgaMcXUDIvMxpQHD_y8jNH8pLEuOt7Uxdpi6dnaU=.14b20934-d921-4e84-b391-344a5f35e114@github.com>

On Thu, 22 Sep 2022 12:56:49 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

> Unlike on x86 (see 8285868 and the discussion in review), isFinite intrinsic turned out to be profitable on RISC-V using the same fclass instruction as for 8293695 (isInfinite instrinsic). Therefore, I'm proposing to have it added on RISC-V in this PR.
> 
> benchmark results:
> 
> before:
> 
> Benchmark                              Mode  Cnt   Score   Error  Units
> DoubleClassCheck.testIsFiniteBranch    avgt   15  52.824 ? 1.744  ns/op
> DoubleClassCheck.testIsFiniteCMov      avgt   15  16.104 ? 0.358  ns/op
> DoubleClassCheck.testIsFiniteStore     avgt   15  14.366 ? 2.174  ns/op
> FloatClassCheck.testIsFiniteBranch     avgt   15  49.821 ? 0.330  ns/op
> FloatClassCheck.testIsFiniteCMov       avgt   15  14.702 ? 0.335  ns/op
> FloatClassCheck.testIsFiniteStore      avgt   15  14.749 ? 0.496  ns/op
> 
> after:
> 
> DoubleClassCheck.testIsFiniteBranch    avgt   15  48.921 ? 0.557  ns/op
> DoubleClassCheck.testIsFiniteCMov      avgt   15  13.716 ? 0.304  ns/op
> DoubleClassCheck.testIsFiniteStore     avgt   15   9.152 ? 0.158  ns/op
> FloatClassCheck.testIsFiniteBranch     avgt   15  47.740 ? 2.028  ns/op
> FloatClassCheck.testIsFiniteCMov       avgt   15  13.299 ? 0.282  ns/op
> FloatClassCheck.testIsFiniteStore      avgt   15   9.185 ? 0.396  ns/op
> 
> Existing isInfinite jtreg test was altered to be able to use common code for isFinite test and fine-grained requires tag filtering. Existing benchmark was modified to include isFinite case. A typo ("Atleast" -> "At least") was fixed on the way.
> 
> Test passed on both release and fastdebug builds. Hotspot tier1 tests were run on x86_64 and RISC-V with no issues.

I don't think old tests TestFloatClassCheck.java and TestDoubleClassCheck.java are modified correctly - they do nothing now. They have to run compiled methods and verify results.

Other then that changes seem fine.

-------------

Changes requested by kvn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10391

From naoto at openjdk.org  Tue Sep 27 16:05:22 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 Sep 2022 16:05:22 GMT
Subject: Integrated: 8294317: Insufficient build rules for tzdb.dat
In-Reply-To: <WS7j8PLGWmQXKydFbhYDSic55ECn9p40NdRIcS7TRHs=.43ced95c-1843-4d3b-9cb1-d526618e0678@github.com>
References: <WS7j8PLGWmQXKydFbhYDSic55ECn9p40NdRIcS7TRHs=.43ced95c-1843-4d3b-9cb1-d526618e0678@github.com>
Message-ID: <ENu5du0eEAupDP8jiI5x5uOppSsZ8Y5o6FGTuN3Wn0Q=.9cd57215-2c16-41d9-be8e-5ff99b2ffb7d@github.com>

On Fri, 23 Sep 2022 22:10:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The current makefile for `tzdb.dat` won't recompile if some dependent files (e.g. `VERSION`) are updated. Adding all files under the tzdb directory to the dependency will fix this issue.

This pull request has now been integrated.

Changeset: 71511283
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/71511283ce02f52aba855a84cc67ba579ab8b586
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8294317: Insufficient build rules for tzdb.dat

Reviewed-by: joehw, erikj

-------------

PR: https://git.openjdk.org/jdk/pull/10415

From duke at openjdk.org  Tue Sep 27 16:07:35 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Tue, 27 Sep 2022 16:07:35 GMT
Subject: Integrated: 8289797: tools/launcher/I18NArgTest.java fails on Japanese
 Windows environment
In-Reply-To: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
References: <jEDJ-krgPoijm-bZxDH6DqxhkBJWmehoXqtKwTXlriQ=.91ae6138-8f9e-4e73-a9cf-fe8189e9706a@github.com>
Message-ID: <Q-AiUyxg6BhmeTABPqaMl6XuvhVSiLtCUTRxqJD3Wv4=.29a8cc15-be64-47a0-9064-df7ea80a73b0@github.com>

On Wed, 6 Jul 2022 06:40:32 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

> I removed a section of via JDK_JAVA_OPTIONS because including main class is not allowed in the specification.
> This behavior is added in JDK-8170832, which add JAVA_OPTIONS environment variable. At this time, this test is mismatch with the specification.
> I tried to test and get Passed on Japanese Windows environment.
> Could you review this fix, please?

This pull request has now been integrated.

Changeset: a11477ce
Author:    KIRIYAMA Takuya <kiriyama.takuya at fujitsu.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a11477ce259d6d2a053117a2300ebb171145cfde
Stats:     51 lines in 1 file changed: 26 ins; 3 del; 22 mod

8289797: tools/launcher/I18NArgTest.java fails on Japanese Windows environment

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/9389

From jwaters at openjdk.org  Tue Sep 27 16:19:20 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 27 Sep 2022 16:19:20 GMT
Subject: RFR: 8292016: Split Windows API error handling from errors passed
 through the runtime in the JDK [v22]
In-Reply-To: <OjGBI4cbdqxyuIjruGTV3GXkajZgbVfAgNKakOnIMnk=.d27dc4fc-ec28-4f4b-b19c-37d9e496c126@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
 <S3foO_lw8Qp5f1NosQ8cx1v96miI57hdDTQ4FIOlYbo=.26b894ca-3505-46e9-9c43-d381e2d4e1bc@github.com>
 <OjGBI4cbdqxyuIjruGTV3GXkajZgbVfAgNKakOnIMnk=.d27dc4fc-ec28-4f4b-b19c-37d9e496c126@github.com>
Message-ID: <lw9XvGNXkiMcKHqHcdIqDHNikiV9ymaBd_RhadHko1c=.ca31ea69-34a3-4858-acf7-e9ac010152e3@github.com>

On Tue, 27 Sep 2022 04:22:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This seems to be trying to future-proof the reporting code by introducing a duality that is not actually needed at present in some cases. That means the code is untested. Are there planned uses of `RUNTIME` in the very near future?

The only use of it is to differentiate Windows API errors from the regular errno ones thus far, I doubt this will change any time soon. Honestly speaking I'm not very happy with the changes here, and it's been pretty tricky trying to come up with an elegant solution to this issue, but I'm not sure if the alternative of deleting all the error reporting utilities across the JDK and using what C already has (for instance perror) is acceptable in this case, because pretty much all of them have this same problem (and is also why I refrained from outright removing JLI_ReportErrorMessageSys initially like Thomas suggested). On the flip side, all of them don't seem to be used in _too many_ places, and can be rather easily replaced, so it is a little tempting to remove them and just sidestep the problem instead. Are any of these a part of the public JNI API?

-------------

PR: https://git.openjdk.org/jdk/pull/9870

From kvn at openjdk.org  Tue Sep 27 16:35:20 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 27 Sep 2022 16:35:20 GMT
Subject: RFR: 8294198: Implement isFinite intrinsic for RISC-V
In-Reply-To: <R4tlj4gD-vO5BzJKgAx9-O4s7BD7q6NlLhMhl6PMUuc=.c67bb8fb-3bf1-4035-be21-cc873220bf70@github.com>
References: <R4tlj4gD-vO5BzJKgAx9-O4s7BD7q6NlLhMhl6PMUuc=.c67bb8fb-3bf1-4035-be21-cc873220bf70@github.com>
Message-ID: <Fsv198Nhm0gn3lFjdFJ-clyzENzaJirrB4JBwI9n6rk=.654bea9d-f0cc-4b93-b222-8f6be3380f53@github.com>

On Thu, 22 Sep 2022 12:56:49 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

> Unlike on x86 (see 8285868 and the discussion in review), isFinite intrinsic turned out to be profitable on RISC-V using the same fclass instruction as for 8293695 (isInfinite instrinsic). Therefore, I'm proposing to have it added on RISC-V in this PR.
> 
> benchmark results:
> 
> before:
> 
> Benchmark                              Mode  Cnt   Score   Error  Units
> DoubleClassCheck.testIsFiniteBranch    avgt   15  52.824 ? 1.744  ns/op
> DoubleClassCheck.testIsFiniteCMov      avgt   15  16.104 ? 0.358  ns/op
> DoubleClassCheck.testIsFiniteStore     avgt   15  14.366 ? 2.174  ns/op
> FloatClassCheck.testIsFiniteBranch     avgt   15  49.821 ? 0.330  ns/op
> FloatClassCheck.testIsFiniteCMov       avgt   15  14.702 ? 0.335  ns/op
> FloatClassCheck.testIsFiniteStore      avgt   15  14.749 ? 0.496  ns/op
> 
> after:
> 
> DoubleClassCheck.testIsFiniteBranch    avgt   15  48.921 ? 0.557  ns/op
> DoubleClassCheck.testIsFiniteCMov      avgt   15  13.716 ? 0.304  ns/op
> DoubleClassCheck.testIsFiniteStore     avgt   15   9.152 ? 0.158  ns/op
> FloatClassCheck.testIsFiniteBranch     avgt   15  47.740 ? 2.028  ns/op
> FloatClassCheck.testIsFiniteCMov       avgt   15  13.299 ? 0.282  ns/op
> FloatClassCheck.testIsFiniteStore      avgt   15   9.185 ? 0.396  ns/op
> 
> Existing isInfinite jtreg test was altered to be able to use common code for isFinite test and fine-grained requires tag filtering. Existing benchmark was modified to include isFinite case. A typo ("Atleast" -> "At least") was fixed on the way.
> 
> Test passed on both release and fastdebug builds. Hotspot tier1 tests were run on x86_64 and RISC-V with no issues.

Not enough coffee at the morning ;^)
Finally noticed how new and old test interact.
Changes are fine and I submitted testing.

-------------

PR: https://git.openjdk.org/jdk/pull/10391

From dnsimon at openjdk.org  Tue Sep 27 18:17:14 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 27 Sep 2022 18:17:14 GMT
Subject: RFR: 8294394: running jlink in GraalVM must copy libgraal into the
 output image
In-Reply-To: <S3wMCKeiTrZJKxEPgpO2wy35kIipmSYnHeXYMzIIm7Q=.081f00f8-6c29-43d6-a685-e3fd048dfd55@github.com>
References: <S3wMCKeiTrZJKxEPgpO2wy35kIipmSYnHeXYMzIIm7Q=.081f00f8-6c29-43d6-a685-e3fd048dfd55@github.com>
Message-ID: <mGqWJxzx8-4QUh_RJ7UNpTuhbhysKJ3xG7zbGh6xfF8=.93a93394-3c82-4b16-94a6-b8f644e41bfc@github.com>

On Tue, 27 Sep 2022 11:30:26 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR adds a new jlink plugin (`--copy-files=<filenames>`) that copies specified files from the current image into the output image.
> This is useful in the context of GraalVM where libgraal (e.g. `lib/libjvmcicompiler.so`) is produced after the final jlink step in the GraalVM JDK build process. The plugin makes it possible for jlink in a GraalVM JDK to propagate libgraal.
> 
> The advantages of this solution over packaging libgraal as a module are:
> * No need to complicate and slow down the GraalVM JDK build process with an extra jlink step.
> * No need to pay the footprint of libgraal twice in a GraalVM JDK (i.e., once in,`lib/libjvmcicompiler.so` and again in a jmod file).

I can appreciate that this may be going against the design of a modular JDK. However, in the context of the possible jlink optimizations you're hinting at, jlink can still know about all classes and resources since the CopyFiles plugin is limited to copying files that already exist within the source image.
That said, we'll revisit the GraalVM build process and see if we can avoid the need for the CopyFiles plugin.

-------------

PR: https://git.openjdk.org/jdk/pull/10448

From svkamath at openjdk.org  Tue Sep 27 18:28:32 2022
From: svkamath at openjdk.org (Smita Kamath)
Date: Tue, 27 Sep 2022 18:28:32 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v10]
In-Reply-To: <Xm1jk2ueFwvkB_dCAefK5JgnWTpz18KZoxC0uTNmVxM=.df6b1b3e-4228-4d01-aa64-d9126cace89b@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <lLRsBGcVOaOTQ8-yuv7AoTMeQEdtXjU3QQVSIzVdRms=.7d0d1d6c-39c8-4136-9d98-db71bc862256@github.com>
 <Xm1jk2ueFwvkB_dCAefK5JgnWTpz18KZoxC0uTNmVxM=.df6b1b3e-4228-4d01-aa64-d9126cace89b@github.com>
Message-ID: <5Ba3iixerNzWeHZno7wPBc0tpS8pGM3-LE7JJy3kfrI=.224be6ee-8da8-43b0-8390-0d8e65e0069e@github.com>

On Tue, 27 Sep 2022 13:20:51 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressed review comments
>
> I have verified my other comments,  we can either handle auto-vectorization of newly added intrinsic in this patch of create a follow up PR.

@jatin-bhateja I will handle auto-vectorization in a follow up PR.

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From mchung at openjdk.org  Tue Sep 27 19:16:11 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 27 Sep 2022 19:16:11 GMT
Subject: RFR: 8237467: effect of jlink plugins for vendor information and
 command-line options should be sticky
In-Reply-To: <ol0heS5-LEFjuZkoFjkdraX-9tjEQ371Pii5KkYyO1c=.1cdd4b7d-426d-4075-ac99-9460d0200904@github.com>
References: <ol0heS5-LEFjuZkoFjkdraX-9tjEQ371Pii5KkYyO1c=.1cdd4b7d-426d-4075-ac99-9460d0200904@github.com>
Message-ID: <LqQOweMH-LOQ1-4uTRzbPskfycBkPBHo_PRsM3AQknk=.794e18d9-0257-4096-bf3a-d209daacc19c@github.com>

On Tue, 27 Sep 2022 11:12:57 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR adds a new jlink plugin (`--save-jlink-argfiles=<filenames>`) to support persisting jlink options.
> 
> 
>> echo "--add-modules jdk.internal.vm.ci --add-options=-Dfoo=xyzzy --vendor-version="XyzzyVM 3.14.15" --vendor-bug-url=https://bugs.xyzzy.com/" > my_image.argfile
>> export ALL_MODULES=$(java --list-modules | sed 's:@.*::g' | tr '\n' ',')
>> jlink --keep-packaged-modules=my_image/jmods --add-modules $ALL_MODULES --output=my_image --save-jlink-argfiles my_image.argfile
>> my_image/bin/java -XshowSettings:properties --version 2>&1 | grep yzzy
>> my_image/bin/jlink --add-modules=java.base --output=my_image2
>> my_image2/bin/java -XshowSettings:properties --version 2>&1 | grep yzzy
>     foo = xyzzy
>     java.vendor.url.bug = https://bugs.xyzzy.com/
>     java.vendor.version = XyzzyVM 3.14.15
> OpenJDK Runtime Environment XyzzyVM 3.14.15 (build 20-internal-2022-09-22-0951036.dnsimon...)
> OpenJDK 64-Bit Server VM XyzzyVM 3.14.15 (build 20-internal-2022-09-22-0951036.dnsimon..., mixed mode)
>> my_image2/bin/java -d jdk.internal.vm.ci | head -1
> jdk.internal.vm.ci at 20-internal

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/CommandLine.java line 2:

> 1: /*
> 2:  * Copyright (c) 1999, 2022, Oracle and/or its affiliates. All rights reserved.

This is a new file and so I would just have the copyright start year.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/CommandLine.java line 43:

> 41:  * Various utility methods for processing Java tool command line arguments.
> 42:  *
> 43:  *  <p><b>This is NOT part of any supported API.

This note was prior to module system.  We could drop this comment since it's encapsulated and it's not an exported package.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 234:

> 232:         Path outputPath = null;
> 233:         try {
> 234:             try (InputStream savedOptions = JlinkTask.class.getModule().getResourceAsStream("jdk/tools/jlink/internal/options")) {

nit: wrap this long line that helps future side-by-side review.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 236:

> 234:             try (InputStream savedOptions = JlinkTask.class.getModule().getResourceAsStream("jdk/tools/jlink/internal/options")) {
> 235:                 if (savedOptions != null) {
> 236:                     List<String> newArgs = new ArrayList<>();

`s/newArgs/prependArgs/` to make it clearer.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SaveJlinkArgfilesPlugin.java line 96:

> 94:     public ResourcePool transform(ResourcePool in, ResourcePoolBuilder out) {
> 95:         in.transformAndCopy(Function.identity(), out);
> 96:         byte[] savedOptions = argfiles.stream().

Formatting consistent with jlink files:

Suggestion:

        byte[] savedOptions = argfiles.stream()
                                      .collect(Collectors.joining("\n"))
                                      .getBytes(StandardCharsets.UTF_8);

test/jdk/tools/jlink/plugins/SaveJlinkArgfilesPluginTest.java line 81:

> 79:         // Check that the primary image creation ignored the saved args
> 80:         oa.shouldHaveExitValue(0);
> 81:         oa.shouldNotMatch("yzzy");

Can this check for `java.vendor.version = XyzzyVM 3.14.15`, that will also help the reader to understand what the test tries to verify.

test/jdk/tools/jlink/plugins/SaveJlinkArgfilesPluginTest.java line 94:

> 92:         oa = ProcessTools.executeProcess(launcher.toString(), "-XshowSettings:properties", "--version");
> 93:         oa.shouldHaveExitValue(0);
> 94:         expectNMatchingLines(oa.getStdout(), "yzzy", 2);

Same for line 94-95: check for `java.vendor.version = XyzzyVM 3.14.15` instead

-------------

PR: https://git.openjdk.org/jdk/pull/10445

From mchung at openjdk.org  Tue Sep 27 19:16:13 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 27 Sep 2022 19:16:13 GMT
Subject: RFR: 8237467: effect of jlink plugins for vendor information and
 command-line options should be sticky
In-Reply-To: <LqQOweMH-LOQ1-4uTRzbPskfycBkPBHo_PRsM3AQknk=.794e18d9-0257-4096-bf3a-d209daacc19c@github.com>
References: <ol0heS5-LEFjuZkoFjkdraX-9tjEQ371Pii5KkYyO1c=.1cdd4b7d-426d-4075-ac99-9460d0200904@github.com>
 <LqQOweMH-LOQ1-4uTRzbPskfycBkPBHo_PRsM3AQknk=.794e18d9-0257-4096-bf3a-d209daacc19c@github.com>
Message-ID: <_IXmbjfLMvsT1L4qeLSIS8gHp7Pbf9xefrfRN2_zxTE=.a6f1f547-d2b3-4446-b00e-50dc665643bb@github.com>

On Tue, 27 Sep 2022 19:00:01 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This PR adds a new jlink plugin (`--save-jlink-argfiles=<filenames>`) to support persisting jlink options.
>> 
>> 
>>> echo "--add-modules jdk.internal.vm.ci --add-options=-Dfoo=xyzzy --vendor-version="XyzzyVM 3.14.15" --vendor-bug-url=https://bugs.xyzzy.com/" > my_image.argfile
>>> export ALL_MODULES=$(java --list-modules | sed 's:@.*::g' | tr '\n' ',')
>>> jlink --keep-packaged-modules=my_image/jmods --add-modules $ALL_MODULES --output=my_image --save-jlink-argfiles my_image.argfile
>>> my_image/bin/java -XshowSettings:properties --version 2>&1 | grep yzzy
>>> my_image/bin/jlink --add-modules=java.base --output=my_image2
>>> my_image2/bin/java -XshowSettings:properties --version 2>&1 | grep yzzy
>>     foo = xyzzy
>>     java.vendor.url.bug = https://bugs.xyzzy.com/
>>     java.vendor.version = XyzzyVM 3.14.15
>> OpenJDK Runtime Environment XyzzyVM 3.14.15 (build 20-internal-2022-09-22-0951036.dnsimon...)
>> OpenJDK 64-Bit Server VM XyzzyVM 3.14.15 (build 20-internal-2022-09-22-0951036.dnsimon..., mixed mode)
>>> my_image2/bin/java -d jdk.internal.vm.ci | head -1
>> jdk.internal.vm.ci at 20-internal
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 234:
> 
>> 232:         Path outputPath = null;
>> 233:         try {
>> 234:             try (InputStream savedOptions = JlinkTask.class.getModule().getResourceAsStream("jdk/tools/jlink/internal/options")) {
> 
> nit: wrap this long line that helps future side-by-side review.

Nit: define a static variable for this resource file name `jdk/tools/jlink/internal/options` that the plugin can use.

-------------

PR: https://git.openjdk.org/jdk/pull/10445

From aturbanov at openjdk.org  Tue Sep 27 19:21:09 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 27 Sep 2022 19:21:09 GMT
Subject: RFR: 8294472: Remove redundant rawtypes suppression in
 AbstractChronology
Message-ID: <Mfc999qMfld7wI8f3N9OKJUHXPqGfyfqKDHWQVabH88=.e04341d2-1a91-4489-ae69-100343891d62@github.com>

Found this redundant suppressions by IntelliJ IDEA inspection.
Seems initially `Chronology` was generic class?

-------------

Commit messages:
 - [PATCH] Remove redundant rawtypes suppression in AbstractChronology

Changes: https://git.openjdk.org/jdk/pull/10433/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10433&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294472
  Stats: 7 lines in 1 file changed: 0 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10433.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10433/head:pull/10433

PR: https://git.openjdk.org/jdk/pull/10433

From lancea at openjdk.org  Tue Sep 27 19:40:16 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 27 Sep 2022 19:40:16 GMT
Subject: RFR: 8294472: Remove redundant rawtypes suppression in
 AbstractChronology
In-Reply-To: <Mfc999qMfld7wI8f3N9OKJUHXPqGfyfqKDHWQVabH88=.e04341d2-1a91-4489-ae69-100343891d62@github.com>
References: <Mfc999qMfld7wI8f3N9OKJUHXPqGfyfqKDHWQVabH88=.e04341d2-1a91-4489-ae69-100343891d62@github.com>
Message-ID: <f2JqJ_hv8G7iS6_H2oikR3ZTC_QQre2NMxSM81Z4yDQ=.883258a4-516f-4d20-afd2-d66d5ec2a05c@github.com>

On Mon, 26 Sep 2022 19:12:16 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Found this redundant suppressions by IntelliJ IDEA inspection.
> Seems initially `Chronology` was generic class?

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10433

From alexander.matveev at oracle.com  Tue Sep 27 19:48:48 2022
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Tue, 27 Sep 2022 19:48:48 +0000
Subject: [External] : Re: RFR: 8293462: [macos] app image signature
 invalid when creating DMG or PKG from post processed signed image
In-Reply-To: <55C45641-6A82-4F9D-85DA-4A757AB209AD@gmail.com>
References: <-sMR9P3CEZeJ31UFe7bzIcnC86rSErUVbY0GOymUoo4=.7c954bca-25c7-4fa0-9e2a-076ce2a485d4@github.com>
 <20F8AC2D-C71B-4892-A2F3-C9A07501046F@gmail.com>
 <707A13E7-9047-428B-86FA-C4DFA047146C@oracle.com>
 <D847BFBF-6DEE-4F39-8EF8-5E1CF3CE3453@gmail.com>
 <A80F3462-C69A-401D-BD23-26391CD96B8C@gmail.com>
 <9CC241FC-952A-46D6-BBF7-FC1CBE094AE0@gmail.com>
 <55C45641-6A82-4F9D-85DA-4A757AB209AD@gmail.com>
Message-ID: <3642C6F3-E022-4C7B-B8CD-6A2FA0345583@oracle.com>

Hi Michael,

It is not possible to provide a unique or hashed CFBundleIdentifier. We already implemented to throw error if ?strip-native-commands are not provided to jlink or if provided runtime contain bin directory.
Look at https://github.com/openjdk/jdk/pull/8666

Thanks,
Alexander

On Sep 27, 2022, at 4:44 AM, Michael Hall <mik3hall at gmail.com<mailto:mik3hall at gmail.com>> wrote:



On Sep 26, 2022, at 9:24 PM, Michael Hall <mik3hall at gmail.com<mailto:mik3hall at gmail.com>> wrote:



On Sep 20, 2022, at 5:50 PM, Michael Hall <mik3hall at gmail.com<mailto:mik3hall at gmail.com>> wrote:

Still you could use post-processing to add whatever java binary executable commands you wanted. This again would mean changes to the embedded jdk that might have signing side effects. I haven?t tested.

Thinking about this I looked at my application that includes java commands and saw that currently I include all. And all appear to be of fixed size. So I assume some kind of launcher stub?

I then remembered

[macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe
https://bugs.openjdk.org/browse/JDK-8286122


It might be an idea, if coming up with a unique or hashed CFBundleIdentifier in the Info.plist isn?t seen as a workable alternative, for jpackage to issue a warning anytime jlink parameters are passed without ?strip-native-commands to issue a warning message that the application will not be eligible for the Mac App Store.
So developers don?t develop applications with a dependency on native commands intending them for the Mac App Store only to find out when they attempt a final MAS version that they are prohibited.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220927/6d507543/attachment-0001.htm>

From mullan at openjdk.org  Tue Sep 27 20:35:21 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 27 Sep 2022 20:35:21 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event
In-Reply-To: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
Message-ID: <QXIQe5EqORYqyigwI84XMHTEYvY3jM-ersDVdN9EeKo=.c0f4ab18-b7f9-4ee9-abc7-816fbd37ff5b@github.com>

On Thu, 22 Sep 2022 15:57:56 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> New JFR event to record state of initial security properties.
>  
> Debug output is also now added for these properties via -Djava.security.debug=properties

src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 312:

> 310:     }
> 311: 
> 312:     private static void emitInitialSecurityProperties() {

Is the `Security` class loaded and have the properties always been populated at this point? ProtectionDomain` doesn't reference the `Security` class AFAICT.

src/jdk.jfr/share/conf/jfr/default.jfc line 713:

> 711: 
> 712:     <event name="jdk.InitialSecurityProperty">
> 713:       <setting name="enabled">true</setting>

The other security related events are not enabled by default. Is this one enabled because it is only generated once? It seems it may still have some startup overhead because AFAIU it forces a load of security properties even if they are never accessed? Perhaps I don't fully understand how this event works though.

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From kvn at openjdk.org  Tue Sep 27 20:41:24 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 27 Sep 2022 20:41:24 GMT
Subject: RFR: 8294198: Implement isFinite intrinsic for RISC-V
In-Reply-To: <R4tlj4gD-vO5BzJKgAx9-O4s7BD7q6NlLhMhl6PMUuc=.c67bb8fb-3bf1-4035-be21-cc873220bf70@github.com>
References: <R4tlj4gD-vO5BzJKgAx9-O4s7BD7q6NlLhMhl6PMUuc=.c67bb8fb-3bf1-4035-be21-cc873220bf70@github.com>
Message-ID: <3v5iAlfcimDqNkND28c4uNkGM-EUcqkbEjhwyIPUM8k=.e9e4a5ec-a76d-4041-af01-9f10b556b481@github.com>

On Thu, 22 Sep 2022 12:56:49 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

> Unlike on x86 (see 8285868 and the discussion in review), isFinite intrinsic turned out to be profitable on RISC-V using the same fclass instruction as for 8293695 (isInfinite instrinsic). Therefore, I'm proposing to have it added on RISC-V in this PR.
> 
> benchmark results:
> 
> before:
> 
> Benchmark                              Mode  Cnt   Score   Error  Units
> DoubleClassCheck.testIsFiniteBranch    avgt   15  52.824 ? 1.744  ns/op
> DoubleClassCheck.testIsFiniteCMov      avgt   15  16.104 ? 0.358  ns/op
> DoubleClassCheck.testIsFiniteStore     avgt   15  14.366 ? 2.174  ns/op
> FloatClassCheck.testIsFiniteBranch     avgt   15  49.821 ? 0.330  ns/op
> FloatClassCheck.testIsFiniteCMov       avgt   15  14.702 ? 0.335  ns/op
> FloatClassCheck.testIsFiniteStore      avgt   15  14.749 ? 0.496  ns/op
> 
> after:
> 
> DoubleClassCheck.testIsFiniteBranch    avgt   15  48.921 ? 0.557  ns/op
> DoubleClassCheck.testIsFiniteCMov      avgt   15  13.716 ? 0.304  ns/op
> DoubleClassCheck.testIsFiniteStore     avgt   15   9.152 ? 0.158  ns/op
> FloatClassCheck.testIsFiniteBranch     avgt   15  47.740 ? 2.028  ns/op
> FloatClassCheck.testIsFiniteCMov       avgt   15  13.299 ? 0.282  ns/op
> FloatClassCheck.testIsFiniteStore      avgt   15   9.185 ? 0.396  ns/op
> 
> Existing isInfinite jtreg test was altered to be able to use common code for isFinite test and fine-grained requires tag filtering. Existing benchmark was modified to include isFinite case. A typo ("Atleast" -> "At least") was fixed on the way.
> 
> Test passed on both release and fastdebug builds. Hotspot tier1 tests were run on x86_64 and RISC-V with no issues.

Testing passed.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10391

From naoto at openjdk.org  Tue Sep 27 20:45:32 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 Sep 2022 20:45:32 GMT
Subject: RFR: 8294472: Remove redundant rawtypes suppression in
 AbstractChronology
In-Reply-To: <Mfc999qMfld7wI8f3N9OKJUHXPqGfyfqKDHWQVabH88=.e04341d2-1a91-4489-ae69-100343891d62@github.com>
References: <Mfc999qMfld7wI8f3N9OKJUHXPqGfyfqKDHWQVabH88=.e04341d2-1a91-4489-ae69-100343891d62@github.com>
Message-ID: <qd2fQKXxfLF6tBN1cVELZgLwOzeeEViHvbmhqJJMWLw=.6a376e2b-2adc-486d-992c-9d787613dc8c@github.com>

On Mon, 26 Sep 2022 19:12:16 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Found this redundant suppressions by IntelliJ IDEA inspection.
> Seems initially `Chronology` was generic class?

+1

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10433

From szegedia at gmail.com  Tue Sep 27 20:47:02 2022
From: szegedia at gmail.com (Attila Szegedi)
Date: Tue, 27 Sep 2022 22:47:02 +0200
Subject: Thread Weak Local / Thread Rental
Message-ID: <94D71C9D-5670-4663-AE45-82D8B0930984@gmail.com>

Hey folks,

I?ve been looking at some performance bottlenecks in a system recently, and found that we have some that stem from synchronizing on a SimpleDateFormat (which, as we know, isn?t thread safe.) This got me thinking about switching to a ThreadLocal of them, but I realized that I don?t need one for each thread, just enough otherwise identical instances to avoid contention.

That further made me think of how it?d be nice to have a class that can instantiate a requisite number of identical instances of a non-threadsafe class, and provide locked access to a consumer I pass to it, internally managing the contention in a similar way to how e.g. LongAccumulator does (or rather, the Striped64 class underlying it), including all the appreciable details that went into that logic such as advancing the Threads' threadLocalRandomProbe to slowly converge on a perfect hash function etc.

So it?s essentially an object pool somewhere between a ThreadLocal and Striped64. I don?t have a good name for it; ?WeakThreadLocal? or ?ThreadRental? come to mind as it?d allow threads to essentially ?rent" these objects :-) Its API would roughly be:

public final class WeakThreadLocal<T> {
  public WeakThreadLocal(Supplier<T> newInstance);
  public void use(Consumer<T> user);
}

and then I could do:

var dateFormats = new WeakThreadLocal(
  // invoked to create instances as contention dictates
  ()=>new SimpleDateFormat(?)
);
?
dateFormats.use(dateFormat => ? while this runs, only this thread has access to this dateFormat)


Is there anything obviously wrong/hard with this idea? (Aside from the admittedly material problem where the pooled class should itself take care against false sharing.) How useful would a class like this be in general?

Thanks for any insights,
  Attila.

From roger.riggs at oracle.com  Tue Sep 27 20:51:45 2022
From: roger.riggs at oracle.com (Roger Riggs)
Date: Tue, 27 Sep 2022 16:51:45 -0400
Subject: Thread Weak Local / Thread Rental
In-Reply-To: <94D71C9D-5670-4663-AE45-82D8B0930984@gmail.com>
References: <94D71C9D-5670-4663-AE45-82D8B0930984@gmail.com>
Message-ID: <a2c5d526-18e7-888b-9a18-161c5c682dd5@oracle.com>

Hi,

Have you considered switching to java.time.format.DateTimeFormatter 
<https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/time/format/package-summary.html>?

If you are going to have to change the callsites, you can use a faster 
and more modern API at the same time.

Regards, Roger


On 9/27/22 4:47 PM, Attila Szegedi wrote:
> Hey folks,
>
> I?ve been looking at some performance bottlenecks in a system recently, and found that we have some that stem from synchronizing on a SimpleDateFormat (which, as we know, isn?t thread safe.) This got me thinking about switching to a ThreadLocal of them, but I realized that I don?t need one for each thread, just enough otherwise identical instances to avoid contention.
>
> That further made me think of how it?d be nice to have a class that can instantiate a requisite number of identical instances of a non-threadsafe class, and provide locked access to a consumer I pass to it, internally managing the contention in a similar way to how e.g. LongAccumulator does (or rather, the Striped64 class underlying it), including all the appreciable details that went into that logic such as advancing the Threads' threadLocalRandomProbe to slowly converge on a perfect hash function etc.
>
> So it?s essentially an object pool somewhere between a ThreadLocal and Striped64. I don?t have a good name for it; ?WeakThreadLocal? or ?ThreadRental? come to mind as it?d allow threads to essentially ?rent" these objects :-) Its API would roughly be:
>
> public final class WeakThreadLocal<T> {
>    public WeakThreadLocal(Supplier<T> newInstance);
>    public void use(Consumer<T> user);
> }
>
> and then I could do:
>
> var dateFormats = new WeakThreadLocal(
>    // invoked to create instances as contention dictates
>    ()=>new SimpleDateFormat(?)
> );
> ?
> dateFormats.use(dateFormat => ? while this runs, only this thread has access to this dateFormat)
>
>
> Is there anything obviously wrong/hard with this idea? (Aside from the admittedly material problem where the pooled class should itself take care against false sharing.) How useful would a class like this be in general?
>
> Thanks for any insights,
>    Attila.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220927/7adeae9b/attachment-0001.htm>

From dnsimon at openjdk.org  Tue Sep 27 20:54:20 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 27 Sep 2022 20:54:20 GMT
Subject: RFR: 8237467: effect of jlink plugins for vendor information and
 command-line options should be sticky
In-Reply-To: <LqQOweMH-LOQ1-4uTRzbPskfycBkPBHo_PRsM3AQknk=.794e18d9-0257-4096-bf3a-d209daacc19c@github.com>
References: <ol0heS5-LEFjuZkoFjkdraX-9tjEQ371Pii5KkYyO1c=.1cdd4b7d-426d-4075-ac99-9460d0200904@github.com>
 <LqQOweMH-LOQ1-4uTRzbPskfycBkPBHo_PRsM3AQknk=.794e18d9-0257-4096-bf3a-d209daacc19c@github.com>
Message-ID: <dXl-pOcXWqsnVVLekKkwUdkAo7OnxUYZNIQuuBiaJhc=.046286e5-fe56-48f1-9ebe-626cade98371@github.com>

On Tue, 27 Sep 2022 19:11:07 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This PR adds a new jlink plugin (`--save-jlink-argfiles=<filenames>`) to support persisting jlink options.
>> 
>> 
>>> echo "--add-modules jdk.internal.vm.ci --add-options=-Dfoo=xyzzy --vendor-version="XyzzyVM 3.14.15" --vendor-bug-url=https://bugs.xyzzy.com/" > my_image.argfile
>>> export ALL_MODULES=$(java --list-modules | sed 's:@.*::g' | tr '\n' ',')
>>> jlink --keep-packaged-modules=my_image/jmods --add-modules $ALL_MODULES --output=my_image --save-jlink-argfiles my_image.argfile
>>> my_image/bin/java -XshowSettings:properties --version 2>&1 | grep yzzy
>>> my_image/bin/jlink --add-modules=java.base --output=my_image2
>>> my_image2/bin/java -XshowSettings:properties --version 2>&1 | grep yzzy
>>     foo = xyzzy
>>     java.vendor.url.bug = https://bugs.xyzzy.com/
>>     java.vendor.version = XyzzyVM 3.14.15
>> OpenJDK Runtime Environment XyzzyVM 3.14.15 (build 20-internal-2022-09-22-0951036.dnsimon...)
>> OpenJDK 64-Bit Server VM XyzzyVM 3.14.15 (build 20-internal-2022-09-22-0951036.dnsimon..., mixed mode)
>>> my_image2/bin/java -d jdk.internal.vm.ci | head -1
>> jdk.internal.vm.ci at 20-internal
>
> test/jdk/tools/jlink/plugins/SaveJlinkArgfilesPluginTest.java line 81:
> 
>> 79:         // Check that the primary image creation ignored the saved args
>> 80:         oa.shouldHaveExitValue(0);
>> 81:         oa.shouldNotMatch("yzzy");
> 
> Can this check for `java.vendor.version = XyzzyVM 3.14.15`, that will also help the reader to understand what the test tries to verify.

Not sure follow as this is a negative match. I don't want it to match `java.vendor.url.bug = https://bugs.xyzzy.com/`, `java.vendor.version = XyzzyVM 3.14.15` or `foo = xyzzy`. I'll expand it out to 3 tests.

-------------

PR: https://git.openjdk.org/jdk/pull/10445

From dholmes at openjdk.org  Tue Sep 27 21:04:17 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 27 Sep 2022 21:04:17 GMT
Subject: RFR: 8293806: JDK_JAVA_OPTIONS picked up twice if LD_LIBRARY_PATH
 is set
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: <9pX9wo9D-gVHNXKeLMZz4bOwLy-qKjXMQmsJKMSUQo8=.bdca5133-26d9-439a-b079-c3c257065ad2@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.

Can't we just remove `JDK_JAVA_OPTIONS` from the new env in that case?

-------------

PR: https://git.openjdk.org/jdk/pull/10430

From dholmes at openjdk.org  Tue Sep 27 21:04:21 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 27 Sep 2022 21:04:21 GMT
Subject: RFR: 8293592: Remove JVM_StopThread, stillborn,
 and related cleanup [v2]
In-Reply-To: <-5Dm6rla6Uq1BWSlvsaVKXwLsbd0c2tgewPhpygfqZ0=.283a80a5-5025-4460-8ede-68a37e668764@github.com>
References: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
 <BlMK7IMjTgIiiwSkkF_1-qLlM1AqaKAhLP55-Z1-eeI=.2383991e-22d3-4c0c-afab-353985e1f8fc@github.com>
 <-5Dm6rla6Uq1BWSlvsaVKXwLsbd0c2tgewPhpygfqZ0=.283a80a5-5025-4460-8ede-68a37e668764@github.com>
Message-ID: <cTKQa2akNrP5Twer92_KlpP7VSkvlFFwnjgEphITrn8=.8b7d488c-8d94-4e2a-80a7-2833a88c55a0@github.com>

On Tue, 27 Sep 2022 08:01:48 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
>> 
>>  - Merge branch 'master' into 8293592-JVM_StopThread
>>  - Removal all special handling of ThreadDeath.
>>  - Remove all references to the stillborn field
>>  - Initial commit: remove JVM_StopThread
>>  - Merge
>>  - Updates to Java Thread Primitive Deprecation page
>>  - Repalce "it" with "victim thread"
>>  - Merge
>>  - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop
>>  - become -> became in javadoc
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/3675f4c2...4eb07903
>
> Looks good, thank for fixing.

Thanks @robehn and @coleenp !

-------------

PR: https://git.openjdk.org/jdk/pull/10400

From dholmes at openjdk.org  Tue Sep 27 21:07:30 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 27 Sep 2022 21:07:30 GMT
Subject: Integrated: 8293592: Remove JVM_StopThread, stillborn,
 and related cleanup
In-Reply-To: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
References: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
Message-ID: <BsCrAy-uo0iUxDCh-4qeIke7J8SzLNsQDQPmOFY2lEA=.752c76c3-b4f9-4332-984c-ada05db68180@github.com>

On Fri, 23 Sep 2022 06:17:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610).
> 
> Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started.
> 
> Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same).
> 
> Testing: tiers 1-3

This pull request has now been integrated.

Changeset: 763d4bf0
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/763d4bf0749e54f74821e5155f672ed24d6f2fcd
Stats:     208 lines in 18 files changed: 19 ins; 146 del; 43 mod

8293592: Remove JVM_StopThread, stillborn, and related cleanup

Reviewed-by: alanb, sspitsyn, rehn, coleenp

-------------

PR: https://git.openjdk.org/jdk/pull/10400

From mik3hall at gmail.com  Tue Sep 27 21:27:29 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 27 Sep 2022 16:27:29 -0500
Subject: [External] : Re: RFR: 8293462: [macos] app image signature
 invalid when creating DMG or PKG from post processed signed image
In-Reply-To: <3642C6F3-E022-4C7B-B8CD-6A2FA0345583@oracle.com>
References: <-sMR9P3CEZeJ31UFe7bzIcnC86rSErUVbY0GOymUoo4=.7c954bca-25c7-4fa0-9e2a-076ce2a485d4@github.com>
 <20F8AC2D-C71B-4892-A2F3-C9A07501046F@gmail.com>
 <707A13E7-9047-428B-86FA-C4DFA047146C@oracle.com>
 <D847BFBF-6DEE-4F39-8EF8-5E1CF3CE3453@gmail.com>
 <A80F3462-C69A-401D-BD23-26391CD96B8C@gmail.com>
 <9CC241FC-952A-46D6-BBF7-FC1CBE094AE0@gmail.com>
 <55C45641-6A82-4F9D-85DA-4A757AB209AD@gmail.com>
 <3642C6F3-E022-4C7B-B8CD-6A2FA0345583@oracle.com>
Message-ID: <4D5AF283-2A40-42DA-B06B-9573BB7A8A22@gmail.com>



> On Sep 27, 2022, at 2:48 PM, Alexander Matveev <alexander.matveev at oracle.com> wrote:
> 
> Hi Michael,
> 
> It is not possible to provide a unique or hashed CFBundleIdentifier. We already implemented to throw error if ?strip-native-commands are not provided to jlink or if provided runtime contain bin directory.
> Look at https://github.com/openjdk/jdk/pull/8666 <https://github.com/openjdk/jdk/pull/8666>
> 
> Thanks,
> Alexander
> 

Alexander 
I assume you do this only if --mac-app-store is indicated? I have an application, not for the App Store, that excludes ?strip-native-commands jlink parm and as I mentioned I get all of the native commands. I don?t pay much attention to the messages because it has been working fine for some time, but I don?t think any exceptions are thrown.
My suggestion is that even doing this and not including ?mac-app-store should get a warning it won?t work for App Store so that if a developer is working on an application with native commands and only when complete tries adding the ?mac-app-store parameter they would know immediately and not after considerable effort that there is a problem.

Thanks
Mike

From the java shell app with embedded commands?

set java.home
java.home=/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/runtime/Contents/Home
exec ${java.home}/bin/java -version
openjdk version "19" 2022-09-20
OpenJDK Runtime Environment (build 19+36-2238)
OpenJDK 64-Bit Server VM (build 19+36-2238, mixed mode)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220927/8d7f1215/attachment-0001.htm>

From lmesnik at openjdk.org  Tue Sep 27 21:30:26 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 27 Sep 2022 21:30:26 GMT
Subject: RFR: 8293613: need to properly handle and hide tmp VTMS
 transitions [v4]
In-Reply-To: <OyzEjJjgvDVNRlKMONSVBtpcnVBJ9QPHdV2LqfcuTSc=.3810b0d9-3ce3-47f6-9662-6a91514efa05@github.com>
References: <O_jzls_cv3HBC0NbzuYV2LXaW9VB2M18FroUfXWXd2w=.fa9d1f3c-40a2-42bd-a09b-dadd5032e513@github.com>
 <OyzEjJjgvDVNRlKMONSVBtpcnVBJ9QPHdV2LqfcuTSc=.3810b0d9-3ce3-47f6-9662-6a91514efa05@github.com>
Message-ID: <ho4BIK-wkbBBu02Sk59TBTcuMIIxk3ZsUF5KpWsEgv0=.b8dce5fb-997c-4db1-a31f-3645575c0a72@github.com>

On Thu, 22 Sep 2022 09:16:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update.
>> 
>> There are a couple of details of this fix to highlight:
>> -  A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`.
>> - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored.
>> - Suspending threads in temporary transition is allowed.
>> 
>> The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   1. addressed review comments from Chris; added VirtualThread.java update from Alan

Marked as reviewed by lmesnik (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10321

From smarks at openjdk.org  Tue Sep 27 21:52:16 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 27 Sep 2022 21:52:16 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v8]
In-Reply-To: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
Message-ID: <x2aasEWjsu_H2S4TucuQNugSnaVLJ2ew65GnFrV64yc=.3950404e-1bcf-45f2-9c7f-7eee1d53448b@github.com>

> The concept of the shutdown sequence needs to be specified more clearly. This PR adds text for this into the class specification of `java.lang.Runtime`. Also includes adjustments to related areas in `addShutdownHook`, `halt`, and in the `System` and `Thread` classes. The changes here should coordinate with similar changes to JLS 12.8, JVMS 5.7, and the Invocation API chapter of the _JNI Specification._

Stuart Marks has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:

 - Merge branch 'master' into JDK-8290036-Runtime-addShutdownHook-spec
 - Minor adjustments
 - Revise Implementation Note discussing JNI Invocation API.
 - Updates from Alan, David, and Alex.
 - More edits from Alex's suggestions.
 - More updates after discussion with Alex.
 - Updates after conversation with Alan:
   - specify that starting a shutdown hook explicitly has an unspecified
     effect on the shutdown sequence
   - link Thread class doc to shutdown sequence
   - link to Thread.UncaughtExceptionHandler
   - clarify that only live non-daemon threads are significant
   - use "thread termination" to conform to the text in the Thread class
   - adjust line breaks and whitespace
 - Additional wording changes to Runtime specs.
 - HTML fixups; updates in response to review comments.
 - Updates to Runtime class spec, exit, halt, and System.exit
 - ... and 3 more: https://git.openjdk.org/jdk/compare/4b81849d...6b559c4c

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9437/files
  - new: https://git.openjdk.org/jdk/pull/9437/files/9796557d..6b559c4c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9437&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9437&range=06-07

  Stats: 190478 lines in 3326 files changed: 95187 ins; 75075 del; 20216 mod
  Patch: https://git.openjdk.org/jdk/pull/9437.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9437/head:pull/9437

PR: https://git.openjdk.org/jdk/pull/9437

From dnsimon at openjdk.org  Tue Sep 27 22:01:40 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 27 Sep 2022 22:01:40 GMT
Subject: RFR: 8237467: effect of jlink plugins for vendor information and
 command-line options should be sticky [v2]
In-Reply-To: <ol0heS5-LEFjuZkoFjkdraX-9tjEQ371Pii5KkYyO1c=.1cdd4b7d-426d-4075-ac99-9460d0200904@github.com>
References: <ol0heS5-LEFjuZkoFjkdraX-9tjEQ371Pii5KkYyO1c=.1cdd4b7d-426d-4075-ac99-9460d0200904@github.com>
Message-ID: <6Nz2hHrvOlKL7lBf-1xR4jm-zY0J9A0TQSDZBxqtNaY=.d83ec23d-3823-4bd3-9a17-05f0651dd8c6@github.com>

> This PR adds a new jlink plugin (`--save-jlink-argfiles=<filenames>`) to support persisting jlink options.
> 
> 
>> echo "--add-modules jdk.internal.vm.ci --add-options=-Dfoo=xyzzy --vendor-version="XyzzyVM 3.14.15" --vendor-bug-url=https://bugs.xyzzy.com/" > my_image.argfile
>> export ALL_MODULES=$(java --list-modules | sed 's:@.*::g' | tr '\n' ',')
>> jlink --keep-packaged-modules=my_image/jmods --add-modules $ALL_MODULES --output=my_image --save-jlink-argfiles my_image.argfile
>> my_image/bin/java -XshowSettings:properties --version 2>&1 | grep yzzy
>> my_image/bin/jlink --add-modules=java.base --output=my_image2
>> my_image2/bin/java -XshowSettings:properties --version 2>&1 | grep yzzy
>     foo = xyzzy
>     java.vendor.url.bug = https://bugs.xyzzy.com/
>     java.vendor.version = XyzzyVM 3.14.15
> OpenJDK Runtime Environment XyzzyVM 3.14.15 (build 20-internal-2022-09-22-0951036.dnsimon...)
> OpenJDK 64-Bit Server VM XyzzyVM 3.14.15 (build 20-internal-2022-09-22-0951036.dnsimon..., mixed mode)
>> my_image2/bin/java -d jdk.internal.vm.ci | head -1
> jdk.internal.vm.ci at 20-internal

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  changes to address review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10445/files
  - new: https://git.openjdk.org/jdk/pull/10445/files/583981a7..9502cd75

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10445&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10445&range=00-01

  Stats: 47 lines in 5 files changed: 9 ins; 22 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/10445.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10445/head:pull/10445

PR: https://git.openjdk.org/jdk/pull/10445

From mchung at openjdk.org  Tue Sep 27 22:17:08 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 27 Sep 2022 22:17:08 GMT
Subject: RFR: 8237467: jlink plugin to save the argument files as input to
 jlink in the output image [v2]
In-Reply-To: <6Nz2hHrvOlKL7lBf-1xR4jm-zY0J9A0TQSDZBxqtNaY=.d83ec23d-3823-4bd3-9a17-05f0651dd8c6@github.com>
References: <ol0heS5-LEFjuZkoFjkdraX-9tjEQ371Pii5KkYyO1c=.1cdd4b7d-426d-4075-ac99-9460d0200904@github.com>
 <6Nz2hHrvOlKL7lBf-1xR4jm-zY0J9A0TQSDZBxqtNaY=.d83ec23d-3823-4bd3-9a17-05f0651dd8c6@github.com>
Message-ID: <rdzQy6HFatXse1FB05WzImGUldLRk0opIxS-yA4HhkY=.b9e1affd-7a5d-42b8-8ccd-5eb0460a48ff@github.com>

On Tue, 27 Sep 2022 22:01:40 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR adds a new jlink plugin (`--save-jlink-argfiles=<filenames>`) to support persisting jlink options.
>> 
>> 
>>> echo "--add-modules jdk.internal.vm.ci --add-options=-Dfoo=xyzzy --vendor-version="XyzzyVM 3.14.15" --vendor-bug-url=https://bugs.xyzzy.com/" > my_image.argfile
>>> export ALL_MODULES=$(java --list-modules | sed 's:@.*::g' | tr '\n' ',')
>>> jlink --keep-packaged-modules=my_image/jmods --add-modules $ALL_MODULES --output=my_image --save-jlink-argfiles my_image.argfile
>>> my_image/bin/java -XshowSettings:properties --version 2>&1 | grep yzzy
>>> my_image/bin/jlink --add-modules=java.base --output=my_image2
>>> my_image2/bin/java -XshowSettings:properties --version 2>&1 | grep yzzy
>>     foo = xyzzy
>>     java.vendor.url.bug = https://bugs.xyzzy.com/
>>     java.vendor.version = XyzzyVM 3.14.15
>> OpenJDK Runtime Environment XyzzyVM 3.14.15 (build 20-internal-2022-09-22-0951036.dnsimon...)
>> OpenJDK 64-Bit Server VM XyzzyVM 3.14.15 (build 20-internal-2022-09-22-0951036.dnsimon..., mixed mode)
>>> my_image2/bin/java -d jdk.internal.vm.ci | head -1
>> jdk.internal.vm.ci at 20-internal
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changes to address review feedback

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SaveJlinkArgfilesPlugin.java line 83:

> 81: 
> 82:         for (String argfile : v.split(File.pathSeparator)) {
> 83:             argfiles.add(readArgfile(argfile));

This plugin should validate if `jdk.jlink` is linked in the resulting image; if not, it should throw an exception.

Otherwise, looks good.

-------------

PR: https://git.openjdk.org/jdk/pull/10445

From dnsimon at openjdk.org  Tue Sep 27 22:37:16 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 27 Sep 2022 22:37:16 GMT
Subject: RFR: 8237467: jlink plugin to save the argument files as input to
 jlink in the output image [v3]
In-Reply-To: <ol0heS5-LEFjuZkoFjkdraX-9tjEQ371Pii5KkYyO1c=.1cdd4b7d-426d-4075-ac99-9460d0200904@github.com>
References: <ol0heS5-LEFjuZkoFjkdraX-9tjEQ371Pii5KkYyO1c=.1cdd4b7d-426d-4075-ac99-9460d0200904@github.com>
Message-ID: <8jlZM_FhM9w2SdZxVmHgAZkSq3_g6h28yzP81CdOQUA=.9af83d24-3c15-4635-8603-bf6173c13b95@github.com>

> This PR adds a new jlink plugin (`--save-jlink-argfiles=<filenames>`) to support persisting jlink options.
> 
> 
>> echo "--add-modules jdk.internal.vm.ci --add-options=-Dfoo=xyzzy --vendor-version="XyzzyVM 3.14.15" --vendor-bug-url=https://bugs.xyzzy.com/" > my_image.argfile
>> export ALL_MODULES=$(java --list-modules | sed 's:@.*::g' | tr '\n' ',')
>> jlink --keep-packaged-modules=my_image/jmods --add-modules $ALL_MODULES --output=my_image --save-jlink-argfiles my_image.argfile
>> my_image/bin/java -XshowSettings:properties --version 2>&1 | grep yzzy
>> my_image/bin/jlink --add-modules=java.base --output=my_image2
>> my_image2/bin/java -XshowSettings:properties --version 2>&1 | grep yzzy
>     foo = xyzzy
>     java.vendor.url.bug = https://bugs.xyzzy.com/
>     java.vendor.version = XyzzyVM 3.14.15
> OpenJDK Runtime Environment XyzzyVM 3.14.15 (build 20-internal-2022-09-22-0951036.dnsimon...)
> OpenJDK 64-Bit Server VM XyzzyVM 3.14.15 (build 20-internal-2022-09-22-0951036.dnsimon..., mixed mode)
>> my_image2/bin/java -d jdk.internal.vm.ci | head -1
> jdk.internal.vm.ci at 20-internal

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  SaveJlinkArgfilesPlugin should verify that jdk.jlink is in the output image

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10445/files
  - new: https://git.openjdk.org/jdk/pull/10445/files/9502cd75..91938caa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10445&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10445&range=01-02

  Stats: 16 lines in 2 files changed: 9 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10445.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10445/head:pull/10445

PR: https://git.openjdk.org/jdk/pull/10445

From mchung at openjdk.org  Tue Sep 27 22:42:23 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 27 Sep 2022 22:42:23 GMT
Subject: RFR: 8237467: jlink plugin to save the argument files as input to
 jlink in the output image [v3]
In-Reply-To: <8jlZM_FhM9w2SdZxVmHgAZkSq3_g6h28yzP81CdOQUA=.9af83d24-3c15-4635-8603-bf6173c13b95@github.com>
References: <ol0heS5-LEFjuZkoFjkdraX-9tjEQ371Pii5KkYyO1c=.1cdd4b7d-426d-4075-ac99-9460d0200904@github.com>
 <8jlZM_FhM9w2SdZxVmHgAZkSq3_g6h28yzP81CdOQUA=.9af83d24-3c15-4635-8603-bf6173c13b95@github.com>
Message-ID: <j5_mDwRCuf7-hAMY1TKsF7w1vh8D-PSdm-PIP32VRmU=.500c79b8-7b57-47cd-af51-9a75cb83665c@github.com>

On Tue, 27 Sep 2022 22:37:16 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR adds a new jlink plugin (`--save-jlink-argfiles=<filenames>`) to support persisting jlink options.
>> 
>> 
>>> echo "--add-modules jdk.internal.vm.ci --add-options=-Dfoo=xyzzy --vendor-version="XyzzyVM 3.14.15" --vendor-bug-url=https://bugs.xyzzy.com/" > my_image.argfile
>>> export ALL_MODULES=$(java --list-modules | sed 's:@.*::g' | tr '\n' ',')
>>> jlink --keep-packaged-modules=my_image/jmods --add-modules $ALL_MODULES --output=my_image --save-jlink-argfiles my_image.argfile
>>> my_image/bin/java -XshowSettings:properties --version 2>&1 | grep yzzy
>>> my_image/bin/jlink --add-modules=java.base --output=my_image2
>>> my_image2/bin/java -XshowSettings:properties --version 2>&1 | grep yzzy
>>     foo = xyzzy
>>     java.vendor.url.bug = https://bugs.xyzzy.com/
>>     java.vendor.version = XyzzyVM 3.14.15
>> OpenJDK Runtime Environment XyzzyVM 3.14.15 (build 20-internal-2022-09-22-0951036.dnsimon...)
>> OpenJDK 64-Bit Server VM XyzzyVM 3.14.15 (build 20-internal-2022-09-22-0951036.dnsimon..., mixed mode)
>>> my_image2/bin/java -d jdk.internal.vm.ci | head -1
>> jdk.internal.vm.ci at 20-internal
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   SaveJlinkArgfilesPlugin should verify that jdk.jlink is in the output image

Looks good.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10445

From mernst at openjdk.org  Tue Sep 27 23:16:16 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Tue, 27 Sep 2022 23:16:16 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com>
Message-ID: <1UZcv-X4dxQHlgj8b5B2sGJ9NpxWrOp1EwbWeazjj2I=.1cf2b14f-7064-47b6-8d25-887732020bb0@github.com>

On Mon, 26 Sep 2022 19:36:02 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Thank you for your efforts on the cleaning up these typos
> 
> I would suggest breaking these changes into separate PRs by team as there seems to be changes to hotspot, core-libs, and client to make it easier to review.
> 
> I realize the changes are fairly trivial but this will most likely expedite getting your changes back

Feel free to break up the pull request if that is what is needed to free it from red tape.
Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From dholmes at openjdk.org  Tue Sep 27 23:46:15 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 27 Sep 2022 23:46:15 GMT
Subject: RFR: 8290482: Update JNI Specification of DestroyJavaVM for better
 alignment with JLS, JVMS, and Java SE API Specifications [v4]
In-Reply-To: <5LZVfXnTpbyr_NWeYid9qzKrnZ6t2b7ZL5BtHEZ4Syc=.bff15db2-726a-4976-89f1-edd826d75bf2@github.com>
References: <M2IRKiuONiNI45YTu9wdu1o8ZXJslnxRmgMvnlVU478=.4aa03d22-0395-4354-bf41-f11a74df791a@github.com>
 <5LZVfXnTpbyr_NWeYid9qzKrnZ6t2b7ZL5BtHEZ4Syc=.bff15db2-726a-4976-89f1-edd826d75bf2@github.com>
Message-ID: <TGc8WDnb4FDB6zNgjsouj9SM1CYk8_7rlEoEmpZF3fg=.5fa04872-0da5-4f0b-9289-9b829947e7c1@github.com>

On Tue, 20 Sep 2022 10:37:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This update is primarily about changes to the JNI Invocation API specification, mainly in relation to `DestroyJavaVM`. The motivation for the changes is to align with changes being made to the JLS, JVMS and `java.lang.Runtime`, specifications in relation to VM termination - ref:
>> 
>> JDK-8290196 12.8: Clarify the definition of program exit
>> https://bugs.openjdk.org/browse/JDK-8290196
>> 
>> JDK-8290388 5.7: Clarify the definition of JVM termination
>> https://bugs.openjdk.org/browse/JDK-8290388
>> 
>> JDK-8290036 Define and specify Runtime shutdown sequence
>> https://bugs.openjdk.org/browse/JDK-8290036
>> 
>> Mostly these are just non-normative changes to the JNI spec prose but there are two actual specification changes:
>> 
>> 1.  The fact it is an error to detach a thread with active Java frames was only mentioned in the overview section, not in the actual `DetachCurrentThread` specification. (Just an oversight - the VM already checked this)
>> 
>> 2.  We need to make it an error to call `DestroyJavaVM` from an attached thread with active Java frames (as this can't work for the same reason we disallow `DetachCurrentThread`). This requires an implementation change in Hotspot.
>> 
>> Issue 2 covers the code change, and regression test, in this PR.
>> 
>> In addition the specification changes can be seen here:
>> 
>> - specdiff: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/diff.html
>> - original: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-original.html
>> - new: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-new.html
>> 
>> The specification itself is not open but comments on the spec changes are welcome - though please see the JBS issue and CSR request first. The revised wording has already been extensively reviewed/negotiated between Alex Buckley, Stuart Marks and myself, so any change must either be a glaring error/problem or else a trivial adjustment.
>> 
>> Thank you.
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix JniVersion test

CSR is now approved.

-------------

PR: https://git.openjdk.org/jdk/pull/10352

From dholmes at openjdk.org  Wed Sep 28 00:01:58 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 28 Sep 2022 00:01:58 GMT
Subject: Integrated: 8290482: Update JNI Specification of DestroyJavaVM for
 better alignment with JLS, JVMS, and Java SE API Specifications
In-Reply-To: <M2IRKiuONiNI45YTu9wdu1o8ZXJslnxRmgMvnlVU478=.4aa03d22-0395-4354-bf41-f11a74df791a@github.com>
References: <M2IRKiuONiNI45YTu9wdu1o8ZXJslnxRmgMvnlVU478=.4aa03d22-0395-4354-bf41-f11a74df791a@github.com>
Message-ID: <H8mdReVLkGmcmH7K7kZjKPm7AlXqDQpnyUPAiABQS_8=.f20774b0-8c55-4df4-8592-7ab191d17077@github.com>

On Tue, 20 Sep 2022 00:55:32 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This update is primarily about changes to the JNI Invocation API specification, mainly in relation to `DestroyJavaVM`. The motivation for the changes is to align with changes being made to the JLS, JVMS and `java.lang.Runtime`, specifications in relation to VM termination - ref:
> 
> JDK-8290196 12.8: Clarify the definition of program exit
> https://bugs.openjdk.org/browse/JDK-8290196
> 
> JDK-8290388 5.7: Clarify the definition of JVM termination
> https://bugs.openjdk.org/browse/JDK-8290388
> 
> JDK-8290036 Define and specify Runtime shutdown sequence
> https://bugs.openjdk.org/browse/JDK-8290036
> 
> Mostly these are just non-normative changes to the JNI spec prose but there are two actual specification changes:
> 
> 1.  The fact it is an error to detach a thread with active Java frames was only mentioned in the overview section, not in the actual `DetachCurrentThread` specification. (Just an oversight - the VM already checked this)
> 
> 2.  We need to make it an error to call `DestroyJavaVM` from an attached thread with active Java frames (as this can't work for the same reason we disallow `DetachCurrentThread`). This requires an implementation change in Hotspot.
> 
> Issue 2 covers the code change, and regression test, in this PR.
> 
> In addition the specification changes can be seen here:
> 
> - specdiff: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/diff.html
> - original: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-original.html
> - new: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-new.html
> 
> The specification itself is not open but comments on the spec changes are welcome - though please see the JBS issue and CSR request first. The revised wording has already been extensively reviewed/negotiated between Alex Buckley, Stuart Marks and myself, so any change must either be a glaring error/problem or else a trivial adjustment.
> 
> Thank you.

This pull request has now been integrated.

Changeset: e5b65c40
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e5b65c40ea032c6955311593e02ed44f14dfe80a
Stats:     112 lines in 6 files changed: 108 ins; 1 del; 3 mod

8290482: Update JNI Specification of DestroyJavaVM for better alignment with JLS, JVMS, and Java SE API Specifications

Reviewed-by: rehn, coleenp

-------------

PR: https://git.openjdk.org/jdk/pull/10352

From dholmes at openjdk.org  Wed Sep 28 01:19:07 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 28 Sep 2022 01:19:07 GMT
Subject: RFR: 8292016: Split Windows API error handling from errors passed
 through the runtime in the JDK [v22]
In-Reply-To: <lw9XvGNXkiMcKHqHcdIqDHNikiV9ymaBd_RhadHko1c=.ca31ea69-34a3-4858-acf7-e9ac010152e3@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
 <S3foO_lw8Qp5f1NosQ8cx1v96miI57hdDTQ4FIOlYbo=.26b894ca-3505-46e9-9c43-d381e2d4e1bc@github.com>
 <OjGBI4cbdqxyuIjruGTV3GXkajZgbVfAgNKakOnIMnk=.d27dc4fc-ec28-4f4b-b19c-37d9e496c126@github.com>
 <lw9XvGNXkiMcKHqHcdIqDHNikiV9ymaBd_RhadHko1c=.ca31ea69-34a3-4858-acf7-e9ac010152e3@github.com>
Message-ID: <h2KR3ui1yWbwgMMBHdwMg7Y7ysbJcVATL6hRdl4GVpU=.258254be-e619-4cb9-a956-c6bd84c0fd77@github.com>

On Tue, 27 Sep 2022 16:14:43 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Are any of these a part of the public JNI API?

No this is all internal-use-only

-------------

PR: https://git.openjdk.org/jdk/pull/9870

From smarks at openjdk.org  Wed Sep 28 04:13:25 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 28 Sep 2022 04:13:25 GMT
Subject: RFR: 8065554: MatchResult should provide values of named-capturing
 groups [v7]
In-Reply-To: <42Ev9fkW6Eikmx176RXPOKvwIU30MbQR3upwFjdKJ6s=.6bb50e0f-d4f0-4285-9905-ef3d56b32ade@github.com>
References: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
 <42Ev9fkW6Eikmx176RXPOKvwIU30MbQR3upwFjdKJ6s=.6bb50e0f-d4f0-4285-9905-ef3d56b32ade@github.com>
Message-ID: <X3uSMDy2pAjxrjCWaC0LbBmBLUv9MkRzOXsSrrKVBLI=.811e6a2b-4120-4099-b4de-840c7564f489@github.com>

On Thu, 22 Sep 2022 10:22:40 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Add support for named groups to java.util.regex.MatchResult
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8065554: MatchResult should provide values of named-capturing groups

OK I took another look at everything and I think this is good to integrate.

The tests seem adequate but it seems like they would benefit from some refactoring. It might be an interesting exercise to revisit them and try out the new JUnit 5 APIs.

-------------

Marked as reviewed by smarks (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10000

From sspitsyn at openjdk.org  Wed Sep 28 04:45:22 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 28 Sep 2022 04:45:22 GMT
Subject: RFR: 8293613: need to properly handle and hide tmp VTMS
 transitions [v4]
In-Reply-To: <OyzEjJjgvDVNRlKMONSVBtpcnVBJ9QPHdV2LqfcuTSc=.3810b0d9-3ce3-47f6-9662-6a91514efa05@github.com>
References: <O_jzls_cv3HBC0NbzuYV2LXaW9VB2M18FroUfXWXd2w=.fa9d1f3c-40a2-42bd-a09b-dadd5032e513@github.com>
 <OyzEjJjgvDVNRlKMONSVBtpcnVBJ9QPHdV2LqfcuTSc=.3810b0d9-3ce3-47f6-9662-6a91514efa05@github.com>
Message-ID: <jM-CSK5y4gjxEV_Vf5ne4QXvEGVO09cfFnBcG_AEjuY=.bcf4b36e-3db9-4432-b57f-984aee5c5161@github.com>

On Thu, 22 Sep 2022 09:16:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update.
>> 
>> There are a couple of details of this fix to highlight:
>> -  A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`.
>> - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored.
>> - Suspending threads in temporary transition is allowed.
>> 
>> The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   1. addressed review comments from Chris; added VirtualThread.java update from Alan

Thank you for review, Leonid!

-------------

PR: https://git.openjdk.org/jdk/pull/10321

From sspitsyn at openjdk.org  Wed Sep 28 04:48:14 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 28 Sep 2022 04:48:14 GMT
Subject: Integrated: 8293613: need to properly handle and hide tmp VTMS
 transitions
In-Reply-To: <O_jzls_cv3HBC0NbzuYV2LXaW9VB2M18FroUfXWXd2w=.fa9d1f3c-40a2-42bd-a09b-dadd5032e513@github.com>
References: <O_jzls_cv3HBC0NbzuYV2LXaW9VB2M18FroUfXWXd2w=.fa9d1f3c-40a2-42bd-a09b-dadd5032e513@github.com>
Message-ID: <wGfmfhcTX-JbA_U4i8ZDuBFTaoeae56nYGPOnRv1dOI=.515c8ce1-99bf-4006-8f4d-d8c396aaaa33@github.com>

On Sun, 18 Sep 2022 09:13:11 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update.
> 
> There are a couple of details of this fix to highlight:
> -  A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`.
> - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored.
> - Suspending threads in temporary transition is allowed.
> 
> The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6.

This pull request has now been integrated.

Changeset: 79ccc791
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/79ccc791f275be7cfea95ff0ce8cf7361c7f08ad
Stats:     148 lines in 10 files changed: 80 ins; 3 del; 65 mod

8293613: need to properly handle and hide tmp VTMS transitions

Reviewed-by: cjplummer, lmesnik

-------------

PR: https://git.openjdk.org/jdk/pull/10321

From iklam at openjdk.org  Wed Sep 28 05:47:46 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 28 Sep 2022 05:47:46 GMT
Subject: RFR: 8293540: [Metrics] Incorrectly detected resource limits with
 additional cgroup fs mounts [v3]
In-Reply-To: <-GC6RSB-rnXjie1pCd0k7bzPNbGlmyRbR6xyNNJNWzU=.c428b704-c7e6-450f-8107-63ce417e6408@github.com>
References: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
 <-GC6RSB-rnXjie1pCd0k7bzPNbGlmyRbR6xyNNJNWzU=.c428b704-c7e6-450f-8107-63ce417e6408@github.com>
Message-ID: <TJY2GKBQMw6V9Fi1LgT2hnyOdaiziTeHNAz7_NR2Zo8=.bc9e32d9-1d33-436e-b5fd-1658c6f319d1@github.com>

On Thu, 15 Sep 2022 08:55:41 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Similar issue to the hotspot change discussed in https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation may get the resource limits wrong if there are additional cgroup fs mounts. Apparently that's more common than one might think. I've reproduced this with these existing tests on cg v2:
>> 
>> 
>> test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java
>> test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java
>> test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java 
>> 
>> 
>> I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` and amended `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which unconditionally fails (irrespective of cgroup version in use). The fix is fairly straight forward and is an extension which we already do for the `cpuset` controller: Allow duplicates, and if there are any prefer those mounted at `/sys/fs/cgroup`.
>> 
>> Testing:
>> - [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the product fix)
>> - [x] added tests fail before, pass after the product fix.
>> - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still pass. 
>> - [x] GHA all pass.
>> 
>> Please review! Many thanks in advance.
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8293540: [Metrics] Potentially incorrectly detected resource limits with additional cgroup fs mounts

The JDK change looks good to me. Some nits for the test cases.

test/jdk/jdk/internal/platform/docker/TestDockerBasic.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @summary Verify that -XshowSettings:system works

Add `@bug 8293540`

test/jdk/jdk/internal/platform/docker/TestDockerBasic.java line 64:

> 62:         opts.addDockerOpts("--memory", "300m");
> 63:         if (addCgroupMounts) {
> 64:             opts.addDockerOpts("--volume", "/sys/fs/cgroup:/cgroup-in:ro");

Add comments that the extra mount should be ignored by the cgroup set-up code. (Same for other test cases).

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10248

From duke at openjdk.org  Wed Sep 28 06:27:22 2022
From: duke at openjdk.org (Markus KARG)
Date: Wed, 28 Sep 2022 06:27:22 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo
 [v11]
In-Reply-To: <dNsTYdjKRFlt9jQxc3o_WX_ZMivOZOgy4SEhYWqsFhE=.9099bfb2-f5d2-4135-96c9-0b02fea75e22@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <_la5Co3yx5ik1wt7Y6Bi7MDC3MCVUxIKxz_iQQp2TT8=.1023ef6d-266f-45f5-aa93-7218d0d89c10@github.com>
 <VNT4kts7ahX1UIRRohyp7x9RSxrF0zslIE90yfJYYF0=.27ebea5e-1d31-4235-b3fa-0e2a2eb4d702@github.com>
 <dNsTYdjKRFlt9jQxc3o_WX_ZMivOZOgy4SEhYWqsFhE=.9099bfb2-f5d2-4135-96c9-0b02fea75e22@github.com>
Message-ID: <GZ4yNTlpe8O_Rs9pAkcDsj9TNAE6YfGJlATQSPH4-3k=.98870d7d-b485-4571-9636-addc2e0bf631@github.com>

On Mon, 26 Sep 2022 21:35:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> @bplb Fixed the issues you pointed out. Kindly requesting approval. :-)
>
>> @bplb Fixed the issues you pointed out.
> 
> @mkarg You are welcome.

@bplb I would be very glad if you would `/sponsor` my PR. :-)

-------------

PR: https://git.openjdk.org/jdk/pull/6935

From turbanoff at gmail.com  Wed Sep 28 06:58:05 2022
From: turbanoff at gmail.com (Andrey Turbanov)
Date: Wed, 28 Sep 2022 09:58:05 +0300
Subject: Redundant @SuppressWarnings("deprecation") for Thread.getThreadGroup()
Message-ID: <CAF+DQ5ecSj-omiq_kNtZa9jm73vLnazMtW091x1qCAt9BKQ94g@mail.gmail.com>

Hello.
IntelliJ IDEA highlights redundant warning suppressions for
Thread.getThreadGroup() calls in ThreadGroup calls.
All of them were added during Loom integration.

https://github.com/openjdk/jdk/blob/79ccc791f275be7cfea95ff0ce8cf7361c7f08ad/src/java.base/share/classes/java/lang/ThreadGroup.java#L378
https://github.com/openjdk/jdk/blob/79ccc791f275be7cfea95ff0ce8cf7361c7f08ad/src/java.base/share/classes/java/lang/ThreadGroup.java#L449
https://github.com/openjdk/jdk/blob/79ccc791f275be7cfea95ff0ce8cf7361c7f08ad/src/java.base/share/classes/java/lang/ThreadGroup.java#L585

Is it still planned to deprecate this method? Or can I remove
redundant suppressions?

Andrey Turbanov

From jpai at openjdk.org  Wed Sep 28 07:10:22 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 28 Sep 2022 07:10:22 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event
In-Reply-To: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
Message-ID: <HVbwXxN92O7Q9shNIuVCnREo0SVI-fGZSVWqaz2eZVE=.4dc123f2-8bda-42d0-867f-a7dbecc7a857@github.com>

On Thu, 22 Sep 2022 15:57:56 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> New JFR event to record state of initial security properties.
>  
> Debug output is also now added for these properties via -Djava.security.debug=properties

Hello Sean,

> Debug output is also now added for these properties via -Djava.security.debug=properties

Looking at the existing code upstream, it appears that the value `properties` is already recognized for `java.security.debug` system property. So it's not something this PR is introducing/proposing. However, the documentation for this system property doesn't seem to be listing that as a value https://docs.oracle.com/en/java/javase/19/security/troubleshooting-security.html. Do you think that documentation would need to be addressed (as a separate issue)?

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From Alan.Bateman at oracle.com  Wed Sep 28 07:17:42 2022
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 28 Sep 2022 08:17:42 +0100
Subject: Redundant @SuppressWarnings("deprecation") for
 Thread.getThreadGroup()
In-Reply-To: <CAF+DQ5ecSj-omiq_kNtZa9jm73vLnazMtW091x1qCAt9BKQ94g@mail.gmail.com>
References: <CAF+DQ5ecSj-omiq_kNtZa9jm73vLnazMtW091x1qCAt9BKQ94g@mail.gmail.com>
Message-ID: <c86e84f2-b89b-7558-b0b6-462d415fbb85@oracle.com>

On 28/09/2022 07:58, Andrey Turbanov wrote:
> Hello.
> IntelliJ IDEA highlights redundant warning suppressions for
> Thread.getThreadGroup() calls in ThreadGroup calls.
> All of them were added during Loom integration.
>
> https://github.com/openjdk/jdk/blob/79ccc791f275be7cfea95ff0ce8cf7361c7f08ad/src/java.base/share/classes/java/lang/ThreadGroup.java#L378
> https://github.com/openjdk/jdk/blob/79ccc791f275be7cfea95ff0ce8cf7361c7f08ad/src/java.base/share/classes/java/lang/ThreadGroup.java#L449
> https://github.com/openjdk/jdk/blob/79ccc791f275be7cfea95ff0ce8cf7361c7f08ad/src/java.base/share/classes/java/lang/ThreadGroup.java#L585
>
> Is it still planned to deprecate this method? Or can I remove
> redundant suppressions?
>
At some point yes, but it may be too disruptive in the short term. I 
think these SW are left over from one of the iterations where it was 
deprecated. It's okay to remove them.

-Alan

From mbaesken at openjdk.org  Wed Sep 28 07:31:29 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 28 Sep 2022 07:31:29 GMT
Subject: RFR: JDK-8293701: jdeps InverseDepsAnalyzer runs into
 NoSuchElementException: No value present
In-Reply-To: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
References: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
Message-ID: <JjbGY0B4M3tpPdvPSFI8QHtDusTt8jseyMpPf2CxfP0=.60239c98-6cb0-46d2-9981-388ab4b16ed0@github.com>

On Fri, 16 Sep 2022 08:26:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We noticed that with certain jar file input, jdeps runs into the following exception, this happens with jdk11, 17 and 20.
> 
> jdeps.exe --multi-release 11 --module-path . --inverse --package com.sap.nw.performance.supa.client test.jar
> 
> Inverse transitive dependences matching packages [com.sap.nw.performance.supa.client]
> Exception in thread "main" java.util.NoSuchElementException: No value present
>         at java.base/java.util.Optional.get(Optional.java:148)
>         at jdk.jdeps/com.sun.tools.jdeps.InverseDepsAnalyzer.lambda$inverseDependences$2(InverseDepsAnalyzer.java:150)
>         at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>         at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>         at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
>         at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>         at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> 
> So an additional  check might be a good idea.

Hi Mandy,

> This is caused by the optional dependency requires static M; which is not resolved in the runtime configuration even if it's observable.

looks like this is indeed the issue. With your patch applied  the exception  "Exception in thread "main" java.util.NoSuchElementException: No value present"  is gone .

I reproduced it on my large example as well.
Reason was that some build dependency jar(s)  were missing at runtime,  and jdeps did not accept this.

-------------

PR: https://git.openjdk.org/jdk/pull/10300

From rgiulietti at openjdk.org  Wed Sep 28 09:14:28 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 28 Sep 2022 09:14:28 GMT
Subject: RFR: 8065554: MatchResult should provide values of named-capturing
 groups [v7]
In-Reply-To: <42Ev9fkW6Eikmx176RXPOKvwIU30MbQR3upwFjdKJ6s=.6bb50e0f-d4f0-4285-9905-ef3d56b32ade@github.com>
References: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
 <42Ev9fkW6Eikmx176RXPOKvwIU30MbQR3upwFjdKJ6s=.6bb50e0f-d4f0-4285-9905-ef3d56b32ade@github.com>
Message-ID: <1Dg_6T4DemTOht4qJ3-VNhpEuk-c82XA6ieEvlZ5V4I=.7ec8b72f-97a2-45ac-8a40-cf8acc3b3879@github.com>

On Thu, 22 Sep 2022 10:22:40 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Add support for named groups to java.util.regex.MatchResult
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8065554: MatchResult should provide values of named-capturing groups

I'll integrate now but agree to open another PR to make use of JUnit in the tests, perhaps later this week or next week.

-------------

PR: https://git.openjdk.org/jdk/pull/10000

From duke at openjdk.org  Wed Sep 28 09:45:32 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Wed, 28 Sep 2022 09:45:32 GMT
Subject: RFR: 8293579:
 tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese
 Windows platform [v2]
In-Reply-To: <ROgI801Y_MVdXiCKPYVtwN9C5kDZTT3gdAo4pnCACbs=.618721ad-4cc5-4db7-a923-3bf740e35181@github.com>
References: <ROgI801Y_MVdXiCKPYVtwN9C5kDZTT3gdAo4pnCACbs=.618721ad-4cc5-4db7-a923-3bf740e35181@github.com>
Message-ID: <25y_sJVHa9QDx4VcfIJDu9RsAO2EYVfCAcpfWthsczw=.d19ddb42-2cad-497d-8345-1918823fdbfb@github.com>

> Could you please review the JDK-8293579 bug fixes?
> 
> tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java attempts to give 
> the launcher the character which is encoded by Windows API WideCharToMultiByte() 
> from UNICODE "?"(0x00e9) as an argument. However, this test fails because the 
> code point "?"(0x00e9) cannot be treated on Japanese Windows.
> 
> WideCharToMultiByte() encodes characters as Shift-JIS on Japanese Windows, but 
> the code point "?"(0x00e9) does not exist in Shift-JIS, and it is replaced with 
> "e"(0x0065) as substitute. Therefore, "?"(0x00e9) and "e"(0x0065) are compared 
> in this test and judged to be different characters, and return as failed.
> 
> So, in the Japanese encoding("MS932", "SJIS"), the test should be modified to 
> give a character such as "?"(0x3042) as the launcher's argument instead of 
> "?"(0x00e9).

KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:

  8293579: tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese Windows platform

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10226/files
  - new: https://git.openjdk.org/jdk/pull/10226/files/476c1a0c..2baff408

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10226&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10226&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10226.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10226/head:pull/10226

PR: https://git.openjdk.org/jdk/pull/10226

From duke at openjdk.org  Wed Sep 28 09:45:33 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Wed, 28 Sep 2022 09:45:33 GMT
Subject: RFR: 8293579:
 tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese
 Windows platform
In-Reply-To: <PslvzFQjyULART_fZym9bib6NkPAxiq9l8kFlpJbpjk=.5453fff3-e74a-4590-a44c-0ff3772403d5@github.com>
References: <ROgI801Y_MVdXiCKPYVtwN9C5kDZTT3gdAo4pnCACbs=.618721ad-4cc5-4db7-a923-3bf740e35181@github.com>
 <PslvzFQjyULART_fZym9bib6NkPAxiq9l8kFlpJbpjk=.5453fff3-e74a-4590-a44c-0ff3772403d5@github.com>
Message-ID: <B-bej7ulwWfR6kB-T96UOr3rgNpoxsE_LsxeJornJMo=.02cbd0b3-4bf1-4466-99e6-2c97630ba719@github.com>

On Wed, 14 Sep 2022 21:07:41 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Could you please review the JDK-8293579 bug fixes?
>> 
>> tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java attempts to give 
>> the launcher the character which is encoded by Windows API WideCharToMultiByte() 
>> from UNICODE "?"(0x00e9) as an argument. However, this test fails because the 
>> code point "?"(0x00e9) cannot be treated on Japanese Windows.
>> 
>> WideCharToMultiByte() encodes characters as Shift-JIS on Japanese Windows, but 
>> the code point "?"(0x00e9) does not exist in Shift-JIS, and it is replaced with 
>> "e"(0x0065) as substitute. Therefore, "?"(0x00e9) and "e"(0x0065) are compared 
>> in this test and judged to be different characters, and return as failed.
>> 
>> So, in the Japanese encoding("MS932", "SJIS"), the test should be modified to 
>> give a character such as "?"(0x3042) as the launcher's argument instead of 
>> "?"(0x00e9).
>
> `native.encoding` holds the host encoding that used to be `file.encoding`.
> Another suggestion is that, the test should only run in encodings that are guaranteed to succeed, e.g., `Cp1252` or `UTF-8`, otherwise it should gracefully exit. Your proposed fix could still fail in locales/encodings other than SJIS/MS932.

@naotoj 
Thank you for your help. I fixed this test to use native.encoding.
It is difficult to add all the encodings, so I will fix for Japanese and would like people who need other languages to do the same.

-------------

PR: https://git.openjdk.org/jdk/pull/10226

From dsamersoff at openjdk.org  Wed Sep 28 09:48:22 2022
From: dsamersoff at openjdk.org (Dmitry Samersoff)
Date: Wed, 28 Sep 2022 09:48:22 GMT
Subject: RFR: 8293806: JDK_JAVA_OPTIONS picked up twice if LD_LIBRARY_PATH
 is set
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: <Rb-Rv_ZGP2OhYPneYO40X4LSX21utYlRNAorLnUABt8=.7690084a-79a6-4625-b431-cd6051094e2e@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.

> 
Unfortunately not. 
Java application (like IDE) may rely on JDK_JAVA_OPTIONS variable to pass Java options to it's child processes.

-------------

PR: https://git.openjdk.org/jdk/pull/10430

From dnsimon at openjdk.org  Wed Sep 28 09:50:31 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 28 Sep 2022 09:50:31 GMT
Subject: RFR: 8237467: jlink plugin to save the argument files as input to
 jlink in the output image [v4]
In-Reply-To: <ol0heS5-LEFjuZkoFjkdraX-9tjEQ371Pii5KkYyO1c=.1cdd4b7d-426d-4075-ac99-9460d0200904@github.com>
References: <ol0heS5-LEFjuZkoFjkdraX-9tjEQ371Pii5KkYyO1c=.1cdd4b7d-426d-4075-ac99-9460d0200904@github.com>
Message-ID: <7xxdb1rLCxV1QpJA0QZkmsDmrF6f2bNXVESF97_2sXk=.e9ff1aae-7450-42ae-b839-84ff0b499dd2@github.com>

> This PR adds a new jlink plugin (`--save-jlink-argfiles=<filenames>`) to support persisting jlink options.
> 
> 
>> echo "--add-modules jdk.internal.vm.ci --add-options=-Dfoo=xyzzy --vendor-version="XyzzyVM 3.14.15" --vendor-bug-url=https://bugs.xyzzy.com/" > my_image.argfile
>> export ALL_MODULES=$(java --list-modules | sed 's:@.*::g' | tr '\n' ',')
>> jlink --keep-packaged-modules=my_image/jmods --add-modules $ALL_MODULES --output=my_image --save-jlink-argfiles my_image.argfile
>> my_image/bin/java -XshowSettings:properties --version 2>&1 | grep yzzy
>> my_image/bin/jlink --add-modules=java.base --output=my_image2
>> my_image2/bin/java -XshowSettings:properties --version 2>&1 | grep yzzy
>     foo = xyzzy
>     java.vendor.url.bug = https://bugs.xyzzy.com/
>     java.vendor.version = XyzzyVM 3.14.15
> OpenJDK Runtime Environment XyzzyVM 3.14.15 (build 20-internal-2022-09-22-0951036.dnsimon...)
> OpenJDK 64-Bit Server VM XyzzyVM 3.14.15 (build 20-internal-2022-09-22-0951036.dnsimon..., mixed mode)
>> my_image2/bin/java -d jdk.internal.vm.ci | head -1
> jdk.internal.vm.ci at 20-internal

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  improved text for help message

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10445/files
  - new: https://git.openjdk.org/jdk/pull/10445/files/91938caa..0c17bc89

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10445&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10445&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10445.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10445/head:pull/10445

PR: https://git.openjdk.org/jdk/pull/10445

From coffeys at openjdk.org  Wed Sep 28 10:09:41 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 28 Sep 2022 10:09:41 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event
In-Reply-To: <QXIQe5EqORYqyigwI84XMHTEYvY3jM-ersDVdN9EeKo=.c0f4ab18-b7f9-4ee9-abc7-816fbd37ff5b@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <QXIQe5EqORYqyigwI84XMHTEYvY3jM-ersDVdN9EeKo=.c0f4ab18-b7f9-4ee9-abc7-816fbd37ff5b@github.com>
Message-ID: <tPKKm9gjnIZtbN189Qb-o0-Mv6fiNq9lm5lUJtjxXcM=.3b43450c-a7fa-4ce0-8004-3b5329597f6b@github.com>

On Tue, 27 Sep 2022 20:29:31 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> New JFR event to record state of initial security properties.
>>  
>> Debug output is also now added for these properties via -Djava.security.debug=properties
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 312:
> 
>> 310:     }
>> 311: 
>> 312:     private static void emitInitialSecurityProperties() {
> 
> Is the `Security` class loaded and have the properties always been populated at this point? ProtectionDomain` doesn't reference the `Security` class AFAICT.

Good catch. JFR does load the Security class [1] via other dependencies but we shouldn't depend on that. I'll add a null check here. If Security class hasn't been loaded, then we shouldn't record any events.


[1]
java.lang.Throwable
        at java.base/java.security.Security.<clinit>(Security.java:73)
        at java.base/sun.security.util.SecurityProperties.getOverridableProperty(SecurityProperties.java:57)
        at java.base/sun.security.util.SecurityProperties.privilegedGetOverridable(SecurityProperties.java:48)
        at java.base/sun.security.util.SecurityProperties.includedInExceptions(SecurityProperties.java:72)
        at java.base/sun.security.util.SecurityProperties.<clinit>(SecurityProperties.java:36)
        at java.base/sun.security.util.FilePermCompat.<clinit>(FilePermCompat.java:43)
        at java.base/java.security.AccessControlContext.<init>(AccessControlContext.java:270)
        at java.base/java.security.AccessController.createWrapper(AccessController.java:649)
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:461)
        at jdk.jfr/jdk.jfr.internal.SecuritySupport.doPrivilegedWithReturn(SecuritySupport.java:261)
        at jdk.jfr/jdk.jfr.internal.SecuritySupport.getPathInProperty(SecuritySupport.java:331)
        at jdk.jfr/jdk.jfr.internal.SecuritySupport.<clinit>(SecuritySupport.java:80)
        at jdk.jfr/jdk.jfr.internal.JVMSupport.checkAvailability(JVMSupport.java:46)
        at jdk.jfr/jdk.jfr.internal.JVMSupport.<clinit>(JVMSupport.java:41)
        at jdk.jfr/jdk.jfr.internal.Logger.<clinit>(Logger.java:41)
        at jdk.jfr/jdk.jfr.internal.dcmd.AbstractDCmd.execute(AbstractDCmd.java:75)

> src/jdk.jfr/share/conf/jfr/default.jfc line 713:
> 
>> 711: 
>> 712:     <event name="jdk.InitialSecurityProperty">
>> 713:       <setting name="enabled">true</setting>
> 
> The other security related events are not enabled by default. Is this one enabled because it is only generated once? It seems it may still have some startup overhead because AFAIU it forces a load of security properties even if they are never accessed? Perhaps I don't fully understand how this event works though.

Yes - the thinking here is that since this is a one time event, we can have it enabled. It's similar to the InitialSystemProperty event. 

We won't force loading of Security properties/class. We shouldn't at least. If no security properties are read in at time of JFR event commit, then we should have no InitialSecurityProperty events. See below/next comment.

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From coffeys at openjdk.org  Wed Sep 28 10:16:22 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 28 Sep 2022 10:16:22 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v2]
In-Reply-To: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
Message-ID: <rwmqU_nerPgYMzJ2MyQ5kr81jRdcmiV2VBvpbE4CaPI=.d67db897-460d-4141-b565-9ab8ba65bfb5@github.com>

> New JFR event to record state of initial security properties.
>  
> Debug output is also now added for these properties via -Djava.security.debug=properties

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  Null check on Properties

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10394/files
  - new: https://git.openjdk.org/jdk/pull/10394/files/5343a056..aed938d2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10394&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10394&range=00-01

  Stats: 7 lines in 1 file changed: 2 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/10394.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10394/head:pull/10394

PR: https://git.openjdk.org/jdk/pull/10394

From coffeys at openjdk.org  Wed Sep 28 10:16:24 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 28 Sep 2022 10:16:24 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event
In-Reply-To: <HVbwXxN92O7Q9shNIuVCnREo0SVI-fGZSVWqaz2eZVE=.4dc123f2-8bda-42d0-867f-a7dbecc7a857@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <HVbwXxN92O7Q9shNIuVCnREo0SVI-fGZSVWqaz2eZVE=.4dc123f2-8bda-42d0-867f-a7dbecc7a857@github.com>
Message-ID: <vpJ3K6Fzruk9P1OvaUd0F7azraM73R6SeLV51xVojMk=.d23f6da9-8da1-4e70-8ef0-f596bf69f1b4@github.com>

On Wed, 28 Sep 2022 07:06:30 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Sean,
> 
> > Debug output is also now added for these properties via -Djava.security.debug=properties
> 
> Looking at the existing code upstream, it appears that the value `properties` is already recognized for `java.security.debug` system property. So it's not something this PR is introducing/proposing. However, the documentation for this system property doesn't seem to be listing that as a value https://docs.oracle.com/en/java/javase/19/security/troubleshooting-security.html. Do you think that documentation would need to be addressed (as a separate issue)?

Good point Jai. It's a rarely used property value I guess, but it would be exposed via the "all" debug value option as per test. I suspect there may be other such properties also. I'll log a JBS issue to track this and to have security/docs team discuss.

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From shade at openjdk.org  Wed Sep 28 11:45:10 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 28 Sep 2022 11:45:10 GMT
Subject: RFR: 8294520: Problemlist java/nio/file/Files/CopyProcFile.java
Message-ID: <A2dFW-gtQuEi0xfTCbDT9UekpO_KfvqGYNXh_rGLYY4=.296066a3-554b-4a13-85b3-ed7ec934e724@github.com>

Problemlist-ing this tier2 test due to [JDK-8294519](https://bugs.openjdk.org/browse/JDK-8294519).

Additional testing:
 - [x] Linux x86_64 fastdebug, test is now skipped

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/10465/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10465&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294520
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10465.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10465/head:pull/10465

PR: https://git.openjdk.org/jdk/pull/10465

From jwaters at openjdk.org  Wed Sep 28 12:14:34 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 28 Sep 2022 12:14:34 GMT
Subject: RFR: 8292016: Split Windows API error handling from errors passed
 through the runtime in the JDK [v22]
In-Reply-To: <S3foO_lw8Qp5f1NosQ8cx1v96miI57hdDTQ4FIOlYbo=.26b894ca-3505-46e9-9c43-d381e2d4e1bc@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
 <S3foO_lw8Qp5f1NosQ8cx1v96miI57hdDTQ4FIOlYbo=.26b894ca-3505-46e9-9c43-d381e2d4e1bc@github.com>
Message-ID: <0SGomU7hjPXkdsZXjiET_RcLHN1YrF10WBNVgKmZwbw=.a0414214-170d-416b-887c-10983adf47a0@github.com>

On Mon, 26 Sep 2022 15:47:51 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> EDIT: Cave and add the ErrorOrigin enum, to differentiate which error type the error reporting functions in libjava will look up. RUNTIME refers to errors passed through the runtime via errno, and SYSTEM is for native errors not visible to the runtime.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Whitespace

Ah alright, will try removing all of them and checking whether behaviour changes rise up in that case. Will push if none result from the change

-------------

PR: https://git.openjdk.org/jdk/pull/9870

From mullan at openjdk.org  Wed Sep 28 12:30:23 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 28 Sep 2022 12:30:23 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v2]
In-Reply-To: <tPKKm9gjnIZtbN189Qb-o0-Mv6fiNq9lm5lUJtjxXcM=.3b43450c-a7fa-4ce0-8004-3b5329597f6b@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <QXIQe5EqORYqyigwI84XMHTEYvY3jM-ersDVdN9EeKo=.c0f4ab18-b7f9-4ee9-abc7-816fbd37ff5b@github.com>
 <tPKKm9gjnIZtbN189Qb-o0-Mv6fiNq9lm5lUJtjxXcM=.3b43450c-a7fa-4ce0-8004-3b5329597f6b@github.com>
Message-ID: <5TadUhgSG09rHgRo7EFIblKjlnvHr-q2DGSGfV2ezF0=.6e824b66-846c-476f-a372-6d5260e3d399@github.com>

On Wed, 28 Sep 2022 10:06:54 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> src/jdk.jfr/share/conf/jfr/default.jfc line 713:
>> 
>>> 711: 
>>> 712:     <event name="jdk.InitialSecurityProperty">
>>> 713:       <setting name="enabled">true</setting>
>> 
>> The other security related events are not enabled by default. Is this one enabled because it is only generated once? It seems it may still have some startup overhead because AFAIU it forces a load of security properties even if they are never accessed? Perhaps I don't fully understand how this event works though.
>
> Yes - the thinking here is that since this is a one time event, we can have it enabled. It's similar to the InitialSystemProperty event. 
> 
> We won't force loading of Security properties/class. We shouldn't at least. If no security properties are read in at time of JFR event commit, then we should have no InitialSecurityProperty events. See below/next comment.

Ok, just so I understand, you want to make sure that if JFR is started after the security properties have already been read, then they are still recorded, right?

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From alanb at openjdk.org  Wed Sep 28 12:37:27 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 28 Sep 2022 12:37:27 GMT
Subject: RFR: 8294520: Problemlist java/nio/file/Files/CopyProcFile.java
In-Reply-To: <A2dFW-gtQuEi0xfTCbDT9UekpO_KfvqGYNXh_rGLYY4=.296066a3-554b-4a13-85b3-ed7ec934e724@github.com>
References: <A2dFW-gtQuEi0xfTCbDT9UekpO_KfvqGYNXh_rGLYY4=.296066a3-554b-4a13-85b3-ed7ec934e724@github.com>
Message-ID: <osW0t3vNgIlpImOEMTdR92mI0ZAIvvhFwW7rAUL8WrA=.615d3961-3f97-4f86-948c-9c0e1c9101ea@github.com>

On Wed, 28 Sep 2022 11:24:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Problemlist-ing this tier2 test due to [JDK-8294519](https://bugs.openjdk.org/browse/JDK-8294519).
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, test is now skipped

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10465

From coffeys at openjdk.org  Wed Sep 28 12:54:19 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 28 Sep 2022 12:54:19 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v2]
In-Reply-To: <5TadUhgSG09rHgRo7EFIblKjlnvHr-q2DGSGfV2ezF0=.6e824b66-846c-476f-a372-6d5260e3d399@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <QXIQe5EqORYqyigwI84XMHTEYvY3jM-ersDVdN9EeKo=.c0f4ab18-b7f9-4ee9-abc7-816fbd37ff5b@github.com>
 <tPKKm9gjnIZtbN189Qb-o0-Mv6fiNq9lm5lUJtjxXcM=.3b43450c-a7fa-4ce0-8004-3b5329597f6b@github.com>
 <5TadUhgSG09rHgRo7EFIblKjlnvHr-q2DGSGfV2ezF0=.6e824b66-846c-476f-a372-6d5260e3d399@github.com>
Message-ID: <H5QVVX7TbXodlDE2Q4AtJVU2sTGe3px3Trr8J-o0C0g=.db75c32e-da1d-4e7a-bb1b-fa5c990069d7@github.com>

On Wed, 28 Sep 2022 12:26:49 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Yes - the thinking here is that since this is a one time event, we can have it enabled. It's similar to the InitialSystemProperty event. 
>> 
>> We won't force loading of Security properties/class. We shouldn't at least. If no security properties are read in at time of JFR event commit, then we should have no InitialSecurityProperty events. See below/next comment.
>
> Ok, just so I understand, you want to make sure that if JFR is started after the security properties have already been read, then they are still recorded, right?

Correct - this type of event period (beginChunk) will fire once when the JFR recording is begun. It should capture Security Properties (if java.security.Security is loaded) for any recording, no matter when it might begin or end. Similar to how InitialSystemProperty is captured (but that's implemented at native/VM level)

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From dfuchs at openjdk.org  Wed Sep 28 13:24:26 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 28 Sep 2022 13:24:26 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <1UZcv-X4dxQHlgj8b5B2sGJ9NpxWrOp1EwbWeazjj2I=.1cf2b14f-7064-47b6-8d25-887732020bb0@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com>
 <1UZcv-X4dxQHlgj8b5B2sGJ9NpxWrOp1EwbWeazjj2I=.1cf2b14f-7064-47b6-8d25-887732020bb0@github.com>
Message-ID: <aY7BXF5EIYZFFZcE_IWj3PwKjQLD35cJPnaJkvQpQmU=.5464c3b4-6a6b-4841-b24f-969b371dfc74@github.com>

On Tue, 27 Sep 2022 23:12:43 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> Feel free to break up the pull request if that is what is needed to free it from red tape.

Only you can do that @mernst

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From dfuchs at openjdk.org  Wed Sep 28 13:38:37 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 28 Sep 2022 13:38:37 GMT
Subject: RFR: 8294377: Prepare to stop auto-inheriting documentation for
 subclasses of exceptions whose documentation is inherited [v2]
In-Reply-To: <rZOv9leE3Krs9IA7nAMMZPVelsIgC5am13o1oU8BF8Y=.fe7d7524-1a12-4a38-aedb-f9dd60cdded8@github.com>
References: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>
 <rZOv9leE3Krs9IA7nAMMZPVelsIgC5am13o1oU8BF8Y=.fe7d7524-1a12-4a38-aedb-f9dd60cdded8@github.com>
Message-ID: <WjnsB8gd3r6yurtHuMpcEK4-TJ8ox_psgBl5HRRLsLs=.512f181c-4da4-4eec-8d3d-63a8f19c2b07@github.com>

On Tue, 27 Sep 2022 12:14:23 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This adds exception documentation to JDK methods that would otherwise lose that documentation once JDK-8287796 is integrated. While adding this exception documentation now does not change [^1] the JDK API Documentation, it will automatically counterbalance the effect that JDK-8287796 will have.
>> 
>> JDK-8287796 seeks to remove an old, undocumented, and esoteric javadoc feature that cannot be suppressed [^2]. The feature is so little known about that IDEs either do not implement it correctly or do not implement it at all, thus rendering documentation differently from how the javadoc tool renders it.
>> 
>> That feature was introduced in JDK-4947455 and manifests as follows. If a method inherits documentation for an exception, along with that documentation the method automatically inherits documentation for all exceptions that are subclasses of that former exception and are documented in an overridden method.
>> 
>> To illustrate that behavior, consider the following example. A method `Subtype.m` inherits documentation for `SuperException`, while the overridden method `Supertype.m` documents `SuperException`, `SubExceptionA` and `SubExceptionB`, where the latter two exceptions are subclasses of the former exception:
>> 
>>     public class Subtype extends Supertype {
>> 
>>         @Override
>>         public void m() throws SuperException {
>>     ...
>> 
>>     public class Supertype {
>> 
>>         /**
>>          * @throws SuperException general problem
>>          * @throws SubExceptionA  specific problem A
>>          * @throws SubExceptionB  specific problem B
>>          */
>>         public void m() throws SuperException {
>>     ...
>> 
>>     public class SuperException extends Exception {
>>     ...
>> 
>>     public class SubExceptionA extends SuperException {
>>     ...
>> 
>>     public class SubExceptionB extends SuperException {
>>     ...
>> 
>> For the above example, the API Documentation for `Subtype.m` will contain documentation for all three exceptions; the page fragment for `Subtype.m` in "Method Details" will look like this:
>> 
>>     public void m()
>>            throws SuperException
>> 
>>     Overrides:
>>         m in class Supertype
>>     Throws:
>>         SuperException - general problem
>>         SubExceptionA - specific problem A
>>         SubExceptionB - specific problem B 
>> 
>> It works for checked and unchecked exceptions, for methods in classes and interfaces.
>> 
>> 
>> If it's the first time you hear about that behavior and this change affects your area, it's a good opportunity to reflect on whether the exception documentation this change adds is really needed or you were simply unaware of the fact that it was automatically added before. If exception documentation is not needed, please comment on this PR. Otherwise, consider approving it.
>> 
>> Keep in mind that if some exception documentation is not needed, **leaving it out** from this PR might require a CSR.
>> 
>> 
>> [^1]: Aside from insignificant changes on class-use and index pages. There's one relatively significant change. This change is in jdk.jshell, where some methods disappeared from "Methods declared in ..." section and other irregularities. We are aware of this and have filed JDK-8291803 to fix the root cause.
>> [^2]: In reality, the feature can be suppressed, but it looks like a bug rather than intentional design. If we legitimize the feature and its suppression behavior, the model for exception documentation inheritance might become much more complicated.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert an extraneous change to jdk.javadoc

The changes to JNDI and NIO look reasonable to me - though I haven't verified whether anything was missing (or no longer needed). If you can assert that the generated docs are the same before and after the proposed change then that's enough for me.

src/java.naming/share/classes/javax/naming/directory/InitialDirContext.java line 186:

> 184:     /**
> 185:      * @throws  AttributeModificationException {@inheritDoc}
> 186:      */

Isn't `{@inheritDoc}` needed in this case to preserve the method & params  description?

-------------

PR: https://git.openjdk.org/jdk/pull/10449

From prappo at openjdk.org  Wed Sep 28 14:04:25 2022
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 28 Sep 2022 14:04:25 GMT
Subject: RFR: 8294377: Prepare to stop auto-inheriting documentation for
 subclasses of exceptions whose documentation is inherited [v2]
In-Reply-To: <WjnsB8gd3r6yurtHuMpcEK4-TJ8ox_psgBl5HRRLsLs=.512f181c-4da4-4eec-8d3d-63a8f19c2b07@github.com>
References: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>
 <rZOv9leE3Krs9IA7nAMMZPVelsIgC5am13o1oU8BF8Y=.fe7d7524-1a12-4a38-aedb-f9dd60cdded8@github.com>
 <WjnsB8gd3r6yurtHuMpcEK4-TJ8ox_psgBl5HRRLsLs=.512f181c-4da4-4eec-8d3d-63a8f19c2b07@github.com>
Message-ID: <AtkGrQJlrGsyJWAgtPgeUmc1nONMsxO_vzqUAFm2csk=.05cfb965-4e97-4507-b500-f95e06583ad8@github.com>

On Wed, 28 Sep 2022 13:34:08 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert an extraneous change to jdk.javadoc
>
> src/java.naming/share/classes/javax/naming/directory/InitialDirContext.java line 186:
> 
>> 184:     /**
>> 185:      * @throws  AttributeModificationException {@inheritDoc}
>> 186:      */
> 
> Isn't `{@inheritDoc}` needed in this case to preserve the method & params  description?

Elements of a method declaration such as formal and type parameters as well as exceptions in the `throws` clause implicitly inherit descriptions, unless those elements are described in that method declaration. The same goes for the main description of a method: unless it exists in the method declaration, it is inherited.

To sum up, those descriptions you ask about are implicitly inherited. No additional javadoc markup is needed.

-------------

PR: https://git.openjdk.org/jdk/pull/10449

From alanb at openjdk.org  Wed Sep 28 14:22:10 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 28 Sep 2022 14:22:10 GMT
Subject: RFR: 8294377: Prepare to stop auto-inheriting documentation for
 subclasses of exceptions whose documentation is inherited [v2]
In-Reply-To: <rZOv9leE3Krs9IA7nAMMZPVelsIgC5am13o1oU8BF8Y=.fe7d7524-1a12-4a38-aedb-f9dd60cdded8@github.com>
References: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>
 <rZOv9leE3Krs9IA7nAMMZPVelsIgC5am13o1oU8BF8Y=.fe7d7524-1a12-4a38-aedb-f9dd60cdded8@github.com>
Message-ID: <jRRrURJQpNTiCWGs_oPoRkJTFb60kh_zg2ARAg_033I=.66258e70-5760-4d88-86a9-9f7bbf47c9de@github.com>

On Tue, 27 Sep 2022 12:14:23 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This adds exception documentation to JDK methods that would otherwise lose that documentation once JDK-8287796 is integrated. While adding this exception documentation now does not change [^1] the JDK API Documentation, it will automatically counterbalance the effect that JDK-8287796 will have.
>> 
>> JDK-8287796 seeks to remove an old, undocumented, and esoteric javadoc feature that cannot be suppressed [^2]. The feature is so little known about that IDEs either do not implement it correctly or do not implement it at all, thus rendering documentation differently from how the javadoc tool renders it.
>> 
>> That feature was introduced in JDK-4947455 and manifests as follows. If a method inherits documentation for an exception, along with that documentation the method automatically inherits documentation for all exceptions that are subclasses of that former exception and are documented in an overridden method.
>> 
>> To illustrate that behavior, consider the following example. A method `Subtype.m` inherits documentation for `SuperException`, while the overridden method `Supertype.m` documents `SuperException`, `SubExceptionA` and `SubExceptionB`, where the latter two exceptions are subclasses of the former exception:
>> 
>>     public class Subtype extends Supertype {
>> 
>>         @Override
>>         public void m() throws SuperException {
>>     ...
>> 
>>     public class Supertype {
>> 
>>         /**
>>          * @throws SuperException general problem
>>          * @throws SubExceptionA  specific problem A
>>          * @throws SubExceptionB  specific problem B
>>          */
>>         public void m() throws SuperException {
>>     ...
>> 
>>     public class SuperException extends Exception {
>>     ...
>> 
>>     public class SubExceptionA extends SuperException {
>>     ...
>> 
>>     public class SubExceptionB extends SuperException {
>>     ...
>> 
>> For the above example, the API Documentation for `Subtype.m` will contain documentation for all three exceptions; the page fragment for `Subtype.m` in "Method Details" will look like this:
>> 
>>     public void m()
>>            throws SuperException
>> 
>>     Overrides:
>>         m in class Supertype
>>     Throws:
>>         SuperException - general problem
>>         SubExceptionA - specific problem A
>>         SubExceptionB - specific problem B 
>> 
>> It works for checked and unchecked exceptions, for methods in classes and interfaces.
>> 
>> 
>> If it's the first time you hear about that behavior and this change affects your area, it's a good opportunity to reflect on whether the exception documentation this change adds is really needed or you were simply unaware of the fact that it was automatically added before. If exception documentation is not needed, please comment on this PR. Otherwise, consider approving it.
>> 
>> Keep in mind that if some exception documentation is not needed, **leaving it out** from this PR might require a CSR.
>> 
>> 
>> [^1]: Aside from insignificant changes on class-use and index pages. There's one relatively significant change. This change is in jdk.jshell, where some methods disappeared from "Methods declared in ..." section and other irregularities. We are aware of this and have filed JDK-8291803 to fix the root cause.
>> [^2]: In reality, the feature can be suppressed, but it looks like a bug rather than intentional design. If we legitimize the feature and its suppression behavior, the model for exception documentation inheritance might become much more complicated.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert an extraneous change to jdk.javadoc

The updates to the channel classes look okay.

-------------

PR: https://git.openjdk.org/jdk/pull/10449

From prappo at openjdk.org  Wed Sep 28 14:22:11 2022
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 28 Sep 2022 14:22:11 GMT
Subject: RFR: 8294377: Prepare to stop auto-inheriting documentation for
 subclasses of exceptions whose documentation is inherited [v2]
In-Reply-To: <WjnsB8gd3r6yurtHuMpcEK4-TJ8ox_psgBl5HRRLsLs=.512f181c-4da4-4eec-8d3d-63a8f19c2b07@github.com>
References: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>
 <rZOv9leE3Krs9IA7nAMMZPVelsIgC5am13o1oU8BF8Y=.fe7d7524-1a12-4a38-aedb-f9dd60cdded8@github.com>
 <WjnsB8gd3r6yurtHuMpcEK4-TJ8ox_psgBl5HRRLsLs=.512f181c-4da4-4eec-8d3d-63a8f19c2b07@github.com>
Message-ID: <xKmD22kAF0LCY9X5tja1gN_hXJdpSJl7mGI5RFNrKiY=.0911fc21-61a4-4536-bb58-1e8947aa2834@github.com>

On Wed, 28 Sep 2022 13:36:18 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> If you can assert that the generated docs are the same before and after the proposed change then that's enough for me.

Would it suffice if I show the result of the diff between JDK API Documentation built at the tip of this PR branch (docs) and that of the jdk/master commit (docs-old) from which this PR branches? If so, please have a look:


    % diff -qnr build/macosx-aarch64/images/docs build/macosx-aarch64/images/docs-old                                                
    Files build/macosx-aarch64/images/docs/api/index-files/index-9.html and build/macosx-aarch64/images/docs-old/api/index-files/index-9.html differ
    Files build/macosx-aarch64/images/docs/api/java.base/java/lang/class-use/Exception.html and build/macosx-aarch64/images/docs-old/api/java.base/java/lang/class-use/Exception.html differ
    Files build/macosx-aarch64/images/docs/api/java.base/java/lang/class-use/Override.html and build/macosx-aarch64/images/docs-old/api/java.base/java/lang/class-use/Override.html differ
    Files build/macosx-aarch64/images/docs/api/java.base/java/lang/class-use/String.html and build/macosx-aarch64/images/docs-old/api/java.base/java/lang/class-use/String.html differ
    Files build/macosx-aarch64/images/docs/api/java.base/java/lang/reflect/class-use/Method.html and build/macosx-aarch64/images/docs-old/api/java.base/java/lang/reflect/class-use/Method.html differ
    Files build/macosx-aarch64/images/docs/api/jdk.jshell/jdk/jshell/execution/JdiDefaultExecutionControl.html and build/macosx-aarch64/images/docs-old/api/jdk.jshell/jdk/jshell/execution/JdiDefaultExecutionControl.html differ
    Files build/macosx-aarch64/images/docs/api/jdk.jshell/jdk/jshell/execution/RemoteExecutionControl.html and build/macosx-aarch64/images/docs-old/api/jdk.jshell/jdk/jshell/execution/RemoteExecutionControl.html differ
    Files build/macosx-aarch64/images/docs/api/member-search-index.js and build/macosx-aarch64/images/docs-old/api/member-search-index.js differ

As I said in the PR description, the differences are insignificant and confined to class-use and index structures. Well, except for jdk.jshell. But even there it might be okay for now.

-------------

PR: https://git.openjdk.org/jdk/pull/10449

From shade at openjdk.org  Wed Sep 28 14:34:25 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 28 Sep 2022 14:34:25 GMT
Subject: RFR: 8294520: Problemlist java/nio/file/Files/CopyProcFile.java
In-Reply-To: <A2dFW-gtQuEi0xfTCbDT9UekpO_KfvqGYNXh_rGLYY4=.296066a3-554b-4a13-85b3-ed7ec934e724@github.com>
References: <A2dFW-gtQuEi0xfTCbDT9UekpO_KfvqGYNXh_rGLYY4=.296066a3-554b-4a13-85b3-ed7ec934e724@github.com>
Message-ID: <6h5hetRgdtftfoX5KKqK-uRzB3xWBB_htOxlxJMhhIo=.46f4fb50-d520-4252-a604-acaf85e8671f@github.com>

On Wed, 28 Sep 2022 11:24:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Problemlist-ing this tier2 test due to [JDK-8294519](https://bugs.openjdk.org/browse/JDK-8294519).
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, test is now skipped

Thanks, I am integrating to get clean `tier2`.

-------------

PR: https://git.openjdk.org/jdk/pull/10465

From shade at openjdk.org  Wed Sep 28 14:35:50 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 28 Sep 2022 14:35:50 GMT
Subject: Integrated: 8294520: Problemlist java/nio/file/Files/CopyProcFile.java
In-Reply-To: <A2dFW-gtQuEi0xfTCbDT9UekpO_KfvqGYNXh_rGLYY4=.296066a3-554b-4a13-85b3-ed7ec934e724@github.com>
References: <A2dFW-gtQuEi0xfTCbDT9UekpO_KfvqGYNXh_rGLYY4=.296066a3-554b-4a13-85b3-ed7ec934e724@github.com>
Message-ID: <Ww8ZzXYilk7Xy7hiS9kSdQP2teKCjRkQZcG6Pzt0hP0=.608639cc-9c8a-4dc9-a5be-6f9ce0936c01@github.com>

On Wed, 28 Sep 2022 11:24:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Problemlist-ing this tier2 test due to [JDK-8294519](https://bugs.openjdk.org/browse/JDK-8294519).
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, test is now skipped

This pull request has now been integrated.

Changeset: 70d8428e
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/70d8428ebbea26cd9d410b186fce08a2d5ea805b
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8294520: Problemlist java/nio/file/Files/CopyProcFile.java

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/10465

From mernst at openjdk.org  Wed Sep 28 14:49:20 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Wed, 28 Sep 2022 14:49:20 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <Jyn0vr5OLxfZ_ITdPDPtLgoutY9Uc5cenHdv7eTi9JU=.eb66135a-cf93-4661-8a64-bd16c9c1a8ed@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 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 six commits:
> 
>  - 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

Regarding breaking up the pull request:
 * No one has stated that this is actually necessary or given a guarantee that it will result in a merged pull request, only that it *might* finally free this pull request of red tape.
 * I have spent a nontrivial amount of time on these fixes.  There have been long delays, which forced me to resolve merge conflicts.  I was told that the changes are "mostly fine" without any indication of what is wrong.  I am reluctant to spend yet more time, only to later (maybe weeks later, as has already happened) find out that I still have to do something else or that all my effort was wasted.
 * No one has explained what to do.  "separate PRs by team" doesn't tell me what to do, since I don't see an org chart anywhere in the documentation that tells me what a "team" is.

I'm sorry to state it so bluntly, but this is not a good look for the JDK team being welcoming to corrections.

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From dfuchs at openjdk.org  Wed Sep 28 15:13:39 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 28 Sep 2022 15:13:39 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <Jyn0vr5OLxfZ_ITdPDPtLgoutY9Uc5cenHdv7eTi9JU=.eb66135a-cf93-4661-8a64-bd16c9c1a8ed@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <Jyn0vr5OLxfZ_ITdPDPtLgoutY9Uc5cenHdv7eTi9JU=.eb66135a-cf93-4661-8a64-bd16c9c1a8ed@github.com>
Message-ID: <kTzLFBRbJQt3hKHD094hV-0zXH9FY4Fg2wdrOvFeK34=.c79081a5-df9a-4ea0-b481-19f903f56bd9@github.com>

On Wed, 28 Sep 2022 14:45:54 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - 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
>
> Regarding breaking up the pull request:
>  * No one has stated that this is actually necessary or given a guarantee that it will result in a merged pull request, only that it *might* finally free this pull request of red tape.
>  * Despite my repeated requests, no one has justified that *this particular pull request* needs the expertise of different teams.  The only reasons stated have been custom and bureaucracy.
>  * I have spent a nontrivial amount of time on these fixes.  There have been long delays, which forced me to resolve merge conflicts.  I was told that the changes are "mostly fine" without any indication of what is wrong.  I am reluctant to spend yet more time, only to later (maybe weeks later, as has already happened) find out that I still have to do something else or that all my effort was wasted.
>  * I was condescendingly told "We have discussed several times in the past ..." even though I was not privy to those discussions.  No pointer to documentation in the JDK itself, about pull requests, was given.
>  * No one has explained what to do.  "separate PRs by team" doesn't tell me what to do, since I don't see an org chart anywhere in the documentation that tells me what a "team" is.
> 
> I'm sorry to state it so bluntly, but this is not a good look for the JDK team being welcoming to contributions.

Hi @mernst, sorry if this is how it appears. Pull requests that involve changes spanning a large set of files are notoriously harder to review since they require a reviewer from each different area to chime in. Basically you will need one reviewer from each of these areas:

-     client
-     compiler
-     core-libs
-     hotspot
-     i18n
-     javadoc
-     jmx
-     net
-     nio
-     security
-     serviceability

Jaikiran suggested to reduce the scope of this PR in his first comment:
https://github.com/openjdk/jdk/pull/10029#issuecomment-1236588632

as did several other reviewers. Sorry if the meaning (or reason) was not clear.

best regards,

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From aivanov at openjdk.org  Wed Sep 28 15:28:24 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 28 Sep 2022 15:28:24 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <XthWrxywPU-tw6sJgFSvCBHFFWiJ28ZomsCejRLM6xA=.433b9877-8e1d-4162-bb6f-60abceddec1e@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 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 six commits:
> 
>  - 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

The title says under `test/jdk/*`, yet there are lots of files changed in `src/*`.

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From mernst at openjdk.org  Wed Sep 28 15:35:40 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Wed, 28 Sep 2022 15:35:40 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <XthWrxywPU-tw6sJgFSvCBHFFWiJ28ZomsCejRLM6xA=.433b9877-8e1d-4162-bb6f-60abceddec1e@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <XthWrxywPU-tw6sJgFSvCBHFFWiJ28ZomsCejRLM6xA=.433b9877-8e1d-4162-bb6f-60abceddec1e@github.com>
Message-ID: <bj6-5xC1mWXfuzSDLowQQPxYmo9OcqnW0XYnGLvEW0c=.c97b6b36-8590-47af-bdc2-e94f2230af08@github.com>

On Wed, 28 Sep 2022 15:26:13 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The title says under `test/jdk/*`, yet there are lots of files changed in `src/*`.

The title was edited by someone other than me, as you can see from the PR history.

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From paul.sandoz at oracle.com  Wed Sep 28 15:36:43 2022
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 28 Sep 2022 15:36:43 +0000
Subject: Collections.shuffle to accept RandomGenerator
In-Reply-To: <CAE+3fjasa2Y8qZQiYNE8Dw2G8iXFmR9z3LruksGOiFMHEKeEiQ@mail.gmail.com>
References: <CAE+3fjasa2Y8qZQiYNE8Dw2G8iXFmR9z3LruksGOiFMHEKeEiQ@mail.gmail.com>
Message-ID: <0AE34224-3FED-4A34-B8F0-E2E916959600@oracle.com>

That looks reasonable.

Thinking a little more broadly.

We could also change Collections.shuffle(List) to use ThreadLocalRandom so it does not have to cache the Random instance, plus it has better concurrent and PRNG properties. The spec does not describe the precise details of randomness.
 
It?s tempting to lift Collections.shuffle(List, RandomGenerator) to List.shuffle(RandomGenerator ), similar to what we did for Collections.sort, to align with that pattern and which also aligns with reverse of sequenced collections. There is likely not much performance advantage to do doing so as there was with sort, but that location is much easier to find and use IMHO. Since the method accepts RandomGenerator the compatibility risk would likely be low.

Paul.

> On Sep 27, 2022, at 3:11 AM, Tagir Valeev <amaembo at gmail.com> wrote:
> 
> Hello!
> 
> Currently, Collections.shuffle(List, Random) accepts an outdated
> Random class instead of RandomGenerator interface. It looks like,
> RandomGenerator would suffice. The code change looks trivial (aside
> from documentation and testing), as shuffle() implementation does not
> need anything except nextInt:
> 
> diff --git a/src/java.base/share/classes/java/util/Collections.java
> b/src/java.base/share/classes/java/util/Collections.java
> --- a/src/java.base/share/classes/java/util/Collections.java (revision
> cab590517bf705418c7376edd5d7066b13b6dde8)
> +++ b/src/java.base/share/classes/java/util/Collections.java (date
> 1664273240190)
> @@ -37,6 +37,7 @@
> import java.util.function.IntFunction;
> import java.util.function.Predicate;
> import java.util.function.UnaryOperator;
> +import java.util.random.RandomGenerator;
> import java.util.stream.IntStream;
> import java.util.stream.Stream;
> import java.util.stream.StreamSupport;
> @@ -454,8 +455,12 @@
>      * @throws UnsupportedOperationException if the specified list or its
>      *         list-iterator does not support the {@code set} operation.
>      */
> -    @SuppressWarnings({"rawtypes", "unchecked"})
>     public static void shuffle(List<?> list, Random rnd) {
> +        shuffle(list, (RandomGenerator) rnd);
> +    }
> +
> +    @SuppressWarnings({"rawtypes", "unchecked"})
> +    public static void shuffle(List<?> list, RandomGenerator rnd) {
>         int size = list.size();
>         if (size < SHUFFLE_THRESHOLD || list instanceof RandomAccess) {
>             for (int i=size; i>1; i--)
> 
> What do you think? Should we implement this improvement? I think I can
> contribute if there's a general agreement that such an enhancement
> would be useful.
> 
> With best regards,
> Tagir Valeev


From smarks at openjdk.org  Wed Sep 28 15:55:34 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 28 Sep 2022 15:55:34 GMT
Subject: RFR: 8178355: IdentityHashMap uses identity-based comparison for
 values everywhere except remove(K,V) and replace(K,V,V) [v4]
In-Reply-To: <ecrTSF37lTaIo-0Fx8rdqknSFii-TS33QdJIV9woDDk=.d7c542dd-f80b-4e07-b9a1-0106e63ce4a0@github.com>
References: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
 <ecrTSF37lTaIo-0Fx8rdqknSFii-TS33QdJIV9woDDk=.d7c542dd-f80b-4e07-b9a1-0106e63ce4a0@github.com>
Message-ID: <tEka3W-pY-nlHG4I6_T--R2bcmj72O7IB7TQFHuewio=.1323c523-c738-447c-afad-265d6af9c755@github.com>

On Fri, 6 May 2022 22:05:35 GMT, liach <duke at openjdk.org> wrote:

>> Explicitly implement `remove` and `replace` in `IdentityHashMap` to compare values by identity. Updated API documentation of these two methods ([Preview](https://cr.openjdk.java.net/~liach/8178355/IdentityHashMap.html#remove(java.lang.Object,java.lang.Object))) to mention such behavior.
>
> liach 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:
> 
>  - Move tests
>  - Merge branch 'master' into fix/identityhashmap-default
>  - Fix assertions
>  - Revamp test and changes. Let ci run the tests
>  - Fix indent
>  - 8178355: IdentityHashMap uses identity-based comparison for values everywhere except remove(K,V) and replace(K,V,V)

I swear, I'll get to this soon! I even pulled over the patch and started looking at it.

@liach Actually one thing that would be helpful would if you could merge a recent master into the PR branch. Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/8259

From bpb at openjdk.org  Wed Sep 28 15:59:36 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 28 Sep 2022 15:59:36 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo
 [v11]
In-Reply-To: <dNsTYdjKRFlt9jQxc3o_WX_ZMivOZOgy4SEhYWqsFhE=.9099bfb2-f5d2-4135-96c9-0b02fea75e22@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <_la5Co3yx5ik1wt7Y6Bi7MDC3MCVUxIKxz_iQQp2TT8=.1023ef6d-266f-45f5-aa93-7218d0d89c10@github.com>
 <VNT4kts7ahX1UIRRohyp7x9RSxrF0zslIE90yfJYYF0=.27ebea5e-1d31-4235-b3fa-0e2a2eb4d702@github.com>
 <dNsTYdjKRFlt9jQxc3o_WX_ZMivOZOgy4SEhYWqsFhE=.9099bfb2-f5d2-4135-96c9-0b02fea75e22@github.com>
Message-ID: <5mng28t4qL6312sjp-phw5Pfvt6s5qGe2MV-CNBCkRY=.e1f98bfd-6ea1-428b-b531-8d591dd31dd5@github.com>

On Mon, 26 Sep 2022 21:35:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> @bplb Fixed the issues you pointed out. Kindly requesting approval. :-)
>
>> @bplb Fixed the issues you pointed out.
> 
> @mkarg You are welcome.

> @bplb I would be very glad if you would `/sponsor` my PR. :-)

Done.

-------------

PR: https://git.openjdk.org/jdk/pull/6935

From duke at openjdk.org  Wed Sep 28 16:01:11 2022
From: duke at openjdk.org (Markus KARG)
Date: Wed, 28 Sep 2022 16:01:11 GMT
Subject: Integrated: 8279283 - BufferedInputStream should override transferTo
In-Reply-To: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
Message-ID: <e_dOJ5sA8zKVxv4tt5pSkp7emuDpcQ96CGT6FmdQvKQ=.6c6c28ea-ccbb-4f08-bd78-c7e3c98b2087@github.com>

On Sun, 26 Dec 2021 17:30:41 GMT, Markus KARG <duke at openjdk.org> wrote:

> Implementation of JDK-8279283

This pull request has now been integrated.

Changeset: 7515b304
Author:    Markus Karg <markus at headcrashing.eu>
Committer: Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7515b304ca5598558424ea6ba90f2f71b36a8e4c
Stats:     277 lines in 2 files changed: 277 ins; 0 del; 0 mod

8279283: BufferedInputStream should override transferTo

Reviewed-by: bpb

-------------

PR: https://git.openjdk.org/jdk/pull/6935

From duke at openjdk.org  Wed Sep 28 16:22:42 2022
From: duke at openjdk.org (liach)
Date: Wed, 28 Sep 2022 16:22:42 GMT
Subject: RFR: 8178355: IdentityHashMap uses identity-based comparison for
 values everywhere except remove(K,V) and replace(K,V,V) [v5]
In-Reply-To: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
References: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
Message-ID: <5dowZkdP3Mp-n9-L3cJIDZBj4-Jk1dw1c1WSsMa1kgI=.6ade44fc-1823-4e72-869e-f39974d02727@github.com>

> Explicitly implement `remove` and `replace` in `IdentityHashMap` to compare values by identity. Updated API documentation of these two methods ([Preview](https://cr.openjdk.java.net/~liach/8178355/IdentityHashMap.html#remove(java.lang.Object,java.lang.Object))) to mention such behavior.

liach has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge branch 'master' of https://git.openjdk.java.net/jdk into fix/identityhashmap-default
 - Move tests
 - Merge branch 'master' into fix/identityhashmap-default
 - Fix assertions
 - Revamp test and changes. Let ci run the tests
 - Fix indent
 - 8178355: IdentityHashMap uses identity-based comparison for values everywhere except remove(K,V) and replace(K,V,V)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/8259/files
  - new: https://git.openjdk.org/jdk/pull/8259/files/c8468ce2..fc2218f0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8259&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8259&range=03-04

  Stats: 666861 lines in 8714 files changed: 393567 ins; 204685 del; 68609 mod
  Patch: https://git.openjdk.org/jdk/pull/8259.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8259/head:pull/8259

PR: https://git.openjdk.org/jdk/pull/8259

From mullan at openjdk.org  Wed Sep 28 16:36:15 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 28 Sep 2022 16:36:15 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v2]
In-Reply-To: <H5QVVX7TbXodlDE2Q4AtJVU2sTGe3px3Trr8J-o0C0g=.db75c32e-da1d-4e7a-bb1b-fa5c990069d7@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <QXIQe5EqORYqyigwI84XMHTEYvY3jM-ersDVdN9EeKo=.c0f4ab18-b7f9-4ee9-abc7-816fbd37ff5b@github.com>
 <tPKKm9gjnIZtbN189Qb-o0-Mv6fiNq9lm5lUJtjxXcM=.3b43450c-a7fa-4ce0-8004-3b5329597f6b@github.com>
 <5TadUhgSG09rHgRo7EFIblKjlnvHr-q2DGSGfV2ezF0=.6e824b66-846c-476f-a372-6d5260e3d399@github.com>
 <H5QVVX7TbXodlDE2Q4AtJVU2sTGe3px3Trr8J-o0C0g=.db75c32e-da1d-4e7a-bb1b-fa5c990069d7@github.com>
Message-ID: <PGi2fwmUOQzOgYcQMCAAqSQQbZK-__--erPRuuyNJMg=.f35b927d-ae6f-47e5-9d4a-90660019e785@github.com>

On Wed, 28 Sep 2022 12:52:02 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Ok, just so I understand, you want to make sure that if JFR is started after the security properties have already been read, then they are still recorded, right?
>
> Correct - this type of event period (beginChunk) will fire once when the JFR recording is begun. It should capture Security Properties (if java.security.Security is loaded) for any recording, no matter when it might begin or end. Similar to how InitialSystemProperty is captured (but that's implemented at native/VM level)

How does it capture the event if JFR was started before the security properties were read? I would think you still need some additional code in Security.java to record the properties if the event is enabled.

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From asemenyuk at openjdk.org  Wed Sep 28 16:50:05 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 28 Sep 2022 16:50:05 GMT
Subject: RFR: 8293579:
 tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese
 Windows platform
In-Reply-To: <B-bej7ulwWfR6kB-T96UOr3rgNpoxsE_LsxeJornJMo=.02cbd0b3-4bf1-4466-99e6-2c97630ba719@github.com>
References: <ROgI801Y_MVdXiCKPYVtwN9C5kDZTT3gdAo4pnCACbs=.618721ad-4cc5-4db7-a923-3bf740e35181@github.com>
 <PslvzFQjyULART_fZym9bib6NkPAxiq9l8kFlpJbpjk=.5453fff3-e74a-4590-a44c-0ff3772403d5@github.com>
 <B-bej7ulwWfR6kB-T96UOr3rgNpoxsE_LsxeJornJMo=.02cbd0b3-4bf1-4466-99e6-2c97630ba719@github.com>
Message-ID: <CUFKfjJUexTzc_PfCRoUGPLiBxOontKsApr8fZGlB6E=.297213f0-9638-4060-b8cc-8aec208426ad@github.com>

On Wed, 28 Sep 2022 09:40:56 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

> It is difficult to add all the encodings, so I will fix for Japanese and would like people who need other languages to do the same.

It would be good to have a comment in the source code describing that this works only for Japanese encodings then.

-------------

PR: https://git.openjdk.org/jdk/pull/10226

From svkamath at openjdk.org  Wed Sep 28 17:40:36 2022
From: svkamath at openjdk.org (Smita Kamath)
Date: Wed, 28 Sep 2022 17:40:36 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v11]
In-Reply-To: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
Message-ID: <_Ghl2lsnrBhiWvVD3TMiwGo6SfQLl6idczb1QVqLa_I=.7cfa48e2-2987-43e0-a689-0e3462e4d270@github.com>

> 8289552: Make intrinsic conversions between bit representations of half precision values and floats

Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:

  Addressed review comment to update test case

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9781/files
  - new: https://git.openjdk.org/jdk/pull/9781/files/c6128b1b..8ccc0657

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=09-10

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9781.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9781/head:pull/9781

PR: https://git.openjdk.org/jdk/pull/9781

From kvn at openjdk.org  Wed Sep 28 17:59:41 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 28 Sep 2022 17:59:41 GMT
Subject: RFR: 8293409: [vectorapi] Intrinsify VectorSupport.indexVector
In-Reply-To: <CES8kmi34gT8zSdoc2iBcgAGeOMDvOnZJrCsjU-9xaA=.091a5ad1-55a4-41c4-9e8c-192a0bca47e4@github.com>
References: <CES8kmi34gT8zSdoc2iBcgAGeOMDvOnZJrCsjU-9xaA=.091a5ad1-55a4-41c4-9e8c-192a0bca47e4@github.com>
Message-ID: <TxP2zuV1ku4C7FEYUmuAOTLwZTC0XPQbGHoGqU9DIoY=.abbc4cc6-800e-433d-aa0a-8e7fc51feaa0@github.com>

On Mon, 19 Sep 2022 08:51:24 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> "`VectorSupport.indexVector()`" is used to compute a vector that contains the index values based on a given vector and a scale value (`i.e. index = vec + iota * scale`). This function is widely used in other APIs like "`VectorMask.indexInRange`" which is useful to the tail loop vectorization. And it can be easily implemented with the vector instructions.
> 
> This patch adds the vector intrinsic implementation of it. The steps are:
> 
>   1) Load the const "iota" vector.
> 
>   We extend the "`vector_iota_indices`" stubs from byte to other integral types. For floating point vectors, it needs an additional vector cast to get the right iota values.
> 
>   2) Compute indexes with "`vec + iota * scale`"
> 
> Here is the performance result to the new added micro benchmark on ARM NEON:
> 
> Benchmark                              Gain
> IndexVectorBenchmark.byteIndexVector   1.477
> IndexVectorBenchmark.doubleIndexVector 5.031
> IndexVectorBenchmark.floatIndexVector  5.342
> IndexVectorBenchmark.intIndexVector    5.529
> IndexVectorBenchmark.longIndexVector   3.177
> IndexVectorBenchmark.shortIndexVector  5.841
> 
> 
> Please help to review and share the feedback! Thanks in advance!

@jatin-bhateja and @sviswa7 please look on this enhancement as Vector API experts.

-------------

PR: https://git.openjdk.org/jdk/pull/10332

From naoto at openjdk.org  Wed Sep 28 18:03:43 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 28 Sep 2022 18:03:43 GMT
Subject: RFR: 8293579:
 tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese
 Windows platform [v2]
In-Reply-To: <25y_sJVHa9QDx4VcfIJDu9RsAO2EYVfCAcpfWthsczw=.d19ddb42-2cad-497d-8345-1918823fdbfb@github.com>
References: <ROgI801Y_MVdXiCKPYVtwN9C5kDZTT3gdAo4pnCACbs=.618721ad-4cc5-4db7-a923-3bf740e35181@github.com>
 <25y_sJVHa9QDx4VcfIJDu9RsAO2EYVfCAcpfWthsczw=.d19ddb42-2cad-497d-8345-1918823fdbfb@github.com>
Message-ID: <3ikhT4YbokA53IEoN9HdDhONo6d3WvhcRVk0-oFHE8I=.edec73e0-acdd-4075-88da-56dd095c82a3@github.com>

On Wed, 28 Sep 2022 09:45:32 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

>> Could you please review the JDK-8293579 bug fixes?
>> 
>> tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java attempts to give 
>> the launcher the character which is encoded by Windows API WideCharToMultiByte() 
>> from UNICODE "?"(0x00e9) as an argument. However, this test fails because the 
>> code point "?"(0x00e9) cannot be treated on Japanese Windows.
>> 
>> WideCharToMultiByte() encodes characters as Shift-JIS on Japanese Windows, but 
>> the code point "?"(0x00e9) does not exist in Shift-JIS, and it is replaced with 
>> "e"(0x0065) as substitute. Therefore, "?"(0x00e9) and "e"(0x0065) are compared 
>> in this test and judged to be different characters, and return as failed.
>> 
>> So, in the Japanese encoding("MS932", "SJIS"), the test should be modified to 
>> give a character such as "?"(0x3042) as the launcher's argument instead of 
>> "?"(0x00e9).
>
> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293579: tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese Windows platform

test/jdk/tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java line 55:

> 53:         String encoding = System.getProperty("native.encoding");
> 54:         switch (encoding) {
> 55:         default:

What I meant by the previous comment was to replace this `default` clause to:

    case "Cp1252", "UTF-8" -> testString = new String(Character.toChars(0x00E9));

And for other unknown encodings:

    default -> {
        System.out.println("Test skipped"); // or better message
        return;
    }

And your fix:

    case "MS932", "SJIS" -> testString = new String(Character.toChars(0x3042));

This way only the encodings that are guaranteed to succeed are tested.

-------------

PR: https://git.openjdk.org/jdk/pull/10226

From aturbanov at openjdk.org  Wed Sep 28 18:47:22 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 28 Sep 2022 18:47:22 GMT
Subject: Integrated: 8294472: Remove redundant rawtypes suppression in
 AbstractChronology
In-Reply-To: <Mfc999qMfld7wI8f3N9OKJUHXPqGfyfqKDHWQVabH88=.e04341d2-1a91-4489-ae69-100343891d62@github.com>
References: <Mfc999qMfld7wI8f3N9OKJUHXPqGfyfqKDHWQVabH88=.e04341d2-1a91-4489-ae69-100343891d62@github.com>
Message-ID: <FJ8GhPRS6A0V281YruR0ItAEMU6Nvl0esMiaAN4NlgY=.65bea7f0-b337-42f1-bc83-3b866af5e95f@github.com>

On Mon, 26 Sep 2022 19:12:16 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Found this redundant suppressions by IntelliJ IDEA inspection.
> Seems initially `Chronology` was generic class?

This pull request has now been integrated.

Changeset: 9309786d
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9309786dbfa584e7762c8011e3942f02d352d2e6
Stats:     7 lines in 1 file changed: 0 ins; 5 del; 2 mod

8294472: Remove redundant rawtypes suppression in AbstractChronology

Reviewed-by: lancea, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/10433

From alanb at openjdk.org  Wed Sep 28 19:19:56 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 28 Sep 2022 19:19:56 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v12]
In-Reply-To: <0wO5jFYhSTw702zqwi0_iLDgLcExZZZOuC5BQuCn4Z8=.4cab2b61-9156-4525-a787-a7dc75243ee2@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <0wO5jFYhSTw702zqwi0_iLDgLcExZZZOuC5BQuCn4Z8=.4cab2b61-9156-4525-a787-a7dc75243ee2@github.com>
Message-ID: <stOdNp4NzKMMvXuB88KOCEXfufzRQ9Zqfn2SdZxIryk=.c5fbc4fa-9342-4ebd-a799-3887fc1e6388@github.com>

On Tue, 20 Sep 2022 18:08:23 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
>> 
>> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
>> 
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added the verification note from JarFile

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10045

From alanb at openjdk.org  Wed Sep 28 19:19:56 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 28 Sep 2022 19:19:56 GMT
Subject: RFR: 8215788: Clarify JarInputStream Manifest access [v12]
In-Reply-To: <bfiWxsz5ohoh3D5f1Sq4Pc1G48_tVhL0bQXLJfj0zEo=.180cd786-8b05-4a79-82fe-4a8ac786c806@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
 <0wO5jFYhSTw702zqwi0_iLDgLcExZZZOuC5BQuCn4Z8=.4cab2b61-9156-4525-a787-a7dc75243ee2@github.com>
 <bfiWxsz5ohoh3D5f1Sq4Pc1G48_tVhL0bQXLJfj0zEo=.180cd786-8b05-4a79-82fe-4a8ac786c806@github.com>
Message-ID: <QlqVDCWJp_zs3vRwYaslpQMA2kGcHkwK5AExLYBhbx0=.42e2d6ea-e294-49dc-bc21-d0ff7766f731@github.com>

On Fri, 23 Sep 2022 17:45:26 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Do you also want to say "Otherwise, the method returns `null`."

The method description has that already, it might be too much detail to include in the class description,.

-------------

PR: https://git.openjdk.org/jdk/pull/10045

From lancea at openjdk.org  Wed Sep 28 19:25:45 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 28 Sep 2022 19:25:45 GMT
Subject: Integrated: 8215788: Clarify JarInputStream Manifest access
In-Reply-To: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
References: <kTztRE4RmlZ2EQaV1m_99931DRbwXzCepCRAlRfnlGU=.c4d9d43e-f3a4-46fb-9c3b-6d26a7092f67@github.com>
Message-ID: <UtKzhEFnHon6wRfLX9aKL6l6HRUdIVzfux7tsV2x6J4=.73289fc9-9a39-4e67-a988-064552faf06b@github.com>

On Fri, 26 Aug 2022 15:48:55 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Please review this PR which updates  the JarInputStream class description to clarify when the Manifest is accessible via JarInputStream::getManifest and JarInputStream::get[Jar]Entry.
> 
> It is worth noting that with this update, we are finally documenting  behavior that dates back to when this class was added to JDK 1.2
> 
> 
> Best,
> Lance

This pull request has now been integrated.

Changeset: 9db95edd
Author:    Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9db95edd0133cb31358416829c942f5dcb84fc55
Stats:     61 lines in 1 file changed: 52 ins; 0 del; 9 mod

8215788: Clarify JarInputStream Manifest access

Reviewed-by: weijun, mullan, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/10045

From duke at openjdk.org  Wed Sep 28 21:52:21 2022
From: duke at openjdk.org (Viktor Klang (Oracle))
Date: Wed, 28 Sep 2022 21:52:21 GMT
Subject: RFR: 8279361: Error in documentation of third Stream.reduce method
Message-ID: <ZDScXuIYVuxEWWS2YvBff2WIm5IURggmJAJ6d7PQ9r8=.c4e324e0-a0ea-4c85-901e-0f77303b8f24@github.com>

This JavaDoc change attempts to shine some light on the `combiner`-function as it relates to the third variant of `Stream.reduce` since it according to the bug submission in JBS can be confusing that the `combiner` is not mentioned in the code example in the documentation.

-------------

Commit messages:
 - 8279361 - Error in documentation of thrid Stream.reduce method

Changes: https://git.openjdk.org/jdk/pull/10469/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10469&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8279361
  Stats: 10 lines in 1 file changed: 6 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10469.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10469/head:pull/10469

PR: https://git.openjdk.org/jdk/pull/10469

From jason_mehrens at hotmail.com  Thu Sep 29 02:26:56 2022
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Thu, 29 Sep 2022 02:26:56 +0000
Subject: Collections.shuffle to accept RandomGenerator
In-Reply-To: <0AE34224-3FED-4A34-B8F0-E2E916959600@oracle.com>
References: <CAE+3fjasa2Y8qZQiYNE8Dw2G8iXFmR9z3LruksGOiFMHEKeEiQ@mail.gmail.com>
 <0AE34224-3FED-4A34-B8F0-E2E916959600@oracle.com>
Message-ID: <SJ0PR18MB4881EA7396DE6199472979CB83579@SJ0PR18MB4881.namprd18.prod.outlook.com>

JDK20 has Random.from(RandomGenerator) which could be used to do something like Collections.shuffle(List, Random.from(rg)).

List.shuffle(RandomGenerator ) would allow for more efficient CopyOnWriteArrayList shuffle.

Jason

________________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Paul Sandoz <paul.sandoz at oracle.com>
Sent: Wednesday, September 28, 2022 10:36 AM
To: Tagir Valeev
Cc: core-libs-dev at openjdk.org
Subject: Re: Collections.shuffle to accept RandomGenerator

That looks reasonable.

Thinking a little more broadly.

We could also change Collections.shuffle(List) to use ThreadLocalRandom so it does not have to cache the Random instance, plus it has better concurrent and PRNG properties. The spec does not describe the precise details of randomness.

It?s tempting to lift Collections.shuffle(List, RandomGenerator) to List.shuffle(RandomGenerator ), similar to what we did for Collections.sort, to align with that pattern and which also aligns with reverse of sequenced collections. There is likely not much performance advantage to do doing so as there was with sort, but that location is much easier to find and use IMHO. Since the method accepts RandomGenerator the compatibility risk would likely be low.

Paul.

> On Sep 27, 2022, at 3:11 AM, Tagir Valeev <amaembo at gmail.com> wrote:
>
> Hello!
>
> Currently, Collections.shuffle(List, Random) accepts an outdated
> Random class instead of RandomGenerator interface. It looks like,
> RandomGenerator would suffice. The code change looks trivial (aside
> from documentation and testing), as shuffle() implementation does not
> need anything except nextInt:
>
> diff --git a/src/java.base/share/classes/java/util/Collections.java
> b/src/java.base/share/classes/java/util/Collections.java
> --- a/src/java.base/share/classes/java/util/Collections.java (revision
> cab590517bf705418c7376edd5d7066b13b6dde8)
> +++ b/src/java.base/share/classes/java/util/Collections.java (date
> 1664273240190)
> @@ -37,6 +37,7 @@
> import java.util.function.IntFunction;
> import java.util.function.Predicate;
> import java.util.function.UnaryOperator;
> +import java.util.random.RandomGenerator;
> import java.util.stream.IntStream;
> import java.util.stream.Stream;
> import java.util.stream.StreamSupport;
> @@ -454,8 +455,12 @@
>      * @throws UnsupportedOperationException if the specified list or its
>      *         list-iterator does not support the {@code set} operation.
>      */
> -    @SuppressWarnings({"rawtypes", "unchecked"})
>     public static void shuffle(List<?> list, Random rnd) {
> +        shuffle(list, (RandomGenerator) rnd);
> +    }
> +
> +    @SuppressWarnings({"rawtypes", "unchecked"})
> +    public static void shuffle(List<?> list, RandomGenerator rnd) {
>         int size = list.size();
>         if (size < SHUFFLE_THRESHOLD || list instanceof RandomAccess) {
>             for (int i=size; i>1; i--)
>
> What do you think? Should we implement this improvement? I think I can
> contribute if there's a general agreement that such an enhancement
> would be useful.
>
> With best regards,
> Tagir Valeev


From dholmes at openjdk.org  Thu Sep 29 04:53:24 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 29 Sep 2022 04:53:24 GMT
Subject: RFR: 8293806: JDK_JAVA_OPTIONS picked up twice if LD_LIBRARY_PATH
 is set
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: <OoWqswpfjk7H1mUUn5R5RGc7f94AwDLKloZoejSBynw=.e797e828-ad87-423d-b19f-3dc33c127fb4@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.

Sorry Dmitry I'm still trying to get my head around the big picture here. The launcher startup process is extremely complex but also quite sophisticated so I'm a bit surprised this issue exists (and that we have not noticed it before!). I have an impression that the intent if we re-exec is that the env var options have already been processed and so the newly exec'd `java` is not supposed to process them again (they have already been converted to items in `argv`) - see `JLI_AddArgsFromEnvVar` and the use of the `relaunch` field. It seems quite redundant to have the exec'd `java` repeat all the arg processing that has already taken place. 

I'm also struggling to understand under what conditions, exactly, we will re-exec when the data-model selection is no longer an issue.

-------------

PR: https://git.openjdk.org/jdk/pull/10430

From tvaleev at openjdk.org  Thu Sep 29 06:59:17 2022
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Thu, 29 Sep 2022 06:59:17 GMT
Subject: RFR: 8279361: Error in documentation of third Stream.reduce method
In-Reply-To: <ZDScXuIYVuxEWWS2YvBff2WIm5IURggmJAJ6d7PQ9r8=.c4e324e0-a0ea-4c85-901e-0f77303b8f24@github.com>
References: <ZDScXuIYVuxEWWS2YvBff2WIm5IURggmJAJ6d7PQ9r8=.c4e324e0-a0ea-4c85-901e-0f77303b8f24@github.com>
Message-ID: <JvOkzxlQ3Hk5_hQeSBLpWBholt3moS96vL1s5-tCRYU=.48c1cc5f-d536-450a-a984-dcce462a98a5@github.com>

On Wed, 28 Sep 2022 15:36:50 GMT, Viktor Klang (Oracle) <duke at openjdk.org> wrote:

> This JavaDoc change attempts to shine some light on the `combiner`-function as it relates to the third variant of `Stream.reduce` since it according to the bug submission in JBS can be confusing that the `combiner` is not mentioned in the code example in the documentation.

Note that similar code is written in other places. E.g.
java.util.stream.Stream#collect(supplier, accumulator, combiner) -- combiner is not mentioned


R result = supplier.get();
for (T element : this stream)
  accumulator.accept(result, element);
return result;


The same for IntStream, LongStream, and DoubleStream.collect.

In fact, I'm not sure that this worth fixing.

-------------

PR: https://git.openjdk.org/jdk/pull/10469

From duke at openjdk.org  Thu Sep 29 08:08:16 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Thu, 29 Sep 2022 08:08:16 GMT
Subject: RFR: 8293579:
 tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese
 Windows platform [v2]
In-Reply-To: <3ikhT4YbokA53IEoN9HdDhONo6d3WvhcRVk0-oFHE8I=.edec73e0-acdd-4075-88da-56dd095c82a3@github.com>
References: <ROgI801Y_MVdXiCKPYVtwN9C5kDZTT3gdAo4pnCACbs=.618721ad-4cc5-4db7-a923-3bf740e35181@github.com>
 <25y_sJVHa9QDx4VcfIJDu9RsAO2EYVfCAcpfWthsczw=.d19ddb42-2cad-497d-8345-1918823fdbfb@github.com>
 <3ikhT4YbokA53IEoN9HdDhONo6d3WvhcRVk0-oFHE8I=.edec73e0-acdd-4075-88da-56dd095c82a3@github.com>
Message-ID: <BJJGTJOIVveQI5SYr7kWG01xg9AGq1LhyCtaHM5zW4g=.a8cfd59a-778f-410b-a2c4-034229aba08f@github.com>

On Wed, 28 Sep 2022 18:00:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8293579: tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese Windows platform
>
> test/jdk/tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java line 55:
> 
>> 53:         String encoding = System.getProperty("native.encoding");
>> 54:         switch (encoding) {
>> 55:         default:
> 
> What I meant by the previous comment was to replace this `default` clause to:
> 
>     case "Cp1252", "UTF-8" -> testString = new String(Character.toChars(0x00E9));
> 
> And for other unknown encodings:
> 
>     default -> {
>         System.out.println("Test skipped"); // or better message
>         return;
>     }
> 
> And your fix:
> 
>     case "MS932", "SJIS" -> testString = new String(Character.toChars(0x3042));
> 
> This way only the encodings that are guaranteed to succeed are tested.

I am sorry to misunderstand your comment. 

I don?t know whether "?"(0x00e9) exists only in "Cp1252", "UTF-8".
Will that be no problem that this test is skipped in other encordings? If skipped, the pattern for its encording probably won't be added forever. I think the other pattern should be added when this test fails. However I will follow the policy of OpenJDK.

-------------

PR: https://git.openjdk.org/jdk/pull/10226

From rgiulietti at openjdk.org  Thu Sep 29 09:20:37 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 29 Sep 2022 09:20:37 GMT
Subject: Integrated: 8065554: MatchResult should provide values of
 named-capturing groups
In-Reply-To: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
References: <d_t0_LQILZp-xKcaM9T099wDbm_CNob8YV6HDMSmbMs=.ecd08726-23cc-4a2e-b9d7-e35f345b387d@github.com>
Message-ID: <FVEbqEquVn5lGR5OclajL0MlnBr5gf9QLuViZzcEwyA=.3ba50cbb-f6c6-4bf6-b041-9719ca17d72b@github.com>

On Wed, 24 Aug 2022 15:48:38 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Add support for named groups to java.util.regex.MatchResult

This pull request has now been integrated.

Changeset: ce85cac9
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ce85cac947158b4e1f554c55f726c923a49b1a41
Stats:     634 lines in 4 files changed: 582 ins; 15 del; 37 mod

8065554: MatchResult should provide values of named-capturing groups

Reviewed-by: smarks

-------------

PR: https://git.openjdk.org/jdk/pull/10000

From duke at openjdk.org  Thu Sep 29 09:22:40 2022
From: duke at openjdk.org (Viktor Klang (Oracle))
Date: Thu, 29 Sep 2022 09:22:40 GMT
Subject: RFR: 8279361: Error in documentation of third Stream.reduce method
In-Reply-To: <JvOkzxlQ3Hk5_hQeSBLpWBholt3moS96vL1s5-tCRYU=.48c1cc5f-d536-450a-a984-dcce462a98a5@github.com>
References: <ZDScXuIYVuxEWWS2YvBff2WIm5IURggmJAJ6d7PQ9r8=.c4e324e0-a0ea-4c85-901e-0f77303b8f24@github.com>
 <JvOkzxlQ3Hk5_hQeSBLpWBholt3moS96vL1s5-tCRYU=.48c1cc5f-d536-450a-a984-dcce462a98a5@github.com>
Message-ID: <H5WvGH5IZOyu3uI0aSZbBagWVrPEOxair_u6qdk1yYc=.31663ed8-0748-43b8-b57c-d2b89a6fc36d@github.com>

On Thu, 29 Sep 2022 06:55:30 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> This JavaDoc change attempts to shine some light on the `combiner`-function as it relates to the third variant of `Stream.reduce` since it according to the bug submission in JBS can be confusing that the `combiner` is not mentioned in the code example in the documentation.
>
> Note that similar code is written in other places. E.g.
> java.util.stream.Stream#collect(supplier, accumulator, combiner) -- combiner is not mentioned
> 
> 
> R result = supplier.get();
> for (T element : this stream)
>   accumulator.accept(result, element);
> return result;
> 
> 
> The same for IntStream, LongStream, and DoubleStream.collect.
> 
> In fact, I'm not sure that this worth fixing.

@amaembo Thanks for the input! If the changed wording in this PR is accepted, it will be straight-forward for me to apply the same treatment to the other methods. At least that was my thinking. :)

-------------

PR: https://git.openjdk.org/jdk/pull/10469

From sgehwolf at openjdk.org  Thu Sep 29 09:35:39 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 29 Sep 2022 09:35:39 GMT
Subject: RFR: 8293540: [Metrics] Incorrectly detected resource limits with
 additional cgroup fs mounts [v4]
In-Reply-To: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
References: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
Message-ID: <AEyJcJcRM1Jl7Q87iSTMtFCbhW_rimqnjBA6wJHvMPs=.8caa82b5-8ae2-4bcb-96c4-98205c016e08@github.com>

> Similar issue to the hotspot change discussed in https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation may get the resource limits wrong if there are additional cgroup fs mounts. Apparently that's more common than one might think. I've reproduced this with these existing tests on cg v2:
> 
> 
> test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java
> test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java
> test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java 
> 
> 
> I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` and amended `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which unconditionally fails (irrespective of cgroup version in use). The fix is fairly straight forward and is an extension which we already do for the `cpuset` controller: Allow duplicates, and if there are any prefer those mounted at `/sys/fs/cgroup`.
> 
> Testing:
> - [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the product fix)
> - [x] added tests fail before, pass after the product fix.
> - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still pass. 
> - [x] GHA all pass.
> 
> Please review! Many thanks in advance.

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Add comments/@bug in tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10248/files
  - new: https://git.openjdk.org/jdk/pull/10248/files/8059dd81..6061a475

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10248&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10248&range=02-03

  Stats: 6 lines in 4 files changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10248.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10248/head:pull/10248

PR: https://git.openjdk.org/jdk/pull/10248

From sgehwolf at openjdk.org  Thu Sep 29 09:35:39 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 29 Sep 2022 09:35:39 GMT
Subject: RFR: 8293540: [Metrics] Incorrectly detected resource limits with
 additional cgroup fs mounts [v3]
In-Reply-To: <TJY2GKBQMw6V9Fi1LgT2hnyOdaiziTeHNAz7_NR2Zo8=.bc9e32d9-1d33-436e-b5fd-1658c6f319d1@github.com>
References: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
 <-GC6RSB-rnXjie1pCd0k7bzPNbGlmyRbR6xyNNJNWzU=.c428b704-c7e6-450f-8107-63ce417e6408@github.com>
 <TJY2GKBQMw6V9Fi1LgT2hnyOdaiziTeHNAz7_NR2Zo8=.bc9e32d9-1d33-436e-b5fd-1658c6f319d1@github.com>
Message-ID: <85W4uWEoa4BGsXK82_8x1y16cg3pPpDf5QO-2l5tp6Q=.023d9525-e803-434a-b831-a4d3b5bb7617@github.com>

On Wed, 28 Sep 2022 05:45:14 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
>> 
>>   8293540: [Metrics] Potentially incorrectly detected resource limits with additional cgroup fs mounts
>
> The JDK change looks good to me. Some nits for the test cases.

Thanks for the review @iklam!

> test/jdk/jdk/internal/platform/docker/TestDockerBasic.java line 26:
> 
>> 24: /*
>> 25:  * @test
>> 26:  * @summary Verify that -XshowSettings:system works
> 
> Add `@bug 8293540`

Thanks, added.

> test/jdk/jdk/internal/platform/docker/TestDockerBasic.java line 64:
> 
>> 62:         opts.addDockerOpts("--memory", "300m");
>> 63:         if (addCgroupMounts) {
>> 64:             opts.addDockerOpts("--volume", "/sys/fs/cgroup:/cgroup-in:ro");
> 
> Add comments that the extra mount should be ignored by the cgroup set-up code. (Same for other test cases).

OK. Added in the updated version.

-------------

PR: https://git.openjdk.org/jdk/pull/10248

From coffeys at openjdk.org  Thu Sep 29 10:04:18 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 29 Sep 2022 10:04:18 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v2]
In-Reply-To: <PGi2fwmUOQzOgYcQMCAAqSQQbZK-__--erPRuuyNJMg=.f35b927d-ae6f-47e5-9d4a-90660019e785@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <QXIQe5EqORYqyigwI84XMHTEYvY3jM-ersDVdN9EeKo=.c0f4ab18-b7f9-4ee9-abc7-816fbd37ff5b@github.com>
 <tPKKm9gjnIZtbN189Qb-o0-Mv6fiNq9lm5lUJtjxXcM=.3b43450c-a7fa-4ce0-8004-3b5329597f6b@github.com>
 <5TadUhgSG09rHgRo7EFIblKjlnvHr-q2DGSGfV2ezF0=.6e824b66-846c-476f-a372-6d5260e3d399@github.com>
 <H5QVVX7TbXodlDE2Q4AtJVU2sTGe3px3Trr8J-o0C0g=.db75c32e-da1d-4e7a-bb1b-fa5c990069d7@github.com>
 <PGi2fwmUOQzOgYcQMCAAqSQQbZK-__--erPRuuyNJMg=.f35b927d-ae6f-47e5-9d4a-90660019e785@github.com>
Message-ID: <leSw2o-uNaML1WUN_Koh9j9rxW6mkx75_hdFtjeWCYE=.26b43b59-3406-430e-9429-ab3ab3d9172e@github.com>

On Wed, 28 Sep 2022 16:32:17 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Correct - this type of event period (beginChunk) will fire once when the JFR recording is begun. It should capture Security Properties (if java.security.Security is loaded) for any recording, no matter when it might begin or end. Similar to how InitialSystemProperty is captured (but that's implemented at native/VM level)
>
> How does it capture the event if JFR was started before the security properties were read? I would think you still need some additional code in Security.java to record the properties if the event is enabled.

As per yesterday's stack trace, JFR triggers loading of the Security class - so your scenario won't arise with current state. We could include the new Event with period of `endChunk `instead of `beingChunk `setting. That should ensure the properties are only captured when the JFR recording is exiting. 
@egahlin - would you have a preference on this ?

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From egahlin at openjdk.org  Thu Sep 29 11:43:11 2022
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 29 Sep 2022 11:43:11 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v2]
In-Reply-To: <leSw2o-uNaML1WUN_Koh9j9rxW6mkx75_hdFtjeWCYE=.26b43b59-3406-430e-9429-ab3ab3d9172e@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <QXIQe5EqORYqyigwI84XMHTEYvY3jM-ersDVdN9EeKo=.c0f4ab18-b7f9-4ee9-abc7-816fbd37ff5b@github.com>
 <tPKKm9gjnIZtbN189Qb-o0-Mv6fiNq9lm5lUJtjxXcM=.3b43450c-a7fa-4ce0-8004-3b5329597f6b@github.com>
 <5TadUhgSG09rHgRo7EFIblKjlnvHr-q2DGSGfV2ezF0=.6e824b66-846c-476f-a372-6d5260e3d399@github.com>
 <H5QVVX7TbXodlDE2Q4AtJVU2sTGe3px3Trr8J-o0C0g=.db75c32e-da1d-4e7a-bb1b-fa5c990069d7@github.com>
 <PGi2fwmUOQzOgYcQMCAAqSQQbZK-__--erPRuuyNJMg=.f35b927d-ae6f-47e5-9d4a-90660019e785@github.com>
 <leSw2o-uNaML1WUN_Koh9j9rxW6mkx75_hdFtjeWCYE=.26b43b59-3406-430e-9429-ab3ab3d9172e@github.com>
Message-ID: <bcYWFVve9-ZRf5OoEB1oAW91ySR1BtUYG9uOtNE-x28=.35da7b5d-b0ed-4666-a00a-c7eabc363ab1@github.com>

On Thu, 29 Sep 2022 10:02:05 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> How does it capture the event if JFR was started before the security properties were read? I would think you still need some additional code in Security.java to record the properties if the event is enabled.
>
> As per yesterday's stack trace, JFR triggers loading of the Security class - so your scenario won't arise with current state. We could include the new Event with period of `endChunk `instead of `beingChunk `setting. That should ensure the properties are only captured when the JFR recording is exiting. 
> @egahlin - would you have a preference on this ?

With event streaming, beginChunk is usually to prefer. Otherwise, a client that monitors the JVM must wait until the first chunk rotation to get the data.

That said, we want startup to be quick. There should probably be a common parameter, i.e. security=off/normal/audit/trace, that handles enablement for all security events. I don't know how expensive this event is and where it would fit among those categories?

If the event triggers class loading, it might make sense to check if the event is enabled first.

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From sgehwolf at openjdk.org  Thu Sep 29 12:11:25 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 29 Sep 2022 12:11:25 GMT
Subject: RFR: 8293540: [Metrics] Incorrectly detected resource limits with
 additional cgroup fs mounts [v5]
In-Reply-To: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
References: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
Message-ID: <Y70XMKVNdGDJMcibQh-3JXWzJHKT7Q151u8fbbRD1os=.1df935a7-3fe8-4683-bac1-4028951b5ed5@github.com>

> Similar issue to the hotspot change discussed in https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation may get the resource limits wrong if there are additional cgroup fs mounts. Apparently that's more common than one might think. I've reproduced this with these existing tests on cg v2:
> 
> 
> test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java
> test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java
> test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java 
> 
> 
> I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` and amended `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which unconditionally fails (irrespective of cgroup version in use). The fix is fairly straight forward and is an extension which we already do for the `cpuset` controller: Allow duplicates, and if there are any prefer those mounted at `/sys/fs/cgroup`.
> 
> Testing:
> - [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the product fix)
> - [x] added tests fail before, pass after the product fix.
> - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still pass. 
> - [x] GHA all pass.
> 
> Please review! Many thanks in advance.

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' into JDK-8293540-metrics-cgroups-mounts
 - Add comments/@bug in tests
 - 8293540: [Metrics] Potentially incorrectly detected resource limits with additional cgroup fs mounts

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10248/files
  - new: https://git.openjdk.org/jdk/pull/10248/files/6061a475..3ecb3b9d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10248&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10248&range=03-04

  Stats: 30991 lines in 1069 files changed: 14803 ins; 10731 del; 5457 mod
  Patch: https://git.openjdk.org/jdk/pull/10248.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10248/head:pull/10248

PR: https://git.openjdk.org/jdk/pull/10248

From jwaters at openjdk.org  Thu Sep 29 12:48:57 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 29 Sep 2022 12:48:57 GMT
Subject: RFR: 8292016: Split Windows API error handling from errors passed
 through the runtime in the JDK [v23]
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <848hjAUCbJoQ73DcSuGU-NTyqVOysvrBnBAWL5kjPlo=.19910ff8-4e4f-4efe-a323-fef8b403a770@github.com>

> EDIT: Cave and add the ErrorOrigin enum, to differentiate which error type the error reporting functions in libjava will look up. RUNTIME refers to errors passed through the runtime via errno, and SYSTEM is for native errors not visible to the runtime.

Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into rework
 - Cleanup
 - Replace JLI_ReportErrorMessageSys with JLI_Perror
 - Merge remote-tracking branch 'upstream/master' into rework
 - Whitespace
 - Split Windows API error handling from errors passed through the runtime

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9870/files
  - new: https://git.openjdk.org/jdk/pull/9870/files/622af5c6..80ef56dc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=21-22

  Stats: 11159 lines in 266 files changed: 5381 ins; 4933 del; 845 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From alanb at openjdk.org  Thu Sep 29 13:03:18 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 29 Sep 2022 13:03:18 GMT
Subject: RFR: 8293806: JDK_JAVA_OPTIONS picked up twice if LD_LIBRARY_PATH
 is set
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: <ROx1SvAhfFAXAGAtWdclGPHUzY1h-zDKqYtQCT7ZC28=.15be99ab-1ea3-43b8-99d9-c1315a858b11@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.

I think I agree with David that the JBS issue or PR needs a better description of the issue. It reads to me that this is caused by setting LD_LIBRARY_PATH to find a libjvm that is coming from somewhere else, is that right?

-------------

PR: https://git.openjdk.org/jdk/pull/10430

From rgiulietti at openjdk.org  Thu Sep 29 13:18:11 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 29 Sep 2022 13:18:11 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK
Message-ID: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>

This fixes misleading indentations, which allows enabling the (currently disabled) `misleading-indentation` warning flag on two `.gmk` files.

-------------

Commit messages:
 - 8294456: Fix misleading-indentation warnings in JDK

Changes: https://git.openjdk.org/jdk/pull/10487/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10487&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294456
  Stats: 9 lines in 4 files changed: 1 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/10487.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10487/head:pull/10487

PR: https://git.openjdk.org/jdk/pull/10487

From rgiulietti at openjdk.org  Thu Sep 29 13:18:11 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 29 Sep 2022 13:18:11 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK
In-Reply-To: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
Message-ID: <UPInEBzT3Pn9XU6eWbUCxoGWPwCPoGDKn9J2BlvhLtA=.21b9cd77-9d0f-4c7d-a69c-044466e6fb6b@github.com>

On Thu, 29 Sep 2022 13:11:03 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> This fixes misleading indentations, which allows enabling the (currently disabled) `misleading-indentation` warning flag on two `.gmk` files.

The misleading indentation might indicate the original intent of the author, which might have forgotten to add braces around the indented code. Anyway, this fix does _not_ address whether the numerical algorithm in itself is correct, it only corrects the indentation.

The original source code also contains misleading indentation, see:
https://netlib.org/fdlibm/e_asin.c
https://netlib.org/fdlibm/k_rem_pio2.c

-------------

PR: https://git.openjdk.org/jdk/pull/10487

From dfuchs at openjdk.org  Thu Sep 29 13:44:26 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 29 Sep 2022 13:44:26 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK
In-Reply-To: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
Message-ID: <fpnPIYgJmPMF3y0STHhlFeO7u3X3Q9NW2vw3zKCp2nA=.79198c44-516f-4bae-aa75-3a57d8f4eaea@github.com>

On Thu, 29 Sep 2022 13:11:03 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> This fixes misleading indentations, which allows enabling the (currently disabled) `misleading-indentation` warning flag on two `.gmk` files.

src/java.base/share/native/libfdlibm/e_asin.c line 102:

> 100:             } else
> 101:                 t = x*x;
> 102:             p = t*(pS0+t*(pS1+t*(pS2+t*(pS3+t*(pS4+t*pS5)))));

should we add an opening brace after the `else` (and close it before line 102) to make it more obvious that there is no problem with the indentation?

-------------

PR: https://git.openjdk.org/jdk/pull/10487

From rgiulietti at openjdk.org  Thu Sep 29 13:48:30 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 29 Sep 2022 13:48:30 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK
In-Reply-To: <fpnPIYgJmPMF3y0STHhlFeO7u3X3Q9NW2vw3zKCp2nA=.79198c44-516f-4bae-aa75-3a57d8f4eaea@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
 <fpnPIYgJmPMF3y0STHhlFeO7u3X3Q9NW2vw3zKCp2nA=.79198c44-516f-4bae-aa75-3a57d8f4eaea@github.com>
Message-ID: <Aw2E36VRLuXt9hakw3jP_PjI26OTtnLnuhxBGsgSc8E=.9f9b3eda-c70d-42c6-b562-5e71cce671b4@github.com>

On Thu, 29 Sep 2022 13:40:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This fixes misleading indentations, which allows enabling the (currently disabled) `misleading-indentation` warning flag on two `.gmk` files.
>
> src/java.base/share/native/libfdlibm/e_asin.c line 102:
> 
>> 100:             } else
>> 101:                 t = x*x;
>> 102:             p = t*(pS0+t*(pS1+t*(pS2+t*(pS3+t*(pS4+t*pS5)))));
> 
> should we add an opening brace after the `else` (and close it before line 102) to make it more obvious that there is no problem with the indentation?

It seems that this code is almost a verbatim copy of the upstream code available on the indicated link.
So, while I agree that it would be better to add braces, it would make the code diverge from the upstream source, even if the change would be benign. and welcome

-------------

PR: https://git.openjdk.org/jdk/pull/10487

From shade at openjdk.org  Thu Sep 29 14:13:31 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 29 Sep 2022 14:13:31 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK
In-Reply-To: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
Message-ID: <IV0KJ9xSrg0X9-i25eNbCa6WRQICVGnQAaJnTuuTdjw=.b3f04a3f-96ac-40b6-b78f-5c84d36f7ba6@github.com>

On Thu, 29 Sep 2022 13:11:03 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> This fixes misleading indentations, which allows enabling the (currently disabled) `misleading-indentation` warning flag on two `.gmk` files.

This looks okay, but let's wait for #10426 to integrate first?

-------------

PR: https://git.openjdk.org/jdk/pull/10487

From rgiulietti at openjdk.org  Thu Sep 29 14:13:32 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 29 Sep 2022 14:13:32 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK
In-Reply-To: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
Message-ID: <bE3u2RaRGXHflHcePwo6bC_XYMrwijyQ64kUTMGNTiw=.77413ca0-4bd1-46d3-8ce8-7d875e2c1a8a@github.com>

On Thu, 29 Sep 2022 13:11:03 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> This fixes misleading indentations, which allows enabling the (currently disabled) `misleading-indentation` warning flag on two `.gmk` files.

Sure.

-------------

PR: https://git.openjdk.org/jdk/pull/10487

From dfuchs at openjdk.org  Thu Sep 29 14:18:22 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 29 Sep 2022 14:18:22 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK
In-Reply-To: <Aw2E36VRLuXt9hakw3jP_PjI26OTtnLnuhxBGsgSc8E=.9f9b3eda-c70d-42c6-b562-5e71cce671b4@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
 <fpnPIYgJmPMF3y0STHhlFeO7u3X3Q9NW2vw3zKCp2nA=.79198c44-516f-4bae-aa75-3a57d8f4eaea@github.com>
 <Aw2E36VRLuXt9hakw3jP_PjI26OTtnLnuhxBGsgSc8E=.9f9b3eda-c70d-42c6-b562-5e71cce671b4@github.com>
Message-ID: <vLqzOCBioAt246Ebl027nhIHB9lD0aHg1nQLWoPxCXs=.c2e8a136-a582-4207-8414-191413576ba2@github.com>

On Thu, 29 Sep 2022 13:44:40 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/native/libfdlibm/e_asin.c line 102:
>> 
>>> 100:             } else
>>> 101:                 t = x*x;
>>> 102:             p = t*(pS0+t*(pS1+t*(pS2+t*(pS3+t*(pS4+t*pS5)))));
>> 
>> should we add an opening brace after the `else` (and close it before line 102) to make it more obvious that there is no problem with the indentation?
>
> It seems that this code is almost a verbatim copy of the upstream code available on the indicated link.
> So, while I agree that it would be better to add braces, it would make the code diverge from the upstream source, even if the change would be benign. and welcome

OK - that's a reasonable concern indeed.

-------------

PR: https://git.openjdk.org/jdk/pull/10487

From coffeys at openjdk.org  Thu Sep 29 15:14:28 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 29 Sep 2022 15:14:28 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v2]
In-Reply-To: <bcYWFVve9-ZRf5OoEB1oAW91ySR1BtUYG9uOtNE-x28=.35da7b5d-b0ed-4666-a00a-c7eabc363ab1@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <QXIQe5EqORYqyigwI84XMHTEYvY3jM-ersDVdN9EeKo=.c0f4ab18-b7f9-4ee9-abc7-816fbd37ff5b@github.com>
 <tPKKm9gjnIZtbN189Qb-o0-Mv6fiNq9lm5lUJtjxXcM=.3b43450c-a7fa-4ce0-8004-3b5329597f6b@github.com>
 <5TadUhgSG09rHgRo7EFIblKjlnvHr-q2DGSGfV2ezF0=.6e824b66-846c-476f-a372-6d5260e3d399@github.com>
 <H5QVVX7TbXodlDE2Q4AtJVU2sTGe3px3Trr8J-o0C0g=.db75c32e-da1d-4e7a-bb1b-fa5c990069d7@github.com>
 <PGi2fwmUOQzOgYcQMCAAqSQQbZK-__--erPRuuyNJMg=.f35b927d-ae6f-47e5-9d4a-90660019e785@github.com>
 <leSw2o-uNaML1WUN_Koh9j9rxW6mkx75_hdFtjeWCYE=.26b43b59-3406-430e-9429-ab3ab3d9172e@github.com>
 <bcYWFVve9-ZRf5OoEB1oAW91ySR1BtUYG9uOtNE-x28=.35da7b5d-b0ed-4666-a00a-c7eabc363ab1@github.com>
Message-ID: <_FWF1bciUEsK9fBUiOle73_FYQWgwOkS1PvPQqzfYxU=.59bb14be-7cd0-4b92-b80f-1c4869c8803e@github.com>

On Thu, 29 Sep 2022 11:41:02 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> As per yesterday's stack trace, JFR triggers loading of the Security class - so your scenario won't arise with current state. We could include the new Event with period of `endChunk `instead of `beingChunk `setting. That should ensure the properties are only captured when the JFR recording is exiting. 
>> @egahlin - would you have a preference on this ?
>
> With event streaming, beginChunk is usually to prefer. Otherwise, a client that monitors the JVM must wait until the first chunk rotation to get the data.
> 
> That said, we want startup to be quick. There should probably be a common parameter, i.e. security=off/normal/audit/trace, that handles enablement for all security events. I don't know how expensive this event is and where it would fit among those categories?
> 
> If the event triggers class loading, it might make sense to check if the event is enabled first.

Thanks @egahlin  - maybe we can leave it at beginChunk setting then.

I've been doing some testing to satisfy myself that the impact of this event on performance is minimal, Running the new `emitInitialSecurityProperties()` is showing a cost of ~ 1.6ms (1602998 ns). 

This new Event itself doesn't trigger extra class loading AFAICT. I went back to a jdk 20 binary without this patch and ran some tests. 

`ProtectionDomain ` is a very early class to initialize [1] (initPhase2)

Without JFR, `java.security.Security` will initialize in a default JDK with a JMX `Agent.startLocalManagementAgent` call in a simple HelloWorld test which prints "Hello" and then sleeps  [2] - the JMX thread starts after about 3 seconds of runtime.

Without JFR and by using the `-XX:+DisableAttachMechanism` option, the Security class will not load in same test.

If JFR is on, then Security class is already being loaded, even without this patch [3]

[1]

	at java.base/java.security.ProtectionDomain.<clinit>(ProtectionDomain.java:64)
	at java.base/java.lang.ClassLoader.<init>(ClassLoader.java:316)
	at java.base/java.lang.ClassLoader.<init>(ClassLoader.java:431)
	at java.base/java.security.SecureClassLoader.<init>(SecureClassLoader.java:113)
	at java.base/jdk.internal.loader.BuiltinClassLoader.<init>(BuiltinClassLoader.java:194)
	at java.base/jdk.internal.loader.ClassLoaders$BootClassLoader.<init>(ClassLoaders.java:135)
	at java.base/jdk.internal.loader.ClassLoaders.<clinit>(ClassLoaders.java:79)
	at java.base/jdk.internal.loader.BootLoader.loadModule(BootLoader.java:120)
	at java.base/jdk.internal.module.ModuleBootstrap.boot2(ModuleBootstrap.java:266)
	at java.base/jdk.internal.module.ModuleBootstrap.boot(ModuleBootstrap.java:174)
	at java.base/java.lang.System.initPhase2(System.java:2214)


[2]

	at java.base/java.security.Security.<clinit>(Security.java:73)
	at java.base/sun.net.InetAddressCachePolicy$1.run(InetAddressCachePolicy.java:93)
	at java.base/sun.net.InetAddressCachePolicy$1.run(InetAddressCachePolicy.java:90)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:319)
	at java.base/sun.net.InetAddressCachePolicy.<clinit>(InetAddressCachePolicy.java:89)
	at java.base/java.net.InetAddress$NameServiceAddresses.get(InetAddress.java:1005)
	at java.base/java.net.InetAddress.getAllByName0(InetAddress.java:1658)
	at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1524)
	at java.base/java.net.InetAddress.getByName(InetAddress.java:1413)
	at jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startLocalConnectorServer(ConnectorBootstrap.java:531)
	at jdk.management.agent/jdk.internal.agent.Agent.startLocalManagementAgent(Agent.java:317)


[3]


	at java.base/java.security.Security.<clinit>(Security.java:73)
	at java.base/sun.security.util.SecurityProperties.getOverridableProperty(SecurityProperties.java:57)
	at java.base/sun.security.util.SecurityProperties.privilegedGetOverridable(SecurityProperties.java:48)
	at java.base/sun.security.util.SecurityProperties.includedInExceptions(SecurityProperties.java:72)
	at java.base/sun.security.util.SecurityProperties.<clinit>(SecurityProperties.java:36)
	at java.base/sun.security.util.FilePermCompat.<clinit>(FilePermCompat.java:43)
	at java.base/java.security.AccessControlContext.<init>(AccessControlContext.java:270)
	at java.base/java.security.AccessController.createWrapper(AccessController.java:649)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:461)
	at jdk.jfr/jdk.jfr.internal.SecuritySupport.doPrivilegedWithReturn(SecuritySupport.java:261)
	at jdk.jfr/jdk.jfr.internal.SecuritySupport.getPathInProperty(SecuritySupport.java:331)
	at jdk.jfr/jdk.jfr.internal.SecuritySupport.<clinit>(SecuritySupport.java:80)
	at jdk.jfr/jdk.jfr.internal.JVMSupport.checkAvailability(JVMSupport.java:46)
	at jdk.jfr/jdk.jfr.internal.JVMSupport.<clinit>(JVMSupport.java:41)
	at jdk.jfr/jdk.jfr.internal.Logger.<clinit>(Logger.java:41)
	at jdk.jfr/jdk.jfr.internal.dcmd.AbstractDCmd.execute(AbstractDCmd.java:75)

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From jbhateja at openjdk.org  Thu Sep 29 15:22:25 2022
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 29 Sep 2022 15:22:25 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v11]
In-Reply-To: <_Ghl2lsnrBhiWvVD3TMiwGo6SfQLl6idczb1QVqLa_I=.7cfa48e2-2987-43e0-a689-0e3462e4d270@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <_Ghl2lsnrBhiWvVD3TMiwGo6SfQLl6idczb1QVqLa_I=.7cfa48e2-2987-43e0-a689-0e3462e4d270@github.com>
Message-ID: <szUuLfL7t6CxZhQ-ci8Ln2rJAqRDWlEf19gpTMy9Dpk=.20201e6a-c8c0-447c-b8dc-d0f1231ba65a@github.com>

On Wed, 28 Sep 2022 17:40:36 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> 8289552: Make intrinsic conversions between bit representations of half precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comment to update test case

Thanks @smita-kamath, patch looks good to me.

-------------

Marked as reviewed by jbhateja (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9781

From jwaters at openjdk.org  Thu Sep 29 15:38:29 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 29 Sep 2022 15:38:29 GMT
Subject: RFR: 8292016: Split Windows API error handling from errors passed
 through the runtime in the JDK [v24]
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <luu4YVKQFlpmaeMo0RsfEftkRvVYPpZncCX3eUQTSSk=.0cdf5d46-2e08-4d85-a0d4-aad8a9425330@github.com>

> EDIT: Cave and add the ErrorOrigin enum, to differentiate which error type the error reporting functions in libjava will look up. RUNTIME refers to errors passed through the runtime via errno, and SYSTEM is for native errors not visible to the runtime.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Remove getErrorString

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9870/files
  - new: https://git.openjdk.org/jdk/pull/9870/files/80ef56dc..00c955ee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=22-23

  Stats: 110 lines in 8 files changed: 0 ins; 102 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From mbaesken at openjdk.org  Thu Sep 29 16:05:44 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 29 Sep 2022 16:05:44 GMT
Subject: RFR: JDK-8293701: jdeps InverseDepsAnalyzer runs into
 NoSuchElementException: No value present [v2]
In-Reply-To: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
References: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
Message-ID: <eQbbxiOC4eXZOrUsn2hH_XKQkly61CnYudE-AkiEB9w=.0ebafb1f-e446-4349-8e0f-de47d963921a@github.com>

> We noticed that with certain jar file input, jdeps runs into the following exception, this happens with jdk11, 17 and 20.
> 
> jdeps.exe --multi-release 11 --module-path . --inverse --package com.sap.nw.performance.supa.client test.jar
> 
> Inverse transitive dependences matching packages [com.sap.nw.performance.supa.client]
> Exception in thread "main" java.util.NoSuchElementException: No value present
>         at java.base/java.util.Optional.get(Optional.java:148)
>         at jdk.jdeps/com.sun.tools.jdeps.InverseDepsAnalyzer.lambda$inverseDependences$2(InverseDepsAnalyzer.java:150)
>         at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>         at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>         at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
>         at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>         at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> 
> So an additional  check might be a good idea.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  adjust check, add test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10300/files
  - new: https://git.openjdk.org/jdk/pull/10300/files/f83f9288..42b1339d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10300&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10300&range=00-01

  Stats: 254 lines in 8 files changed: 253 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10300.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10300/head:pull/10300

PR: https://git.openjdk.org/jdk/pull/10300

From psandoz at openjdk.org  Thu Sep 29 16:33:25 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 29 Sep 2022 16:33:25 GMT
Subject: RFR: 8279361: Error in documentation of third Stream.reduce method
In-Reply-To: <ZDScXuIYVuxEWWS2YvBff2WIm5IURggmJAJ6d7PQ9r8=.c4e324e0-a0ea-4c85-901e-0f77303b8f24@github.com>
References: <ZDScXuIYVuxEWWS2YvBff2WIm5IURggmJAJ6d7PQ9r8=.c4e324e0-a0ea-4c85-901e-0f77303b8f24@github.com>
Message-ID: <D3sJANNfdWF1YeYX9bIHFwohm0HolRY-R4w77K7X7lM=.516f540c-beb0-48d2-acc7-ab210e3191b8@github.com>

On Wed, 28 Sep 2022 15:36:50 GMT, Viktor Klang <duke at openjdk.org> wrote:

> This JavaDoc change attempts to shine some light on the `combiner`-function as it relates to the third variant of `Stream.reduce` since it according to the bug submission in JBS can be confusing that the `combiner` is not mentioned in the code example in the documentation.

The current JavaDoc is not wrong :-) (same in other places). I think what you propose may not add much clarity (given the complexities of reasoning about parallelism).

We could add something after "but is not constrained to execute sequentially." e.g. 

"
Parallel execution may result in intermediate results computed as if by the code above. Such results are combined using the combining function to produce the final result."
"

-------------

PR: https://git.openjdk.org/jdk/pull/10469

From asemenyuk at openjdk.org  Thu Sep 29 16:49:20 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 29 Sep 2022 16:49:20 GMT
Subject: RFR: 8293579:
 tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese
 Windows platform [v2]
In-Reply-To: <BJJGTJOIVveQI5SYr7kWG01xg9AGq1LhyCtaHM5zW4g=.a8cfd59a-778f-410b-a2c4-034229aba08f@github.com>
References: <ROgI801Y_MVdXiCKPYVtwN9C5kDZTT3gdAo4pnCACbs=.618721ad-4cc5-4db7-a923-3bf740e35181@github.com>
 <25y_sJVHa9QDx4VcfIJDu9RsAO2EYVfCAcpfWthsczw=.d19ddb42-2cad-497d-8345-1918823fdbfb@github.com>
 <3ikhT4YbokA53IEoN9HdDhONo6d3WvhcRVk0-oFHE8I=.edec73e0-acdd-4075-88da-56dd095c82a3@github.com>
 <BJJGTJOIVveQI5SYr7kWG01xg9AGq1LhyCtaHM5zW4g=.a8cfd59a-778f-410b-a2c4-034229aba08f@github.com>
Message-ID: <SEXLY0pFioXy1sOLP8x4qJLARtwQwBJFDso6n7RdZsg=.925b1fd6-6a1b-4371-b14a-006618f62040@github.com>

On Thu, 29 Sep 2022 08:04:07 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

>> test/jdk/tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java line 55:
>> 
>>> 53:         String encoding = System.getProperty("native.encoding");
>>> 54:         switch (encoding) {
>>> 55:         default:
>> 
>> What I meant by the previous comment was to replace this `default` clause to:
>> 
>>     case "Cp1252", "UTF-8" -> testString = new String(Character.toChars(0x00E9));
>> 
>> And for other unknown encodings:
>> 
>>     default -> {
>>         System.out.println("Test skipped"); // or better message
>>         return;
>>     }
>> 
>> And your fix:
>> 
>>     case "MS932", "SJIS" -> testString = new String(Character.toChars(0x3042));
>> 
>> This way only the encodings that are guaranteed to succeed are tested.
>
> I am sorry to misunderstand your comment. 
> 
> I don?t know whether "?"(0x00e9) exists only in "Cp1252", "UTF-8".
> Will that be no problem that this test is skipped in other encordings? If skipped, the pattern for its encording probably won't be added forever. I think the other pattern should be added when this test fails. However I will follow the policy of OpenJDK.

I agree skipping the test is not the best solution. Leaving a hint in the comments on how to fix the issue looks better alternative.

-------------

PR: https://git.openjdk.org/jdk/pull/10226

From rriggs at openjdk.org  Thu Sep 29 15:10:04 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 29 Sep 2022 15:10:04 GMT
Subject: RFR: 8294533: Documentation mistake in Process::getErrorStream and
 getInputStream
Message-ID: <t90ytF8iOGzi2tx1085-rv65hycEozKqtgWFMl3jkgs=.b6f3eafd-6537-43d2-8e7d-fb08f1975d16@github.com>

Correct javadoc links and references.

The links should refer to the method `()` instead of field.

The apiNote in `getErrorStream` should refer to the error stream not the input stream and reader.

-------------

Commit messages:
 - 8294533: Documentation mistake in Process::getErrorStream and getInputStream

Changes: https://git.openjdk.org/jdk/pull/10492/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10492&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294533
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10492.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10492/head:pull/10492

PR: https://git.openjdk.org/jdk/pull/10492

From iris at openjdk.org  Thu Sep 29 17:16:48 2022
From: iris at openjdk.org (Iris Clark)
Date: Thu, 29 Sep 2022 17:16:48 GMT
Subject: RFR: 8294533: Documentation mistake in Process::getErrorStream and
 getInputStream
In-Reply-To: <t90ytF8iOGzi2tx1085-rv65hycEozKqtgWFMl3jkgs=.b6f3eafd-6537-43d2-8e7d-fb08f1975d16@github.com>
References: <t90ytF8iOGzi2tx1085-rv65hycEozKqtgWFMl3jkgs=.b6f3eafd-6537-43d2-8e7d-fb08f1975d16@github.com>
Message-ID: <Dl_fnhopkg28CWI3u4P55orHm7nzzhE9I_eEoeARRW8=.fe5dc55c-033c-4d03-9b92-07d43cc4114f@github.com>

On Thu, 29 Sep 2022 15:01:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Correct javadoc links and references.
> 
> The links should refer to the method `()` instead of field.
> 
> The apiNote in `getErrorStream` should refer to the error stream not the input stream and reader.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10492

From aturbanov at openjdk.org  Thu Sep 29 17:40:08 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 29 Sep 2022 17:40:08 GMT
Subject: RFR: 8294608: Remove redundant unchecked suppression in FileDescriptor
Message-ID: <Kaatiu8ZDph6uUog_BHU0jz1cINsm809e7DyH9kB_E0=.830f1c34-1419-4ea4-880a-5f3ea4d3099c@github.com>

Found this redundant suppressions by IntelliJ IDEA inspection.
It seems [JDK-8189330](https://bugs.openjdk.org/browse/JDK-8189330) made them redundant.

-------------

Commit messages:
 - [PATCH] Remove redundant unchecked suppression in FileDescriptor

Changes: https://git.openjdk.org/jdk/pull/10473/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10473&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294608
  Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10473.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10473/head:pull/10473

PR: https://git.openjdk.org/jdk/pull/10473

From svkamath at openjdk.org  Thu Sep 29 17:49:27 2022
From: svkamath at openjdk.org (Smita Kamath)
Date: Thu, 29 Sep 2022 17:49:27 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v8]
In-Reply-To: <QdS7Tx2gk2HR7Y-qe6Ig8_QgyGRi5i3k14aERVEHTs4=.b5839efb-e45f-4700-b9d6-7fca6d61cd77@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com>
 <QdS7Tx2gk2HR7Y-qe6Ig8_QgyGRi5i3k14aERVEHTs4=.b5839efb-e45f-4700-b9d6-7fca6d61cd77@github.com>
Message-ID: <frb3je6a390Xqi6O21nZc6GVwti4hYcTm0MQZi2EXTk=.56910d50-38bf-4af6-9e16-6766b772b0bd@github.com>

On Wed, 21 Sep 2022 16:41:19 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressed review comments
>
> tier2 and 3 passed. I will wait update with test and JVMCI fix before doing more testing.

@vnkozlov I have addressed all review comments. Could you please run the patch through your testing? Thanks a lot for all the help.

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From kvn at openjdk.org  Thu Sep 29 18:17:33 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 29 Sep 2022 18:17:33 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v11]
In-Reply-To: <_Ghl2lsnrBhiWvVD3TMiwGo6SfQLl6idczb1QVqLa_I=.7cfa48e2-2987-43e0-a689-0e3462e4d270@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <_Ghl2lsnrBhiWvVD3TMiwGo6SfQLl6idczb1QVqLa_I=.7cfa48e2-2987-43e0-a689-0e3462e4d270@github.com>
Message-ID: <nvBqpaATZJe5KJJtXg9PB70tXbXjO54dZrKVvWq9wQg=.915e7f64-b526-47cb-a768-2041b7c99d55@github.com>

On Wed, 28 Sep 2022 17:40:36 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> 8289552: Make intrinsic conversions between bit representations of half precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comment to update test case

I submitted new testing (for version 10).

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From naoto at openjdk.org  Thu Sep 29 18:19:32 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 29 Sep 2022 18:19:32 GMT
Subject: RFR: 8293579:
 tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese
 Windows platform [v2]
In-Reply-To: <SEXLY0pFioXy1sOLP8x4qJLARtwQwBJFDso6n7RdZsg=.925b1fd6-6a1b-4371-b14a-006618f62040@github.com>
References: <ROgI801Y_MVdXiCKPYVtwN9C5kDZTT3gdAo4pnCACbs=.618721ad-4cc5-4db7-a923-3bf740e35181@github.com>
 <25y_sJVHa9QDx4VcfIJDu9RsAO2EYVfCAcpfWthsczw=.d19ddb42-2cad-497d-8345-1918823fdbfb@github.com>
 <3ikhT4YbokA53IEoN9HdDhONo6d3WvhcRVk0-oFHE8I=.edec73e0-acdd-4075-88da-56dd095c82a3@github.com>
 <BJJGTJOIVveQI5SYr7kWG01xg9AGq1LhyCtaHM5zW4g=.a8cfd59a-778f-410b-a2c4-034229aba08f@github.com>
 <SEXLY0pFioXy1sOLP8x4qJLARtwQwBJFDso6n7RdZsg=.925b1fd6-6a1b-4371-b14a-006618f62040@github.com>
Message-ID: <4ARgpqckW-WNkVGHuxIznh32zqRF75NlpGEDTQ7Nvlk=.ddcc063a-a821-49f6-b0fe-aaed1de2e3c6@github.com>

On Thu, 29 Sep 2022 16:47:01 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> I am sorry to misunderstand your comment. 
>> 
>> I don?t know whether "?"(0x00e9) exists only in "Cp1252", "UTF-8".
>> Will that be no problem that this test is skipped in other encordings? If skipped, the pattern for its encording probably won't be added forever. I think the other pattern should be added when this test fails. However I will follow the policy of OpenJDK.
>
> I agree skipping the test is not the best solution. Leaving a hint in the comments on how to fix the issue looks better alternative.

Well, what concerns me with the current fix is that it is simply patching only the case for the Japanese setup. We don't know if the same failure would happen in other setups (I'm pretty sure the same failure would happen with some Chinese Windows setups) which makes the test fragile. If that happens, we are not sure if it is a real bug or a test case false positive at a glance. For that reason, I think we should only run tests on the setup where we are sure the false positive won't happen (by skipping other unknown host encodings). And for the purpose of this test, that should suffice the need.
Another option would be to actually check if the test string can be encoded with a CharsetEncoder, but that may be overkill.

-------------

PR: https://git.openjdk.org/jdk/pull/10226

From alanb at openjdk.org  Thu Sep 29 18:24:50 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 29 Sep 2022 18:24:50 GMT
Subject: RFR: 8293940: Some tests for virtual threads take too long
Message-ID: <T6sXe46wig_0aqViyffF43Ct5sjYJsSHEGkf50dcUI8=.0fc7cf5d-3b94-4c06-8d70-fc7718fb75f4@github.com>

This is a test only change to split the execution of some of the larger tests for virtual threads and reduce the execution time of a few others.

The tests StructuredTaskScopeTest, ThreadFockTest and ThreadPerTaskExecutorTest contain a lot of tests and run with thread factories for both platform and virtual threads. These tests are changed to run twice, one with the thread factory for platform threads, the other for virtual threads. This allows the tests to run concurrently. A number of sleeps/delays in these tests are adjusted. StructuredTaskScopeTest goes from ~50s to two runs of ~15s. ThreadFockTest goes from 39s to two runs of 15s, ThreadPerTaskExecutorTest goes from 21s to two runs of 8.5. There is more that could be done but these tests are likely to change a bit the APIs evolve so it may not be worth doing now.

ThreadAPI also contains a lot of tests. A number of tests sleep to give time for a virtual thread to park or block. These sleeps are replaced with a poll of the thread state. A number of other tests are changed to use shorter sleeps. There are a few cleanups that include introducing a number of data providers and using a STPE for delayed actions. Its execution time goes from ~31s to ~12s.

CloseTest has two tests that sleep 1s and they are run with a data provider that produces six inputs so the sleep time adds up. These lengthy delays aren't needed for testing 

Finally, some of the stress changes have been changed. The two runs of PingPong are changed so they are in separate @test descriptions and the iteration count on a few tests has been reduced for release builds - the iteration count for debug builds is not changed.

-------------

Commit messages:
 - Update
 - Merge
 - Update
 - Initial changes

Changes: https://git.openjdk.org/jdk/pull/10463/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10463&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293940
  Stats: 459 lines in 11 files changed: 162 ins; 96 del; 201 mod
  Patch: https://git.openjdk.org/jdk/pull/10463.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10463/head:pull/10463

PR: https://git.openjdk.org/jdk/pull/10463

From duke at openjdk.org  Thu Sep 29 18:34:12 2022
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 29 Sep 2022 18:34:12 GMT
Subject: RFR: 8279361: Error in documentation of third Stream.reduce method
In-Reply-To: <D3sJANNfdWF1YeYX9bIHFwohm0HolRY-R4w77K7X7lM=.516f540c-beb0-48d2-acc7-ab210e3191b8@github.com>
References: <ZDScXuIYVuxEWWS2YvBff2WIm5IURggmJAJ6d7PQ9r8=.c4e324e0-a0ea-4c85-901e-0f77303b8f24@github.com>
 <D3sJANNfdWF1YeYX9bIHFwohm0HolRY-R4w77K7X7lM=.516f540c-beb0-48d2-acc7-ab210e3191b8@github.com>
Message-ID: <1edthBQHu9oFXpNBu03mX0H32z9SfWz74K13eBcZ-6I=.f5b11ad5-4fb5-42b3-8726-9a582074cd6d@github.com>

On Thu, 29 Sep 2022 16:29:54 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> This JavaDoc change attempts to shine some light on the `combiner`-function as it relates to the third variant of `Stream.reduce` since it according to the bug submission in JBS can be confusing that the `combiner` is not mentioned in the code example in the documentation.
>
> The current JavaDoc is not wrong :-) (same in other places). I think what you propose may not add much clarity (given the complexities of reasoning about parallelism).
> 
> We could add something after "but is not constrained to execute sequentially." e.g. 
> 
> "
> Parallel execution may result in intermediate results computed as if by the code above. Such results are combined using the combining function to produce the final result."
> "

@PaulSandoz That sounds like a fair solution to me, who else can chime in? :)

-------------

PR: https://git.openjdk.org/jdk/pull/10469

From kvn at openjdk.org  Thu Sep 29 18:39:24 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 29 Sep 2022 18:39:24 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v8]
In-Reply-To: <frb3je6a390Xqi6O21nZc6GVwti4hYcTm0MQZi2EXTk=.56910d50-38bf-4af6-9e16-6766b772b0bd@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com>
 <QdS7Tx2gk2HR7Y-qe6Ig8_QgyGRi5i3k14aERVEHTs4=.b5839efb-e45f-4700-b9d6-7fca6d61cd77@github.com>
 <frb3je6a390Xqi6O21nZc6GVwti4hYcTm0MQZi2EXTk=.56910d50-38bf-4af6-9e16-6766b772b0bd@github.com>
Message-ID: <m1OYhjDuNDzdJpvJdYw8wxy-GqRRGgTn1nH_tiSVp28=.4073f671-bfad-4778-b823-abca57cb40a6@github.com>

On Thu, 29 Sep 2022 17:45:49 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> tier2 and 3 passed. I will wait update with test and JVMCI fix before doing more testing.
>
> @vnkozlov I have addressed all review comments. Could you please run the patch through your testing? Thanks a lot for all the help.

@smita-kamath I have builds failures. Please, build and test yourself to verify changes.

src/hotspot/cpu/x86/assembler_x86.cpp: In member function 'void Assembler::evcvtps2ph(Address, KRegister, XMMRegister, int, int)':
src/hotspot/cpu/x86/assembler_x86.cpp:1950:15: error: no matching function for call to 'Assembler::emit_operand(XMMRegister&, Address&)'
 emit_operand(src, dst);

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From avoitylov at openjdk.org  Thu Sep 29 18:48:17 2022
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Thu, 29 Sep 2022 18:48:17 GMT
Subject: RFR: 8294198: Implement isFinite intrinsic for RISC-V
In-Reply-To: <WBWuthkb8Xz_Grgclr3TeGV9_NON6G2JL9HE-8CXGHk=.f79dbfe4-8472-49e3-b5ad-3acd8ae42ce8@github.com>
References: <R4tlj4gD-vO5BzJKgAx9-O4s7BD7q6NlLhMhl6PMUuc=.c67bb8fb-3bf1-4035-be21-cc873220bf70@github.com>
 <WBWuthkb8Xz_Grgclr3TeGV9_NON6G2JL9HE-8CXGHk=.f79dbfe4-8472-49e3-b5ad-3acd8ae42ce8@github.com>
Message-ID: <dGATiidOG_Vr-LAC7ZYe5IK69fYYrtx4moM51efv4lE=.010b416f-6167-46e1-b0ab-ea7a8f26acfd@github.com>

On Thu, 22 Sep 2022 17:20:02 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Unlike on x86 (see 8285868 and the discussion in review), isFinite intrinsic turned out to be profitable on RISC-V using the same fclass instruction as for 8293695 (isInfinite instrinsic). Therefore, I'm proposing to have it added on RISC-V in this PR.
>> 
>> benchmark results:
>> 
>> before:
>> 
>> Benchmark                              Mode  Cnt   Score   Error  Units
>> DoubleClassCheck.testIsFiniteBranch    avgt   15  52.824 ? 1.744  ns/op
>> DoubleClassCheck.testIsFiniteCMov      avgt   15  16.104 ? 0.358  ns/op
>> DoubleClassCheck.testIsFiniteStore     avgt   15  14.366 ? 2.174  ns/op
>> FloatClassCheck.testIsFiniteBranch     avgt   15  49.821 ? 0.330  ns/op
>> FloatClassCheck.testIsFiniteCMov       avgt   15  14.702 ? 0.335  ns/op
>> FloatClassCheck.testIsFiniteStore      avgt   15  14.749 ? 0.496  ns/op
>> 
>> after:
>> 
>> DoubleClassCheck.testIsFiniteBranch    avgt   15  48.921 ? 0.557  ns/op
>> DoubleClassCheck.testIsFiniteCMov      avgt   15  13.716 ? 0.304  ns/op
>> DoubleClassCheck.testIsFiniteStore     avgt   15   9.152 ? 0.158  ns/op
>> FloatClassCheck.testIsFiniteBranch     avgt   15  47.740 ? 2.028  ns/op
>> FloatClassCheck.testIsFiniteCMov       avgt   15  13.299 ? 0.282  ns/op
>> FloatClassCheck.testIsFiniteStore      avgt   15   9.185 ? 0.396  ns/op
>> 
>> Existing isInfinite jtreg test was altered to be able to use common code for isFinite test and fine-grained requires tag filtering. Existing benchmark was modified to include isFinite case. A typo ("Atleast" -> "At least") was fixed on the way.
>> 
>> Test passed on both release and fastdebug builds. Hotspot tier1 tests were run on x86_64 and RISC-V with no issues.
>
> The java.lang.* changes look fine if the rest of the work proceeds.

Thank you @jddarcy @RealFYang @vnkozlov for your reviews.

I also ran the benchmarks with -XX:LoopUnrollLimit=0 -XX:LoopMaxUnroll=0 and see the improvement with these flags as well.

-------------

PR: https://git.openjdk.org/jdk/pull/10391

From mchung at openjdk.org  Thu Sep 29 18:49:28 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 29 Sep 2022 18:49:28 GMT
Subject: RFR: JDK-8293701: jdeps InverseDepsAnalyzer runs into
 NoSuchElementException: No value present [v2]
In-Reply-To: <eQbbxiOC4eXZOrUsn2hH_XKQkly61CnYudE-AkiEB9w=.0ebafb1f-e446-4349-8e0f-de47d963921a@github.com>
References: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
 <eQbbxiOC4eXZOrUsn2hH_XKQkly61CnYudE-AkiEB9w=.0ebafb1f-e446-4349-8e0f-de47d963921a@github.com>
Message-ID: <5Q5UnUPCBPuDkhBdV6CndDU64xmlM1tihsabnRWzmtk=.3154b78e-1ecf-478f-b798-937f1ba44ab9@github.com>

On Thu, 29 Sep 2022 16:05:44 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We noticed that with certain jar file input, jdeps runs into the following exception, this happens with jdk11, 17 and 20.
>> 
>> jdeps.exe --multi-release 11 --module-path . --inverse --package com.sap.nw.performance.supa.client test.jar
>> 
>> Inverse transitive dependences matching packages [com.sap.nw.performance.supa.client]
>> Exception in thread "main" java.util.NoSuchElementException: No value present
>>         at java.base/java.util.Optional.get(Optional.java:148)
>>         at jdk.jdeps/com.sun.tools.jdeps.InverseDepsAnalyzer.lambda$inverseDependences$2(InverseDepsAnalyzer.java:150)
>>         at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>>         at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>>         at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
>>         at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>>         at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
>> 
>> So an additional  check might be a good idea.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust check, add test

src/jdk.jdeps/share/classes/com/sun/tools/jdeps/InverseDepsAnalyzer.java line 150:

> 148:                         // filter "requires static" if the module is not resolved in the configuration
> 149:                         .filter(req -> !req.modifiers().contains(Requires.Modifier.STATIC)
> 150:                         || configuration.findModule(req.name()).isPresent())

Nit: indent further to the right for readability (maybe 16 spaces)

test/langtools/tools/jdeps/optionalDependency/OptionalDependencyError.java line 43:

> 41: import static org.testng.Assert.assertTrue;
> 42: 
> 43: public class OptionalDependencyError {

I'd rename the test to `OptionalDependencyTest` since it's not expecting an error.

test/langtools/tools/jdeps/optionalDependency/OptionalDependencyError.java line 73:

> 71:      */
> 72:     @Test
> 73:     public void noOptionalDependencyError() {

This test case verifies when m3 is resolved in the configuration.   I suggest to rename this to `optionalDependenceResolved`.  Please also add the comment something like


/*
 * Test if a requires static dependence is resolved in the configuration.
 */


can you add one more test case that m3 is not resolved `optinalDependenceNotResolved`?

-------------

PR: https://git.openjdk.org/jdk/pull/10300

From avoitylov at openjdk.org  Thu Sep 29 18:54:40 2022
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Thu, 29 Sep 2022 18:54:40 GMT
Subject: Integrated: 8294198: Implement isFinite intrinsic for RISC-V
In-Reply-To: <R4tlj4gD-vO5BzJKgAx9-O4s7BD7q6NlLhMhl6PMUuc=.c67bb8fb-3bf1-4035-be21-cc873220bf70@github.com>
References: <R4tlj4gD-vO5BzJKgAx9-O4s7BD7q6NlLhMhl6PMUuc=.c67bb8fb-3bf1-4035-be21-cc873220bf70@github.com>
Message-ID: <Rhvy5idkpo_Oqy3T2-RFVtv0pokE4-7B4ktda50jo2s=.3e9a2e1e-5777-4f54-b5a0-3e1481fc8dd8@github.com>

On Thu, 22 Sep 2022 12:56:49 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

> Unlike on x86 (see 8285868 and the discussion in review), isFinite intrinsic turned out to be profitable on RISC-V using the same fclass instruction as for 8293695 (isInfinite instrinsic). Therefore, I'm proposing to have it added on RISC-V in this PR.
> 
> benchmark results:
> 
> before:
> 
> Benchmark                              Mode  Cnt   Score   Error  Units
> DoubleClassCheck.testIsFiniteBranch    avgt   15  52.824 ? 1.744  ns/op
> DoubleClassCheck.testIsFiniteCMov      avgt   15  16.104 ? 0.358  ns/op
> DoubleClassCheck.testIsFiniteStore     avgt   15  14.366 ? 2.174  ns/op
> FloatClassCheck.testIsFiniteBranch     avgt   15  49.821 ? 0.330  ns/op
> FloatClassCheck.testIsFiniteCMov       avgt   15  14.702 ? 0.335  ns/op
> FloatClassCheck.testIsFiniteStore      avgt   15  14.749 ? 0.496  ns/op
> 
> after:
> 
> DoubleClassCheck.testIsFiniteBranch    avgt   15  48.921 ? 0.557  ns/op
> DoubleClassCheck.testIsFiniteCMov      avgt   15  13.716 ? 0.304  ns/op
> DoubleClassCheck.testIsFiniteStore     avgt   15   9.152 ? 0.158  ns/op
> FloatClassCheck.testIsFiniteBranch     avgt   15  47.740 ? 2.028  ns/op
> FloatClassCheck.testIsFiniteCMov       avgt   15  13.299 ? 0.282  ns/op
> FloatClassCheck.testIsFiniteStore      avgt   15   9.185 ? 0.396  ns/op
> 
> Existing isInfinite jtreg test was altered to be able to use common code for isFinite test and fine-grained requires tag filtering. Existing benchmark was modified to include isFinite case. A typo ("Atleast" -> "At least") was fixed on the way.
> 
> Test passed on both release and fastdebug builds. Hotspot tier1 tests were run on x86_64 and RISC-V with no issues.

This pull request has now been integrated.

Changeset: aeef3ecd
Author:    Aleksei Voitylov <avoitylov at openjdk.org>
Committer: Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aeef3ecdc4d99d4bfb9e762cb038d9571c3c56df
Stats:     363 lines in 17 files changed: 315 ins; 47 del; 1 mod

8294198: Implement isFinite intrinsic for RISC-V

Reviewed-by: fyang, kvn

-------------

PR: https://git.openjdk.org/jdk/pull/10391

From asemenyuk at openjdk.org  Thu Sep 29 19:05:21 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 29 Sep 2022 19:05:21 GMT
Subject: RFR: 8293579:
 tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese
 Windows platform [v2]
In-Reply-To: <4ARgpqckW-WNkVGHuxIznh32zqRF75NlpGEDTQ7Nvlk=.ddcc063a-a821-49f6-b0fe-aaed1de2e3c6@github.com>
References: <ROgI801Y_MVdXiCKPYVtwN9C5kDZTT3gdAo4pnCACbs=.618721ad-4cc5-4db7-a923-3bf740e35181@github.com>
 <25y_sJVHa9QDx4VcfIJDu9RsAO2EYVfCAcpfWthsczw=.d19ddb42-2cad-497d-8345-1918823fdbfb@github.com>
 <3ikhT4YbokA53IEoN9HdDhONo6d3WvhcRVk0-oFHE8I=.edec73e0-acdd-4075-88da-56dd095c82a3@github.com>
 <BJJGTJOIVveQI5SYr7kWG01xg9AGq1LhyCtaHM5zW4g=.a8cfd59a-778f-410b-a2c4-034229aba08f@github.com>
 <SEXLY0pFioXy1sOLP8x4qJLARtwQwBJFDso6n7RdZsg=.925b1fd6-6a1b-4371-b14a-006618f62040@github.com>
 <4ARgpqckW-WNkVGHuxIznh32zqRF75NlpGEDTQ7Nvlk=.ddcc063a-a821-49f6-b0fe-aaed1de2e3c6@github.com>
Message-ID: <nry-aKoKUn-GECMSY3WNHJkn1MRQ8cgHZhtvw7L-tOs=.f6e5d4b6-c4ed-484a-8365-e475353fa148@github.com>

On Thu, 29 Sep 2022 18:17:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> I agree skipping the test is not the best solution. Leaving a hint in the comments on how to fix the issue looks better alternative.
>
> Well, what concerns me with the current fix is that it is simply patching only the case for the Japanese setup. We don't know if the same failure would happen in other setups (I'm pretty sure the same failure would happen with some Chinese Windows setups) which makes the test fragile. If that happens, we are not sure if it is a real bug or a test case false positive at a glance. For that reason, I think we should only run tests on the setup where we are sure the false positive won't happen (by skipping other unknown host encodings). And for the purpose of this test, that should suffice the need.
> Another option would be to actually check if the test string can be encoded with a CharsetEncoder, but that may be overkill.

I don't think it will be many practical setups where this test fails. This test has been around for more than 2 years and this is the first accident.

-------------

PR: https://git.openjdk.org/jdk/pull/10226

From jjg at openjdk.org  Thu Sep 29 20:21:26 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 29 Sep 2022 20:21:26 GMT
Subject: RFR: JDK-8287597: List all preview features on the javadoc PREVIEW
 page [v4]
In-Reply-To: <d-6h91d_CUceEHACGegid35NS2lNqSqoWOLPgDfCtkM=.1c4e879f-5860-4fab-b783-07381ffcfd31@github.com>
References: <0UfKceKzCT3_exJ2vDs5y7IeroB2IHU8kHPO7b46KDY=.bbc662cb-5bd9-4205-acc2-3025ad1a5ab1@github.com>
 <d-6h91d_CUceEHACGegid35NS2lNqSqoWOLPgDfCtkM=.1c4e879f-5860-4fab-b783-07381ffcfd31@github.com>
Message-ID: <qAztQcEGQImXoRmFN56ZAmz7CcqwQ3zXjd8pKyAhRWs=.7bf5d603-c285-4389-9733-e11964fd0c9b@github.com>

On Tue, 27 Sep 2022 11:37:23 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review an enhancement to the preview page to add a list of preview features and allow users to explore the preview APIs by feature. 
>> 
>> While the changes for the enhancement itself are not overly complex, the work entailed a moderate cleanup of other summary API lists (Deprecated and New API pages) as well as a few unrelated summary pages that happened to share some of the CSS classes and HTML structure.
>> 
>> The change itself starts with a new internal `jdk.internal.javac.PreviewFeature.JEP` annotation interface to add JEP information to the nearby `jdk.internal.javac.PreviewFeature.Feature` enum. This JEP information is retrieved by new methods in the javadoc `Utils` class and then fetched by `PreviewAPIListBuilder` which passes it on to `PreviewListWriter`. 
>> 
>> The superclass of `PreviewListWriter` and other API summary writer classes, `SummaryListWriter`, gets a new `addContentSelectors(Content)` method to add the checkboxes to show/hide various parts of the page content. The class is also now abstract as this and other methods do not have useful implementations in the base class. 
>> 
>> Another change to `SummaryListWriter` is that `pageMode`, `description`, `headContent` and `titleKey` are no longer fields in the class but rather sent to the `generateSummaryListFile` method as parameters since they are mostly just used locally in that method. On the other hand, the associated Builder is used in many places and previously had to be retrieved from the configuration object or passed around as parameter, so that is now set as a final field in `SummaryListWriter`. 
>> 
>> Finally, a few words about changes in CSS and HTML: The "Contents" list containing various kinds of elements in the API list was previously contained in the `<div class="header">` element that also contains the page header, and the stylesheet used the `.header ul`  selector to style the list. Now that the checkboxes separate the page header from the contents list it felt wrong to put all this in the header div (most other pages only use the div for the header itself). I also didn't like the indirect CSS selector too much, `.header ul` is not very indicative of what it applies to.
>> 
>> I therefore decided to create a new dedicated CSS class for the contents list called `contents-list`, and move the `<ul>` element out of the header div. Apart from the summary API pages, this change also affects the "Constant Values"  page as well as the top and package level "Tree" (class hierarchy) pages. I made sure the contents list in these pages look the same as before.
>> 
>> The list items in the contents list now each have an `id` attribute to allow hiding the list item if no content for the element kind is currently selected/visible. The value of the `id` attribute uses the format `contents-<element-kind>`.
>> 
>> There is one additional CSS class called `preview-feature-list` used for the list of preview feature JEPs. 
>> 
>> Demo output for the new preview page as well as other pages is available here:
>> http://cr.openjdk.java.net/~hannesw/8287597/api.03/preview-list.html
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix URL in test

A couple of minor typographical issues.
Running a build to view output, before approving.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SummaryListWriter.java line 163:

> 161:      */
> 162:     protected void addIndexLink(HtmlId id, String headingKey, Content content) {
> 163:         // The "contents-" + id value is used in JavaScript code to toggle visiblity of the link.

typo: visiblity

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 124:

> 122: doclet.New_Label=New
> 123: doclet.Preview_API=Preview API
> 124: doclet.Preview_API_Checkbox_Label=Show preview API for:

Should "Preview API" be capitalized as a Proper Noun?

-------------

PR: https://git.openjdk.org/jdk/pull/9336

From aturbanov at openjdk.org  Thu Sep 29 21:03:26 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 29 Sep 2022 21:03:26 GMT
Subject: RFR: 8291966: SwitchBootstrap.typeSwitch could be faster
In-Reply-To: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
References: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
Message-ID: <AYJzv9kF2jLIoQm5wE1hWElhRIMMetquoJD0N6ZlZ6w=.a55c6b78-c7db-4ad9-99d1-87ad8dbaaa80@github.com>

On Fri, 5 Aug 2022 16:12:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The pattern matching switches are using a bootstrap method `SwitchBootstrap.typeSwitch` to implement the jumps in the switch. Basically, for a switch like:
> 
> switch (obj) {
>     case String s when s.isEmpty() -> {}
>     case String s -> {}
>     case CharSequence cs -> {}
>     ...
> }
> 
> 
> this method will produce a MethodHandle that will be analyze the provided selector value (`obj` in the example), and will return the case index to which the switch should jump. This method also accepts a (re)start index for the search, which is used to handle guards. For example, if the `s.isEmpty()` guard in the above sample returns false, the matching is restarted on the next case.
> 
> The current implementation is fairly slow, it basically goes through the labels in a loop. The proposal here is to replace that with a MethodHandle structure like this:
> 
> obj == null ? -1
>                   : switch (restartIndex) {
>                         case 0 -> obj instanceof String ? 0 : obj instanceof CharSequence ? 2 : ... ;
>                         case 1 -> obj instanceof String ? 1 : obj instanceof CharSequence ? 2 : ... ;
>                         case 2 -> obj instanceof CharSequence ? 2 : ... ;
>                         ...
>                         default -> <labels-count>;
>                     }
> 
> 
> This appear to run faster than the current implementation, using testcase similar to the one used for https://github.com/openjdk/jdk/pull/9746 , these are the results
> 
> PatternsOptimizationTest.testLegacyIndyLongSwitch   thrpt   25   1515989.562 ? 32047.918  ops/s
> PatternsOptimizationTest.testHandleIndyLongSwitch   thrpt   25   2630707.585 ? 37202.210  ops/s
> 
> PatternsOptimizationTest.testLegacyIndyShortSwitch  thrpt   25   6789310.900 ? 61921.636  ops/s
> PatternsOptimizationTest.testHandleIndyShortSwitch  thrpt   25  10771729.464 ? 69607.467  ops/s
> 
> 
> The "LegacyIndy" is the current implementation, "HandleIndy" is the one proposed here. The translation in javac used is the one from #9746 in all cases.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 140:

> 138:         Stream.of(labels).forEach(SwitchBootstraps::verifyLabel);
> 139: 
> 140:         MethodHandle target  = createMethodHandleSwitch(labels);

let's remove redundant space before `=`

-------------

PR: https://git.openjdk.org/jdk/pull/9779

From aturbanov at openjdk.org  Thu Sep 29 21:18:36 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 29 Sep 2022 21:18:36 GMT
Subject: RFR: 8289711: Add container configuration data to mbeans [v10]
In-Reply-To: <x2l5NJ4dB6yRfSGryPbHf_LW3Q2G6jvwysxE2Gr1f8s=.36811dd0-a7a8-46d2-bf2e-59fc6ebd856e@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
 <x2l5NJ4dB6yRfSGryPbHf_LW3Q2G6jvwysxE2Gr1f8s=.36811dd0-a7a8-46d2-bf2e-59fc6ebd856e@github.com>
Message-ID: <suiDhkLmIlfjqIvWEqLp69lLfq9MOxw07rPlAXfimcU=.6586ab22-3170-4b2c-96ec-408a4bee9651@github.com>

On Wed, 10 Aug 2022 02:10:25 GMT, xpbob <duke at openjdk.org> wrote:

>> Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios.
>> Results the following
>> ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png)
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add bean to list

src/jdk.management/share/classes/com/sun/management/ContainerInfoMXBean.java line 31:

> 29:  * This is a special bean , only available on Linux systems
> 30:  */
> 31: public interface ContainerInfoMXBean  extends PlatformManagedObject {

let's remove one redundant space before `extends`

-------------

PR: https://git.openjdk.org/jdk/pull/9372

From aturbanov at openjdk.org  Thu Sep 29 21:24:29 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 29 Sep 2022 21:24:29 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: <lj59AHABulol9ckpGWiEayGQQJ-XtGDdgijdELF-aSU=.1073ff8c-c716-46d1-87d2-40b1fd93a87f@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

src/java.naming/share/classes/com/sun/jndi/ldap/LdapNamingEnumeration.java line 74:

> 72:             ncp.setNameInNamespace(dn);
> 73:             return ncp;
> 74:         }  finally {

let's remove one redundant space after `}`

-------------

PR: https://git.openjdk.org/jdk/pull/8311

From jjg at openjdk.org  Thu Sep 29 21:25:25 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 29 Sep 2022 21:25:25 GMT
Subject: RFR: JDK-8287597: List all preview features on the javadoc PREVIEW
 page [v4]
In-Reply-To: <d-6h91d_CUceEHACGegid35NS2lNqSqoWOLPgDfCtkM=.1c4e879f-5860-4fab-b783-07381ffcfd31@github.com>
References: <0UfKceKzCT3_exJ2vDs5y7IeroB2IHU8kHPO7b46KDY=.bbc662cb-5bd9-4205-acc2-3025ad1a5ab1@github.com>
 <d-6h91d_CUceEHACGegid35NS2lNqSqoWOLPgDfCtkM=.1c4e879f-5860-4fab-b783-07381ffcfd31@github.com>
Message-ID: <kV9fIILiBe4R_DWQkSP8Vie4874H9o84-mZsg_zLEm4=.f82bff97-ccaf-496e-be0d-cec06aaa1ebd@github.com>

On Tue, 27 Sep 2022 11:37:23 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review an enhancement to the preview page to add a list of preview features and allow users to explore the preview APIs by feature. 
>> 
>> While the changes for the enhancement itself are not overly complex, the work entailed a moderate cleanup of other summary API lists (Deprecated and New API pages) as well as a few unrelated summary pages that happened to share some of the CSS classes and HTML structure.
>> 
>> The change itself starts with a new internal `jdk.internal.javac.PreviewFeature.JEP` annotation interface to add JEP information to the nearby `jdk.internal.javac.PreviewFeature.Feature` enum. This JEP information is retrieved by new methods in the javadoc `Utils` class and then fetched by `PreviewAPIListBuilder` which passes it on to `PreviewListWriter`. 
>> 
>> The superclass of `PreviewListWriter` and other API summary writer classes, `SummaryListWriter`, gets a new `addContentSelectors(Content)` method to add the checkboxes to show/hide various parts of the page content. The class is also now abstract as this and other methods do not have useful implementations in the base class. 
>> 
>> Another change to `SummaryListWriter` is that `pageMode`, `description`, `headContent` and `titleKey` are no longer fields in the class but rather sent to the `generateSummaryListFile` method as parameters since they are mostly just used locally in that method. On the other hand, the associated Builder is used in many places and previously had to be retrieved from the configuration object or passed around as parameter, so that is now set as a final field in `SummaryListWriter`. 
>> 
>> Finally, a few words about changes in CSS and HTML: The "Contents" list containing various kinds of elements in the API list was previously contained in the `<div class="header">` element that also contains the page header, and the stylesheet used the `.header ul`  selector to style the list. Now that the checkboxes separate the page header from the contents list it felt wrong to put all this in the header div (most other pages only use the div for the header itself). I also didn't like the indirect CSS selector too much, `.header ul` is not very indicative of what it applies to.
>> 
>> I therefore decided to create a new dedicated CSS class for the contents list called `contents-list`, and move the `<ul>` element out of the header div. Apart from the summary API pages, this change also affects the "Constant Values"  page as well as the top and package level "Tree" (class hierarchy) pages. I made sure the contents list in these pages look the same as before.
>> 
>> The list items in the contents list now each have an `id` attribute to allow hiding the list item if no content for the element kind is currently selected/visible. The value of the `id` attribute uses the format `contents-<element-kind>`.
>> 
>> There is one additional CSS class called `preview-feature-list` used for the list of preview feature JEPs. 
>> 
>> Demo output for the new preview page as well as other pages is available here:
>> http://cr.openjdk.java.net/~hannesw/8287597/api.03/preview-list.html
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix URL in test

Approved, with a question...

Looking at the generated output, would it be better to prefix theJEP numbers in the initial list of checkboxes with the word `JEP` ?

(Also note the preceding typo comments.)

-------------

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9336

From duke at openjdk.org  Thu Sep 29 21:27:02 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 29 Sep 2022 21:27:02 GMT
Subject: RFR: 8294397: Replace StringBuffer with StringBuilder within java.text
Message-ID: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>

Problem: Unnecessary instances of StringBuffer within java.text (internal only)

Fix: StringBuffer Replaced with StringBuilder, and adjusted variable/method names

-------------

Commit messages:
 - Update PatternEntry test case for StringBuilder
 - Copyright update
 - Replace buffer in both, adjust addToBuilder dependencies
 - Adjust variable names within DigitList
 - Fix: Replace StringBuffer in CollationElementIterator
 - Fix: replace StringBuffer with StringBuilder

Changes: https://git.openjdk.org/jdk/pull/10475/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10475&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294397
  Stats: 35 lines in 5 files changed: 0 ins; 0 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/10475.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10475/head:pull/10475

PR: https://git.openjdk.org/jdk/pull/10475

From lancea at openjdk.org  Thu Sep 29 21:38:20 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 29 Sep 2022 21:38:20 GMT
Subject: RFR: 8294397: Replace StringBuffer with StringBuilder within
 java.text
In-Reply-To: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
Message-ID: <Rn_ql55nLv1vN-Zoq6NPAipzUQulUAjuJBZvei2hj7Y=.085c2b36-5de8-4bcf-81e3-aeaa94958154@github.com>

On Wed, 28 Sep 2022 22:54:33 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Unnecessary instances of StringBuffer within java.text (internal only)
> 
> Fix: StringBuffer Replaced with StringBuilder, and adjusted variable/method names

Looks good.

should we update test/jdk/sun/text/IntHashtable/patch-src/java.base/java/text/Bug4170614Test.java to include `@test, @bug, @run, @summary`?

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10475

From duke at openjdk.org  Thu Sep 29 21:51:43 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 29 Sep 2022 21:51:43 GMT
Subject: RFR: 8294397: Replace StringBuffer with StringBuilder within
 java.text
In-Reply-To: <Rn_ql55nLv1vN-Zoq6NPAipzUQulUAjuJBZvei2hj7Y=.085c2b36-5de8-4bcf-81e3-aeaa94958154@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <Rn_ql55nLv1vN-Zoq6NPAipzUQulUAjuJBZvei2hj7Y=.085c2b36-5de8-4bcf-81e3-aeaa94958154@github.com>
Message-ID: <cX5-qU_wl7WQRuBoCC0RrFAgZgFvXZqcE_tWNDf8OGA=.b205ca38-1548-4aa8-8d7e-0d627f3fe97d@github.com>

On Thu, 29 Sep 2022 21:34:24 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> should we update test/jdk/sun/text/IntHashtable/patch-src/java.base/java/text/Bug4170614Test.java to include `@test, @bug, @run, @summary`?

Brent actually pointed that out to me as well. I believe since Bug4170614Test.java is managed by Bug4170614TestRun.java which has tags, then it would be fine to not include the tags(in Bug4170614Test.java), but please let me know your thoughts. @LanceAndersen

-------------

PR: https://git.openjdk.org/jdk/pull/10475

From bchristi at openjdk.org  Thu Sep 29 21:51:43 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 29 Sep 2022 21:51:43 GMT
Subject: RFR: 8294397: Replace StringBuffer with StringBuilder within
 java.text
In-Reply-To: <cX5-qU_wl7WQRuBoCC0RrFAgZgFvXZqcE_tWNDf8OGA=.b205ca38-1548-4aa8-8d7e-0d627f3fe97d@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <Rn_ql55nLv1vN-Zoq6NPAipzUQulUAjuJBZvei2hj7Y=.085c2b36-5de8-4bcf-81e3-aeaa94958154@github.com>
 <cX5-qU_wl7WQRuBoCC0RrFAgZgFvXZqcE_tWNDf8OGA=.b205ca38-1548-4aa8-8d7e-0d627f3fe97d@github.com>
Message-ID: <0V9OZIDGjTl4mNUFSqeGQXRZUzG8hIBLjixuoISbS1I=.c5c0d643-2e83-4870-b27e-fae90e16aafb@github.com>

On Thu, 29 Sep 2022 21:48:52 GMT, Justin Lu <duke at openjdk.org> wrote:

> should we update test/jdk/sun/text/IntHashtable/patch-src/java.base/java/text/Bug4170614Test.java to include `@test, @bug, @run, @summary`?


/*
    (this test doesn't have an at-test tag because it's run by Bug4170614TestRun.java
     instead of directly by the test harness)
*/

:)

-------------

PR: https://git.openjdk.org/jdk/pull/10475

From lancea at openjdk.org  Thu Sep 29 21:58:21 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 29 Sep 2022 21:58:21 GMT
Subject: RFR: 8294397: Replace StringBuffer with StringBuilder within
 java.text
In-Reply-To: <0V9OZIDGjTl4mNUFSqeGQXRZUzG8hIBLjixuoISbS1I=.c5c0d643-2e83-4870-b27e-fae90e16aafb@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <Rn_ql55nLv1vN-Zoq6NPAipzUQulUAjuJBZvei2hj7Y=.085c2b36-5de8-4bcf-81e3-aeaa94958154@github.com>
 <cX5-qU_wl7WQRuBoCC0RrFAgZgFvXZqcE_tWNDf8OGA=.b205ca38-1548-4aa8-8d7e-0d627f3fe97d@github.com>
 <0V9OZIDGjTl4mNUFSqeGQXRZUzG8hIBLjixuoISbS1I=.c5c0d643-2e83-4870-b27e-fae90e16aafb@github.com>
Message-ID: <9_WnJ6L0hddDDWuv0_ePWSASObEVohCHIJqCCRacFvw=.9cae45d1-5d97-423e-96ee-aeed57c78ecd@github.com>

On Thu, 29 Sep 2022 21:49:05 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> > should we update test/jdk/sun/text/IntHashtable/patch-src/java.base/java/text/Bug4170614Test.java to include `@test, @bug, @run, @summary`?
> 
> ```
> /*
>     (this test doesn't have an at-test tag because it's run by Bug4170614TestRun.java
>      instead of directly by the test harness)
> */
> ```
> 
> :)

Justin, Brent

Thanks for pointing that out.   Do either of you know why this is configured as it is as I am not sure I see a reason for the wrapper?

-------------

PR: https://git.openjdk.org/jdk/pull/10475

From naoto at openjdk.org  Thu Sep 29 22:12:30 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 29 Sep 2022 22:12:30 GMT
Subject: RFR: 8294397: Replace StringBuffer with StringBuilder within
 java.text
In-Reply-To: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
Message-ID: <I0pOPJcXxnvEQH4YWOgPUOLAQEwemkWbmOODGTvX9VI=.9bf13cd7-3da9-4698-b3ac-354152acb6d1@github.com>

On Wed, 28 Sep 2022 22:54:33 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Unnecessary instances of StringBuffer within java.text (internal only)
> 
> Fix: StringBuffer Replaced with StringBuilder, and adjusted variable/method names

AFAICT, the reason is described in the test class description, i.e., tweak to be in `java.text` package so that it can test the internal `hashCode` method.

btw I find a typo there:

* Bug #4170614 complained that we had two iternal classes that

-------------

PR: https://git.openjdk.org/jdk/pull/10475

From duke at openjdk.org  Thu Sep 29 22:15:00 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 29 Sep 2022 22:15:00 GMT
Subject: RFR: 8294397: Replace StringBuffer with StringBuilder within
 java.text [v2]
In-Reply-To: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
Message-ID: <xrmZ8iFlP7a0nxPA63ytSX4LMbwfX74Ql5LLmQ2MBpg=.a71088ce-2541-4151-a765-2badff8d6f86@github.com>

> Problem: Unnecessary instances of StringBuffer within java.text (internal only)
> 
> Fix: StringBuffer Replaced with StringBuilder, and adjusted variable/method names

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Adjust typo within test description

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10475/files
  - new: https://git.openjdk.org/jdk/pull/10475/files/ea2bc5e7..e02edf67

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10475&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10475&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10475.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10475/head:pull/10475

PR: https://git.openjdk.org/jdk/pull/10475

From lancea at openjdk.org  Thu Sep 29 22:26:35 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 29 Sep 2022 22:26:35 GMT
Subject: RFR: 8294397: Replace StringBuffer with StringBuilder within
 java.text [v2]
In-Reply-To: <xrmZ8iFlP7a0nxPA63ytSX4LMbwfX74Ql5LLmQ2MBpg=.a71088ce-2541-4151-a765-2badff8d6f86@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <xrmZ8iFlP7a0nxPA63ytSX4LMbwfX74Ql5LLmQ2MBpg=.a71088ce-2541-4151-a765-2badff8d6f86@github.com>
Message-ID: <uVmN8TUOx2B9EiSYVLfoXl5IuP9QoumcR00ZDNNKWu8=.2b7ba17a-d7b4-4f7f-a739-c7c053de170c@github.com>

On Thu, 29 Sep 2022 22:15:00 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Problem: Unnecessary instances of StringBuffer within java.text (internal only)
>> 
>> Fix: StringBuffer Replaced with StringBuilder, and adjusted variable/method names
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust typo within test description

Marked as reviewed by lancea (Reviewer).

> > should we update test/jdk/sun/text/IntHashtable/patch-src/java.base/java/text/Bug4170614Test.java to include `@test, @bug, @run, @summary`?
> 
> Brent actually pointed that out to me as well. I believe since Bug4170614Test.java is managed by Bug4170614TestRun.java which has tags, then it would be fine to not include the tags(in Bug4170614Test.java), but please let me know your thoughts. @LanceAndersen



> > should we update test/jdk/sun/text/IntHashtable/patch-src/java.base/java/text/Bug4170614Test.java to include `@test, @bug, @run, @summary`?
> 
> Brent actually pointed that out to me as well. I believe since Bug4170614Test.java is managed by Bug4170614TestRun.java which has tags, then it would be fine to not include the tags(in Bug4170614Test.java), but please let me know your thoughts. @LanceAndersen

Hi Justin,

Yes if the wrapper class is needed then we do not need the tags in the actual test.

-------------

PR: https://git.openjdk.org/jdk/pull/10475

From lancea at openjdk.org  Thu Sep 29 22:26:35 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 29 Sep 2022 22:26:35 GMT
Subject: RFR: 8294397: Replace StringBuffer with StringBuilder within
 java.text
In-Reply-To: <I0pOPJcXxnvEQH4YWOgPUOLAQEwemkWbmOODGTvX9VI=.9bf13cd7-3da9-4698-b3ac-354152acb6d1@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <I0pOPJcXxnvEQH4YWOgPUOLAQEwemkWbmOODGTvX9VI=.9bf13cd7-3da9-4698-b3ac-354152acb6d1@github.com>
Message-ID: <ulkwaHRYr1Z7P9CfNSfpGy3aFKoSTu5Zo4TBPLMKXVU=.abbfd0db-69a5-4984-a0d9-9a2aaae3a882@github.com>

On Thu, 29 Sep 2022 22:07:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> AFAICT, the reason is described in the test class description, i.e., tweak to be in `java.text` package so that it can test the internal `hashCode` method.

Understand, I guess I don't see the difference from moving the tags to the actual test but there could be a subtlety  I am missing (wouldn't be the first time ;-) )

-------------

PR: https://git.openjdk.org/jdk/pull/10475

From naoto at openjdk.org  Thu Sep 29 22:34:19 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 29 Sep 2022 22:34:19 GMT
Subject: RFR: 8294397: Replace StringBuffer with StringBuilder within
 java.text
In-Reply-To: <ulkwaHRYr1Z7P9CfNSfpGy3aFKoSTu5Zo4TBPLMKXVU=.abbfd0db-69a5-4984-a0d9-9a2aaae3a882@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <I0pOPJcXxnvEQH4YWOgPUOLAQEwemkWbmOODGTvX9VI=.9bf13cd7-3da9-4698-b3ac-354152acb6d1@github.com>
 <ulkwaHRYr1Z7P9CfNSfpGy3aFKoSTu5Zo4TBPLMKXVU=.abbfd0db-69a5-4984-a0d9-9a2aaae3a882@github.com>
Message-ID: <4-c7dC9feD9vgVdjtLf3rgcmBi6yM2kvYErlwzqvDhQ=.2dce9d38-d3af-4038-8ba9-ce462191ddd1@github.com>

On Thu, 29 Sep 2022 22:19:26 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Understand, I guess I don't see the difference from moving the tags to the actual test but there could be a subtlety I am missing (wouldn't be the first time ;-) )

The runner has a @library/@build tag to build the test case as a library for the said reason.

-------------

PR: https://git.openjdk.org/jdk/pull/10475

From bchristi at openjdk.org  Thu Sep 29 22:34:24 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 29 Sep 2022 22:34:24 GMT
Subject: RFR: 8294397: Replace StringBuffer with StringBuilder within
 java.text [v2]
In-Reply-To: <xrmZ8iFlP7a0nxPA63ytSX4LMbwfX74Ql5LLmQ2MBpg=.a71088ce-2541-4151-a765-2badff8d6f86@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <xrmZ8iFlP7a0nxPA63ytSX4LMbwfX74Ql5LLmQ2MBpg=.a71088ce-2541-4151-a765-2badff8d6f86@github.com>
Message-ID: <7R_FJi6DYp4rE7nHNvpW6LPOsa5L_e7ul1ii1t8QeIA=.a8628f49-e0ce-41ee-8c7e-4e8f7faf983e@github.com>

On Thu, 29 Sep 2022 22:15:00 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Problem: Unnecessary instances of StringBuffer within java.text (internal only)
>> 
>> Fix: StringBuffer Replaced with StringBuilder, and adjusted variable/method names
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust typo within test description

src/java.base/share/classes/java/text/DigitList.java line 808:

> 806:         }
> 807:         return tempBuilder;
> 808:     }

Is it worth considering whether it's still necessary to cache and reuse a single String[Buffer|Builder] instance when using 2022 garbage collectors?

src/java.base/share/classes/java/text/PatternEntry.java line 117:

> 115:                      boolean showExtension,
> 116:                      boolean showWhiteSpace,
> 117:                      PatternEntry lastEntry)

Nit: update the indentation on these lines

src/java.base/share/classes/java/text/PatternEntry.java line 291:

> 289:         // We re-use these objects in order to improve performance
> 290:         private StringBuilder newChars = new StringBuilder();
> 291:         private StringBuilder newExtension = new StringBuilder();

Again, in 2022, I don't know that this cache+reuse pattern is needed for performance.

-------------

PR: https://git.openjdk.org/jdk/pull/10475

From duke at openjdk.org  Thu Sep 29 22:44:43 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 29 Sep 2022 22:44:43 GMT
Subject: RFR: 8294397: Replace StringBuffer with StringBuilder within
 java.text [v3]
In-Reply-To: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
Message-ID: <lo5pfg_gUjctlGjXpVwkYWAvAGgrC3D7sU-YdxFOy0M=.da974483-38f8-477d-9e6e-398a59765fb0@github.com>

> Problem: Unnecessary instances of StringBuffer within java.text (internal only)
> 
> Fix: StringBuffer Replaced with StringBuilder, and adjusted variable/method names

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Tweak indentation in PaternEntry

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10475/files
  - new: https://git.openjdk.org/jdk/pull/10475/files/e02edf67..cd966f31

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10475&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10475&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10475.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10475/head:pull/10475

PR: https://git.openjdk.org/jdk/pull/10475

From duke at openjdk.org  Fri Sep 30 00:03:35 2022
From: duke at openjdk.org (Justin Lu)
Date: Fri, 30 Sep 2022 00:03:35 GMT
Subject: RFR: 8294307: ISO 4217 Amendment 173 Update
Message-ID: <LwGHj6uO96npFnZooUdQhkCGynrdTGVsTKW5ogE27nY=.b4b6e06b-fd1f-40f4-bd3a-dca742540e8b@github.com>

Problem: Amendment number outdated

Fix: Update amendment number + date in properties file and test case data file

-------------

Commit messages:
 - Update amendment number in test case data file
 - Update amendment number

Changes: https://git.openjdk.org/jdk/pull/10499/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10499&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294307
  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10499.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10499/head:pull/10499

PR: https://git.openjdk.org/jdk/pull/10499

From svkamath at openjdk.org  Fri Sep 30 00:13:26 2022
From: svkamath at openjdk.org (Smita Kamath)
Date: Fri, 30 Sep 2022 00:13:26 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v8]
In-Reply-To: <m1OYhjDuNDzdJpvJdYw8wxy-GqRRGgTn1nH_tiSVp28=.4073f671-bfad-4778-b823-abca57cb40a6@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com>
 <QdS7Tx2gk2HR7Y-qe6Ig8_QgyGRi5i3k14aERVEHTs4=.b5839efb-e45f-4700-b9d6-7fca6d61cd77@github.com>
 <frb3je6a390Xqi6O21nZc6GVwti4hYcTm0MQZi2EXTk=.56910d50-38bf-4af6-9e16-6766b772b0bd@github.com>
 <m1OYhjDuNDzdJpvJdYw8wxy-GqRRGgTn1nH_tiSVp28=.4073f671-bfad-4778-b823-abca57cb40a6@github.com>
Message-ID: <6q8gs4wdve3OSfdHZsca1jVyt_RxZAvYZTm-Ve8GFtE=.11f0ecfa-9944-44cb-ba8d-d1e231dbb13d@github.com>

On Thu, 29 Sep 2022 18:34:41 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> @vnkozlov I have addressed all review comments. Could you please run the patch through your testing? Thanks a lot for all the help.
>
> @smita-kamath I have builds failures. Please, build and test yourself to verify changes.
> 
> src/hotspot/cpu/x86/assembler_x86.cpp: In member function 'void Assembler::evcvtps2ph(Address, KRegister, XMMRegister, int, int)':
> src/hotspot/cpu/x86/assembler_x86.cpp:1950:15: error: no matching function for call to 'Assembler::emit_operand(XMMRegister&, Address&)'
>  emit_operand(src, dst);

Hi @vnkozlov, I apologize for the inconvenience. However, I don't see any build failures on Windows or Linux. Can you please let me know the platform for which your build fails? Thanks a lot.

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From sviswanathan at openjdk.org  Fri Sep 30 00:19:23 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 30 Sep 2022 00:19:23 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v8]
In-Reply-To: <m1OYhjDuNDzdJpvJdYw8wxy-GqRRGgTn1nH_tiSVp28=.4073f671-bfad-4778-b823-abca57cb40a6@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com>
 <QdS7Tx2gk2HR7Y-qe6Ig8_QgyGRi5i3k14aERVEHTs4=.b5839efb-e45f-4700-b9d6-7fca6d61cd77@github.com>
 <frb3je6a390Xqi6O21nZc6GVwti4hYcTm0MQZi2EXTk=.56910d50-38bf-4af6-9e16-6766b772b0bd@github.com>
 <m1OYhjDuNDzdJpvJdYw8wxy-GqRRGgTn1nH_tiSVp28=.4073f671-bfad-4778-b823-abca57cb40a6@github.com>
Message-ID: <VX0HdkmkRojaD7bkldD-hQyT7J68xs2Rw4wX0zxBIcM=.ded18091-13a1-45b7-bea2-b748e2882f3d@github.com>

On Thu, 29 Sep 2022 18:34:41 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> @vnkozlov I have addressed all review comments. Could you please run the patch through your testing? Thanks a lot for all the help.
>
> @smita-kamath I have builds failures. Please, build and test yourself to verify changes.
> 
> src/hotspot/cpu/x86/assembler_x86.cpp: In member function 'void Assembler::evcvtps2ph(Address, KRegister, XMMRegister, int, int)':
> src/hotspot/cpu/x86/assembler_x86.cpp:1950:15: error: no matching function for call to 'Assembler::emit_operand(XMMRegister&, Address&)'
>  emit_operand(src, dst);

@vnkozlov I also don't see any build issue. I tried creating a dummy draft PR under my fork to get the GHA to run. But looks like now-a-days GHA doesn't run on draft PR.

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From lancea at openjdk.org  Fri Sep 30 00:21:36 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 30 Sep 2022 00:21:36 GMT
Subject: RFR: 8294307: ISO 4217 Amendment 173 Update
In-Reply-To: <LwGHj6uO96npFnZooUdQhkCGynrdTGVsTKW5ogE27nY=.b4b6e06b-fd1f-40f4-bd3a-dca742540e8b@github.com>
References: <LwGHj6uO96npFnZooUdQhkCGynrdTGVsTKW5ogE27nY=.b4b6e06b-fd1f-40f4-bd3a-dca742540e8b@github.com>
Message-ID: <57AQADcwjE5ew8vvvRKjcfW9l5HgzXGaPdEK-T_jC-k=.0b6f11a6-ac0d-44ea-ba92-88312b6d1f29@github.com>

On Thu, 29 Sep 2022 23:19:16 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Amendment number outdated
> 
> Fix: Update amendment number + date in properties file and test case data file

looks good to me

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10499

From lancea at openjdk.org  Fri Sep 30 00:29:17 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 30 Sep 2022 00:29:17 GMT
Subject: RFR: 8294397: Replace StringBuffer with StringBuilder within
 java.text
In-Reply-To: <4-c7dC9feD9vgVdjtLf3rgcmBi6yM2kvYErlwzqvDhQ=.2dce9d38-d3af-4038-8ba9-ce462191ddd1@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <I0pOPJcXxnvEQH4YWOgPUOLAQEwemkWbmOODGTvX9VI=.9bf13cd7-3da9-4698-b3ac-354152acb6d1@github.com>
 <ulkwaHRYr1Z7P9CfNSfpGy3aFKoSTu5Zo4TBPLMKXVU=.abbfd0db-69a5-4984-a0d9-9a2aaae3a882@github.com>
 <4-c7dC9feD9vgVdjtLf3rgcmBi6yM2kvYErlwzqvDhQ=.2dce9d38-d3af-4038-8ba9-ce462191ddd1@github.com>
Message-ID: <K1Her0bg1xAMH_07XqEQqycDK9psBgeedS-guo0ewio=.27ea5945-e599-4c63-aab8-9ac8c0eac6e9@github.com>

On Thu, 29 Sep 2022 22:29:10 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> > Understand, I guess I don't see the difference from moving the tags to the actual test but there could be a subtlety I am missing (wouldn't be the first time ;-) )
> 
> The runner has a @library/@build tag to build the test case as a library for the said reason.

Ok, thanks Naoto

-------------

PR: https://git.openjdk.org/jdk/pull/10475

From ysatowse at openjdk.org  Fri Sep 30 00:36:54 2022
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Fri, 30 Sep 2022 00:36:54 GMT
Subject: RFR: 8294357: (tz) Update Timezone Data to 2022d
Message-ID: <d0VR2DsGI8lvviROr676OVP_uGBkzt1CSrVOGS0l5xY=.8e79029d-ca1d-4c41-acfc-c308395319b3@github.com>

Please review this PR.  The change include some code changes in ZoneInfoFile.java and TestZoneInfo310.java since tzdata2022d breaks TestZoneInfo310.java.

-------------

Commit messages:
 - Added minor changes in comment lines
 - reverting irrelvant change in pom.xml
 - 1st commit for tz2022d

Changes: https://git.openjdk.org/jdk/pull/10460/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10460&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294357
  Stats: 105 lines in 11 files changed: 31 ins; 55 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/10460.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10460/head:pull/10460

PR: https://git.openjdk.org/jdk/pull/10460

From naoto at openjdk.org  Fri Sep 30 00:36:54 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 30 Sep 2022 00:36:54 GMT
Subject: RFR: 8294357: (tz) Update Timezone Data to 2022d
In-Reply-To: <d0VR2DsGI8lvviROr676OVP_uGBkzt1CSrVOGS0l5xY=.8e79029d-ca1d-4c41-acfc-c308395319b3@github.com>
References: <d0VR2DsGI8lvviROr676OVP_uGBkzt1CSrVOGS0l5xY=.8e79029d-ca1d-4c41-acfc-c308395319b3@github.com>
Message-ID: <Ud-PCouqcyoN3FVsKkkuGjcLIXLiuKGkocs0wY9Kuec=.c08af7dc-ced8-42c6-a9fb-72c8c0f0cf33@github.com>

On Wed, 28 Sep 2022 03:40:06 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  The change include some code changes in ZoneInfoFile.java and TestZoneInfo310.java since tzdata2022d breaks TestZoneInfo310.java.

Some minor comments

src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java line 588:

> 586:                     // will not work for Asia/Gaza and Asia/Hebron which follow
> 587:                     // Palestine DST rules.
> 588:                     // No need of hacking for Plaestine DST rules from tz2022d

Should this comment be removed, or at least modified to be better explained?

test/jdk/sun/util/calendar/zi/TestZoneInfo310.java line 201:

> 199:                 zid.equals("Asia/Tehran") || // last rule mismatch
> 200:                 zid.equals("Asia/Gaza") ||
> 201:                 zid.equals("Asia/Hebron") ||

It'd be helpful to append `// uses "Palestine" rule`.

-------------

PR: https://git.openjdk.org/jdk/pull/10460

From darcy at openjdk.org  Fri Sep 30 00:40:24 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 00:40:24 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org
Message-ID: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>

With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.

Updates were made using a shell script. I"ll run a copyright updater before any push.

-------------

Commit messages:
 - JDK-8294618: Update openjdk.java.net => openjdk.org

Changes: https://git.openjdk.org/jdk/pull/10501/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294618
  Stats: 79 lines in 39 files changed: 0 ins; 0 del; 79 mod
  Patch: https://git.openjdk.org/jdk/pull/10501.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501

PR: https://git.openjdk.org/jdk/pull/10501

From smarks at openjdk.org  Fri Sep 30 00:46:25 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 30 Sep 2022 00:46:25 GMT
Subject: RFR: 8279361: Error in documentation of third Stream.reduce method
In-Reply-To: <ZDScXuIYVuxEWWS2YvBff2WIm5IURggmJAJ6d7PQ9r8=.c4e324e0-a0ea-4c85-901e-0f77303b8f24@github.com>
References: <ZDScXuIYVuxEWWS2YvBff2WIm5IURggmJAJ6d7PQ9r8=.c4e324e0-a0ea-4c85-901e-0f77303b8f24@github.com>
Message-ID: <jkAa-p1-tgHJe2NiBOGdTyZRiK27r08-EKiOOOqXF44=.85db430a-f204-4005-b996-97a670853b66@github.com>

On Wed, 28 Sep 2022 15:36:50 GMT, Viktor Klang <duke at openjdk.org> wrote:

> This JavaDoc change attempts to shine some light on the `combiner`-function as it relates to the third variant of `Stream.reduce` since it according to the bug submission in JBS can be confusing that the `combiner` is not mentioned in the code example in the documentation.

One of the problems with pseudo-code is that people can interpret it too literally. Even though we say things like "the result is as if..." it still invites confusion. For example, the proposed chunk code invokes the combiner even in the case where there is only one chunk. However, the clause that follows says:

> In the case where there are less than two chunks, invoking the
> combiner is not needed as there is no merging to be done.

seems to be quasi-normative in that it implies (or does it?) that the combiner _won't_ be called if there is only a single chunk. While that's true of the current implementation, the current spec doesn't guarantee it, and I don't think we want to add such a requirement even though it might be desirable. (At least, we shouldn't add a requirement without good reason.)

So there's still a question of whether or not the combiner is called in sequential cases, and also about its fundamental role in the reduce operation. I've answered a couple Stack Overflow questions on it:

https://stackoverflow.com/questions/24308146/why-is-a-combiner-needed-for-reduce-method-that-converts-type-in-java-8/24316429#24316429

https://stackoverflow.com/questions/29210176/can-a-collectors-combiner-function-ever-be-used-on-sequential-streams/29295055#29295055

(And maybe @amaembo has too. And yes Tagir we're still thinking about ordered reduce or fold operations.)

So maybe a prose description of the splitting and combining process would be preferable. Or possibly a more-pseudo pseudo-code example that doesn't have as much detail, so people don't read into it so much.

-------------

PR: https://git.openjdk.org/jdk/pull/10469

From mikael at openjdk.org  Fri Sep 30 00:54:06 2022
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Fri, 30 Sep 2022 00:54:06 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v2]
In-Reply-To: <0BcqbC6x_sIhKNxYSL9KNDSyLc1UhJEs-DiWe9uTmRg=.4a85ed60-f7cf-4e92-8315-777ab768f8c3@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <0BcqbC6x_sIhKNxYSL9KNDSyLc1UhJEs-DiWe9uTmRg=.4a85ed60-f7cf-4e92-8315-777ab768f8c3@github.com>
Message-ID: <dFUTds1k1M7DaK_xGvMGBDegFeXy76CIcZ_PLh6gYC4=.188412c8-2ca0-42bb-a284-910d88d53422@github.com>

On Fri, 30 Sep 2022 00:50:13 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
>> 
>> Updates were made using a shell script. I"ll run a copyright updater before any push.
>
> Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright.
>  - Revert unintended update to binary file.

Marked as reviewed by mikael (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10501

From mikael at openjdk.org  Fri Sep 30 00:54:08 2022
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Fri, 30 Sep 2022 00:54:08 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <HiyEDr1oKUXjcBsScaiI_yypZx_j0Gxo9erNEub-bRo=.7e0840cb-c2f4-4f5c-8040-20b76298f3cc@github.com>

On Fri, 30 Sep 2022 00:33:57 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

Switch to https where needed/applicable while at it?

-------------

PR: https://git.openjdk.org/jdk/pull/10501

From darcy at openjdk.org  Fri Sep 30 00:54:05 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 00:54:05 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v2]
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <0BcqbC6x_sIhKNxYSL9KNDSyLc1UhJEs-DiWe9uTmRg=.4a85ed60-f7cf-4e92-8315-777ab768f8c3@github.com>

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:

 - Update copyright.
 - Revert unintended update to binary file.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/b12d774f..2f257762

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=00-01

  Stats: 10 lines in 11 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/10501.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501

PR: https://git.openjdk.org/jdk/pull/10501

From darcy at openjdk.org  Fri Sep 30 01:01:29 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 01:01:29 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v3]
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <boxVctVZD3zFCVCc9kH4kEwNs-yE1UY9fP1YMTqCWlc=.171a92b3-ddf2-4e51-b3ec-ae5c5a265487@github.com>

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Undo manpage update.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/2f257762..04dfc3ef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=01-02

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/10501.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501

PR: https://git.openjdk.org/jdk/pull/10501

From darcy at openjdk.org  Fri Sep 30 01:08:12 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 01:08:12 GMT
Subject: RFR: JDK-8294539: Augment discussion of equivlance relations on
 floating-point values
Message-ID: <IFvazBhQBWfMUqr0aTvIJ-P4XyhGx4c93vSUsTjh4bU=.8b32592f-ccbf-437e-ab90-1e0902fd437c@github.com>

While the floating-point == operation is *not* an equivalence relation, there are useful equivalence relations that can be defined over floating-point values. Text is added to java.lang.Double to discuss and name those relations.

-------------

Commit messages:
 - JDK-8294539: Augment discussion of equivlance relations on floating-point values

Changes: https://git.openjdk.org/jdk/pull/10498/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10498&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294539
  Stats: 38 lines in 1 file changed: 37 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10498.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10498/head:pull/10498

PR: https://git.openjdk.org/jdk/pull/10498

From jrose at openjdk.org  Fri Sep 30 01:08:14 2022
From: jrose at openjdk.org (John R Rose)
Date: Fri, 30 Sep 2022 01:08:14 GMT
Subject: RFR: JDK-8294539: Augment discussion of equivlance relations on
 floating-point values
In-Reply-To: <IFvazBhQBWfMUqr0aTvIJ-P4XyhGx4c93vSUsTjh4bU=.8b32592f-ccbf-437e-ab90-1e0902fd437c@github.com>
References: <IFvazBhQBWfMUqr0aTvIJ-P4XyhGx4c93vSUsTjh4bU=.8b32592f-ccbf-437e-ab90-1e0902fd437c@github.com>
Message-ID: <EWh1i0LUe1YGuq7_TExTYf5IgHABVREIB229FtAnJhc=.d43c2b0b-9dcd-4c18-9b22-e2ce29a0eece@github.com>

On Thu, 29 Sep 2022 22:14:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> While the floating-point == operation is *not* an equivalence relation, there are useful equivalence relations that can be defined over floating-point values. Text is added to java.lang.Double to discuss and name those relations.

src/java.base/share/classes/java/lang/Double.java line 157:

> 155:  * Under this relation, {@code +0.0} and {@code -0.0} are distinguished
> 156:  * from each other and every bit pattern encoding a NaN is distinguished
> 157:  * form other bit patterns encoding a NaN.

s/form/from

src/java.base/share/classes/java/lang/Double.java line 180:

> 178:  * of equivalence to test the behavior of {@linkplain StrictMath math
> 179:  * libraries}.
> 180:  * </dd>

This list deserves to include the not-quite-equivalence relation `==`.  Suggest:

 - numerical equivalence
 - {@code +0.0} and {@code -0.0} are equivalent to each other.
 - infinite numbers of the same sign are equivalent to each other

The two floating point numbers represent the same mathematical finite value or signed infinity.

Expressions implementing this ER include `x == y`, `x > y | x < y`, etc.

Numerical equivalence does not apply to NaN, as NaN violates the reflexive property required of all equivalences, but on the domain of all non-NaNs, numerical equivalence is in fact an equivalence relation.

-------------

PR: https://git.openjdk.org/jdk/pull/10498

From darcy at openjdk.org  Fri Sep 30 01:11:45 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 01:11:45 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  http -> https

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/04dfc3ef..cee96d0a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=02-03

  Stats: 22 lines in 6 files changed: 0 ins; 0 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/10501.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501

PR: https://git.openjdk.org/jdk/pull/10501

From darcy at openjdk.org  Fri Sep 30 01:11:45 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 01:11:45 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org
In-Reply-To: <HiyEDr1oKUXjcBsScaiI_yypZx_j0Gxo9erNEub-bRo=.7e0840cb-c2f4-4f5c-8040-20b76298f3cc@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <HiyEDr1oKUXjcBsScaiI_yypZx_j0Gxo9erNEub-bRo=.7e0840cb-c2f4-4f5c-8040-20b76298f3cc@github.com>
Message-ID: <uBCZJHk7h3OFdIKNzXs7DXXlCJUbhiSGt7HZOnDf51Q=.c58467fe-b9cd-4edf-83af-ae99c17c196a@github.com>

On Fri, 30 Sep 2022 00:48:02 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Switch to https where needed/applicable while at it?

Good idea; might as well do the update in a single changeset.

-------------

PR: https://git.openjdk.org/jdk/pull/10501

From darcy at openjdk.org  Fri Sep 30 01:37:10 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 01:37:10 GMT
Subject: RFR: 8293806: JDK_JAVA_OPTIONS picked up twice if LD_LIBRARY_PATH
 is set
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: <inJGt-dp4UAY7vyr36iG9TCPyoAtieU4qd4czgxIu90=.c506a0a8-1ad3-4a29-adca-9e5ccae56025@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.

Years back, I worked on maintaining the launcher. Previously the launcher could re-exec to change data model (e.g. change from 32 to 64 bit on a Solaris environment that supported both options) and to pick a different version.

IIRC, both features were dropped so I would also need some additional context and explanation as it what is being attempted here.

-------------

PR: https://git.openjdk.org/jdk/pull/10430

From sviswanathan at openjdk.org  Fri Sep 30 03:15:32 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 30 Sep 2022 03:15:32 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v8]
In-Reply-To: <m1OYhjDuNDzdJpvJdYw8wxy-GqRRGgTn1nH_tiSVp28=.4073f671-bfad-4778-b823-abca57cb40a6@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com>
 <QdS7Tx2gk2HR7Y-qe6Ig8_QgyGRi5i3k14aERVEHTs4=.b5839efb-e45f-4700-b9d6-7fca6d61cd77@github.com>
 <frb3je6a390Xqi6O21nZc6GVwti4hYcTm0MQZi2EXTk=.56910d50-38bf-4af6-9e16-6766b772b0bd@github.com>
 <m1OYhjDuNDzdJpvJdYw8wxy-GqRRGgTn1nH_tiSVp28=.4073f671-bfad-4778-b823-abca57cb40a6@github.com>
Message-ID: <xi5R9hmey3jw8jHASbCLtq5tU3gGnu77E7w-qavRFRU=.c6cea845-8d8e-4c7d-9004-f0339decf162@github.com>

On Thu, 29 Sep 2022 18:34:41 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> @vnkozlov I have addressed all review comments. Could you please run the patch through your testing? Thanks a lot for all the help.
>
> @smita-kamath I have builds failures. Please, build and test yourself to verify changes.
> 
> src/hotspot/cpu/x86/assembler_x86.cpp: In member function 'void Assembler::evcvtps2ph(Address, KRegister, XMMRegister, int, int)':
> src/hotspot/cpu/x86/assembler_x86.cpp:1950:15: error: no matching function for call to 'Assembler::emit_operand(XMMRegister&, Address&)'
>  emit_operand(src, dst);

@vnkozlov I spoke too soon. All the GHA tests passed in the dummy draft PR I created using Smita's patch:
https://github.com/openjdk/jdk/pull/10500
Please take a look. No build failures reported and all tier1 tests passed.

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From naoto at openjdk.org  Fri Sep 30 03:36:15 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 30 Sep 2022 03:36:15 GMT
Subject: RFR: 8294397: Replace StringBuffer with StringBuilder within
 java.text
In-Reply-To: <K1Her0bg1xAMH_07XqEQqycDK9psBgeedS-guo0ewio=.27ea5945-e599-4c63-aab8-9ac8c0eac6e9@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <I0pOPJcXxnvEQH4YWOgPUOLAQEwemkWbmOODGTvX9VI=.9bf13cd7-3da9-4698-b3ac-354152acb6d1@github.com>
 <ulkwaHRYr1Z7P9CfNSfpGy3aFKoSTu5Zo4TBPLMKXVU=.abbfd0db-69a5-4984-a0d9-9a2aaae3a882@github.com>
 <4-c7dC9feD9vgVdjtLf3rgcmBi6yM2kvYErlwzqvDhQ=.2dce9d38-d3af-4038-8ba9-ce462191ddd1@github.com>
 <K1Her0bg1xAMH_07XqEQqycDK9psBgeedS-guo0ewio=.27ea5945-e599-4c63-aab8-9ac8c0eac6e9@github.com>
Message-ID: <lAFpj8p2EvfLjYgToKW1x82QcaSrqLP1MnBKRymqB_M=.5fcffa24-9c25-4f5f-8c20-1341fead7b94@github.com>

On Fri, 30 Sep 2022 00:25:24 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> > > Understand, I guess I don't see the difference from moving the tags to the actual test but there could be a subtlety I am missing (wouldn't be the first time ;-) )
> > 
> > 
> > The runner has a @library/@build tag to build the test case as a library for the said reason.
> 
> Ok, thanks Naoto

You are correct, Lance. Yes, the wrapper can be removed. Sorry for the confusion.

-------------

PR: https://git.openjdk.org/jdk/pull/10475

From iris at openjdk.org  Fri Sep 30 04:11:19 2022
From: iris at openjdk.org (Iris Clark)
Date: Fri, 30 Sep 2022 04:11:19 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
Message-ID: <nFiCHw9g6IyGbqTuxvar8EhHobplelceRLF1KqsySv0=.5e63a863-e6c0-4f0a-a6cd-c972a0221308@github.com>

On Fri, 30 Sep 2022 01:11:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
>> 
>> Updates were made using a shell script. I"ll run a copyright updater before any push.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   http -> https

Marked as reviewed by iris (Reviewer).

src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 34:

> 32:  * the following link:
> 33:  *
> 34:  * http://hg.openjdk.org/jdk9/jdk9/jdk/raw-file/tip/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c

The domain for hg wasn't changed to openjdk.org.  The original URL is correct.

-------------

PR: https://git.openjdk.org/jdk/pull/10501

From naoto at openjdk.org  Fri Sep 30 04:20:39 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 30 Sep 2022 04:20:39 GMT
Subject: RFR: 8294357: (tz) Update Timezone Data to 2022d
In-Reply-To: <d0VR2DsGI8lvviROr676OVP_uGBkzt1CSrVOGS0l5xY=.8e79029d-ca1d-4c41-acfc-c308395319b3@github.com>
References: <d0VR2DsGI8lvviROr676OVP_uGBkzt1CSrVOGS0l5xY=.8e79029d-ca1d-4c41-acfc-c308395319b3@github.com>
Message-ID: <AyAedAdzSPb37eR0YHi3PV34HeMQFsNJnZNvduK3kys=.8ec5fbc6-faa6-4400-8bec-a9ef93d9caf9@github.com>

On Wed, 28 Sep 2022 03:40:06 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  The change include some code changes in ZoneInfoFile.java and TestZoneInfo310.java since tzdata2022d breaks TestZoneInfo310.java.

test/jdk/java/util/TimeZone/TimeZoneData/displaynames.txt line 170:

> 168: Europe/Vilnius EET EEST
> 169: Europe/Warsaw CET CEST
> 170: Europe/Zaporozhye EET EEST

Do we need to remove those newly linked zone ids from testing?

-------------

PR: https://git.openjdk.org/jdk/pull/10460

From ysatowse at openjdk.org  Fri Sep 30 04:56:30 2022
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Fri, 30 Sep 2022 04:56:30 GMT
Subject: RFR: 8294357: (tz) Update Timezone Data to 2022d
In-Reply-To: <AyAedAdzSPb37eR0YHi3PV34HeMQFsNJnZNvduK3kys=.8ec5fbc6-faa6-4400-8bec-a9ef93d9caf9@github.com>
References: <d0VR2DsGI8lvviROr676OVP_uGBkzt1CSrVOGS0l5xY=.8e79029d-ca1d-4c41-acfc-c308395319b3@github.com>
 <AyAedAdzSPb37eR0YHi3PV34HeMQFsNJnZNvduK3kys=.8ec5fbc6-faa6-4400-8bec-a9ef93d9caf9@github.com>
Message-ID: <q54rfW8kz15BHtjpf_SgCYHxL1iGlNTM8YvkdER9Uwo=.f341d1f7-529d-4dc7-b68b-174831bd4a07@github.com>

On Fri, 30 Sep 2022 04:17:54 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review this PR.  The change include some code changes in ZoneInfoFile.java and TestZoneInfo310.java since tzdata2022d breaks TestZoneInfo310.java.
>
> test/jdk/java/util/TimeZone/TimeZoneData/displaynames.txt line 170:
> 
>> 168: Europe/Vilnius EET EEST
>> 169: Europe/Warsaw CET CEST
>> 170: Europe/Zaporozhye EET EEST
> 
> Do we need to remove those newly linked zone ids from testing?

This file is not maintained by hand but generated from java/util/TimeZone/TimeZoneData/tools/share/Makefile.  
These two Ukraine zones are integrated to Europe/Kyiv and removed from tzdata/europe, so the entries disappeared in this file.

-------------

PR: https://git.openjdk.org/jdk/pull/10460

From joe.darcy at oracle.com  Fri Sep 30 04:41:06 2022
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Thu, 29 Sep 2022 21:41:06 -0700
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <nFiCHw9g6IyGbqTuxvar8EhHobplelceRLF1KqsySv0=.5e63a863-e6c0-4f0a-a6cd-c972a0221308@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
 <nFiCHw9g6IyGbqTuxvar8EhHobplelceRLF1KqsySv0=.5e63a863-e6c0-4f0a-a6cd-c972a0221308@github.com>
Message-ID: <857259f1-daa2-46a0-ded8-24d866482707@oracle.com>

Thanks for catching that Iris; I'll changes those to git URLs.

-Joe

On 9/29/2022 9:11 PM, Iris Clark wrote:
> On Fri, 30 Sep 2022 01:11:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:
>
>>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
>>>
>>> Updates were made using a shell script. I"ll run a copyright updater before any push.
>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    http -> https
> Marked as reviewed by iris (Reviewer).
>
> src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 34:
>
>> 32:  * the following link:
>> 33:  *
>> 34:  * http://hg.openjdk.org/jdk9/jdk9/jdk/raw-file/tip/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c
> The domain for hg wasn't changed to openjdk.org.  The original URL is correct.
>
> -------------
>
> PR: https://git.openjdk.org/jdk/pull/10501

From coffeys at openjdk.org  Fri Sep 30 05:45:07 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 30 Sep 2022 05:45:07 GMT
Subject: RFR: 8294357: (tz) Update Timezone Data to 2022d
In-Reply-To: <d0VR2DsGI8lvviROr676OVP_uGBkzt1CSrVOGS0l5xY=.8e79029d-ca1d-4c41-acfc-c308395319b3@github.com>
References: <d0VR2DsGI8lvviROr676OVP_uGBkzt1CSrVOGS0l5xY=.8e79029d-ca1d-4c41-acfc-c308395319b3@github.com>
Message-ID: <Pg3Rhe2fBD_qIBhL18JqYIpBbcMt2Vt9F-G8UjjZi8Y=.a6b19cbc-a774-41ab-98d0-0e50ae73c03d@github.com>

On Wed, 28 Sep 2022 03:40:06 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  The change include some code changes in ZoneInfoFile.java and TestZoneInfo310.java since tzdata2022d breaks TestZoneInfo310.java.

LGTM

-------------

Marked as reviewed by coffeys (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10460

From alanb at openjdk.org  Fri Sep 30 05:48:18 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 Sep 2022 05:48:18 GMT
Subject: RFR: 8294608: Remove redundant unchecked suppression in
 FileDescriptor
In-Reply-To: <Kaatiu8ZDph6uUog_BHU0jz1cINsm809e7DyH9kB_E0=.830f1c34-1419-4ea4-880a-5f3ea4d3099c@github.com>
References: <Kaatiu8ZDph6uUog_BHU0jz1cINsm809e7DyH9kB_E0=.830f1c34-1419-4ea4-880a-5f3ea4d3099c@github.com>
Message-ID: <sEvCN8xqtSPkGDYuQbrXB2YeE4gcfJOq_wZFcjw5-tw=.9e56431a-14c1-41c5-92e9-d9ff660c6b5f@github.com>

On Wed, 28 Sep 2022 20:39:03 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Found this redundant suppressions by IntelliJ IDEA inspection.
> It seems [JDK-8189330](https://bugs.openjdk.org/browse/JDK-8189330) made them redundant.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10473

From sgehwolf at openjdk.org  Fri Sep 30 08:48:35 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 30 Sep 2022 08:48:35 GMT
Subject: Integrated: 8293540: [Metrics] Incorrectly detected resource limits
 with additional cgroup fs mounts
In-Reply-To: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
References: <Nt25BNxrnb04oAt9CFlg9MTYRAnaUqqoW_xS7OQLwNg=.d4011797-6728-45e9-932d-000934309685@github.com>
Message-ID: <A3aAd8Bk52jpvZ96RQcr3C1gUuSbNnI16NXYvIvURVg=.9f78f1d7-47ef-4ecd-a5bb-11817792e84f@github.com>

On Tue, 13 Sep 2022 13:06:10 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Similar issue to the hotspot change discussed in https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation may get the resource limits wrong if there are additional cgroup fs mounts. Apparently that's more common than one might think. I've reproduced this with these existing tests on cg v2:
> 
> 
> test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java
> test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java
> test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java 
> 
> 
> I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` and amended `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which unconditionally fails (irrespective of cgroup version in use). The fix is fairly straight forward and is an extension which we already do for the `cpuset` controller: Allow duplicates, and if there are any prefer those mounted at `/sys/fs/cgroup`.
> 
> Testing:
> - [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the product fix)
> - [x] added tests fail before, pass after the product fix.
> - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still pass. 
> - [x] GHA all pass.
> 
> Please review! Many thanks in advance.

This pull request has now been integrated.

Changeset: 6d83482a
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6d83482a6b5f1898514fd450d8143dbfef57e362
Stats:     181 lines in 6 files changed: 143 ins; 23 del; 15 mod

8293540: [Metrics] Incorrectly detected resource limits with additional cgroup fs mounts

Reviewed-by: iklam

-------------

PR: https://git.openjdk.org/jdk/pull/10248

From duke at openjdk.org  Fri Sep 30 09:14:08 2022
From: duke at openjdk.org (Viktor Klang)
Date: Fri, 30 Sep 2022 09:14:08 GMT
Subject: RFR: 8279361: Error in documentation of third Stream.reduce method
In-Reply-To: <jkAa-p1-tgHJe2NiBOGdTyZRiK27r08-EKiOOOqXF44=.85db430a-f204-4005-b996-97a670853b66@github.com>
References: <ZDScXuIYVuxEWWS2YvBff2WIm5IURggmJAJ6d7PQ9r8=.c4e324e0-a0ea-4c85-901e-0f77303b8f24@github.com>
 <jkAa-p1-tgHJe2NiBOGdTyZRiK27r08-EKiOOOqXF44=.85db430a-f204-4005-b996-97a670853b66@github.com>
Message-ID: <VAWiLRnwbv4POkGWxB4tNM6c8HuhDRgBALQAAAysGwQ=.23fe47f8-d5e1-4056-90b6-e0b73a1ee975@github.com>

On Fri, 30 Sep 2022 00:44:01 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> This JavaDoc change attempts to shine some light on the `combiner`-function as it relates to the third variant of `Stream.reduce` since it according to the bug submission in JBS can be confusing that the `combiner` is not mentioned in the code example in the documentation.
>
> One of the problems with pseudo-code is that people can interpret it too literally. Even though we say things like "the result is as if..." it still invites confusion. For example, the proposed chunk code invokes the combiner even in the case where there is only one chunk. However, the clause that follows says:
> 
>> In the case where there are less than two chunks, invoking the
>> combiner is not needed as there is no merging to be done.
> 
> seems to be quasi-normative in that it implies (or does it?) that the combiner _won't_ be called if there is only a single chunk. While that's true of the current implementation, the current spec doesn't guarantee it, and I don't think we want to add such a requirement even though it might be desirable. (At least, we shouldn't add a requirement without good reason.)
> 
> So there's still a question of whether or not the combiner is called in sequential cases, and also about its fundamental role in the reduce operation. I've answered a couple Stack Overflow questions on it:
> 
> https://stackoverflow.com/questions/24308146/why-is-a-combiner-needed-for-reduce-method-that-converts-type-in-java-8/24316429#24316429
> 
> https://stackoverflow.com/questions/29210176/can-a-collectors-combiner-function-ever-be-used-on-sequential-streams/29295055#29295055
> 
> (And maybe @amaembo has too. And yes Tagir we're still thinking about ordered reduce or fold operations.)
> 
> So maybe a prose description of the splitting and combining process would be preferable. Or possibly a more-pseudo pseudo-code example that doesn't have as much detail, so people don't read into it so much.

@stuart-marks 

Since there is no contract requiring the use of the `combiner`, all the documentation can say is that "it will be used if the implementation needs it"?which still doesn't answer (deterministically) *when* it will be applied, as even in the parallel case, presuming that the source is small enough not to warrant more than one chunk.

I've taken a couple of stabs at trying to word this in a clear manner, but to be honest, perhaps the most confusion-reducing action is to delete the pseudocode altogether? ?

-------------

PR: https://git.openjdk.org/jdk/pull/10469

From hannesw at openjdk.org  Fri Sep 30 09:59:37 2022
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 30 Sep 2022 09:59:37 GMT
Subject: RFR: JDK-8287597: List all preview features on the javadoc PREVIEW
 page [v5]
In-Reply-To: <0UfKceKzCT3_exJ2vDs5y7IeroB2IHU8kHPO7b46KDY=.bbc662cb-5bd9-4205-acc2-3025ad1a5ab1@github.com>
References: <0UfKceKzCT3_exJ2vDs5y7IeroB2IHU8kHPO7b46KDY=.bbc662cb-5bd9-4205-acc2-3025ad1a5ab1@github.com>
Message-ID: <yubnZ9xfsNenPX-C4lFS1ntQh9mhKNuzTjT--6VXg6U=.06282c09-d2ad-4403-9be7-0f88389952a8@github.com>

> Please review an enhancement to the preview page to add a list of preview features and allow users to explore the preview APIs by feature. 
> 
> While the changes for the enhancement itself are not overly complex, the work entailed a moderate cleanup of other summary API lists (Deprecated and New API pages) as well as a few unrelated summary pages that happened to share some of the CSS classes and HTML structure.
> 
> The change itself starts with a new internal `jdk.internal.javac.PreviewFeature.JEP` annotation interface to add JEP information to the nearby `jdk.internal.javac.PreviewFeature.Feature` enum. This JEP information is retrieved by new methods in the javadoc `Utils` class and then fetched by `PreviewAPIListBuilder` which passes it on to `PreviewListWriter`. 
> 
> The superclass of `PreviewListWriter` and other API summary writer classes, `SummaryListWriter`, gets a new `addContentSelectors(Content)` method to add the checkboxes to show/hide various parts of the page content. The class is also now abstract as this and other methods do not have useful implementations in the base class. 
> 
> Another change to `SummaryListWriter` is that `pageMode`, `description`, `headContent` and `titleKey` are no longer fields in the class but rather sent to the `generateSummaryListFile` method as parameters since they are mostly just used locally in that method. On the other hand, the associated Builder is used in many places and previously had to be retrieved from the configuration object or passed around as parameter, so that is now set as a final field in `SummaryListWriter`. 
> 
> Finally, a few words about changes in CSS and HTML: The "Contents" list containing various kinds of elements in the API list was previously contained in the `<div class="header">` element that also contains the page header, and the stylesheet used the `.header ul`  selector to style the list. Now that the checkboxes separate the page header from the contents list it felt wrong to put all this in the header div (most other pages only use the div for the header itself). I also didn't like the indirect CSS selector too much, `.header ul` is not very indicative of what it applies to.
> 
> I therefore decided to create a new dedicated CSS class for the contents list called `contents-list`, and move the `<ul>` element out of the header div. Apart from the summary API pages, this change also affects the "Constant Values"  page as well as the top and package level "Tree" (class hierarchy) pages. I made sure the contents list in these pages look the same as before.
> 
> The list items in the contents list now each have an `id` attribute to allow hiding the list item if no content for the element kind is currently selected/visible. The value of the `id` attribute uses the format `contents-<element-kind>`.
> 
> There is one additional CSS class called `preview-feature-list` used for the list of preview feature JEPs. 
> 
> Demo output for the new preview page as well as other pages is available here:
> http://cr.openjdk.java.net/~hannesw/8287597/api.03/preview-list.html

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9336/files
  - new: https://git.openjdk.org/jdk/pull/9336/files/94dc98c6..adc469a1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9336&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9336&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9336.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9336/head:pull/9336

PR: https://git.openjdk.org/jdk/pull/9336

From bkilambi at openjdk.org  Fri Sep 30 10:01:27 2022
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Fri, 30 Sep 2022 10:01:27 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v11]
In-Reply-To: <_Ghl2lsnrBhiWvVD3TMiwGo6SfQLl6idczb1QVqLa_I=.7cfa48e2-2987-43e0-a689-0e3462e4d270@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <_Ghl2lsnrBhiWvVD3TMiwGo6SfQLl6idczb1QVqLa_I=.7cfa48e2-2987-43e0-a689-0e3462e4d270@github.com>
Message-ID: <5pqC4k2fyhaYIa9d6D3Dciv2ohYR-JCPvYW7lZsbXhw=.4a3071d6-39b8-4828-86a4-9c3871401844@github.com>

On Wed, 28 Sep 2022 17:40:36 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> 8289552: Make intrinsic conversions between bit representations of half precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comment to update test case

Hi, would you be adding IR tests to verify the generation of the the newly introduced IR nodes?

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From hannesw at openjdk.org  Fri Sep 30 10:02:27 2022
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 30 Sep 2022 10:02:27 GMT
Subject: RFR: JDK-8287597: List all preview features on the javadoc PREVIEW
 page [v4]
In-Reply-To: <qAztQcEGQImXoRmFN56ZAmz7CcqwQ3zXjd8pKyAhRWs=.7bf5d603-c285-4389-9733-e11964fd0c9b@github.com>
References: <0UfKceKzCT3_exJ2vDs5y7IeroB2IHU8kHPO7b46KDY=.bbc662cb-5bd9-4205-acc2-3025ad1a5ab1@github.com>
 <d-6h91d_CUceEHACGegid35NS2lNqSqoWOLPgDfCtkM=.1c4e879f-5860-4fab-b783-07381ffcfd31@github.com>
 <qAztQcEGQImXoRmFN56ZAmz7CcqwQ3zXjd8pKyAhRWs=.7bf5d603-c285-4389-9733-e11964fd0c9b@github.com>
Message-ID: <Ct_lJdnXUKy-ode4YR_lRK93PEsthDftUAEscq_V-N4=.fa117c8d-e0bd-43c7-a12d-0b7b7db9c4a6@github.com>

On Thu, 29 Sep 2022 20:12:43 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix URL in test
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 124:
> 
>> 122: doclet.New_Label=New
>> 123: doclet.Preview_API=Preview API
>> 124: doclet.Preview_API_Checkbox_Label=Show preview API for:
> 
> Should "Preview API" be capitalized as a Proper Noun?

You surely know better about English capitalization rules than me, but I notice that "preview API" is commonly written in lower case, for instance here: https://openjdk.org/jeps/12. I'll leave it like this for now, feel free to raise the issue if you think it should be changed.

-------------

PR: https://git.openjdk.org/jdk/pull/9336

From dfuchs at openjdk.org  Fri Sep 30 10:03:21 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 30 Sep 2022 10:03:21 GMT
Subject: RFR: 8293940: Some tests for virtual threads take too long
In-Reply-To: <T6sXe46wig_0aqViyffF43Ct5sjYJsSHEGkf50dcUI8=.0fc7cf5d-3b94-4c06-8d70-fc7718fb75f4@github.com>
References: <T6sXe46wig_0aqViyffF43Ct5sjYJsSHEGkf50dcUI8=.0fc7cf5d-3b94-4c06-8d70-fc7718fb75f4@github.com>
Message-ID: <7oz2b47gjNAYl3-9Wek4OuVLEHjz0lqhy54PixiMRGQ=.7c884b69-f833-4e45-bb7b-02c72c64536f@github.com>

On Wed, 28 Sep 2022 08:07:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test only change to split the execution of some of the larger tests for virtual threads and reduce the execution time of a few others.
> 
> The tests StructuredTaskScopeTest, ThreadFockTest and ThreadPerTaskExecutorTest contain a lot of tests and run with thread factories for both platform and virtual threads. These tests are changed to run twice, one with the thread factory for platform threads, the other for virtual threads. This allows the tests to run concurrently. A number of sleeps/delays in these tests are adjusted. StructuredTaskScopeTest goes from ~50s to two runs of ~15s. ThreadFockTest goes from 39s to two runs of 15s, ThreadPerTaskExecutorTest goes from 21s to two runs of 8.5. There is more that could be done but these tests are likely to change a bit the APIs evolve so it may not be worth doing now.
> 
> ThreadAPI also contains a lot of tests. A number of tests sleep to give time for a virtual thread to park or block. These sleeps are replaced with a poll of the thread state. A number of other tests are changed to use shorter sleeps. There are a few cleanups that include introducing a number of data providers and using a STPE for delayed actions. Its execution time goes from ~31s to ~12s.
> 
> CloseTest has two tests that sleep 1s and they are run with a data provider that produces six inputs so the sleep time adds up. These lengthy delays aren't needed for testing 
> 
> Finally, some of the stress changes have been changed. The two runs of PingPong are changed so they are in separate @test descriptions and the iteration count on a few tests has been reduced for release builds - the iteration count for debug builds is not changed.

I have gone through the proposed changes and they look reasonable.
I can't comment on the new threshold values which I assume have been obtained from careful experimentation.
If that makes the tests faster and if you checked that they remain stable in the CI then this looks like a good change!

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10463

From qamai at openjdk.org  Fri Sep 30 10:08:33 2022
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 30 Sep 2022 10:08:33 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v11]
In-Reply-To: <_Ghl2lsnrBhiWvVD3TMiwGo6SfQLl6idczb1QVqLa_I=.7cfa48e2-2987-43e0-a689-0e3462e4d270@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <_Ghl2lsnrBhiWvVD3TMiwGo6SfQLl6idczb1QVqLa_I=.7cfa48e2-2987-43e0-a689-0e3462e4d270@github.com>
Message-ID: <P3WD1fmVLCwmvGi1rEyYNJg9vRN0J8JgV8bn4eIHsc4=.186a8e48-1cb9-4e88-b2e2-7ca142fb9163@github.com>

On Wed, 28 Sep 2022 17:40:36 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> 8289552: Make intrinsic conversions between bit representations of half precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comment to update test case

src/hotspot/cpu/x86/x86.ad line 3674:

> 3672: %}
> 3673: 
> 3674: instruct convF2HF_mem_reg(memory mem, regF src, kReg ktmp, rRegI rtmp) %{

You can use `kmovwl` instead which will relax the avx512bw constraint, however, you will need avx512vl for `evcvtps2ph`. Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From hannesw at openjdk.org  Fri Sep 30 10:09:43 2022
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 30 Sep 2022 10:09:43 GMT
Subject: RFR: JDK-8287597: List all preview features on the javadoc PREVIEW
 page [v4]
In-Reply-To: <kV9fIILiBe4R_DWQkSP8Vie4874H9o84-mZsg_zLEm4=.f82bff97-ccaf-496e-be0d-cec06aaa1ebd@github.com>
References: <0UfKceKzCT3_exJ2vDs5y7IeroB2IHU8kHPO7b46KDY=.bbc662cb-5bd9-4205-acc2-3025ad1a5ab1@github.com>
 <d-6h91d_CUceEHACGegid35NS2lNqSqoWOLPgDfCtkM=.1c4e879f-5860-4fab-b783-07381ffcfd31@github.com>
 <kV9fIILiBe4R_DWQkSP8Vie4874H9o84-mZsg_zLEm4=.f82bff97-ccaf-496e-be0d-cec06aaa1ebd@github.com>
Message-ID: <sJtpE6RUb0FS37EUW1jnfqTc36RYtzbd0ifUUN99c80=.e8aca84d-6cd3-4ca0-8ea8-8ad8f2128975@github.com>

On Thu, 29 Sep 2022 21:21:44 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Approved, with a question...
> 
> Looking at the generated output, would it be better to prefix theJEP numbers in the initial list of checkboxes with the word `JEP` ?

That format was suggested by Alex as it is the one used in other places, such as the JDK release page on openjdk.org:  https://openjdk.org/projects/jdk/19/

I'll leave it as it is now, we can always tweak the output in a followup issue.

-------------

PR: https://git.openjdk.org/jdk/pull/9336

From mbaesken at openjdk.org  Fri Sep 30 10:51:53 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Sep 2022 10:51:53 GMT
Subject: RFR: JDK-8293701: jdeps InverseDepsAnalyzer runs into
 NoSuchElementException: No value present [v3]
In-Reply-To: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
References: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
Message-ID: <uZcnYBHyBXqeRaeNzPmB4rxNjZUuyd6iHou9YGddxC0=.49777030-f05e-46d6-952c-1f127da597b2@github.com>

> We noticed that with certain jar file input, jdeps runs into the following exception, this happens with jdk11, 17 and 20.
> 
> jdeps.exe --multi-release 11 --module-path . --inverse --package com.sap.nw.performance.supa.client test.jar
> 
> Inverse transitive dependences matching packages [com.sap.nw.performance.supa.client]
> Exception in thread "main" java.util.NoSuchElementException: No value present
>         at java.base/java.util.Optional.get(Optional.java:148)
>         at jdk.jdeps/com.sun.tools.jdeps.InverseDepsAnalyzer.lambda$inverseDependences$2(InverseDepsAnalyzer.java:150)
>         at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>         at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>         at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
>         at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>         at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> 
> So an additional  check might be a good idea.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Adjust test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10300/files
  - new: https://git.openjdk.org/jdk/pull/10300/files/42b1339d..3c2f0938

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10300&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10300&range=01-02

  Stats: 9 lines in 2 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/10300.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10300/head:pull/10300

PR: https://git.openjdk.org/jdk/pull/10300

From mbaesken at openjdk.org  Fri Sep 30 10:51:54 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Sep 2022 10:51:54 GMT
Subject: RFR: JDK-8293701: jdeps InverseDepsAnalyzer runs into
 NoSuchElementException: No value present [v2]
In-Reply-To: <eQbbxiOC4eXZOrUsn2hH_XKQkly61CnYudE-AkiEB9w=.0ebafb1f-e446-4349-8e0f-de47d963921a@github.com>
References: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
 <eQbbxiOC4eXZOrUsn2hH_XKQkly61CnYudE-AkiEB9w=.0ebafb1f-e446-4349-8e0f-de47d963921a@github.com>
Message-ID: <Hdlc248VlyLWlhMQ8tiq9nrvyOhAswLNddvLJpX786Y=.ff09f729-63ec-4bc9-b6e7-5a7087340bc4@github.com>

On Thu, 29 Sep 2022 16:05:44 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We noticed that with certain jar file input, jdeps runs into the following exception, this happens with jdk11, 17 and 20.
>> 
>> jdeps.exe --multi-release 11 --module-path . --inverse --package com.sap.nw.performance.supa.client test.jar
>> 
>> Inverse transitive dependences matching packages [com.sap.nw.performance.supa.client]
>> Exception in thread "main" java.util.NoSuchElementException: No value present
>>         at java.base/java.util.Optional.get(Optional.java:148)
>>         at jdk.jdeps/com.sun.tools.jdeps.InverseDepsAnalyzer.lambda$inverseDependences$2(InverseDepsAnalyzer.java:150)
>>         at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>>         at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>>         at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
>>         at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>>         at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
>> 
>> So an additional  check might be a good idea.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust check, add test

Hi Mandy, I adjusted the indentation and renamed and adjusted the test.
Especially I removed the  --add-modules m3  from the test because it is not necessary any more.

-------------

PR: https://git.openjdk.org/jdk/pull/10300

From qamai at openjdk.org  Fri Sep 30 11:05:08 2022
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 30 Sep 2022 11:05:08 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v8]
In-Reply-To: <xi5R9hmey3jw8jHASbCLtq5tU3gGnu77E7w-qavRFRU=.c6cea845-8d8e-4c7d-9004-f0339decf162@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com>
 <QdS7Tx2gk2HR7Y-qe6Ig8_QgyGRi5i3k14aERVEHTs4=.b5839efb-e45f-4700-b9d6-7fca6d61cd77@github.com>
 <frb3je6a390Xqi6O21nZc6GVwti4hYcTm0MQZi2EXTk=.56910d50-38bf-4af6-9e16-6766b772b0bd@github.com>
 <m1OYhjDuNDzdJpvJdYw8wxy-GqRRGgTn1nH_tiSVp28=.4073f671-bfad-4778-b823-abca57cb40a6@github.com>
 <xi5R9hmey3jw8jHASbCLtq5tU3gGnu77E7w-qavRFRU=.c6cea845-8d8e-4c7d-9004-f0339decf162@github.com>
Message-ID: <xtR8QzysTx1o-8KxGvJrnBGmCLaHCFl41a1C9ivnU9A=.4c9b89e5-7687-42de-8aac-023c5bdaa75e@github.com>

On Fri, 30 Sep 2022 03:13:09 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> @smita-kamath I have builds failures. Please, build and test yourself to verify changes.
>> 
>> src/hotspot/cpu/x86/assembler_x86.cpp: In member function 'void Assembler::evcvtps2ph(Address, KRegister, XMMRegister, int, int)':
>> src/hotspot/cpu/x86/assembler_x86.cpp:1950:15: error: no matching function for call to 'Assembler::emit_operand(XMMRegister&, Address&)'
>>  emit_operand(src, dst);
>
> @vnkozlov I spoke too soon. All the GHA tests passed in the dummy draft PR I created using Smita's patch:
> https://github.com/openjdk/jdk/pull/10500
> Please take a look. No build failures reported and all tier1 tests passed.

@sviswa7 The failure is due to [JDK-8293618](https://bugs.openjdk.org/browse/JDK-8293618), @smita-kamath  please merge with master. Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From hannesw at openjdk.org  Fri Sep 30 11:15:30 2022
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 30 Sep 2022 11:15:30 GMT
Subject: Integrated: JDK-8287597: List all preview features on the javadoc
 PREVIEW page
In-Reply-To: <0UfKceKzCT3_exJ2vDs5y7IeroB2IHU8kHPO7b46KDY=.bbc662cb-5bd9-4205-acc2-3025ad1a5ab1@github.com>
References: <0UfKceKzCT3_exJ2vDs5y7IeroB2IHU8kHPO7b46KDY=.bbc662cb-5bd9-4205-acc2-3025ad1a5ab1@github.com>
Message-ID: <AqH9XBEJAGTjJECWJ8KdYwAcXYeS_g22Qvh6a_tNaXw=.cacac9bb-e338-4b1c-bbb9-921e8f888ad7@github.com>

On Thu, 30 Jun 2022 15:14:40 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review an enhancement to the preview page to add a list of preview features and allow users to explore the preview APIs by feature. 
> 
> While the changes for the enhancement itself are not overly complex, the work entailed a moderate cleanup of other summary API lists (Deprecated and New API pages) as well as a few unrelated summary pages that happened to share some of the CSS classes and HTML structure.
> 
> The change itself starts with a new internal `jdk.internal.javac.PreviewFeature.JEP` annotation interface to add JEP information to the nearby `jdk.internal.javac.PreviewFeature.Feature` enum. This JEP information is retrieved by new methods in the javadoc `Utils` class and then fetched by `PreviewAPIListBuilder` which passes it on to `PreviewListWriter`. 
> 
> The superclass of `PreviewListWriter` and other API summary writer classes, `SummaryListWriter`, gets a new `addContentSelectors(Content)` method to add the checkboxes to show/hide various parts of the page content. The class is also now abstract as this and other methods do not have useful implementations in the base class. 
> 
> Another change to `SummaryListWriter` is that `pageMode`, `description`, `headContent` and `titleKey` are no longer fields in the class but rather sent to the `generateSummaryListFile` method as parameters since they are mostly just used locally in that method. On the other hand, the associated Builder is used in many places and previously had to be retrieved from the configuration object or passed around as parameter, so that is now set as a final field in `SummaryListWriter`. 
> 
> Finally, a few words about changes in CSS and HTML: The "Contents" list containing various kinds of elements in the API list was previously contained in the `<div class="header">` element that also contains the page header, and the stylesheet used the `.header ul`  selector to style the list. Now that the checkboxes separate the page header from the contents list it felt wrong to put all this in the header div (most other pages only use the div for the header itself). I also didn't like the indirect CSS selector too much, `.header ul` is not very indicative of what it applies to.
> 
> I therefore decided to create a new dedicated CSS class for the contents list called `contents-list`, and move the `<ul>` element out of the header div. Apart from the summary API pages, this change also affects the "Constant Values"  page as well as the top and package level "Tree" (class hierarchy) pages. I made sure the contents list in these pages look the same as before.
> 
> The list items in the contents list now each have an `id` attribute to allow hiding the list item if no content for the element kind is currently selected/visible. The value of the `id` attribute uses the format `contents-<element-kind>`.
> 
> There is one additional CSS class called `preview-feature-list` used for the list of preview feature JEPs. 
> 
> Demo output for the new preview page as well as other pages is available here:
> http://cr.openjdk.java.net/~hannesw/8287597/api.03/preview-list.html

This pull request has now been integrated.

Changeset: 64da8620
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/64da8620e154e0fe556c7b82547915595d014188
Stats:     466 lines in 24 files changed: 295 ins; 66 del; 105 mod

8287597: List all preview features on the javadoc PREVIEW page

Reviewed-by: jjg

-------------

PR: https://git.openjdk.org/jdk/pull/9336

From kevin.rushforth at oracle.com  Fri Sep 30 12:29:20 2022
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 30 Sep 2022 05:29:20 -0700
Subject: professional (24-bit) sampled audio support in the Windows native
 implementation of libjsound
In-Reply-To: <02e901d8d4c0$7dd12ee0$79738ca0$@gmail.com>
References: <02e901d8d4c0$7dd12ee0$79738ca0$@gmail.com>
Message-ID: <506f19c5-28ae-e606-e7f1-22464793afcb@oracle.com>

Java Sound is in the client-libs area. You can file the bug yourself at 
https://bugreport.java.com/ if you like, or ask the sponsor of your bug 
(when one steps forward) to do it.

If you want to contribute your fix, please see the contributing a patch 
section [1] in the JDK Developers Guide for the next steps.

-- Kevin

[1] https://openjdk.org/guide/#i-have-a-patch-what-do-i-do


On 9/30/2022 4:33 AM, magare31 at gmail.com wrote:
>
> Would anyone want to sponsor the following simple bug fix?
>
> - The purpose is to enable playback and recording of 24-bit sampled 
> audio on Windows.? This is already supported on other systems.
>
> - There is no associated bug in the bug database.? I noted it as a 
> "bug" as the code misunderstands the WAVE RIFF format standards.
>
> - There will be two very small changes to one Windows native cpp file 
> under libjsound
>
> - I have tested the changes on a jdk build of the latest code.
>
> Also, please advise which of these two groups this belongs to: client 
> libs or core libs?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220930/a6d05e08/attachment-0001.htm>

From naoto at openjdk.org  Fri Sep 30 12:46:17 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 30 Sep 2022 12:46:17 GMT
Subject: RFR: 8294357: (tz) Update Timezone Data to 2022d
In-Reply-To: <d0VR2DsGI8lvviROr676OVP_uGBkzt1CSrVOGS0l5xY=.8e79029d-ca1d-4c41-acfc-c308395319b3@github.com>
References: <d0VR2DsGI8lvviROr676OVP_uGBkzt1CSrVOGS0l5xY=.8e79029d-ca1d-4c41-acfc-c308395319b3@github.com>
Message-ID: <y1vih96QjE9A2a5HuLNVRMiLu6GgYncxrq3FEnSxUBw=.5daa91f6-4bf0-40e0-877e-d19ee93f9a6f@github.com>

On Wed, 28 Sep 2022 03:40:06 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  The change include some code changes in ZoneInfoFile.java and TestZoneInfo310.java since tzdata2022d breaks TestZoneInfo310.java.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10460

From naoto at openjdk.org  Fri Sep 30 12:46:19 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 30 Sep 2022 12:46:19 GMT
Subject: RFR: 8294357: (tz) Update Timezone Data to 2022d
In-Reply-To: <q54rfW8kz15BHtjpf_SgCYHxL1iGlNTM8YvkdER9Uwo=.f341d1f7-529d-4dc7-b68b-174831bd4a07@github.com>
References: <d0VR2DsGI8lvviROr676OVP_uGBkzt1CSrVOGS0l5xY=.8e79029d-ca1d-4c41-acfc-c308395319b3@github.com>
 <AyAedAdzSPb37eR0YHi3PV34HeMQFsNJnZNvduK3kys=.8ec5fbc6-faa6-4400-8bec-a9ef93d9caf9@github.com>
 <q54rfW8kz15BHtjpf_SgCYHxL1iGlNTM8YvkdER9Uwo=.f341d1f7-529d-4dc7-b68b-174831bd4a07@github.com>
Message-ID: <WbJ6usbWjyaTYL8QSbXYhPhURoCpljE-sFpIfTG99I8=.5b850f4b-872d-41a0-8557-a34b865d2ad9@github.com>

On Fri, 30 Sep 2022 04:54:27 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> test/jdk/java/util/TimeZone/TimeZoneData/displaynames.txt line 170:
>> 
>>> 168: Europe/Vilnius EET EEST
>>> 169: Europe/Warsaw CET CEST
>>> 170: Europe/Zaporozhye EET EEST
>> 
>> Do we need to remove those newly linked zone ids from testing?
>
> This file is not maintained by hand but generated from java/util/TimeZone/TimeZoneData/tools/share/Makefile.  
> These two Ukraine zones are integrated to Europe/Kyiv and removed from tzdata/europe, so the entries disappeared in this file.

OK. It's a bit odd that the links are removed for the test because they still exist as zone ids, and should have the same name as `Europe/Kyiv`.

-------------

PR: https://git.openjdk.org/jdk/pull/10460

From ysatowse at openjdk.org  Fri Sep 30 12:49:20 2022
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Fri, 30 Sep 2022 12:49:20 GMT
Subject: Integrated: 8294357: (tz) Update Timezone Data to 2022d
In-Reply-To: <d0VR2DsGI8lvviROr676OVP_uGBkzt1CSrVOGS0l5xY=.8e79029d-ca1d-4c41-acfc-c308395319b3@github.com>
References: <d0VR2DsGI8lvviROr676OVP_uGBkzt1CSrVOGS0l5xY=.8e79029d-ca1d-4c41-acfc-c308395319b3@github.com>
Message-ID: <GWvkSe-WnZ0EWgds_kCyuNnyaYmeMms0zzfZMshVZqg=.d0040a44-0746-49e7-a38d-3f316d198ef4@github.com>

On Wed, 28 Sep 2022 03:40:06 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  The change include some code changes in ZoneInfoFile.java and TestZoneInfo310.java since tzdata2022d breaks TestZoneInfo310.java.

This pull request has now been integrated.

Changeset: f0157336
Author:    Yoshiki Sato <ysatowse at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f01573368f905f27d26f1d07d9cfd26dcc736a54
Stats:     105 lines in 11 files changed: 31 ins; 55 del; 19 mod

8294357: (tz) Update Timezone Data to 2022d

Reviewed-by: naoto, coffeys

-------------

PR: https://git.openjdk.org/jdk/pull/10460

From dsamersoff at openjdk.org  Fri Sep 30 12:56:20 2022
From: dsamersoff at openjdk.org (Dmitry Samersoff)
Date: Fri, 30 Sep 2022 12:56:20 GMT
Subject: RFR: 8293806: JDK_JAVA_OPTIONS picked up twice if LD_LIBRARY_PATH
 is set
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: <Ngug_uJlyTYFE1p3EtyaLpDOYRtQvcl2AkZxLGbqBqA=.e00ef1cd-cb3c-442a-8a07-d9839dcdfcfd@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.

_I updated description in the CR, https://bugs.openjdk.org/browse/JDK-8293806 but for convenience copy it here. Also, I added some debug output to the comments for CR_

Under some circumstances, the launcher have to update LD_LIBRARY_PATH, but the runtime linker only considers this variable during application startup, so after updating LD_LIBRARY_PATH the launcher must re-execute it self by calling execvp().

The decision to re-launch is made after all options from all sources (JDK_JAVA_OPTIONS, @argfile) already been processed and copied to argv[] array. Thus, parameters passed through JDK_JAVA_OPTIONS variable are processed twice.

If an option cannot be accepted twice (e.g., -agentlib), the application fails to start.

We cannot just remove the JDK_JAVA_OPTIONS variable because some applications (e.g. IDEs) use it to pass user parameters through the chain of child java processes.

It happens under following conditions:

1. Under MUSL libc launcher have to set LD_LIBRARY_PATH to resolve dependency between libjava and libjvm
2. On AIX launcher have to set LD_LIBRARY_PATH because the runtime linker doesn't support $ORIGIN
3. User set LD_LIBRARY_PATH variable to some location containing libjvm.so. According to comment in java_md.c, LD_LIBRARY_PATH have to be updated to avoid recursion.

-------------

PR: https://git.openjdk.org/jdk/pull/10430

From duke at openjdk.org  Fri Sep 30 13:52:36 2022
From: duke at openjdk.org (Eivind =?UTF-8?B?QmVyZ3N0w7hs?=)
Date: Fri, 30 Sep 2022 13:52:36 GMT
Subject: RFR: 8282227: Locale information for nb is not working properly
In-Reply-To: <nc9aTrJt7qhdTHUyVtXcMdGmObgLs7-s-57ehuVWxlo=.30ec889f-ea60-4343-b756-862542ed9630@github.com>
References: <nc9aTrJt7qhdTHUyVtXcMdGmObgLs7-s-57ehuVWxlo=.30ec889f-ea60-4343-b756-862542ed9630@github.com>
Message-ID: <D2QYXTtITb4HrMLQH5Jj56hAwS6hiqc1wM2fv2GQ9lU=.fd177356-bfb3-4410-8ab1-4c1e960c32f3@github.com>

On Tue, 26 Apr 2022 00:32:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This was caused by incorporating CLDR v39, which switched the Norwegian locale inheritance from `no` -> `nb` to `nb` ->`no` and moved the resources from `nb` to `no`, which now contradicts Java's locale fallback. Explicitly inheriting `no` from `nb` will fix the issue.

Will this fix make its way back to java 17?

-------------

PR: https://git.openjdk.org/jdk/pull/8394

From ihse at openjdk.org  Fri Sep 30 14:01:18 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 30 Sep 2022 14:01:18 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
Message-ID: <eCjWYSRQB0sC2mcoavSzqTGOt7Tw5GdAKAqnDRmq07A=.f8403857-eb3a-4069-940a-a4414a8b83e8@github.com>

On Fri, 30 Sep 2022 01:11:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
>> 
>> Updates were made using a shell script. I"ll run a copyright updater before any push.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   http -> https

$ grep -rl doc make -e openjdk.java.net
doc/hotspot-unit-tests.html
doc/hotspot-style.html
doc/building.html
doc/hotspot-unit-tests.md
doc/hotspot-style.md
doc/building.md
make/Doctor.gmk
make/jdk/src/classes/build/tools/taglet/Incubating.java
make/autoconf/configure.ac
make/conf/branding.conf


Think you can fix those as well?

Also, FWIW, there are 100+ hits in `test` as well. But that is so many it might warrant a separate PR..?

-------------

PR: https://git.openjdk.org/jdk/pull/10501

From weijun at openjdk.org  Fri Sep 30 14:18:28 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 30 Sep 2022 14:18:28 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <nFiCHw9g6IyGbqTuxvar8EhHobplelceRLF1KqsySv0=.5e63a863-e6c0-4f0a-a6cd-c972a0221308@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
 <nFiCHw9g6IyGbqTuxvar8EhHobplelceRLF1KqsySv0=.5e63a863-e6c0-4f0a-a6cd-c972a0221308@github.com>
Message-ID: <eM7WMgB7uVvIw-lqL8AzCf6zG-Xz6UUQQPibY5hRn6A=.80c398cb-9d26-4b94-b73c-50c85e438730@github.com>

On Fri, 30 Sep 2022 04:05:51 GMT, Iris Clark <iris at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   http -> https
>
> src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 34:
> 
>> 32:  * the following link:
>> 33:  *
>> 34:  * http://hg.openjdk.org/jdk9/jdk9/jdk/raw-file/tip/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c
> 
> The domain for hg wasn't changed to openjdk.org.  The original URL is correct.

Why do we need to link to a URL? Why not `../../bridge/AccessBridgeCalls.c`?

-------------

PR: https://git.openjdk.org/jdk/pull/10501

From bpb at openjdk.org  Fri Sep 30 14:57:23 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 30 Sep 2022 14:57:23 GMT
Subject: RFR: 8294307: ISO 4217 Amendment 173 Update
In-Reply-To: <LwGHj6uO96npFnZooUdQhkCGynrdTGVsTKW5ogE27nY=.b4b6e06b-fd1f-40f4-bd3a-dca742540e8b@github.com>
References: <LwGHj6uO96npFnZooUdQhkCGynrdTGVsTKW5ogE27nY=.b4b6e06b-fd1f-40f4-bd3a-dca742540e8b@github.com>
Message-ID: <XSXpq-6ATmG-dljbyL95rhbxhHoMF-dw5M9z4XIx1kk=.629424cb-24c4-4e1d-afab-1a6461816726@github.com>

On Thu, 29 Sep 2022 23:19:16 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Amendment number outdated
> 
> Fix: Update amendment number + date in properties file and test case data file

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10499

From bpb at openjdk.org  Fri Sep 30 15:01:25 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 30 Sep 2022 15:01:25 GMT
Subject: RFR: 8294608: Remove redundant unchecked suppression in
 FileDescriptor
In-Reply-To: <Kaatiu8ZDph6uUog_BHU0jz1cINsm809e7DyH9kB_E0=.830f1c34-1419-4ea4-880a-5f3ea4d3099c@github.com>
References: <Kaatiu8ZDph6uUog_BHU0jz1cINsm809e7DyH9kB_E0=.830f1c34-1419-4ea4-880a-5f3ea4d3099c@github.com>
Message-ID: <4g5ofGEux87r1PRiSsbUuVNH5Plq1yi8BUibBYM3F7Y=.cc2c585c-8288-4ce9-8832-f2f8e8326142@github.com>

On Wed, 28 Sep 2022 20:39:03 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Found this redundant suppressions by IntelliJ IDEA inspection.
> It seems [JDK-8189330](https://bugs.openjdk.org/browse/JDK-8189330) made them redundant.

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10473

From duke at openjdk.org  Fri Sep 30 16:18:28 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 30 Sep 2022 16:18:28 GMT
Subject: RFR: 8294397: Replace StringBuffer with StringBuilder within
 java.text [v3]
In-Reply-To: <7R_FJi6DYp4rE7nHNvpW6LPOsa5L_e7ul1ii1t8QeIA=.a8628f49-e0ce-41ee-8c7e-4e8f7faf983e@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <xrmZ8iFlP7a0nxPA63ytSX4LMbwfX74Ql5LLmQ2MBpg=.a71088ce-2541-4151-a765-2badff8d6f86@github.com>
 <7R_FJi6DYp4rE7nHNvpW6LPOsa5L_e7ul1ii1t8QeIA=.a8628f49-e0ce-41ee-8c7e-4e8f7faf983e@github.com>
Message-ID: <tc5rcYHhEMUUnxTi7Mxsr1oeEZfSp5lCwO_d-J_DN9s=.6d770e42-75cd-4b27-b5b4-06bfc50e5b87@github.com>

On Thu, 29 Sep 2022 22:29:43 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tweak indentation in PaternEntry
>
> src/java.base/share/classes/java/text/PatternEntry.java line 291:
> 
>> 289:         // We re-use these objects in order to improve performance
>> 290:         private StringBuilder newChars = new StringBuilder();
>> 291:         private StringBuilder newExtension = new StringBuilder();
> 
> Again, in 2022, I don't know that this cache+reuse pattern is needed for performance.

Due to some [bootstrapping issues](https://stackoverflow.com/questions/71834059/why-invokedynamic-based-string-concatenation-is-not-available-for-javac-in-java) in `java.base` explicit String concatenation is not translated into invokedynamic, so in practice it's faster to use `StringBuilder.append()` than `str1 + str2`, see e.g. https://github.com/openjdk/jdk/pull/3903

-------------

PR: https://git.openjdk.org/jdk/pull/10475

From naoto at openjdk.org  Fri Sep 30 16:30:42 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 30 Sep 2022 16:30:42 GMT
Subject: RFR: 8294307: ISO 4217 Amendment 173 Update
In-Reply-To: <LwGHj6uO96npFnZooUdQhkCGynrdTGVsTKW5ogE27nY=.b4b6e06b-fd1f-40f4-bd3a-dca742540e8b@github.com>
References: <LwGHj6uO96npFnZooUdQhkCGynrdTGVsTKW5ogE27nY=.b4b6e06b-fd1f-40f4-bd3a-dca742540e8b@github.com>
Message-ID: <bZmqEoNm0_k288-BbsAEw0eu24BxgcagCTPX7HhFoAk=.8015e2a7-fcc8-4f89-9844-af0de61435a6@github.com>

On Thu, 29 Sep 2022 23:19:16 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Amendment number outdated
> 
> Fix: Update amendment number + date in properties file and test case data file

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10499

From mchung at openjdk.org  Fri Sep 30 16:31:51 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 30 Sep 2022 16:31:51 GMT
Subject: RFR: JDK-8293701: jdeps InverseDepsAnalyzer runs into
 NoSuchElementException: No value present [v3]
In-Reply-To: <uZcnYBHyBXqeRaeNzPmB4rxNjZUuyd6iHou9YGddxC0=.49777030-f05e-46d6-952c-1f127da597b2@github.com>
References: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
 <uZcnYBHyBXqeRaeNzPmB4rxNjZUuyd6iHou9YGddxC0=.49777030-f05e-46d6-952c-1f127da597b2@github.com>
Message-ID: <WGbFa-Ff8vEBaTkIN_akLyvPDI3Kpm9zGW5LYhIKnow=.f735cfd4-5c13-466c-8be3-a16590e7a4be@github.com>

On Fri, 30 Sep 2022 10:51:53 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We noticed that with certain jar file input, jdeps runs into the following exception, this happens with jdk11, 17 and 20.
>> 
>> jdeps.exe --multi-release 11 --module-path . --inverse --package com.sap.nw.performance.supa.client test.jar
>> 
>> Inverse transitive dependences matching packages [com.sap.nw.performance.supa.client]
>> Exception in thread "main" java.util.NoSuchElementException: No value present
>>         at java.base/java.util.Optional.get(Optional.java:148)
>>         at jdk.jdeps/com.sun.tools.jdeps.InverseDepsAnalyzer.lambda$inverseDependences$2(InverseDepsAnalyzer.java:150)
>>         at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>>         at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>>         at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
>>         at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>>         at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
>> 
>> So an additional  check might be a good idea.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust test

test/langtools/tools/jdeps/optionalDependency/OptionalDependencyTest.java line 73:

> 71:      */
> 72:     @Test
> 73:     public void optionalDependenceResolved() {

Since you removed `--add-modules m3` is removed, this test case is `OptionalDependenceNotResolved`.    Although the bug only happens if m3 is not resolved in the configuration,  a test case to resolve m3 (with `--add-modules m3`) is for completeness and also helps future debugging in case any of these cases was broken.

-------------

PR: https://git.openjdk.org/jdk/pull/10300

From alanb at openjdk.org  Fri Sep 30 16:45:03 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 Sep 2022 16:45:03 GMT
Subject: Integrated: 8293940: Some tests for virtual threads take too long
In-Reply-To: <T6sXe46wig_0aqViyffF43Ct5sjYJsSHEGkf50dcUI8=.0fc7cf5d-3b94-4c06-8d70-fc7718fb75f4@github.com>
References: <T6sXe46wig_0aqViyffF43Ct5sjYJsSHEGkf50dcUI8=.0fc7cf5d-3b94-4c06-8d70-fc7718fb75f4@github.com>
Message-ID: <BQUI3HaClG_0I0bvFPecIEfygdXGH4zuBSgFeKdJgKk=.a467efab-86bd-4ce9-8717-a7c569d55281@github.com>

On Wed, 28 Sep 2022 08:07:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test only change to split the execution of some of the larger tests for virtual threads and reduce the execution time of a few others.
> 
> The tests StructuredTaskScopeTest, ThreadFockTest and ThreadPerTaskExecutorTest contain a lot of tests and run with thread factories for both platform and virtual threads. These tests are changed to run twice, one with the thread factory for platform threads, the other for virtual threads. This allows the tests to run concurrently. A number of sleeps/delays in these tests are adjusted. StructuredTaskScopeTest goes from ~50s to two runs of ~15s. ThreadFockTest goes from 39s to two runs of 15s, ThreadPerTaskExecutorTest goes from 21s to two runs of 8.5. There is more that could be done but these tests are likely to change a bit the APIs evolve so it may not be worth doing now.
> 
> ThreadAPI also contains a lot of tests. A number of tests sleep to give time for a virtual thread to park or block. These sleeps are replaced with a poll of the thread state. A number of other tests are changed to use shorter sleeps. There are a few cleanups that include introducing a number of data providers and using a STPE for delayed actions. Its execution time goes from ~31s to ~12s.
> 
> CloseTest has two tests that sleep 1s and they are run with a data provider that produces six inputs so the sleep time adds up. These lengthy delays aren't needed for testing 
> 
> Finally, some of the stress changes have been changed. The two runs of PingPong are changed so they are in separate @test descriptions and the iteration count on a few tests has been reduced for release builds - the iteration count for debug builds is not changed.

This pull request has now been integrated.

Changeset: b8f9a915
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b8f9a915a2bfd0f7920ecfc5b3a08670df5f9f3e
Stats:     459 lines in 11 files changed: 162 ins; 96 del; 201 mod

8293940: Some tests for virtual threads take too long

Reviewed-by: dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/10463

From jwaters at openjdk.org  Fri Sep 30 16:47:25 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 30 Sep 2022 16:47:25 GMT
Subject: RFR: 8292016: Split Windows API error handling from errors passed
 through the runtime in the JDK [v25]
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <I4hOHCRmwozd1v_R03UEPUZbBaqbOpgawo2-vdhtev8=.ed1a71bc-3486-4f94-a315-116bd39260d5@github.com>

> EDIT: Cave and add the ErrorOrigin enum, to differentiate which error type the error reporting functions in libjava will look up. RUNTIME refers to errors passed through the runtime via errno, and SYSTEM is for native errors not visible to the runtime.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Progress

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9870/files
  - new: https://git.openjdk.org/jdk/pull/9870/files/00c955ee..ea8678b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=23-24

  Stats: 79 lines in 6 files changed: 67 ins; 3 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From bchristi at openjdk.org  Fri Sep 30 16:56:20 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 30 Sep 2022 16:56:20 GMT
Subject: RFR: 8294397: Replace StringBuffer with StringBuilder within
 java.text [v3]
In-Reply-To: <tc5rcYHhEMUUnxTi7Mxsr1oeEZfSp5lCwO_d-J_DN9s=.6d770e42-75cd-4b27-b5b4-06bfc50e5b87@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <xrmZ8iFlP7a0nxPA63ytSX4LMbwfX74Ql5LLmQ2MBpg=.a71088ce-2541-4151-a765-2badff8d6f86@github.com>
 <7R_FJi6DYp4rE7nHNvpW6LPOsa5L_e7ul1ii1t8QeIA=.a8628f49-e0ce-41ee-8c7e-4e8f7faf983e@github.com>
 <tc5rcYHhEMUUnxTi7Mxsr1oeEZfSp5lCwO_d-J_DN9s=.6d770e42-75cd-4b27-b5b4-06bfc50e5b87@github.com>
Message-ID: <z8HUkpBrbxW8--Em1sgnTG29-sTk6ruQRn4ck182Gus=.b69f830a-12c9-4ef8-adbf-ea46346e4d1d@github.com>

On Fri, 30 Sep 2022 16:14:38 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/PatternEntry.java line 291:
>> 
>>> 289:         // We re-use these objects in order to improve performance
>>> 290:         private StringBuilder newChars = new StringBuilder();
>>> 291:         private StringBuilder newExtension = new StringBuilder();
>> 
>> Again, in 2022, I don't know that this cache+reuse pattern is needed for performance.
>
> Due to some [bootstrapping issues](https://stackoverflow.com/questions/71834059/why-invokedynamic-based-string-concatenation-is-not-available-for-javac-in-java) in `java.base` explicit String concatenation is not translated into invokedynamic, so in practice it's faster to use `StringBuilder.append()` than `str1 + str2`, see e.g. https://github.com/openjdk/jdk/pull/3903

Thanks. I was not suggesting that we use string concatenation, but rather just remove the `newChar`/`newExtension` fields, and replace, e.g.:
`214             newChars.setLength(0);`
with
`214            StringBuilder newChars = new StringBuilder();`
though I'll admit that I don't have a good sense of whether that's worth doing.

-------------

PR: https://git.openjdk.org/jdk/pull/10475

From jwaters at openjdk.org  Fri Sep 30 17:10:25 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 30 Sep 2022 17:10:25 GMT
Subject: RFR: 8292016: Split Windows API error handling from errors passed
 through the runtime in the JDK [v26]
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <wLMWUM3LNgu0ZCjGKNpURiv2QZcWDXPRBUj3ICT_qvo=.8b66319d-6652-4ea8-979c-889ed53663d0@github.com>

> EDIT: Cave and add the ErrorOrigin enum, to differentiate which error type the error reporting functions in libjava will look up. RUNTIME refers to errors passed through the runtime via errno, and SYSTEM is for native errors not visible to the runtime.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  JNU_ThrowByNameWithMessageAndLastError

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9870/files
  - new: https://git.openjdk.org/jdk/pull/9870/files/ea8678b2..973fb766

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=24-25

  Stats: 93 lines in 8 files changed: 58 ins; 1 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From jwaters at openjdk.org  Fri Sep 30 17:13:08 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 30 Sep 2022 17:13:08 GMT
Subject: RFR: 8292016: Split Windows API error handling from errors passed
 through the runtime in the JDK [v27]
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <ZNzpe4UOKKN1ArZgTTNw9NsFIM6IABklsaJcQlCRz1w=.a1f5364e-b34d-445d-a934-7f38171d1a19@github.com>

> EDIT: Cave and add the ErrorOrigin enum, to differentiate which error type the error reporting functions in libjava will look up. RUNTIME refers to errors passed through the runtime via errno, and SYSTEM is for native errors not visible to the runtime.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9870/files
  - new: https://git.openjdk.org/jdk/pull/9870/files/973fb766..6ad4d68a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=25-26

  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From duke at openjdk.org  Fri Sep 30 17:13:26 2022
From: duke at openjdk.org (Justin Lu)
Date: Fri, 30 Sep 2022 17:13:26 GMT
Subject: Integrated: 8294307: ISO 4217 Amendment 173 Update
In-Reply-To: <LwGHj6uO96npFnZooUdQhkCGynrdTGVsTKW5ogE27nY=.b4b6e06b-fd1f-40f4-bd3a-dca742540e8b@github.com>
References: <LwGHj6uO96npFnZooUdQhkCGynrdTGVsTKW5ogE27nY=.b4b6e06b-fd1f-40f4-bd3a-dca742540e8b@github.com>
Message-ID: <yjgIDDp_cgMvpQxNNMmmk1N_UwjTQYMKbeBKPt-om7c=.dfe6f82b-43de-4066-b2bd-b2918178804c@github.com>

On Thu, 29 Sep 2022 23:19:16 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Amendment number outdated
> 
> Fix: Update amendment number + date in properties file and test case data file

This pull request has now been integrated.

Changeset: 3b1bc217
Author:    Justin Lu <justin.lu at oracle.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3b1bc21727636cb50cd04d958031832f48fe17e3
Stats:     4 lines in 2 files changed: 0 ins; 0 del; 4 mod

8294307: ISO 4217 Amendment 173 Update

Reviewed-by: lancea, bpb, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/10499

From jwaters at openjdk.org  Fri Sep 30 17:18:42 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 30 Sep 2022 17:18:42 GMT
Subject: RFR: 8292016: Split Windows API error handling from errors passed
 through the runtime in the JDK [v28]
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <3RSCtmrpHyE-sB9JivBhgx1LJLZEKUv5ZofgljzL4oQ=.d1cc0ea7-7f11-4fc7-b4df-3879fa2bdc4c@github.com>

> EDIT: Cave and add the ErrorOrigin enum, to differentiate which error type the error reporting functions in libjava will look up. RUNTIME refers to errors passed through the runtime via errno, and SYSTEM is for native errors not visible to the runtime.

Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into rework
 - Cleanup
 - Cleanup
 - JNU_ThrowByNameWithMessageAndLastError
 - Progress
 - Remove getErrorString
 - Merge remote-tracking branch 'upstream/master' into rework
 - Cleanup
 - Replace JLI_ReportErrorMessageSys with JLI_Perror
 - Merge remote-tracking branch 'upstream/master' into rework
 - ... and 2 more: https://git.openjdk.org/jdk/compare/47a18bbb...a4fa093e

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9870/files
  - new: https://git.openjdk.org/jdk/pull/9870/files/6ad4d68a..a4fa093e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=26-27

  Stats: 1843 lines in 102 files changed: 1078 ins; 335 del; 430 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From darcy at openjdk.org  Fri Sep 30 17:24:40 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 17:24:40 GMT
Subject: RFR: JDK-8294539: Augment discussion of equivalence relations on
 floating-point values [v2]
In-Reply-To: <IFvazBhQBWfMUqr0aTvIJ-P4XyhGx4c93vSUsTjh4bU=.8b32592f-ccbf-437e-ab90-1e0902fd437c@github.com>
References: <IFvazBhQBWfMUqr0aTvIJ-P4XyhGx4c93vSUsTjh4bU=.8b32592f-ccbf-437e-ab90-1e0902fd437c@github.com>
Message-ID: <esL7scbswpM_Y8MCwbQTxk-Ohh4rMkDlvUO1-NeeQ_A=.890adc61-1331-4ce1-a804-b812ef85cae3@github.com>

> While the floating-point == operation is *not* an equivalence relation, there are useful equivalence relations that can be defined over floating-point values. Text is added to java.lang.Double to discuss and name those relations.

Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:

 - Add discussion of numerical equality.
 - Fix typo.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10498/files
  - new: https://git.openjdk.org/jdk/pull/10498/files/7d18585f..58543643

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10498&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10498&range=00-01

  Stats: 15 lines in 1 file changed: 12 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10498.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10498/head:pull/10498

PR: https://git.openjdk.org/jdk/pull/10498

From kvn at openjdk.org  Fri Sep 30 17:28:31 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 30 Sep 2022 17:28:31 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v8]
In-Reply-To: <xi5R9hmey3jw8jHASbCLtq5tU3gGnu77E7w-qavRFRU=.c6cea845-8d8e-4c7d-9004-f0339decf162@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com>
 <QdS7Tx2gk2HR7Y-qe6Ig8_QgyGRi5i3k14aERVEHTs4=.b5839efb-e45f-4700-b9d6-7fca6d61cd77@github.com>
 <frb3je6a390Xqi6O21nZc6GVwti4hYcTm0MQZi2EXTk=.56910d50-38bf-4af6-9e16-6766b772b0bd@github.com>
 <m1OYhjDuNDzdJpvJdYw8wxy-GqRRGgTn1nH_tiSVp28=.4073f671-bfad-4778-b823-abca57cb40a6@github.com>
 <xi5R9hmey3jw8jHASbCLtq5tU3gGnu77E7w-qavRFRU=.c6cea845-8d8e-4c7d-9004-f0339decf162@github.com>
Message-ID: <Fp6o1eyQn6Q9CJbGMIc9BpRYGV05HvZLyXD5tBLq6L4=.f2d0c5a4-c2d2-406e-8024-69c8c941365b@github.com>

On Fri, 30 Sep 2022 03:13:09 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> @smita-kamath I have builds failures. Please, build and test yourself to verify changes.
>> 
>> src/hotspot/cpu/x86/assembler_x86.cpp: In member function 'void Assembler::evcvtps2ph(Address, KRegister, XMMRegister, int, int)':
>> src/hotspot/cpu/x86/assembler_x86.cpp:1950:15: error: no matching function for call to 'Assembler::emit_operand(XMMRegister&, Address&)'
>>  emit_operand(src, dst);
>
> @vnkozlov I spoke too soon. All the GHA tests passed in the dummy draft PR I created using Smita's patch:
> https://github.com/openjdk/jdk/pull/10500
> Please take a look. No build failures reported and all tier1 tests passed.

> @sviswa7 The failure is due to [JDK-8293618](https://bugs.openjdk.org/browse/JDK-8293618), @smita-kamath please merge with master. Thanks.

Yes, I tested with latest JDK sources which includes JDK-8293618.

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From rriggs at openjdk.org  Fri Sep 30 17:36:24 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 30 Sep 2022 17:36:24 GMT
Subject: RFR: 8294397: Replace StringBuffer with StringBuilder within
 java.text [v3]
In-Reply-To: <z8HUkpBrbxW8--Em1sgnTG29-sTk6ruQRn4ck182Gus=.b69f830a-12c9-4ef8-adbf-ea46346e4d1d@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <xrmZ8iFlP7a0nxPA63ytSX4LMbwfX74Ql5LLmQ2MBpg=.a71088ce-2541-4151-a765-2badff8d6f86@github.com>
 <7R_FJi6DYp4rE7nHNvpW6LPOsa5L_e7ul1ii1t8QeIA=.a8628f49-e0ce-41ee-8c7e-4e8f7faf983e@github.com>
 <tc5rcYHhEMUUnxTi7Mxsr1oeEZfSp5lCwO_d-J_DN9s=.6d770e42-75cd-4b27-b5b4-06bfc50e5b87@github.com>
 <z8HUkpBrbxW8--Em1sgnTG29-sTk6ruQRn4ck182Gus=.b69f830a-12c9-4ef8-adbf-ea46346e4d1d@github.com>
Message-ID: <_A18rxGSIcrT7YHYxDUF23T4Vt3FWKl0Tm9e8wQmt14=.10babfbc-fd94-4af1-9a6a-01c837a7568e@github.com>

On Fri, 30 Sep 2022 16:52:40 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Due to some [bootstrapping issues](https://stackoverflow.com/questions/71834059/why-invokedynamic-based-string-concatenation-is-not-available-for-javac-in-java) in `java.base` explicit String concatenation is not translated into invokedynamic, so in practice it's faster to use `StringBuilder.append()` than `str1 + str2`, see e.g. https://github.com/openjdk/jdk/pull/3903
>
> Thanks. I was not suggesting that we use string concatenation, but rather just remove the `newChar`/`newExtension` fields, and replace, e.g.:
> `214             newChars.setLength(0);`
> with
> `214            StringBuilder newChars = new StringBuilder();`
> though I'll admit that I don't have a good sense of whether that's worth doing.

Memory you don't allocate doesn't need to be GC'd.  I'd leave it alone and save the GC overhead.

-------------

PR: https://git.openjdk.org/jdk/pull/10475

From prr at openjdk.org  Fri Sep 30 17:42:29 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 30 Sep 2022 17:42:29 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <eM7WMgB7uVvIw-lqL8AzCf6zG-Xz6UUQQPibY5hRn6A=.80c398cb-9d26-4b94-b73c-50c85e438730@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
 <nFiCHw9g6IyGbqTuxvar8EhHobplelceRLF1KqsySv0=.5e63a863-e6c0-4f0a-a6cd-c972a0221308@github.com>
 <eM7WMgB7uVvIw-lqL8AzCf6zG-Xz6UUQQPibY5hRn6A=.80c398cb-9d26-4b94-b73c-50c85e438730@github.com>
Message-ID: <RAPey5BSjlbfy8WMa3N39QofovAuJ1wnJdx9xm-lvJw=.12e7b645-4668-4810-a24f-4c6fc20cd9ed@github.com>

On Fri, 30 Sep 2022 14:16:24 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 34:
>> 
>>> 32:  * the following link:
>>> 33:  *
>>> 34:  * http://hg.openjdk.org/jdk9/jdk9/jdk/raw-file/tip/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c
>> 
>> The domain for hg wasn't changed to openjdk.org.  The original URL is correct.
>
> Why do we need to link to a URL? Why not `../../bridge/AccessBridgeCalls.c`?

This is correct.
AccessBridge.h is published with the include/header files of the JDK and anyone reading it there can't exactly make use of "../"

-------------

PR: https://git.openjdk.org/jdk/pull/10501

From joehw at openjdk.org  Fri Sep 30 18:12:25 2022
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 30 Sep 2022 18:12:25 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
Message-ID: <e9sYCA3vCcVdXUjRRnPbEK3Z7Ik5WANQMziL6OStdts=.aa1ad3f4-5d91-485d-b48f-3c59579f1869@github.com>

On Fri, 30 Sep 2022 01:11:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
>> 
>> Updates were made using a shell script. I"ll run a copyright updater before any push.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   http -> https

The ones in java.xml look good to me.

-------------

Marked as reviewed by joehw (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10501

From smarks at openjdk.org  Fri Sep 30 18:48:30 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 30 Sep 2022 18:48:30 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v6]
In-Reply-To: <NTqD8AGbaS3c2uTKVFxgg8bAcONc4kwogiBj4wHNwfc=.81e9bebd-75d3-4590-abb2-2e0f32790d6c@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <sVvztWqr_J9916zDbNTZdC1SNDHtW_dCVIizVI1K87c=.08964fc4-fb1f-4838-9b72-b3e74e2a9902@github.com>
 <NTqD8AGbaS3c2uTKVFxgg8bAcONc4kwogiBj4wHNwfc=.81e9bebd-75d3-4590-abb2-2e0f32790d6c@github.com>
Message-ID: <yTcLxJZlrnw7Uq_0NyKMQSBZiffYyz4tbUc9iWF3i6g=.e59a2ecd-fa95-4e78-851c-ab039109d6f6@github.com>

On Thu, 11 Aug 2022 10:35:55 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revise Implementation Note discussing JNI Invocation API.
>
> src/java.base/share/classes/java/lang/Runtime.java line 197:
> 
>> 195:      * as possible. They should also not rely blindly upon services that may
>> 196:      * have registered their own shutdown hooks and therefore may themselves in
>> 197:      * the process of shutting down. Attempts to use other thread-based
> 
> Is there a "be" missing here? 
>> may themselves *be* in the process ...

Yes, "be" is missing. Hm, I hadn't edited that text... Ha that typo was introduced by MR in 1999! OK, fixed.

-------------

PR: https://git.openjdk.org/jdk/pull/9437

From rriggs at openjdk.org  Fri Sep 30 19:13:27 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 30 Sep 2022 19:13:27 GMT
Subject: Integrated: 8294533: Documentation mistake in Process::getErrorStream
 and getInputStream
In-Reply-To: <t90ytF8iOGzi2tx1085-rv65hycEozKqtgWFMl3jkgs=.b6f3eafd-6537-43d2-8e7d-fb08f1975d16@github.com>
References: <t90ytF8iOGzi2tx1085-rv65hycEozKqtgWFMl3jkgs=.b6f3eafd-6537-43d2-8e7d-fb08f1975d16@github.com>
Message-ID: <kPXogxt544-rlQOzfKk-e4Wb7N17e_kXuR3pE3_tlo0=.43a63f44-bc38-43e4-b76a-d2c0139651c4@github.com>

On Thu, 29 Sep 2022 15:01:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Correct javadoc links and references.
> 
> The links should refer to the method `()` instead of field.
> 
> The apiNote in `getErrorStream` should refer to the error stream not the input stream and reader.

This pull request has now been integrated.

Changeset: d207da8a
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d207da8a8c2806ea254909658f2a50e037554866
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8294533: Documentation mistake in Process::getErrorStream and getInputStream

Reviewed-by: iris

-------------

PR: https://git.openjdk.org/jdk/pull/10492

From prr at openjdk.org  Fri Sep 30 19:17:22 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 30 Sep 2022 19:17:22 GMT
Subject: RFR: 8294377: Prepare to stop auto-inheriting documentation for
 subclasses of exceptions whose documentation is inherited [v2]
In-Reply-To: <rZOv9leE3Krs9IA7nAMMZPVelsIgC5am13o1oU8BF8Y=.fe7d7524-1a12-4a38-aedb-f9dd60cdded8@github.com>
References: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>
 <rZOv9leE3Krs9IA7nAMMZPVelsIgC5am13o1oU8BF8Y=.fe7d7524-1a12-4a38-aedb-f9dd60cdded8@github.com>
Message-ID: <PlQjfMvDRNRyYFL9xVnKoirPgtOk_QhEMl_QbNRnzrU=.0b472944-6d3a-48f2-bc79-ec592df83c79@github.com>

On Tue, 27 Sep 2022 12:14:23 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This adds exception documentation to JDK methods that would otherwise lose that documentation once JDK-8287796 is integrated. While adding this exception documentation now does not change [^1] the JDK API Documentation, it will automatically counterbalance the effect that JDK-8287796 will have.
>> 
>> JDK-8287796 seeks to remove an old, undocumented, and esoteric javadoc feature that cannot be suppressed [^2]. The feature is so little known about that IDEs either do not implement it correctly or do not implement it at all, thus rendering documentation differently from how the javadoc tool renders it.
>> 
>> That feature was introduced in JDK-4947455 and manifests as follows. If a method inherits documentation for an exception, along with that documentation the method automatically inherits documentation for all exceptions that are subclasses of that former exception and are documented in an overridden method.
>> 
>> To illustrate that behavior, consider the following example. A method `Subtype.m` inherits documentation for `SuperException`, while the overridden method `Supertype.m` documents `SuperException`, `SubExceptionA` and `SubExceptionB`, where the latter two exceptions are subclasses of the former exception:
>> 
>>     public class Subtype extends Supertype {
>> 
>>         @Override
>>         public void m() throws SuperException {
>>     ...
>> 
>>     public class Supertype {
>> 
>>         /**
>>          * @throws SuperException general problem
>>          * @throws SubExceptionA  specific problem A
>>          * @throws SubExceptionB  specific problem B
>>          */
>>         public void m() throws SuperException {
>>     ...
>> 
>>     public class SuperException extends Exception {
>>     ...
>> 
>>     public class SubExceptionA extends SuperException {
>>     ...
>> 
>>     public class SubExceptionB extends SuperException {
>>     ...
>> 
>> For the above example, the API Documentation for `Subtype.m` will contain documentation for all three exceptions; the page fragment for `Subtype.m` in "Method Details" will look like this:
>> 
>>     public void m()
>>            throws SuperException
>> 
>>     Overrides:
>>         m in class Supertype
>>     Throws:
>>         SuperException - general problem
>>         SubExceptionA - specific problem A
>>         SubExceptionB - specific problem B 
>> 
>> It works for checked and unchecked exceptions, for methods in classes and interfaces.
>> 
>> 
>> If it's the first time you hear about that behavior and this change affects your area, it's a good opportunity to reflect on whether the exception documentation this change adds is really needed or you were simply unaware of the fact that it was automatically added before. If exception documentation is not needed, please comment on this PR. Otherwise, consider approving it.
>> 
>> Keep in mind that if some exception documentation is not needed, **leaving it out** from this PR might require a CSR.
>> 
>> 
>> [^1]: Aside from insignificant changes on class-use and index pages. There's one relatively significant change. This change is in jdk.jshell, where some methods disappeared from "Methods declared in ..." section and other irregularities. We are aware of this and have filed JDK-8291803 to fix the root cause.
>> [^2]: In reality, the feature can be suppressed, but it looks like a bug rather than intentional design. If we legitimize the feature and its suppression behavior, the model for exception documentation inheritance might become much more complicated.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert an extraneous change to jdk.javadoc

src/java.desktop/share/classes/javax/imageio/stream/ImageInputStreamImpl.java line 206:

> 204:      * @throws EOFException {@inheritDoc}
> 205:      */
> 206:     public boolean readBoolean() throws IOException {

If the docs end up the same as you say that is fine by me since for the two ImageIO classes
that seems to be what we'd want.

But inheritDoc behaviour is still "surprising".
I've never been sure I understood it and now I'm just sure I don't.

1) The two ImageIO methods don't have @override or *anything* and yet javadoc infers
they'd want to inherit the docs from the interface .. clever javadoc .. I guess I can see
that some doc is better than none so this is OK

2) When it does inherit I'd expected that it copies the EXACT and ENTIRE javadoc
from the super-interface, which for your change to work can't be all its doing.
You've added JUST
/**
 * @throws SomeExceptionSubType blah-blah
 */

and yet javadoc somehow figures out this is to be ADDED to the super-type doc
for the method and not replace it .. ???

3) What the old code was doing seems to me to be "natural" to the extent any of
this does and the fix you are preparing would add to the surprising behaviours ..

-------------

PR: https://git.openjdk.org/jdk/pull/10449

From mullan at openjdk.org  Fri Sep 30 19:36:23 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 30 Sep 2022 19:36:23 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v2]
In-Reply-To: <_FWF1bciUEsK9fBUiOle73_FYQWgwOkS1PvPQqzfYxU=.59bb14be-7cd0-4b92-b80f-1c4869c8803e@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <QXIQe5EqORYqyigwI84XMHTEYvY3jM-ersDVdN9EeKo=.c0f4ab18-b7f9-4ee9-abc7-816fbd37ff5b@github.com>
 <tPKKm9gjnIZtbN189Qb-o0-Mv6fiNq9lm5lUJtjxXcM=.3b43450c-a7fa-4ce0-8004-3b5329597f6b@github.com>
 <5TadUhgSG09rHgRo7EFIblKjlnvHr-q2DGSGfV2ezF0=.6e824b66-846c-476f-a372-6d5260e3d399@github.com>
 <H5QVVX7TbXodlDE2Q4AtJVU2sTGe3px3Trr8J-o0C0g=.db75c32e-da1d-4e7a-bb1b-fa5c990069d7@github.com>
 <PGi2fwmUOQzOgYcQMCAAqSQQbZK-__--erPRuuyNJMg=.f35b927d-ae6f-47e5-9d4a-90660019e785@github.com>
 <leSw2o-uNaML1WUN_Koh9j9rxW6mkx75_hdFtjeWCYE=.26b43b59-3406-430e-9429-ab3ab3d9172e@github.com>
 <bcYWFVve9-ZRf5OoEB1oAW91ySR1BtUYG9uOtNE-x28=.35da7b5d-b0ed-4666-a00a-c7eabc363ab1@github.com>
 <_FWF1bciUEsK9fBUiOle73_FYQWgwOkS1PvPQqzfYxU=.59bb14be-7cd0-4b92-b80f-1c4869c8803e@github.com>
Message-ID: <j4k9R1AoIxafqLpYbXI7jAvBWX2S6BRsXGgLMyuH5_s=.f513dae6-42ac-4c83-b077-981c74779f4e@github.com>

On Thu, 29 Sep 2022 15:12:06 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> With event streaming, beginChunk is usually to prefer. Otherwise, a client that monitors the JVM must wait until the first chunk rotation to get the data.
>> 
>> That said, we want startup to be quick. There should probably be a common parameter, i.e. security=off/normal/audit/trace, that handles enablement for all security events. I don't know how expensive this event is and where it would fit among those categories?
>> 
>> If the event triggers class loading, it might make sense to check if the event is enabled first.
>
> Thanks @egahlin  - maybe we can leave it at beginChunk setting then.
> 
> I've been doing some testing to satisfy myself that the impact of this event on performance is minimal, Running the new `emitInitialSecurityProperties()` is showing a cost of ~ 1.6ms (1602998 ns). 
> 
> This new Event itself doesn't trigger extra class loading AFAICT. I went back to a jdk 20 binary without this patch and ran some tests. 
> 
> `ProtectionDomain ` is a very early class to initialize [1] (initPhase2)
> 
> Without JFR, `java.security.Security` will initialize in a default JDK with a JMX `Agent.startLocalManagementAgent` call in a simple HelloWorld test which prints "Hello" and then sleeps  [2] - the JMX thread starts after about 3 seconds of runtime.
> 
> Without JFR and by using the `-XX:+DisableAttachMechanism` option, the Security class will not load in same test.
> 
> If JFR is on, then Security class is already being loaded, even without this patch [3]
> 
> [1]
> 
> 	at java.base/java.security.ProtectionDomain.<clinit>(ProtectionDomain.java:64)
> 	at java.base/java.lang.ClassLoader.<init>(ClassLoader.java:316)
> 	at java.base/java.lang.ClassLoader.<init>(ClassLoader.java:431)
> 	at java.base/java.security.SecureClassLoader.<init>(SecureClassLoader.java:113)
> 	at java.base/jdk.internal.loader.BuiltinClassLoader.<init>(BuiltinClassLoader.java:194)
> 	at java.base/jdk.internal.loader.ClassLoaders$BootClassLoader.<init>(ClassLoaders.java:135)
> 	at java.base/jdk.internal.loader.ClassLoaders.<clinit>(ClassLoaders.java:79)
> 	at java.base/jdk.internal.loader.BootLoader.loadModule(BootLoader.java:120)
> 	at java.base/jdk.internal.module.ModuleBootstrap.boot2(ModuleBootstrap.java:266)
> 	at java.base/jdk.internal.module.ModuleBootstrap.boot(ModuleBootstrap.java:174)
> 	at java.base/java.lang.System.initPhase2(System.java:2214)
> 
> 
> [2]
> 
> 	at java.base/java.security.Security.<clinit>(Security.java:73)
> 	at java.base/sun.net.InetAddressCachePolicy$1.run(InetAddressCachePolicy.java:93)
> 	at java.base/sun.net.InetAddressCachePolicy$1.run(InetAddressCachePolicy.java:90)
> 	at java.base/java.security.AccessController.doPrivileged(AccessController.java:319)
> 	at java.base/sun.net.InetAddressCachePolicy.<clinit>(InetAddressCachePolicy.java:89)
> 	at java.base/java.net.InetAddress$NameServiceAddresses.get(InetAddress.java:1005)
> 	at java.base/java.net.InetAddress.getAllByName0(InetAddress.java:1658)
> 	at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1524)
> 	at java.base/java.net.InetAddress.getByName(InetAddress.java:1413)
> 	at jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startLocalConnectorServer(ConnectorBootstrap.java:531)
> 	at jdk.management.agent/jdk.internal.agent.Agent.startLocalManagementAgent(Agent.java:317)
> 
> 
> [3]
> 
> 
> 	at java.base/java.security.Security.<clinit>(Security.java:73)
> 	at java.base/sun.security.util.SecurityProperties.getOverridableProperty(SecurityProperties.java:57)
> 	at java.base/sun.security.util.SecurityProperties.privilegedGetOverridable(SecurityProperties.java:48)
> 	at java.base/sun.security.util.SecurityProperties.includedInExceptions(SecurityProperties.java:72)
> 	at java.base/sun.security.util.SecurityProperties.<clinit>(SecurityProperties.java:36)
> 	at java.base/sun.security.util.FilePermCompat.<clinit>(FilePermCompat.java:43)
> 	at java.base/java.security.AccessControlContext.<init>(AccessControlContext.java:270)
> 	at java.base/java.security.AccessController.createWrapper(AccessController.java:649)
> 	at java.base/java.security.AccessController.doPrivileged(AccessController.java:461)
> 	at jdk.jfr/jdk.jfr.internal.SecuritySupport.doPrivilegedWithReturn(SecuritySupport.java:261)
> 	at jdk.jfr/jdk.jfr.internal.SecuritySupport.getPathInProperty(SecuritySupport.java:331)
> 	at jdk.jfr/jdk.jfr.internal.SecuritySupport.<clinit>(SecuritySupport.java:80)
> 	at jdk.jfr/jdk.jfr.internal.JVMSupport.checkAvailability(JVMSupport.java:46)
> 	at jdk.jfr/jdk.jfr.internal.JVMSupport.<clinit>(JVMSupport.java:41)
> 	at jdk.jfr/jdk.jfr.internal.Logger.<clinit>(Logger.java:41)
> 	at jdk.jfr/jdk.jfr.internal.dcmd.AbstractDCmd.execute(AbstractDCmd.java:75)

When support for the SM is removed, the dependency on `AccessController.doPrivileged` will be removed and there may no longer be a JFR dependency on loading the `Security` class. So, it is ok for now, but a solution that doesn't depend on this might be better in the long run.

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From rriggs at openjdk.org  Fri Sep 30 20:05:28 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 30 Sep 2022 20:05:28 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK
In-Reply-To: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
Message-ID: <hUV_jxvIYNPdrzCMBxFsRYul-Zlc9hXhJc0ZqdmRXnk=.cecc2fa2-f8ac-452c-b051-cd1876973f7f@github.com>

On Thu, 29 Sep 2022 13:11:03 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> This fixes misleading indentations, which allows enabling the (currently disabled) `misleading-indentation` warning flag on two `.gmk` files.

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10487

From duke at openjdk.org  Fri Sep 30 20:08:10 2022
From: duke at openjdk.org (Justin Lu)
Date: Fri, 30 Sep 2022 20:08:10 GMT
Subject: RFR: 8294397: Replace StringBuffer with StringBuilder within
 java.text [v4]
In-Reply-To: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
Message-ID: <CDP31ApvZYF4Tg2urnsB2ZHolOhvzj6CLGVQ5CrsGW8=.e4191df2-af79-49a3-9230-3e601192e5d6@github.com>

> Problem: Unnecessary instances of StringBuffer within java.text (internal only)
> 
> Fix: StringBuffer Replaced with StringBuilder, and adjusted variable/method names

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - Remove comment typo
 - Remove test wrapper

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10475/files
  - new: https://git.openjdk.org/jdk/pull/10475/files/cd966f31..442c2a4e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10475&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10475&range=02-03

  Stats: 45 lines in 3 files changed: 9 ins; 35 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10475.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10475/head:pull/10475

PR: https://git.openjdk.org/jdk/pull/10475

From iris at openjdk.org  Fri Sep 30 20:14:24 2022
From: iris at openjdk.org (Iris Clark)
Date: Fri, 30 Sep 2022 20:14:24 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK
In-Reply-To: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
Message-ID: <He9lyN2nspc2lonTKoozPa2_rjKBRQ0Y8ZLmqUiUBPw=.f9c857f3-126d-44ac-aa01-53abbc7fe0f8@github.com>

On Thu, 29 Sep 2022 13:11:03 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> This fixes misleading indentations, which allows enabling the (currently disabled) `misleading-indentation` warning flag on two `.gmk` files.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10487

From aturbanov at openjdk.org  Fri Sep 30 20:23:08 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 30 Sep 2022 20:23:08 GMT
Subject: Integrated: 8294608: Remove redundant unchecked suppression in
 FileDescriptor
In-Reply-To: <Kaatiu8ZDph6uUog_BHU0jz1cINsm809e7DyH9kB_E0=.830f1c34-1419-4ea4-880a-5f3ea4d3099c@github.com>
References: <Kaatiu8ZDph6uUog_BHU0jz1cINsm809e7DyH9kB_E0=.830f1c34-1419-4ea4-880a-5f3ea4d3099c@github.com>
Message-ID: <l14e3KNO2di8HauOcPvgxKHvuvnC5o_hc80cWtle_Jk=.696f713d-afa0-44a3-96ca-678b5729e265@github.com>

On Wed, 28 Sep 2022 20:39:03 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Found this redundant suppressions by IntelliJ IDEA inspection.
> It seems [JDK-8189330](https://bugs.openjdk.org/browse/JDK-8189330) made them redundant.

This pull request has now been integrated.

Changeset: 375f02fb
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/375f02fb21ae37c381229e2a28b1f26e3cb926d4
Stats:     5 lines in 1 file changed: 0 ins; 4 del; 1 mod

8294608: Remove redundant unchecked suppression in FileDescriptor

Reviewed-by: alanb, bpb

-------------

PR: https://git.openjdk.org/jdk/pull/10473

From psandoz at openjdk.org  Fri Sep 30 20:25:49 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 30 Sep 2022 20:25:49 GMT
Subject: RFR: JDK-8294539: Augment discussion of equivalence relations on
 floating-point values [v2]
In-Reply-To: <esL7scbswpM_Y8MCwbQTxk-Ohh4rMkDlvUO1-NeeQ_A=.890adc61-1331-4ce1-a804-b812ef85cae3@github.com>
References: <IFvazBhQBWfMUqr0aTvIJ-P4XyhGx4c93vSUsTjh4bU=.8b32592f-ccbf-437e-ab90-1e0902fd437c@github.com>
 <esL7scbswpM_Y8MCwbQTxk-Ohh4rMkDlvUO1-NeeQ_A=.890adc61-1331-4ce1-a804-b812ef85cae3@github.com>
Message-ID: <DsT0dICpGdqWlhkY6E6I50NmTQ7Y8mVJ29fchW8xPbk=.ed23a8f0-6982-4af2-874a-4c28e2e247ef@github.com>

On Fri, 30 Sep 2022 17:24:40 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> While the floating-point == operation is *not* an equivalence relation, there are useful equivalence relations that can be defined over floating-point values. Text is added to java.lang.Double to discuss and name those relations.
>
> Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add discussion of numerical equality.
>  - Fix typo.

Marked as reviewed by psandoz (Reviewer).

src/java.base/share/classes/java/lang/Double.java line 166:

> 164:  * equivalence relation for {@code double} values {@code a} and {@code b} is
> 165:  * implemented by the expression
> 166:  * <br>{@code Double.doubleTo}<code><b>Raw</b></code>{@code LongBits(a) == Double.doubleTo}<code><b>Raw</b></code>{@code LongBits(b)}<br>

Place in a code snippet since it's hard to read in source otherwise? Snippets allow for highlighting e.g.

/**
 * {@snippet :
 * Double.doubleToRawLongBits(a) == Double.doubleToRawLongBits(b) // @highlight substring="Raw"
 * }
 */

-------------

PR: https://git.openjdk.org/jdk/pull/10498

From darcy at openjdk.org  Fri Sep 30 20:29:20 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 20:29:20 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v5]
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <amUS-nAMV81aBx2GLfnDtuk_O_MhFE1Oi0Sxs2DYy2o=.d8155a10-80d6-4ab2-9f2a-4bc8ee61b96b@github.com>

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

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:

 - Update hg URLs to git.
 - Merge branch 'master' into JDK-8294618
 - http -> https
 - Undo manpage update.
 - Update copyright.
 - Revert unintended update to binary file.
 - JDK-8294618: Update openjdk.java.net => openjdk.org

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/cee96d0a..fbaf3d4c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=03-04

  Stats: 2670 lines in 133 files changed: 1729 ins; 406 del; 535 mod
  Patch: https://git.openjdk.org/jdk/pull/10501.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501

PR: https://git.openjdk.org/jdk/pull/10501

From darcy at openjdk.org  Fri Sep 30 20:29:21 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 20:29:21 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <eCjWYSRQB0sC2mcoavSzqTGOt7Tw5GdAKAqnDRmq07A=.f8403857-eb3a-4069-940a-a4414a8b83e8@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
 <eCjWYSRQB0sC2mcoavSzqTGOt7Tw5GdAKAqnDRmq07A=.f8403857-eb3a-4069-940a-a4414a8b83e8@github.com>
Message-ID: <xtCGcSpiMRaJNEOP0fgvF56wVK2gaB_x8Qym-i_lnZU=.33efcb67-350a-4b6d-8a0d-ffb13d5a6a4e@github.com>

On Fri, 30 Sep 2022 13:59:12 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Also, FWIW, there are 100+ hits in `test` as well. But that is so many it might warrant a separate PR..?

Yes; I think it is sufficient to update src and doc with this PR.

-------------

PR: https://git.openjdk.org/jdk/pull/10501

From darcy at openjdk.org  Fri Sep 30 20:29:22 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 20:29:22 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <RAPey5BSjlbfy8WMa3N39QofovAuJ1wnJdx9xm-lvJw=.12e7b645-4668-4810-a24f-4c6fc20cd9ed@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
 <nFiCHw9g6IyGbqTuxvar8EhHobplelceRLF1KqsySv0=.5e63a863-e6c0-4f0a-a6cd-c972a0221308@github.com>
 <eM7WMgB7uVvIw-lqL8AzCf6zG-Xz6UUQQPibY5hRn6A=.80c398cb-9d26-4b94-b73c-50c85e438730@github.com>
 <RAPey5BSjlbfy8WMa3N39QofovAuJ1wnJdx9xm-lvJw=.12e7b645-4668-4810-a24f-4c6fc20cd9ed@github.com>
Message-ID: <q7j-egb4NojCIVKfF-PxraFVvU3FucPfulisSzexu30=.888b04a2-1624-4de1-a81c-e65e747ccd73@github.com>

On Fri, 30 Sep 2022 17:38:54 GMT, Phil Race <prr at openjdk.org> wrote:

> This is correct. AccessBridge.h is published with the include/header files of the JDK and anyone reading it there can't exactly make use of "../"

Update to persistent git links.

-------------

PR: https://git.openjdk.org/jdk/pull/10501

From smarks at openjdk.org  Fri Sep 30 21:38:22 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 30 Sep 2022 21:38:22 GMT
Subject: RFR: 8279361: Error in documentation of third Stream.reduce method
In-Reply-To: <ZDScXuIYVuxEWWS2YvBff2WIm5IURggmJAJ6d7PQ9r8=.c4e324e0-a0ea-4c85-901e-0f77303b8f24@github.com>
References: <ZDScXuIYVuxEWWS2YvBff2WIm5IURggmJAJ6d7PQ9r8=.c4e324e0-a0ea-4c85-901e-0f77303b8f24@github.com>
Message-ID: <W3qCfO8RX32vhX6PF1ldDke6_VcnGuiMJp8yTDaFUFY=.182f1c1f-dd31-4e2f-aac7-ccb751bf9bf1@github.com>

On Wed, 28 Sep 2022 15:36:50 GMT, Viktor Klang <duke at openjdk.org> wrote:

> This JavaDoc change attempts to shine some light on the `combiner`-function as it relates to the third variant of `Stream.reduce` since it according to the bug submission in JBS can be confusing that the `combiner` is not mentioned in the code example in the documentation.

Deleting the pseudocode might be the right way to go. To restate the meta-issue, a problem with pseudocode is that it's difficult to separate the accidental from the essential. With something that has as much essential complexity as parallel reduction, it seems like pseudocode introduces a lot of accidental complexity that can be confusing or misleading. So yeah, if pseudocode isn't helping, then get rid of it.

-------------

PR: https://git.openjdk.org/jdk/pull/10469

From smarks at openjdk.org  Fri Sep 30 21:38:27 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 30 Sep 2022 21:38:27 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v7]
In-Reply-To: <fv-KUmviw7HBex58cHnMkY7hpPXFTMEOSGfFav4u-Yk=.18356296-4f30-4cf8-878d-3388f6aeffe3@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <LP-gofubXbRsQ_VDAN1CcBqr3ethNG7WAW963kJHXYU=.cf685c2f-09db-427f-a718-746c928613dd@github.com>
 <xgVZFbSZN7cVLZ5jdSecQKr-3Jc25uS9prS5AJgV9sQ=.e5a94319-565c-47b0-b461-705bf2ae439f@github.com>
 <oGzFPebmEl9Sww4TzDlySv-11G55f3RBlpEl-sg6HEc=.00521a1b-8e66-4f6d-8d74-3f5afdef0f6a@github.com>
 <5dksriRuuZ4zEr_XQTk9zVcJ2Y77KoX9POg8H40IMtI=.b5e1ea74-dfb0-413a-b731-47f7d7106351@github.com>
 <fv-KUmviw7HBex58cHnMkY7hpPXFTMEOSGfFav4u-Yk=.18356296-4f30-4cf8-878d-3388f6aeffe3@github.com>
Message-ID: <ZlxzwCdQM4k3Pqo9Hghrey7SMf4MFvRcdRBkz8wQp2Y=.34010ab0-c448-40c9-9a0c-8ce1f28f5c5e@github.com>

On Thu, 1 Sep 2022 06:31:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> There are subtle differences (invoking a virtual Thread's run method directly does no nothing) but that is too much detail and would confusing to say anything about in the introduction paragraphs.
>> 
>> The following is closer to what I think we should have. The existing paragraph 2 describes starting a thread so this is where the Thread.run method is introduced. Paragraph 3 follows to describe termination.
>> 
>> 
>>  * <p> {@code Thread} defines constructors and a {@link Builder} to create threads.
>>  * {@linkplain #start() Starting} a thread schedules it to execute its {@link #run() run}
>>  * method. The newly started thread executes concurrently with the thread that caused
>>  * it to start.
>>  *
>>  * <p> A thread <i>terminates</i> if either its {@code run} method completes normally,
>>  * or if its {@code run} method completes abruptly and the appropriate {@linkplain
>>  * Thread.UncaughtExceptionHandler uncaught exception handler} completes normally or
>>  * abruptly. With no code left to run, the thread has completed execution. Thread
>>  * defines the {@link #join() join} method to wait for a thread to terminate.
>
> That sounds reasonable to me.

OK, I've applied Alan's suggestion with slight edits.

-------------

PR: https://git.openjdk.org/jdk/pull/9437

From smarks at openjdk.org  Fri Sep 30 21:41:26 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 30 Sep 2022 21:41:26 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v4]
In-Reply-To: <GiO4NCVFu-WoXJVfQbJ8JXaZ4T5kSrRUIUJvYSMioQ0=.b33c6355-382a-4eb1-aaa0-9b154f924628@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <JStsS80ewZoqjxdIO2Rl5sGkDIBA3l4d85x2HhQ-m_o=.865c1517-7579-4789-8414-d09184256f16@github.com>
 <LNWjm_Itqm86_Qj_ETWxkE42IAqfgwS5NqM4-I2u0Es=.37e666e1-049d-4a2c-9973-bd7bb03027d5@github.com>
 <PezGo5NB5M8uY_xZo-tD6yhq9NK3yLEPDBq62JWYLr4=.0650964f-11d5-4444-ac24-2552c73cd4ff@github.com>
 <ntqaF5LH1gGuhZ7oxXyYzgP-jz1a0hS6gFr4DczI7AI=.d9ca88dd-dbf1-42ee-ae45-b846f6132aeb@github.com>
 <BX_UHsETk2nbNMcvFM0y2_sP90IRCfUZtSj-0SoJw40=.b0719da1-dedf-4273-bd61-838b643d1b1b@github.com>
 <FM7sQqMq6aYLngEIKR3d1rEAB4cr48JvRux0xQvhum0=.d79d145b-2413-4933-9430-a0eb9d5154d2@github.com>
 <GiO4NCVFu-WoXJVfQbJ8JXaZ4T5kSrRUIUJvYSMioQ0=.b33c6355-382a-4eb1-aaa0-9b154f924628@github.com>
Message-ID: <ZmFvlhv3GFsFp3nt2KX2AYbCRTbT1tWMVDt-DXai0dw=.263ae980-643a-4bd0-8ac7-b7b12d6e3ac3@github.com>

On Thu, 11 Aug 2022 07:23:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> What you have is okay although I would have preferred if the sentence on the join method was in the previous paragraph rather as it fits with termination.
>
> Plus one on the join() bit. You could also argue for mentioning isAlive() here too.

Merged `join` sentence into previous paragraph per David's earlier suggestion. I didn't mention `isAlive` though, no need to complicate this further.

-------------

PR: https://git.openjdk.org/jdk/pull/9437

From smarks at openjdk.org  Fri Sep 30 21:46:34 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 30 Sep 2022 21:46:34 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v9]
In-Reply-To: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
Message-ID: <gQMPe5GcAQCW66RZv7cvXbgrXtQDDyWlGzz1ejeo3L0=.afbaa62f-a307-4d4c-8715-7a2c39eb63e0@github.com>

> The concept of the shutdown sequence needs to be specified more clearly. This PR adds text for this into the class specification of `java.lang.Runtime`. Also includes adjustments to related areas in `addShutdownHook`, `halt`, and in the `System` and `Thread` classes. The changes here should coordinate with similar changes to JLS 12.8, JVMS 5.7, and the Invocation API chapter of the _JNI Specification._

Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:

  Additional edits to Runtime and Thread specs.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9437/files
  - new: https://git.openjdk.org/jdk/pull/9437/files/6b559c4c..ca369058

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9437&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9437&range=07-08

  Stats: 24 lines in 2 files changed: 2 ins; 5 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/9437.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9437/head:pull/9437

PR: https://git.openjdk.org/jdk/pull/9437

From smarks at openjdk.org  Fri Sep 30 21:53:23 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 30 Sep 2022 21:53:23 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v9]
In-Reply-To: <gQMPe5GcAQCW66RZv7cvXbgrXtQDDyWlGzz1ejeo3L0=.afbaa62f-a307-4d4c-8715-7a2c39eb63e0@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <gQMPe5GcAQCW66RZv7cvXbgrXtQDDyWlGzz1ejeo3L0=.afbaa62f-a307-4d4c-8715-7a2c39eb63e0@github.com>
Message-ID: <BP9BS88QXBQeWw7eb9usp_vc0o5qXwI9cJBowCtafCM=.d3f2b78c-5f18-4e12-a1ea-17c55c352bf1@github.com>

On Fri, 30 Sep 2022 21:46:34 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> The concept of the shutdown sequence needs to be specified more clearly. This PR adds text for this into the class specification of `java.lang.Runtime`. Also includes adjustments to related areas in `addShutdownHook`, `halt`, and in the `System` and `Thread` classes. The changes here should coordinate with similar changes to JLS 12.8, JVMS 5.7, and the Invocation API chapter of the _JNI Specification._
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional edits to Runtime and Thread specs.

OK, I finally got back to this. I incorporated most suggested edits. Please re-review.

-------------

PR: https://git.openjdk.org/jdk/pull/9437

From naoto at openjdk.org  Fri Sep 30 23:53:28 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 30 Sep 2022 23:53:28 GMT
Subject: RFR: 8294397: Replace StringBuffer with StringBuilder within
 java.text [v4]
In-Reply-To: <CDP31ApvZYF4Tg2urnsB2ZHolOhvzj6CLGVQ5CrsGW8=.e4191df2-af79-49a3-9230-3e601192e5d6@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <CDP31ApvZYF4Tg2urnsB2ZHolOhvzj6CLGVQ5CrsGW8=.e4191df2-af79-49a3-9230-3e601192e5d6@github.com>
Message-ID: <i4l8P0SMuF6c5ERrJfU8lLNegPzBwtIE6SGaZ6EJZOo=.fdbed496-97cd-45e7-a070-b615fa83f8c2@github.com>

On Fri, 30 Sep 2022 20:08:10 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Problem: Unnecessary instances of StringBuffer within java.text (internal only)
>> 
>> Fix: StringBuffer Replaced with StringBuilder, and adjusted variable/method names
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove comment typo
>  - Remove test wrapper

LGTM. Thanks for removing the unnecessary wrapper.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10475