From lmesnik at openjdk.org  Fri Dec  1 01:04:20 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 1 Dec 2023 01:04:20 GMT
Subject: RFR: 8320129: "top" command during jtreg failure handler does not
 display CPU usage on OSX
Message-ID: <cylR98W-HGZUXrw7n5BMFLq-efMWfdg7ZcaW6OQaIa0=.edaa4e47-a216-4dde-be51-b5b47fd978e6@github.com>

Description of problem and propsed fix from @plummercj 
'
In test/failure_handler/src/share/conf/mac.properties we have:

process.top.app=top
process.top.args=-l 1

So top is run with the "-l 1" args, causing it to do one iteration and then exit. Unfortunately the first iteration always shows all 0's for CPU usage. If you do at least 2 iterations, you do see the proper CPU usage on the 2nd iteration. The user just needs to know to scroll down to see it. I suggest we start using "-l 2" unless someone has a better idea.

BTW, for proper CPU usage you can instead look at the failure handler "ps" output, which seems to be correct. But it is nice to have "top" produce the correct output so all the CPU hogs are at the top of the list.
'

I verified that top report contains now 2 samples.

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

Commit messages:
 - 8320129: "top" command during jtreg failure handler does not display CPU usage on OSX

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

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

From xgong at openjdk.org  Fri Dec  1 01:16:15 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 1 Dec 2023 01:16:15 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v5]
In-Reply-To: <9VeMdTAJPaPZDg9ZW7FVJOf9XGl4gGqAS-2g8SFc9c0=.36792cd5-66d9-4abc-ba0c-aee3478627f4@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <nZFspjlPXfeQxrr5cKfbjeL3typf6DKSgNQUNszhufE=.caac471d-9c7b-4f8f-953f-04ee4a13f111@github.com>
 <9VeMdTAJPaPZDg9ZW7FVJOf9XGl4gGqAS-2g8SFc9c0=.36792cd5-66d9-4abc-ba0c-aee3478627f4@github.com>
Message-ID: <mnf_hjWdemelALPlwcS8mnKIxR5ljIyGD6MHpqCPDsQ=.0cb49580-ed76-4728-a604-acff3dff42a5@github.com>

On Thu, 30 Nov 2023 11:13:14 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename vmath to sleef in configure
>
> make/autoconf/lib-sleef.m4 line 56:
> 
>> 54:         AC_MSG_CHECKING([for the specified LIBSLEEF])
>> 55:         if test -e ${with_libsleef}/lib/libsleef.so &&
>> 56:            test -e ${with_libsleef}/include/sleef.h; then
> 
> This fails on my system because libsleef is in `/usr/local/lib64/`. This is the correct place to look according to the Linux FHS. You should _not_ hard-code `/lib`

Did you try to find the libsleef by passing `--with-libsleef=` ? Currently `--with-libsleef=` can only work for people manually built from sleef source code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1411488447

From duke at openjdk.org  Fri Dec  1 01:22:08 2023
From: duke at openjdk.org (jmehrens)
Date: Fri, 1 Dec 2023 01:22:08 GMT
Subject: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter
 of transferTo() is trusted [v2]
In-Reply-To: <qzx0Xi4T398BV7qeBj6bLS-R7LcLA8JE-gMwxuD3lcI=.5d447f3b-328e-40df-b823-4a74eec3f1a4@github.com>
References: <zRINQ_LiJh7Ifnt7UwL2Q0PcpestYwzx74fopLor_2w=.c93f3a3a-8172-40d2-9e5d-0530eb905f2a@github.com>
 <qvDeG-fdlsLWk-rEcZHRMA3Mv0hJag2hvJlHqu4Y-yo=.3b0e1f6f-b69d-4471-909a-9d4dd45618b1@github.com>
 <KbgvHJmxFxcJSCf2iOvYxblmTvg8RDV1QtqhylX-bHo=.fe8878ab-7b19-4e72-81f3-d6a65965fa1b@github.com>
 <qzx0Xi4T398BV7qeBj6bLS-R7LcLA8JE-gMwxuD3lcI=.5d447f3b-328e-40df-b823-4a74eec3f1a4@github.com>
Message-ID: <eyFDDWXEomWObizhgeIormpHtFAXmTrXbWkMOxK2ML4=.a3d6ca9d-5b73-456c-b997-78bc5894c136@github.com>

On Thu, 30 Nov 2023 23:27:13 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Good catch: that in fact defeats the protection.
>
> Changed in 176d5165f7d8f3fa4814c9838abb5d18d9f3c338 not to trust `FilterOutputStream`s.

The only other alternative would be to walk `((FilterOutputStream)out).out` and if everything in the out chain is in the "java." package then the out can be trusted.

byte[] tmp = null;
for (OutputStream os = out; os != null;) {
    if (os.getClass().getPackageName().startsWith("java.")) {
        if (os instanceof FilterOutputStream fos) {
            //loops in this chain is going to cause this code to never end.
            // self reference A -> A or transitive reference A -> B -> C ->A
            os = fos.out;
            continue;
        }
        break;
    }
            
    tmp = new byte[Integer.min(len, MAX_TRANSFER_SIZE)];
    break;
}

I don't like the approach of deny list, walking the chain as (subjectively) it seems too fragile.

Also I think I can break this version of the code with ChannelOutputStream. I didn't run this through a compiler nor test it but the idea is that ChannelOutputStream calls ByteBuffer.wrap(bs) and doesn't call ByteBuffer.asReadOnlyBuffer.  So a malicious WritableByteChannel should be able to gain access to the original array:

WritableByteChannel wolf = new WritableByteChannel() {
public int write(ByteBuffer src) throws IOException {
      src.array()[0] = '0'; //oh no!
      return 0;
 }
};

ByteArrayInputStream bais = new ByteArrayInputStream(bytes);
OutputStream wolfInSheepSuitAndTie = Channels.newOutputStream(wolf);
bais.transferTo(wolfInSheepSuitAndTie);


Which leads us back to an allow list that Alan was talking about and the draw backs that it brings.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16893#discussion_r1411491609

From xgong at openjdk.org  Fri Dec  1 01:22:15 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 1 Dec 2023 01:22:15 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v5]
In-Reply-To: <WsVnzofMlpBbTX3sKjOxbdkOxpujdPyNv7VlPZ9g72M=.04bb24ee-ec4f-48ba-bc8d-a4ee68b0eedf@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <nZFspjlPXfeQxrr5cKfbjeL3typf6DKSgNQUNszhufE=.caac471d-9c7b-4f8f-953f-04ee4a13f111@github.com>
 <WsVnzofMlpBbTX3sKjOxbdkOxpujdPyNv7VlPZ9g72M=.04bb24ee-ec4f-48ba-bc8d-a4ee68b0eedf@github.com>
Message-ID: <WXWoaO4OuJ9zqTe9JxFuVEML97LM84F_XUdFuEKNZBA=.79a6e865-a699-4b02-8464-93f6a470f0a1@github.com>

On Thu, 30 Nov 2023 20:13:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Not having a build time dependency on libsleef means you cannot really verify that the functions you want to call are correct, but maybe you feel secure that they will never change?

I'm not sure. The main reason that we add such a wrapper library is to catch the sleef's ABI version changing earlier (i.e. at build time). So using .s code and not including sleef at built time can not match this requirement?

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1835248759

From jpai at openjdk.org  Fri Dec  1 01:30:10 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 1 Dec 2023 01:30:10 GMT
Subject: RFR: 8320798: Console read line with zero out should zero out
 underlying buffer [v3]
In-Reply-To: <8mADwh5tk-5DhucpbLxUAiPDOgxSkJru210ndcjXWaU=.f1dbb46e-974a-4975-8b08-cb8d34bf92cc@github.com>
References: <CdG_iGykiGmAUIsoDTD7KBhH4pzbLDhFU5PVxiTwSNU=.10d379f6-427f-493a-9c24-a616e8d5f329@github.com>
 <8mADwh5tk-5DhucpbLxUAiPDOgxSkJru210ndcjXWaU=.f1dbb46e-974a-4975-8b08-cb8d34bf92cc@github.com>
Message-ID: <vuY38UbdAc25_6guYSxx-vDttmljH-VnqCuEqVAXqrg=.bf4e1aac-1cfc-4278-9997-5a15d633feb2@github.com>

On Thu, 30 Nov 2023 17:39:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> It is best practice to zero out the underlying buffer after use.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove ensureOpen()

Thank you for the update Naoto. The changes look good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16861#pullrequestreview-1758847432

From xgong at openjdk.org  Fri Dec  1 01:33:12 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 1 Dec 2023 01:33:12 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v5]
In-Reply-To: <nZFspjlPXfeQxrr5cKfbjeL3typf6DKSgNQUNszhufE=.caac471d-9c7b-4f8f-953f-04ee4a13f111@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <nZFspjlPXfeQxrr5cKfbjeL3typf6DKSgNQUNszhufE=.caac471d-9c7b-4f8f-953f-04ee4a13f111@github.com>
Message-ID: <XHN46bYotm3S0YdY5J3Uea28KgaFpRKCEPxFGv2CmHc=.9e3f0d53-f0ab-453a-9a47-1f82f2bc87fe@github.com>

On Thu, 30 Nov 2023 06:39:43 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
>> 
>> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
>> 
>> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
>> 
>> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
>> 
>> [1] https://github.com/openjdk/jdk/pull/3638
>> [2] https://sleef.org/
>> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
>> [4] https://packages.debian.org/bookworm/libsleef3
>> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename vmath to sleef in configure

> Okay, now I found a few more of your comments that I missed before. I apologize, the Github PR review UI can be a bit confusing when discussions are taking place in multiple locations. So, here's a revision to my list above:
> 
> 1. An aach64 CPU can have both Neon and SVE present at the same time.
> 2. You are assuming that Neon is always present, and what I referred to as the fallback case is in fact using Neon instead of SVE.
> 3. You would like to split vect_math.c into two parts, e.g.  vect_math_neon.c and vect_math_sve.c.
> 4. You will then, use heuristics in hotspot to determine at runtime if SVE or Neon functionality should be used.  Even if SVE is present on the runtime machine, heuristics can chose to use the Neon implementation anyway in some cases.
> 5. Only vect_math_sve.c. need the -march+sve.

Yes, all the above are true.

> 6. The neon part do not need the -march+sve flag, and will fail if built with this flag. (???)

Current neon code does not need the `-march=arm-a+sve` flag, but it will not fail if we built with it. Because the C compiler (GCC/Clang) can also supports SVE and NEON at the same time. My concert is that if we build the neon code with sve flags,  it has the possibility that compiler may generate SVE specific instructions inside the NEON functions in future (e.g. if sve has new features related to method call) , although it doesn't happen now. If so, calling the neon stubs (which contains sve instructions) on non-sve supported machines in runtime may crash. Hence, it's more safe if we can separate neon and sve code and use different flags for them.


> Anyway, it is straightforward to add compiler flags to individual files. You do it like this:
> 
> $(eval $(call SetupJdkLibrary, BUILD_LIBVMATH, \
      NAME := vmath, \
      CFLAGS := $(CFLAGS_JDKLIB) $(LIBSLEEF_CFLAGS) -fvisibility=default, \
      vect_math_sve.c_CFLAGS := $(SVE_CFLAGS), \
 ...

Thanks so much for this. That's very helpful!

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1835258683

From jpai at openjdk.org  Fri Dec  1 01:34:05 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 1 Dec 2023 01:34:05 GMT
Subject: RFR: 8320699: Add parameter to skip progress logging of
 OutputAnalyzer [v2]
In-Reply-To: <-gLq1S8NvfT65BAJBv59gCbHv6kDsKYV-WszQLgYN1k=.7e0946f2-2cd2-43b4-b48b-93ce0ce86ed7@github.com>
References: <nMSAMM8k9aiAM3qiRuj-jmyIVugoNOI95xu2N48B0e8=.64a80b3c-cc0d-44c2-ab61-29a8068d4f3d@github.com>
 <-gLq1S8NvfT65BAJBv59gCbHv6kDsKYV-WszQLgYN1k=.7e0946f2-2cd2-43b4-b48b-93ce0ce86ed7@github.com>
Message-ID: <dQ53YrOPj8_UuyMGDKpP5Bu907kwLMQ7uO74gr8qSaY=.7a0dd740-3ea6-42da-9619-ba36423ad0f9@github.com>

On Thu, 30 Nov 2023 16:23:39 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Tests using ProcessTools.executeProcess gets the following output written to stdout:
>> [2023-11-24T09:58:16.797540608Z] Gathering output for process 2517117
>> [2023-11-24T09:58:23.070781345Z] Waiting for completion for process 2517117
>> [2023-11-24T09:58:23.071045055Z] Waiting for completion finished for process 2517117
>> 
>> This might be good for some use cases and debugging, but some tests spawns a large number of processes and for those this output fills up the log files.
>> 
>> I propose that we add a way to turn of this output for tests where we find this output to be too noisy.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update OutputBuffer.java copyright years

These changes look good to me. Please wait for another review before integrating.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16807#pullrequestreview-1758849913

From cjplummer at openjdk.org  Fri Dec  1 01:45:04 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 1 Dec 2023 01:45:04 GMT
Subject: RFR: 8320129: "top" command during jtreg failure handler does not
 display CPU usage on OSX
In-Reply-To: <cylR98W-HGZUXrw7n5BMFLq-efMWfdg7ZcaW6OQaIa0=.edaa4e47-a216-4dde-be51-b5b47fd978e6@github.com>
References: <cylR98W-HGZUXrw7n5BMFLq-efMWfdg7ZcaW6OQaIa0=.edaa4e47-a216-4dde-be51-b5b47fd978e6@github.com>
Message-ID: <Zq_385nLTn9g7T8HK7WLRjoSZ6Kmx6Bt8gzsOdLQGkM=.fd6d10e4-56c0-481f-8f85-967ef93d5cbd@github.com>

On Fri, 1 Dec 2023 00:58:57 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Description of problem and propsed fix from @plummercj 
> '
> In test/failure_handler/src/share/conf/mac.properties we have:
> 
> process.top.app=top
> process.top.args=-l 1
> 
> So top is run with the "-l 1" args, causing it to do one iteration and then exit. Unfortunately the first iteration always shows all 0's for CPU usage. If you do at least 2 iterations, you do see the proper CPU usage on the 2nd iteration. The user just needs to know to scroll down to see it. I suggest we start using "-l 2" unless someone has a better idea.
> 
> BTW, for proper CPU usage you can instead look at the failure handler "ps" output, which seems to be correct. But it is nice to have "top" produce the correct output so all the CPU hogs are at the top of the list.
> '
> 
> I verified that top report contains now 2 samples.

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16915#pullrequestreview-1758861630

From asemenyuk at openjdk.org  Fri Dec  1 01:56:21 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 1 Dec 2023 01:56:21 GMT
Subject: Integrated: 8227529: With malformed --app-image the error messages are
 awful
In-Reply-To: <MjTGH0g_O0Gh3ZXgiI15oM-kZ12NHYzI8-Bn8E4GoeI=.93571a98-b498-4bd2-9a35-a949fb7ab609@github.com>
References: <MjTGH0g_O0Gh3ZXgiI15oM-kZ12NHYzI8-Bn8E4GoeI=.93571a98-b498-4bd2-9a35-a949fb7ab609@github.com>
Message-ID: <aVXpiZ7Cs210SyOpDl9aeRJ0GLMyk3hRpDddpv1rXOA=.6a8b02a2-e2ff-4b21-bd01-92024f49511c@github.com>

On Thu, 30 Nov 2023 14:14:56 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Add tests to make sure jpackage emits meaningful error messages when used with invalid app images.
> 
> Added `JPackageCommand.nullableOutputBundle()` function that returns an empty `Optional` instance if it fails to deduce a path to the output bundle from jpackage command line. This is the case when jpackage command is used with `--app-image` cli option and referenced app image directory is missing `.jpackage.xml` file.

This pull request has now been integrated.

Changeset: 56d4c33f
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/56d4c33f4096d98d08eba870070b5f21125f80be
Stats:     71 lines in 3 files changed: 64 ins; 0 del; 7 mod

8227529: With malformed --app-image the error messages are awful

Reviewed-by: almatvee

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

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

From bpb at openjdk.org  Fri Dec  1 02:51:04 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 1 Dec 2023 02:51:04 GMT
Subject: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter
 of transferTo() is trusted [v2]
In-Reply-To: <eyFDDWXEomWObizhgeIormpHtFAXmTrXbWkMOxK2ML4=.a3d6ca9d-5b73-456c-b997-78bc5894c136@github.com>
References: <zRINQ_LiJh7Ifnt7UwL2Q0PcpestYwzx74fopLor_2w=.c93f3a3a-8172-40d2-9e5d-0530eb905f2a@github.com>
 <qvDeG-fdlsLWk-rEcZHRMA3Mv0hJag2hvJlHqu4Y-yo=.3b0e1f6f-b69d-4471-909a-9d4dd45618b1@github.com>
 <KbgvHJmxFxcJSCf2iOvYxblmTvg8RDV1QtqhylX-bHo=.fe8878ab-7b19-4e72-81f3-d6a65965fa1b@github.com>
 <qzx0Xi4T398BV7qeBj6bLS-R7LcLA8JE-gMwxuD3lcI=.5d447f3b-328e-40df-b823-4a74eec3f1a4@github.com>
 <eyFDDWXEomWObizhgeIormpHtFAXmTrXbWkMOxK2ML4=.a3d6ca9d-5b73-456c-b997-78bc5894c136@github.com>
Message-ID: <EC7_LI524HAiIY3cDlcVmoqKY4H4eMy7shWEyDU-td8=.b2f87afe-9d6b-41ab-9145-858f4deded60@github.com>

On Fri, 1 Dec 2023 01:19:32 GMT, jmehrens <duke at openjdk.org> wrote:

>> Changed in 176d5165f7d8f3fa4814c9838abb5d18d9f3c338 not to trust `FilterOutputStream`s.
>
> The only other alternative would be to walk `((FilterOutputStream)out).out` and if everything in the out chain is in the "java." package then the out can be trusted.
> 
> byte[] tmp = null;
> for (OutputStream os = out; os != null;) {
>     if (os.getClass().getPackageName().startsWith("java.")) {
>         if (os instanceof FilterOutputStream fos) {
>             //loops in this chain is going to cause this code to never end.
>             // self reference A -> A or transitive reference A -> B -> C ->A
>             os = fos.out;
>             continue;
>         }
>         break;
>     }
>             
>     tmp = new byte[Integer.min(len, MAX_TRANSFER_SIZE)];
>     break;
> }
> 
> I don't like the approach of deny list, walking the chain as (subjectively) it seems too fragile.
> 
> Also I think I can break this version of the code with ChannelOutputStream. I didn't run this through a compiler nor test it but the idea is that ChannelOutputStream calls ByteBuffer.wrap(bs) and doesn't call ByteBuffer.asReadOnlyBuffer.  So a malicious WritableByteChannel should be able to gain access to the original array:
> 
> WritableByteChannel wolf = new WritableByteChannel() {
> public int write(ByteBuffer src) throws IOException {
>       src.array()[0] = '0'; //oh no!
>       return 0;
>  }
> };
> 
> ByteArrayInputStream bais = new ByteArrayInputStream(bytes);
> OutputStream wolfInSheepSuitAndTie = Channels.newOutputStream(wolf);
> bais.transferTo(wolfInSheepSuitAndTie);
> 
> However, the ChannelOutputStream is in sun.nio.ch so on second thought it shouldn't break.  The pattern is repeated in Channels.newOutputStream(AsynchronousByteChannel ch) so that should fail as it is in the "java." namespace.
> 
> I think an allow list would be safer but that brings all the drawbacks that Alan was talking about before.

I might have done this incorrectly, but with this version of the above `wolf` I do not see any corruption:

        java.nio.channels.WritableByteChannel wolf =
            new java.nio.channels.WritableByteChannel() {
                private boolean closed = false;
                
                public int write(java.nio.ByteBuffer src) throws IOException {
                    int rem = src.remaining();
                    Arrays.fill(src.array(), src.arrayOffset() + src.position(),
                                src.arrayOffset() + src.limit(),
                                (byte)'0');
                    src.position(src.limit());
                    return rem;
                }

                public boolean isOpen() {
                    return !closed;
                }

                public void close() throws IOException {
                    closed = true;
                }
            };

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16893#discussion_r1411539285

From duke at openjdk.org  Fri Dec  1 04:04:04 2023
From: duke at openjdk.org (jmehrens)
Date: Fri, 1 Dec 2023 04:04:04 GMT
Subject: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter
 of transferTo() is trusted [v2]
In-Reply-To: <EC7_LI524HAiIY3cDlcVmoqKY4H4eMy7shWEyDU-td8=.b2f87afe-9d6b-41ab-9145-858f4deded60@github.com>
References: <zRINQ_LiJh7Ifnt7UwL2Q0PcpestYwzx74fopLor_2w=.c93f3a3a-8172-40d2-9e5d-0530eb905f2a@github.com>
 <qvDeG-fdlsLWk-rEcZHRMA3Mv0hJag2hvJlHqu4Y-yo=.3b0e1f6f-b69d-4471-909a-9d4dd45618b1@github.com>
 <KbgvHJmxFxcJSCf2iOvYxblmTvg8RDV1QtqhylX-bHo=.fe8878ab-7b19-4e72-81f3-d6a65965fa1b@github.com>
 <qzx0Xi4T398BV7qeBj6bLS-R7LcLA8JE-gMwxuD3lcI=.5d447f3b-328e-40df-b823-4a74eec3f1a4@github.com>
 <eyFDDWXEomWObizhgeIormpHtFAXmTrXbWkMOxK2ML4=.a3d6ca9d-5b73-456c-b997-78bc5894c136@github.com>
 <EC7_LI524HAiIY3cDlcVmoqKY4H4eMy7shWEyDU-td8=.b2f87afe-9d6b-41ab-9145-858f4deded60@github.com>
Message-ID: <jQBQyMguCr22Ihi66y1Ub4pbCBVgYzDMqaPkj_FvIFM=.4ad14e27-50ff-4621-91cf-bfbf9cf726b9@github.com>

On Fri, 1 Dec 2023 02:48:42 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> The only other alternative would be to walk `((FilterOutputStream)out).out` and if everything in the out chain is in the "java." package then the out can be trusted.
>> 
>> byte[] tmp = null;
>> for (OutputStream os = out; os != null;) {
>>     if (os.getClass().getPackageName().startsWith("java.")) {
>>         if (os instanceof FilterOutputStream fos) {
>>             //loops in this chain is going to cause this code to never end.
>>             // self reference A -> A or transitive reference A -> B -> C ->A
>>             os = fos.out;
>>             continue;
>>         }
>>         break;
>>     }
>>             
>>     tmp = new byte[Integer.min(len, MAX_TRANSFER_SIZE)];
>>     break;
>> }
>> 
>> I don't like the approach of deny list, walking the chain as (subjectively) it seems too fragile.
>> 
>> Also I think I can break this version of the code with ChannelOutputStream. I didn't run this through a compiler nor test it but the idea is that ChannelOutputStream calls ByteBuffer.wrap(bs) and doesn't call ByteBuffer.asReadOnlyBuffer.  So a malicious WritableByteChannel should be able to gain access to the original array:
>> 
>> WritableByteChannel wolf = new WritableByteChannel() {
>> public int write(ByteBuffer src) throws IOException {
>>       src.array()[0] = '0'; //oh no!
>>       return 0;
>>  }
>> };
>> 
>> ByteArrayInputStream bais = new ByteArrayInputStream(bytes);
>> OutputStream wolfInSheepSuitAndTie = Channels.newOutputStream(wolf);
>> bais.transferTo(wolfInSheepSuitAndTie);
>> 
>> However, the ChannelOutputStream is in sun.nio.ch so on second thought it shouldn't break.  The pattern is repeated in Channels.newOutputStream(AsynchronousByteChannel ch) so that should fail as it is in the "java." namespace.
>> 
>> I think an allow list would be safer but that brings all the drawbacks that Alan was talking about before.
>
> I might have done this incorrectly, but with this version of the above `wolf` I do not see any corruption:
> 
>         java.nio.channels.WritableByteChannel wolf =
>             new java.nio.channels.WritableByteChannel() {
>                 private boolean closed = false;
>                 
>                 public int write(java.nio.ByteBuffer src) throws IOException {
>                     int rem = src.remaining();
>                     Arrays.fill(src.array(), src.arrayOffset() + src.position(),
>                                 src.arrayOffset() + src.limit(),
>                                 (byte)'0');
>                     src.position(src.limit());
>                     return rem;
>                 }
> 
>                 public boolean isOpen() {
>                     return !closed;
>                 }
> 
>                 public void close() throws IOException {
>                     closed = true;
>                 }
>             };

@bplb You did it right.  The reason it works is because the ChannelOutputStream is in the "sun." package and not the "java." package.  That is not the case for Channels.newOutputStream(AsynchronousByteChannel ch) as that wrapper should be able to access the byte array.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16893#discussion_r1411575001

From alanb at openjdk.org  Fri Dec  1 07:34:14 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 1 Dec 2023 07:34:14 GMT
Subject: Integrated: 8320716: ResolvedModule::reads includes self when
 configuration contains two or more automatic modules
In-Reply-To: <ZZ5rpp1ZhSDMQ3JUB_vqwISbvZeHyPjvEQEchjnp_XQ=.30a8dbdb-a1ac-45c3-ba0d-e13e0c2411e7@github.com>
References: <ZZ5rpp1ZhSDMQ3JUB_vqwISbvZeHyPjvEQEchjnp_XQ=.30a8dbdb-a1ac-45c3-ba0d-e13e0c2411e7@github.com>
Message-ID: <ZGtkZdWabhAWGX8njNUcNiD05wrcgsRgNM618epMp6s=.bdf95c0b-1f88-4e36-9245-83b874f58488@github.com>

On Sun, 26 Nov 2023 18:18:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is update to the specification of the j.l.module.ResolvedModule.reads method to clarify that the set of resolved modules returned does not include itself. There is a small implementation change to align with the specification and fix an anomaly that arises with configurations that contain two or more automatic modules.
> 
> Every module reads itself but the intent with ResolvedModule.reads is that it returns a set that doesn't include self. As things stand right now, the returned set does not include self when all modules in the configuration are explicit modules.  However, if the configuration contains two or more automatic modules then the set includes self, a side effect of augmenting the readability graph due to implied readability.
> 
> The specification of the "reads" method is updated. The implementation is also changed to skip automatic modules when augmenting the graph due to implied readability. It is skipped as each automatic module already reads all other modules. Note that it is not goal here to change the algorithm for handling implied readability, this may be a topic for a follow on PR.
> 
> The existing ConfigurationTest already includes several tests for configurations consisting solely of explicit modules, no updates are needed. For configurations that include automatic modules, the existing AutomaticModulesTest is updated to add new asserts to each of the testConfigurationXXX methods. I decided to migrate this test to JUnit while visiting, most of it is just migrating the TestNG data providers to be parameterized tests. If needed then we could separate this but it's a simple migration so I left it in.

This pull request has now been integrated.

Changeset: 2476be45
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2476be4590f9ece654d16bf7b94f108f18a86061
Stats:     234 lines in 3 files changed: 46 ins; 51 del; 137 mod

8320716: ResolvedModule::reads includes self when configuration contains two or more automatic modules

Reviewed-by: mchung

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

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

From xgong at openjdk.org  Fri Dec  1 08:48:52 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 1 Dec 2023 08:48:52 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v6]
In-Reply-To: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
Message-ID: <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>

> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
> 
> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
> 
> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
> 
> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
> 
> [1] https://github.com/openjdk/jdk/pull/3638
> [2] https://sleef.org/
> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
> [4] https://packages.debian.org/bookworm/libsleef3
> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html

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

 - Separate neon and sve functions into two source files
 - Merge branch 'jdk:master' into JDK-8312425
 - Rename vmath to sleef in configure
 - Address review comments in build system
 - Add a bundled native lib in jdk as a bridge to libsleef
 - Merge 'jdk:master' into JDK-8312425
 - Disable sleef by default
 - Merge 'jdk:master' into JDK-8312425
 - 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16234/files
  - new: https://git.openjdk.org/jdk/pull/16234/files/c1ce1968..ee5caf6d

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

  Stats: 638331 lines in 1866 files changed: 100400 ins; 474467 del; 63464 mod
  Patch: https://git.openjdk.org/jdk/pull/16234.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16234/head:pull/16234

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

From alanb at openjdk.org  Fri Dec  1 08:53:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 1 Dec 2023 08:53:04 GMT
Subject: RFR: JDK-8319626: Override toString() for ZipFile [v5]
In-Reply-To: <7Iv6zv2OJnMWtJLbxAm8UnyphN19jbbJ-FuzK4yzr58=.4f1d7891-9484-4e79-8bb0-922cdc094034@github.com>
References: <UEVJDXC8Cs_RSBUEsWgmq8SPvI-T4LSydbPKr8u29iA=.fdce7d47-87a8-42ba-9cd4-119bf9023ad9@github.com>
 <wB4yFDlB09wPiTVnVh_c8D6CCd891DVhkXRhVYS6ds0=.39caf916-1699-4f55-a19a-769f99b6b03e@github.com>
 <lpGHlMeTl3m97zKwyq8KL42LrIgCLkF3eDBItZGnyZs=.8f751dfa-ad8e-4fab-bfee-13bfb320d0ea@github.com>
 <z2KCa_GpQ99W9mkXWDpfPeayo9p4GZSALbyXMcOUmis=.00ade9f7-5530-4b7e-914e-32e86fbc8df4@github.com>
 <kJg-Cqk1k9WG0O8ZmtzX4S1WmK1rDaPVI_oiKO04pTE=.e4087dbc-8cc0-403a-b62c-aa524005d849@github.com>
 <7Iv6zv2OJnMWtJLbxAm8UnyphN19jbbJ-FuzK4yzr58=.4f1d7891-9484-4e79-8bb0-922cdc094034@github.com>
Message-ID: <jTdmT2eHGx2qpT49lS1Kfc7qOREJ129QIV8NL9ZChXY=.920b6abb-4276-45aa-a418-005f3a414a12@github.com>

On Thu, 30 Nov 2023 21:08:35 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Hello Justin,
>> 
>>> I am not sure if you have a preference one way or another regarding providing the full path versus just the file name, but I can switch the full path for just the file name if need be.
>> 
>> My opinion is that we should not use the absolute path here. Section 2.1 of secure coding guidelines https://www.oracle.com/java/technologies/javase/seccodeguide.html#2-1 suggests not to include full paths in exception messages.
>> 
>> With the proposed change to the toString() method here, which uses absolute paths, I think it would then mean that we would have to review (within the JDK) usages of (explicit or implicit) `ZipFile.toString()` to prevent accidentally including the complete paths in the exceptions, like in the case below:
>> 
>> 
>> final ZipFile zf = new ZipFile("/home/me/xyz.zip");
>> ... // do something 
>> throw new Exception("failed to handle zipfile " + zf);
>
> Thanks Jai, that makes sense. Replaced full path with just the base name in latest commit.

I think the second paragraph of the method description is problematic. Documenting the representation and then saying it is subject to change is going to cause problems in the future? Can you just drop this paragraph?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16643#discussion_r1411789346

From alanb at openjdk.org  Fri Dec  1 08:57:05 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 1 Dec 2023 08:57:05 GMT
Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v4]
In-Reply-To: <P9uONCgJlH6ON2nqV1TxpJ5tn_XrGmBuFWKrU45JrKs=.4f773cc2-b13c-42c8-a7f4-2591af065743@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
 <P9uONCgJlH6ON2nqV1TxpJ5tn_XrGmBuFWKrU45JrKs=.4f773cc2-b13c-42c8-a7f4-2591af065743@github.com>
Message-ID: <Lx5ZzbGIV584QK73SK4GaA8OF-41M-BECYxzWGmh8Fk=.37a42cf6-50e9-48f4-9d76-b071c2ead567@github.com>

On Thu, 30 Nov 2023 23:49:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start making preparations for JDK 23.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update symbol files to JDK 22 b26.

Good good. I assume you'll bump the copyright header on the files that need it before integration, e.g. JavacTestingAbstractProcessor.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16505#pullrequestreview-1759306298

From jpai at openjdk.org  Fri Dec  1 09:57:21 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 1 Dec 2023 09:57:21 GMT
Subject: RFR: 8321163: [test] OutputAnalyzer.getExitValue() unnecessarily logs
 even when process has already completed
Message-ID: <uZ77Eagw9Lxz1BKJ8fMnCzvp8Z5VVqsGnsLZtqKZDIo=.0fb8e6cf-7d79-4d4e-b99d-171e008210e9@github.com>

Can I please get a review for this change to the test library's `OutputAnalyzer` class, which proposes to remove some unnecessary logging from the `getExitValue()` call?

As noted in https://bugs.openjdk.org/browse/JDK-8321163, right now this method logs:


[2023-11-24T11:47:54.557561Z] Waiting for completion for process 24909
[2023-11-24T11:47:54.557873Z] Waiting for completion finished for process 24909


even when the process has already completed and the exit value already known. The change in this PR makes it such that if the exit value is available then we no longer log this (nor call `process.waitFor()`).

No new tests have been added given the nature of this change. tier1, tier2 and tier3 tests continue to pass with this change.

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

Commit messages:
 - 8321163: [test] OutputAnalyzer.getExitValue() unnecessarily logs even when process has already completed

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

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

From aph at openjdk.org  Fri Dec  1 10:00:14 2023
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 1 Dec 2023 10:00:14 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v5]
In-Reply-To: <U5tslVEJqPTFCqtp_apAwmECDHvE0UOE7xN3l0KU70M=.f11ab8e8-7b8f-4603-937a-cf395cb10c5d@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <nZFspjlPXfeQxrr5cKfbjeL3typf6DKSgNQUNszhufE=.caac471d-9c7b-4f8f-953f-04ee4a13f111@github.com>
 <8SBUvWGDLtQmwYPRBDeUkeuq4pf2nJfKfDY5rzZODFU=.3f1cc0ff-02e6-4a4e-9425-5ffccc9cbc8f@github.com>
 <U5tslVEJqPTFCqtp_apAwmECDHvE0UOE7xN3l0KU70M=.f11ab8e8-7b8f-4603-937a-cf395cb10c5d@github.com>
Message-ID: <SpmEywJ-EtFMxPwE2pFHnwlPS5ZHfUUcuj2nM5ui06k=.caee3bc9-4bce-4fc8-b369-691f9b2fae54@github.com>

On Thu, 30 Nov 2023 14:50:24 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Do this, but with the name vect_math.S. Don't use SLEEF headers in the build. I think you can do this with no build-time dependency on SLEEF at all if you load the library lazily at runtime.
>> 
>> [vect_math.S.txt](https://github.com/openjdk/jdk/files/13512306/vect_math.S.txt)
>
>> [vect_math.S.txt](https://github.com/openjdk/jdk/files/13512306/vect_math.S.txt)
> 
> I guess this will live only in os_linux and os_bsd because the Windows compiler won't like it AFAIK.

> @theRealAph So your suggestion is that this assembly files lives in hotspot, instead of jdk.incubator.vector?

I don't think it much matters, because these functions will only be available to HotSpot.

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1835801386

From jpai at openjdk.org  Fri Dec  1 10:00:07 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 1 Dec 2023 10:00:07 GMT
Subject: RFR: 8320129: "top" command during jtreg failure handler does not
 display CPU usage on OSX
In-Reply-To: <cylR98W-HGZUXrw7n5BMFLq-efMWfdg7ZcaW6OQaIa0=.edaa4e47-a216-4dde-be51-b5b47fd978e6@github.com>
References: <cylR98W-HGZUXrw7n5BMFLq-efMWfdg7ZcaW6OQaIa0=.edaa4e47-a216-4dde-be51-b5b47fd978e6@github.com>
Message-ID: <a0Fhr7SOA4fiHDPTmFb2X0vEDXA7bBHbGkopsbXb1Kk=.26a56c0b-35f8-4ba3-a440-4ad44e0bac93@github.com>

On Fri, 1 Dec 2023 00:58:57 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Description of problem and propsed fix from @plummercj 
> '
> In test/failure_handler/src/share/conf/mac.properties we have:
> 
> process.top.app=top
> process.top.args=-l 1
> 
> So top is run with the "-l 1" args, causing it to do one iteration and then exit. Unfortunately the first iteration always shows all 0's for CPU usage. If you do at least 2 iterations, you do see the proper CPU usage on the 2nd iteration. The user just needs to know to scroll down to see it. I suggest we start using "-l 2" unless someone has a better idea.
> 
> BTW, for proper CPU usage you can instead look at the failure handler "ps" output, which seems to be correct. But it is nice to have "top" produce the correct output so all the CPU hogs are at the top of the list.
> '
> 
> I verified that top report contains now 2 samples.

Hello Leonid, this looks OK to me. I see that the `windows.properties` and `linux.properties` for the `top` command use `-n 1`. Should we be doing a similar change in those files too, to use `-n 2`?

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

PR Comment: https://git.openjdk.org/jdk/pull/16915#issuecomment-1835801008

From aph at openjdk.org  Fri Dec  1 10:05:19 2023
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 1 Dec 2023 10:05:19 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v5]
In-Reply-To: <WXWoaO4OuJ9zqTe9JxFuVEML97LM84F_XUdFuEKNZBA=.79a6e865-a699-4b02-8464-93f6a470f0a1@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <nZFspjlPXfeQxrr5cKfbjeL3typf6DKSgNQUNszhufE=.caac471d-9c7b-4f8f-953f-04ee4a13f111@github.com>
 <WsVnzofMlpBbTX3sKjOxbdkOxpujdPyNv7VlPZ9g72M=.04bb24ee-ec4f-48ba-bc8d-a4ee68b0eedf@github.com>
 <WXWoaO4OuJ9zqTe9JxFuVEML97LM84F_XUdFuEKNZBA=.79a6e865-a699-4b02-8464-93f6a470f0a1@github.com>
Message-ID: <GKVDsKAo5D0GxwenweAGcQXem0-t6Jk80VhUoFciNw0=.b4886d75-1155-42f8-950d-d7500f628732@github.com>

On Fri, 1 Dec 2023 01:19:12 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> > Not having a build time dependency on libsleef means you cannot really verify that the functions you want to call are correct, but maybe you feel secure that they will never change?
> 
> I'm not sure. The main reason that we add such a wrapper library is to catch the sleef's ABI version changing earlier (i.e. at build time). So using .s code and not including sleef at built time can not match this requirement?

I don't know what this means. If we're using an external SLEEF, then we can't catch ABI versions changes at build time.

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1835805290

From aph at openjdk.org  Fri Dec  1 10:05:23 2023
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 1 Dec 2023 10:05:23 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v5]
In-Reply-To: <mnf_hjWdemelALPlwcS8mnKIxR5ljIyGD6MHpqCPDsQ=.0cb49580-ed76-4728-a604-acff3dff42a5@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <nZFspjlPXfeQxrr5cKfbjeL3typf6DKSgNQUNszhufE=.caac471d-9c7b-4f8f-953f-04ee4a13f111@github.com>
 <9VeMdTAJPaPZDg9ZW7FVJOf9XGl4gGqAS-2g8SFc9c0=.36792cd5-66d9-4abc-ba0c-aee3478627f4@github.com>
 <mnf_hjWdemelALPlwcS8mnKIxR5ljIyGD6MHpqCPDsQ=.0cb49580-ed76-4728-a604-acff3dff42a5@github.com>
Message-ID: <aArEqABKvjZDCxOkkpKS1rlX9Q0aafCUY8ZS3L5OBek=.f009f07b-c9e4-437b-a6d3-c86fb29d75a0@github.com>

On Fri, 1 Dec 2023 01:13:37 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> make/autoconf/lib-sleef.m4 line 56:
>> 
>>> 54:         AC_MSG_CHECKING([for the specified LIBSLEEF])
>>> 55:         if test -e ${with_libsleef}/lib/libsleef.so &&
>>> 56:            test -e ${with_libsleef}/include/sleef.h; then
>> 
>> This fails on my system because libsleef is in `/usr/local/lib64/`. This is the correct place to look according to the Linux FHS. You should _not_ hard-code `/lib`
>
> Did you try to find the libsleef by passing `--with-libsleef=` ? Currently `--with-libsleef=` can only work for people manually built from sleef source code.

Yes. It still failed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1411877145

From aph at openjdk.org  Fri Dec  1 10:08:11 2023
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 1 Dec 2023 10:08:11 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v5]
In-Reply-To: <GKVDsKAo5D0GxwenweAGcQXem0-t6Jk80VhUoFciNw0=.b4886d75-1155-42f8-950d-d7500f628732@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <nZFspjlPXfeQxrr5cKfbjeL3typf6DKSgNQUNszhufE=.caac471d-9c7b-4f8f-953f-04ee4a13f111@github.com>
 <WsVnzofMlpBbTX3sKjOxbdkOxpujdPyNv7VlPZ9g72M=.04bb24ee-ec4f-48ba-bc8d-a4ee68b0eedf@github.com>
 <WXWoaO4OuJ9zqTe9JxFuVEML97LM84F_XUdFuEKNZBA=.79a6e865-a699-4b02-8464-93f6a470f0a1@github.com>
 <GKVDsKAo5D0GxwenweAGcQXem0-t6Jk80VhUoFciNw0=.b4886d75-1155-42f8-950d-d7500f628732@github.com>
Message-ID: <bT3yG7Pt3b1aX7LruU5oNjHpoiHo2sj_fUJ3UhfPfOE=.1db43dbc-bfa3-401f-b889-ab855facfdae@github.com>

On Fri, 1 Dec 2023 09:59:58 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Not having a build time dependency on libsleef means you cannot really verify that the functions you want to call are correct, but maybe you feel secure that they will never change?

We can still have SLEEF tests, but they will require a SLEEF library to be there. We can't control what is present at runtime, though. What are you trying to verify?

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1835812963

From kevinw at openjdk.org  Fri Dec  1 10:09:15 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 1 Dec 2023 10:09:15 GMT
Subject: RFR: 8316649: JMX connection timeout cannot be changed and uses
 the default of 0 (infinite)
In-Reply-To: <AHzWJTFvWl3uqdSWODRqGoHIihnBhuEmsAtoqz9t3lQ=.d8031c9d-bb54-4fa8-84eb-0c61ce7cb8e6@github.com>
References: <AHzWJTFvWl3uqdSWODRqGoHIihnBhuEmsAtoqz9t3lQ=.d8031c9d-bb54-4fa8-84eb-0c61ce7cb8e6@github.com>
Message-ID: <ufBO68lvnE5Jn2FvJjcPduQj_eXxJJxOcwX4L6rzZpY=.14a9ee24-6ea9-45ba-afaa-622b57746c19@github.com>

On Tue, 21 Nov 2023 17:57:32 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> RMI Connections (in general) should use a timeout on the Socket connect call by default.
> 
> JMX connections use RMI and some connection failures never terminate.  The hang described in 8316649 is hard to reproduce manually: the description says it can be caused by a firewall that never returns a response.
> 
> src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
> has other timeouts but nothing to control the initial Socket connect.
> 
> Defaulting to a 1 minute timeout on connect has no effect on existing tests for RMI and JMX, and should go unnoticed in applications unless there really is a significant connection delay.  Specifying zero for the new System Property sun.rmi.transport.tcp.initialConnectTimeout uses the old code path of a connect with no timeout.
> 
> I have a test, but it is not realistically usable: although specifying a 1 millisecond timeout will often fail (as expected/desired for the test), it will often pass as the connection happens immediately.

Thanks for the feedback.
Additionally, there can be a concern that affecting all RMI activity with the timeout property could produce unintended side-effects.

At the moment the demand for the timeout is not strong, and the behaviour is what it has been for many years, so I am going to close this without progressing it.

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

PR Comment: https://git.openjdk.org/jdk/pull/16771#issuecomment-1835814563

From kevinw at openjdk.org  Fri Dec  1 10:09:16 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 1 Dec 2023 10:09:16 GMT
Subject: Withdrawn: 8316649: JMX connection timeout cannot be changed and uses
 the default of 0 (infinite)
In-Reply-To: <AHzWJTFvWl3uqdSWODRqGoHIihnBhuEmsAtoqz9t3lQ=.d8031c9d-bb54-4fa8-84eb-0c61ce7cb8e6@github.com>
References: <AHzWJTFvWl3uqdSWODRqGoHIihnBhuEmsAtoqz9t3lQ=.d8031c9d-bb54-4fa8-84eb-0c61ce7cb8e6@github.com>
Message-ID: <4unS4JFDIbdxbZVL0RPVLhp6YME98o-OJpUfmwWQ83Y=.b7e2f0d3-bc27-4941-baca-cc47d5e998bf@github.com>

On Tue, 21 Nov 2023 17:57:32 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> RMI Connections (in general) should use a timeout on the Socket connect call by default.
> 
> JMX connections use RMI and some connection failures never terminate.  The hang described in 8316649 is hard to reproduce manually: the description says it can be caused by a firewall that never returns a response.
> 
> src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
> has other timeouts but nothing to control the initial Socket connect.
> 
> Defaulting to a 1 minute timeout on connect has no effect on existing tests for RMI and JMX, and should go unnoticed in applications unless there really is a significant connection delay.  Specifying zero for the new System Property sun.rmi.transport.tcp.initialConnectTimeout uses the old code path of a connect with no timeout.
> 
> I have a test, but it is not realistically usable: although specifying a 1 millisecond timeout will often fail (as expected/desired for the test), it will often pass as the connection happens immediately.

This pull request has been closed without being integrated.

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

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

From aph at openjdk.org  Fri Dec  1 10:19:16 2023
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 1 Dec 2023 10:19:16 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v6]
In-Reply-To: <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
Message-ID: <Syv4IWJ121JzIDObF0lqtO8OwFRhrbtRk1BLstaXbAw=.cce3e27b-c5d8-4d00-9d66-5104d34eefa2@github.com>

On Fri, 1 Dec 2023 08:48:52 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
>> 
>> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
>> 
>> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
>> 
>> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
>> 
>> [1] https://github.com/openjdk/jdk/pull/3638
>> [2] https://sleef.org/
>> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
>> [4] https://packages.debian.org/bookworm/libsleef3
>> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html
>
> Xiaohong Gong has updated the pull request with a new target base 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:
> 
>  - Separate neon and sve functions into two source files
>  - Merge branch 'jdk:master' into JDK-8312425
>  - Rename vmath to sleef in configure
>  - Address review comments in build system
>  - Add a bundled native lib in jdk as a bridge to libsleef
>  - Merge 'jdk:master' into JDK-8312425
>  - Disable sleef by default
>  - Merge 'jdk:master' into JDK-8312425
>  - 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF

Let me summarize the issues, as I see them:

To a high-order approximation, no one builds their own JDK.
We want people to be able to use these vector math operations.
There is no need to depend on a specific SLEEF library version.
I do not expect SLEEF to break the ABI by e.g. renaming functions. (I know, but let's assume.)
As long as the functions we want to use are present, we should use them.
SLEEF is not (yet) a standard part of OSs and build systems.

We don't want to fail unnecessarily at runtime because of a SLEEF ABI version change.
We don't want to fail to build the JDK if our GCC is too old for SVE. (Is that a problem now? It might be.)
We want to be able to test and run with any version of SLEEF, as long as the functions we need are present.

It should be possible to drop a SLEEF library into the system, and the JDK will use it.
The alternative is to package SLEEF with the JDK.

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1835829658

From aph at openjdk.org  Fri Dec  1 10:22:21 2023
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 1 Dec 2023 10:22:21 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v6]
In-Reply-To: <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
Message-ID: <3cK9QjVQNIgZoWWhrWKEb3XxfbLjprjRMBbStWegH7M=.6df92651-b97d-445a-aa42-302ea791bbea@github.com>

On Fri, 1 Dec 2023 08:48:52 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
>> 
>> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
>> 
>> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
>> 
>> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
>> 
>> [1] https://github.com/openjdk/jdk/pull/3638
>> [2] https://sleef.org/
>> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
>> [4] https://packages.debian.org/bookworm/libsleef3
>> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html
>
> Xiaohong Gong has updated the pull request with a new target base 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:
> 
>  - Separate neon and sve functions into two source files
>  - Merge branch 'jdk:master' into JDK-8312425
>  - Rename vmath to sleef in configure
>  - Address review comments in build system
>  - Add a bundled native lib in jdk as a bridge to libsleef
>  - Merge 'jdk:master' into JDK-8312425
>  - Disable sleef by default
>  - Merge 'jdk:master' into JDK-8312425
>  - 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF

Oh, and:

If we can't trust SLEEF not to break the ABI we're using, we should not be using SLEEF.

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1835833150

From duke at openjdk.org  Fri Dec  1 10:43:04 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 1 Dec 2023 10:43:04 GMT
Subject: RFR: 8316141: Improve CEN header validation checking
In-Reply-To: <UPqU1snygN84AiDbn5nxQzfsxQrovnsRuSLHpROqAUc=.63d4c018-ac1f-466f-9842-94a84e6d09fa@github.com>
References: <UPqU1snygN84AiDbn5nxQzfsxQrovnsRuSLHpROqAUc=.63d4c018-ac1f-466f-9842-94a84e6d09fa@github.com>
Message-ID: <ozGbJpzoSy_E87FaH19T4DZ1lLvZIXxM5ygd0hfGTeM=.76f080c6-a1dd-421c-8541-22300a5c37ab@github.com>

On Wed, 8 Nov 2023 19:59:34 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Please review this  PR which enhances the existing CEN header validation checking to ensure that the
>  size of the CEN Header + name length + comment length + extra length do not exceed 65,535 bytes per the PKWare APP.NOTE 4.4.10, 4.4.11, & 4.4.12. Also check that current CEN header will not exceed the length of the CEN array.
> 
> Mach 5 tiers 1-3 are clean with this change.

While investigating an unrelated issue, I noticed that Android's `zipalign` tool processes zip files and injects data into the extra field  to make the beginning of the file data be word-aligned or page-aligned:

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

PR Comment: https://git.openjdk.org/jdk/pull/16570#issuecomment-1835864018

From cstein at openjdk.org  Fri Dec  1 11:05:15 2023
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 1 Dec 2023 11:05:15 GMT
Subject: Integrated: 8321127: ProblemList
 java/util/stream/GatherersTest.java
In-Reply-To: <a58ewftdxulGC-bzknlJ5np-JVayU_XVu5eT8Fm8UDA=.f841ce2d-4944-45c2-b77a-55dcb6d4593d@github.com>
References: <a58ewftdxulGC-bzknlJ5np-JVayU_XVu5eT8Fm8UDA=.f841ce2d-4944-45c2-b77a-55dcb6d4593d@github.com>
Message-ID: <p1OTxhlEUmm1YvO8BXE5Cmt94Wtcvt6EM6sw5rAZWBQ=.ecfb55d1-edcf-41fd-8485-fec82e7dd03c@github.com>

On Thu, 30 Nov 2023 16:08:54 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/util/stream/GatherersTest.java.

Off by one "s"?

Or does `java/util/stream/GathererTest`  (without "s") fail in addition? https://github.com/sormuras/jdk/actions/runs/7058601775#user-content-java_util_stream_gatherertest

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

PR Comment: https://git.openjdk.org/jdk/pull/16909#issuecomment-1835895191

From stefank at openjdk.org  Fri Dec  1 11:13:09 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 1 Dec 2023 11:13:09 GMT
Subject: RFR: 8321163: [test] OutputAnalyzer.getExitValue() unnecessarily
 logs even when process has already completed
In-Reply-To: <uZ77Eagw9Lxz1BKJ8fMnCzvp8Z5VVqsGnsLZtqKZDIo=.0fb8e6cf-7d79-4d4e-b99d-171e008210e9@github.com>
References: <uZ77Eagw9Lxz1BKJ8fMnCzvp8Z5VVqsGnsLZtqKZDIo=.0fb8e6cf-7d79-4d4e-b99d-171e008210e9@github.com>
Message-ID: <pk8iTDKzhZ8MgZfFtiEE5peXcbiVYSMfdodCf2zSEJM=.ac775ca6-d7ac-441c-bd15-440bc6325d4a@github.com>

On Fri, 1 Dec 2023 09:48:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change to the test library's `OutputAnalyzer` class, which proposes to remove some unnecessary logging from the `getExitValue()` call?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8321163, right now this method logs:
> 
> 
> [2023-11-24T11:47:54.557561Z] Waiting for completion for process 24909
> [2023-11-24T11:47:54.557873Z] Waiting for completion finished for process 24909
> 
> 
> even when the process has already completed and the exit value already known. The change in this PR makes it such that if the exit value is available then we no longer log this (nor call `process.waitFor()`).
> 
> No new tests have been added given the nature of this change. tier1, tier2 and tier3 tests continue to pass with this change.

Great find and nice to get rid of the extra logging!

test/lib/jdk/test/lib/process/OutputBuffer.java line 150:

> 148:     @Override
> 149:     public int getExitValue() {
> 150:       Integer exitCode = this.processExitCode;

Do we really need the local `exitCode` variable? Even if another multiple threads write to processExitCode, I expect them to all write a non-null Integer.

test/lib/jdk/test/lib/process/OutputBuffer.java line 158:

> 156:           boolean aborted = true;
> 157:           try {
> 158:               this.processExitCode = exitCode = p.waitFor();

According to the `waitFor` javadocs it returns the "exit value" and this function is named `getExitValue()`. I propose that we rename `processExitCode` to `exitValue` (alt. `processExitValue`).

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

PR Review: https://git.openjdk.org/jdk/pull/16919#pullrequestreview-1759560718
PR Review Comment: https://git.openjdk.org/jdk/pull/16919#discussion_r1411946205
PR Review Comment: https://git.openjdk.org/jdk/pull/16919#discussion_r1411948365

From stefank at openjdk.org  Fri Dec  1 11:13:11 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 1 Dec 2023 11:13:11 GMT
Subject: RFR: 8321163: [test] OutputAnalyzer.getExitValue() unnecessarily
 logs even when process has already completed
In-Reply-To: <pk8iTDKzhZ8MgZfFtiEE5peXcbiVYSMfdodCf2zSEJM=.ac775ca6-d7ac-441c-bd15-440bc6325d4a@github.com>
References: <uZ77Eagw9Lxz1BKJ8fMnCzvp8Z5VVqsGnsLZtqKZDIo=.0fb8e6cf-7d79-4d4e-b99d-171e008210e9@github.com>
 <pk8iTDKzhZ8MgZfFtiEE5peXcbiVYSMfdodCf2zSEJM=.ac775ca6-d7ac-441c-bd15-440bc6325d4a@github.com>
Message-ID: <8y4tuWdqFeq3BiNUFoCVKFaAuI_X-bA-8K5739sGwJw=.a5a8b9bb-1ffe-4483-abeb-7b229a22df73@github.com>

On Fri, 1 Dec 2023 11:09:30 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Can I please get a review for this change to the test library's `OutputAnalyzer` class, which proposes to remove some unnecessary logging from the `getExitValue()` call?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8321163, right now this method logs:
>> 
>> 
>> [2023-11-24T11:47:54.557561Z] Waiting for completion for process 24909
>> [2023-11-24T11:47:54.557873Z] Waiting for completion finished for process 24909
>> 
>> 
>> even when the process has already completed and the exit value already known. The change in this PR makes it such that if the exit value is available then we no longer log this (nor call `process.waitFor()`).
>> 
>> No new tests have been added given the nature of this change. tier1, tier2 and tier3 tests continue to pass with this change.
>
> test/lib/jdk/test/lib/process/OutputBuffer.java line 158:
> 
>> 156:           boolean aborted = true;
>> 157:           try {
>> 158:               this.processExitCode = exitCode = p.waitFor();
> 
> According to the `waitFor` javadocs it returns the "exit value" and this function is named `getExitValue()`. I propose that we rename `processExitCode` to `exitValue` (alt. `processExitValue`).

With the earlier suggestion, this would become:

exitValue = p.waitFor();

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16919#discussion_r1411949002

From jpai at openjdk.org  Fri Dec  1 11:17:08 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 1 Dec 2023 11:17:08 GMT
Subject: RFR: 8321163: [test] OutputAnalyzer.getExitValue() unnecessarily
 logs even when process has already completed
In-Reply-To: <pk8iTDKzhZ8MgZfFtiEE5peXcbiVYSMfdodCf2zSEJM=.ac775ca6-d7ac-441c-bd15-440bc6325d4a@github.com>
References: <uZ77Eagw9Lxz1BKJ8fMnCzvp8Z5VVqsGnsLZtqKZDIo=.0fb8e6cf-7d79-4d4e-b99d-171e008210e9@github.com>
 <pk8iTDKzhZ8MgZfFtiEE5peXcbiVYSMfdodCf2zSEJM=.ac775ca6-d7ac-441c-bd15-440bc6325d4a@github.com>
Message-ID: <qDo_ZrRBDTpKm05CZDjQQX12Ou2Fxa0BomZpZmhNgc4=.27b409eb-0453-45a3-ab8b-b31eefac43cb@github.com>

On Fri, 1 Dec 2023 11:07:06 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Can I please get a review for this change to the test library's `OutputAnalyzer` class, which proposes to remove some unnecessary logging from the `getExitValue()` call?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8321163, right now this method logs:
>> 
>> 
>> [2023-11-24T11:47:54.557561Z] Waiting for completion for process 24909
>> [2023-11-24T11:47:54.557873Z] Waiting for completion finished for process 24909
>> 
>> 
>> even when the process has already completed and the exit value already known. The change in this PR makes it such that if the exit value is available then we no longer log this (nor call `process.waitFor()`).
>> 
>> No new tests have been added given the nature of this change. tier1, tier2 and tier3 tests continue to pass with this change.
>
> test/lib/jdk/test/lib/process/OutputBuffer.java line 150:
> 
>> 148:     @Override
>> 149:     public int getExitValue() {
>> 150:       Integer exitCode = this.processExitCode;
> 
> Do we really need the local `exitCode` variable? Even if another multiple threads write to processExitCode, I expect them to all write a non-null Integer.

Hello Stefan, this is just for a tiny optimization to prevent multiple reads (in the same thread) on the `volatile` field `processExitCode` in this method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16919#discussion_r1411952233

From prappo at openjdk.org  Fri Dec  1 11:22:33 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 1 Dec 2023 11:22:33 GMT
Subject: RFR: 8321114: Rename "Unnamed Classes" to
 "Implicitly Declared Classes" better [v2]
In-Reply-To: <d3r3nT5LxWPoS4DhcboPkdthPPZRfBLBUflnJny-r9k=.e6b21d45-a104-4a48-8dad-6e06e73dbd01@github.com>
References: <d3r3nT5LxWPoS4DhcboPkdthPPZRfBLBUflnJny-r9k=.e6b21d45-a104-4a48-8dad-6e06e73dbd01@github.com>
Message-ID: <NwoT4GfVEnRAJkwM9fl2TZ1DBj2l5uVGV6RRGqkZgrc=.cf5565ae-6c40-46eb-8031-b2774ca5183c@github.com>

> Please review this PR to correctly rename "Unnamed Class" to "Implicitly Declared Class", not "Implicit Class".
> 
> Renaming is fixed where it affects documentation or the end-user. Renaming is not fixed where it only affects code: it's perfectly okay to derive an internal element name from "Implicit Class" rather than "Implicitly Declared Class", for brevity.

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

  Remove a comment typo introduced in JEP 445

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16904/files
  - new: https://git.openjdk.org/jdk/pull/16904/files/089aeee2..3676b500

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

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

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

From prappo at openjdk.org  Fri Dec  1 11:22:35 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 1 Dec 2023 11:22:35 GMT
Subject: RFR: 8321114: Rename "Unnamed Classes" to
 "Implicitly Declared Classes" better [v2]
In-Reply-To: <GG8vHiLmpF27IH7i1FsCeVMGVSApXD1Ie3gkc2w3zLM=.b4baf3d5-652a-4fdb-92f6-974e53bd3d4b@github.com>
References: <d3r3nT5LxWPoS4DhcboPkdthPPZRfBLBUflnJny-r9k=.e6b21d45-a104-4a48-8dad-6e06e73dbd01@github.com>
 <GG8vHiLmpF27IH7i1FsCeVMGVSApXD1Ie3gkc2w3zLM=.b4baf3d5-652a-4fdb-92f6-974e53bd3d4b@github.com>
Message-ID: <YfzcP47LOx0aMNoi1xqxmVKpHjrYy5Mm206sxj2dDXg=.cf749939-2c0f-4bae-9e59-25437fa59786@github.com>

On Thu, 30 Nov 2023 16:11:01 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove a comment typo introduced in JEP 445
>
> LGTM

@JimLaskey please re-review this PR due to a newly pushed [3676b50](https://github.com/openjdk/jdk/pull/16904/commits/3676b500834cd5e91b5829545e3fed71e43312a7). Also, please double-check if the comment is still valid factually.

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

PR Comment: https://git.openjdk.org/jdk/pull/16904#issuecomment-1835914750

From jpai at openjdk.org  Fri Dec  1 11:27:18 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 1 Dec 2023 11:27:18 GMT
Subject: RFR: 8321163: [test] OutputAnalyzer.getExitValue() unnecessarily
 logs even when process has already completed [v2]
In-Reply-To: <uZ77Eagw9Lxz1BKJ8fMnCzvp8Z5VVqsGnsLZtqKZDIo=.0fb8e6cf-7d79-4d4e-b99d-171e008210e9@github.com>
References: <uZ77Eagw9Lxz1BKJ8fMnCzvp8Z5VVqsGnsLZtqKZDIo=.0fb8e6cf-7d79-4d4e-b99d-171e008210e9@github.com>
Message-ID: <MbrPJCRUb-_yZBEkmIparSxa0tMkpXpLZ9x4gyQZSFA=.98285219-0b98-4ae8-98d2-2d9df997fbde@github.com>

> Can I please get a review for this change to the test library's `OutputAnalyzer` class, which proposes to remove some unnecessary logging from the `getExitValue()` call?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8321163, right now this method logs:
> 
> 
> [2023-11-24T11:47:54.557561Z] Waiting for completion for process 24909
> [2023-11-24T11:47:54.557873Z] Waiting for completion finished for process 24909
> 
> 
> even when the process has already completed and the exit value already known. The change in this PR makes it such that if the exit value is available then we no longer log this (nor call `process.waitFor()`).
> 
> No new tests have been added given the nature of this change. tier1, tier2 and tier3 tests continue to pass with this change.

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

  Stefan's suggestion - rename exitCode to exitValue

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16919/files
  - new: https://git.openjdk.org/jdk/pull/16919/files/1586288f..2fc11922

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

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

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

From jpai at openjdk.org  Fri Dec  1 11:27:20 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 1 Dec 2023 11:27:20 GMT
Subject: RFR: 8321163: [test] OutputAnalyzer.getExitValue() unnecessarily
 logs even when process has already completed [v2]
In-Reply-To: <8y4tuWdqFeq3BiNUFoCVKFaAuI_X-bA-8K5739sGwJw=.a5a8b9bb-1ffe-4483-abeb-7b229a22df73@github.com>
References: <uZ77Eagw9Lxz1BKJ8fMnCzvp8Z5VVqsGnsLZtqKZDIo=.0fb8e6cf-7d79-4d4e-b99d-171e008210e9@github.com>
 <pk8iTDKzhZ8MgZfFtiEE5peXcbiVYSMfdodCf2zSEJM=.ac775ca6-d7ac-441c-bd15-440bc6325d4a@github.com>
 <8y4tuWdqFeq3BiNUFoCVKFaAuI_X-bA-8K5739sGwJw=.a5a8b9bb-1ffe-4483-abeb-7b229a22df73@github.com>
Message-ID: <7Jo-SSD5DqtfXI8_7pbd8gnpNSF2Bm7Gluk5l_28s1o=.49298f32-b9a4-4baf-a262-c86f95b32fe0@github.com>

On Fri, 1 Dec 2023 11:10:16 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> test/lib/jdk/test/lib/process/OutputBuffer.java line 158:
>> 
>>> 156:           boolean aborted = true;
>>> 157:           try {
>>> 158:               this.processExitCode = exitCode = p.waitFor();
>> 
>> According to the `waitFor` javadocs it returns the "exit value" and this function is named `getExitValue()`. I propose that we rename `processExitCode` to `exitValue` (alt. `processExitValue`).
>
> With the earlier suggestion, this would become:
> 
> exitValue = p.waitFor();

You are right - exitValue instead of exitCode would be appropriate. I've updated the PR to implement this suggestion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16919#discussion_r1411962118

From tschatzl at openjdk.org  Fri Dec  1 11:49:05 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 1 Dec 2023 11:49:05 GMT
Subject: RFR: 8321130: Microbenchmarks do not build any more after 8254693
 on 32 bit platforms
In-Reply-To: <A4KrvO_fHfypgMMr50LTHkstsS4KgljMQH69q0pd4NA=.3ac73c6a-9491-4de3-bc89-980dfb253039@github.com>
References: <A4KrvO_fHfypgMMr50LTHkstsS4KgljMQH69q0pd4NA=.3ac73c6a-9491-4de3-bc89-980dfb253039@github.com>
Message-ID: <jie7Z2X9MnKhkijqFiVdPug85bSnlFDuhpJnccXoN6I=.c82c2fff-4ea9-4e96-9c71-6949a10499a4@github.com>

On Thu, 30 Nov 2023 20:59:01 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Need to use `jlong_to_ptr` instead of raw cast.
> 
> I've also fixed another latent issue in `CLayouts` where we were initializing `C_LONG_LONG` with the `long` layout. This was resulting in a class cast exception when running the XorTest benchmark. The size of `long` on Linux x86 32-bits is 4 bytes, so the returned layout has type `ValueLayout.OfInt` which we then try to cast to `ValueLayout.OfLong`, resulting in a CCE. This would also be an issue on Windows.
> 
> Testing: running XorTest benchmark on linux-x86 and windows-x64.

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16913#pullrequestreview-1759654945

From jlaskey at openjdk.org  Fri Dec  1 11:49:05 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 1 Dec 2023 11:49:05 GMT
Subject: RFR: 8321114: Rename "Unnamed Classes" to
 "Implicitly Declared Classes" better [v2]
In-Reply-To: <NwoT4GfVEnRAJkwM9fl2TZ1DBj2l5uVGV6RRGqkZgrc=.cf5565ae-6c40-46eb-8031-b2774ca5183c@github.com>
References: <d3r3nT5LxWPoS4DhcboPkdthPPZRfBLBUflnJny-r9k=.e6b21d45-a104-4a48-8dad-6e06e73dbd01@github.com>
 <NwoT4GfVEnRAJkwM9fl2TZ1DBj2l5uVGV6RRGqkZgrc=.cf5565ae-6c40-46eb-8031-b2774ca5183c@github.com>
Message-ID: <6IOB2NP-9rEDhWnsUHQGMYZbC9-hSJ4z8_dp-5cI9fg=.cd69a6ed-4e4c-4cea-8023-af78ffc8a503@github.com>

On Fri, 1 Dec 2023 11:22:33 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR to correctly rename "Unnamed Class" to "Implicitly Declared Class", not "Implicit Class".
>> 
>> Renaming is fixed where it affects documentation or the end-user. Renaming is not fixed where it only affects code: it's perfectly okay to derive an internal element name from "Implicit Class" rather than "Implicitly Declared Class", for brevity.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove a comment typo introduced in JEP 445

Marked as reviewed by jlaskey (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16904#pullrequestreview-1759655045

From prappo at openjdk.org  Fri Dec  1 11:54:13 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 1 Dec 2023 11:54:13 GMT
Subject: Integrated: 8321114: Rename "Unnamed Classes" to
 "Implicitly Declared Classes" better
In-Reply-To: <d3r3nT5LxWPoS4DhcboPkdthPPZRfBLBUflnJny-r9k=.e6b21d45-a104-4a48-8dad-6e06e73dbd01@github.com>
References: <d3r3nT5LxWPoS4DhcboPkdthPPZRfBLBUflnJny-r9k=.e6b21d45-a104-4a48-8dad-6e06e73dbd01@github.com>
Message-ID: <VGKZuEfvKuoe7A811l21TjPoaj_SpPcR4D8TrSeuaTo=.175e8fcd-e5e0-4600-9ed4-a8cd70a41eec@github.com>

On Thu, 30 Nov 2023 15:00:00 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR to correctly rename "Unnamed Class" to "Implicitly Declared Class", not "Implicit Class".
> 
> Renaming is fixed where it affects documentation or the end-user. Renaming is not fixed where it only affects code: it's perfectly okay to derive an internal element name from "Implicit Class" rather than "Implicitly Declared Class", for brevity.

This pull request has now been integrated.

Changeset: 8f1d40b4
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8f1d40b48bf145144ae90b1d147d418d3905661b
Stats:     19 lines in 8 files changed: 0 ins; 0 del; 19 mod

8321114: Rename "Unnamed Classes" to "Implicitly Declared Classes" better

Reviewed-by: jlaskey

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

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

From stefank at openjdk.org  Fri Dec  1 12:12:07 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 1 Dec 2023 12:12:07 GMT
Subject: RFR: 8321163: [test] OutputAnalyzer.getExitValue() unnecessarily
 logs even when process has already completed [v2]
In-Reply-To: <qDo_ZrRBDTpKm05CZDjQQX12Ou2Fxa0BomZpZmhNgc4=.27b409eb-0453-45a3-ab8b-b31eefac43cb@github.com>
References: <uZ77Eagw9Lxz1BKJ8fMnCzvp8Z5VVqsGnsLZtqKZDIo=.0fb8e6cf-7d79-4d4e-b99d-171e008210e9@github.com>
 <pk8iTDKzhZ8MgZfFtiEE5peXcbiVYSMfdodCf2zSEJM=.ac775ca6-d7ac-441c-bd15-440bc6325d4a@github.com>
 <qDo_ZrRBDTpKm05CZDjQQX12Ou2Fxa0BomZpZmhNgc4=.27b409eb-0453-45a3-ab8b-b31eefac43cb@github.com>
Message-ID: <gx-oUJgRh4fcVb6-DNkh_SzEwWj7vNOBHtuJNpdOvZo=.7bf15ba1-c994-4aff-ad5f-224c320e25a1@github.com>

On Fri, 1 Dec 2023 11:14:04 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/lib/jdk/test/lib/process/OutputBuffer.java line 150:
>> 
>>> 148:     @Override
>>> 149:     public int getExitValue() {
>>> 150:       Integer exitCode = this.processExitCode;
>> 
>> Do we really need the local `exitCode` variable? Even if another multiple threads write to processExitCode, I expect them to all write a non-null Integer.
>
> Hello Stefan, this is just for a tiny optimization to prevent multiple reads (in the same thread) on the `volatile` field `processExitCode` in this method.

I don't think such an optimization is needed here. This is not performance-critical code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16919#discussion_r1412028528

From jpai at openjdk.org  Fri Dec  1 12:44:17 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 1 Dec 2023 12:44:17 GMT
Subject: RFR: 8321163: [test] OutputAnalyzer.getExitValue() unnecessarily
 logs even when process has already completed [v3]
In-Reply-To: <uZ77Eagw9Lxz1BKJ8fMnCzvp8Z5VVqsGnsLZtqKZDIo=.0fb8e6cf-7d79-4d4e-b99d-171e008210e9@github.com>
References: <uZ77Eagw9Lxz1BKJ8fMnCzvp8Z5VVqsGnsLZtqKZDIo=.0fb8e6cf-7d79-4d4e-b99d-171e008210e9@github.com>
Message-ID: <0GAdkVhk4e3WJp5bQuLdvtxHk5BtRguNmQ7PoQ5dH50=.4f01dd8f-e2f5-47f8-b66a-2801156d56f5@github.com>

> Can I please get a review for this change to the test library's `OutputAnalyzer` class, which proposes to remove some unnecessary logging from the `getExitValue()` call?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8321163, right now this method logs:
> 
> 
> [2023-11-24T11:47:54.557561Z] Waiting for completion for process 24909
> [2023-11-24T11:47:54.557873Z] Waiting for completion finished for process 24909
> 
> 
> even when the process has already completed and the exit value already known. The change in this PR makes it such that if the exit value is available then we no longer log this (nor call `process.waitFor()`).
> 
> No new tests have been added given the nature of this change. tier1, tier2 and tier3 tests continue to pass with this change.

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

  remove micro optimization

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16919/files
  - new: https://git.openjdk.org/jdk/pull/16919/files/2fc11922..d81f8e12

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

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

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

From jpai at openjdk.org  Fri Dec  1 12:44:19 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 1 Dec 2023 12:44:19 GMT
Subject: RFR: 8321163: [test] OutputAnalyzer.getExitValue() unnecessarily
 logs even when process has already completed [v3]
In-Reply-To: <gx-oUJgRh4fcVb6-DNkh_SzEwWj7vNOBHtuJNpdOvZo=.7bf15ba1-c994-4aff-ad5f-224c320e25a1@github.com>
References: <uZ77Eagw9Lxz1BKJ8fMnCzvp8Z5VVqsGnsLZtqKZDIo=.0fb8e6cf-7d79-4d4e-b99d-171e008210e9@github.com>
 <pk8iTDKzhZ8MgZfFtiEE5peXcbiVYSMfdodCf2zSEJM=.ac775ca6-d7ac-441c-bd15-440bc6325d4a@github.com>
 <qDo_ZrRBDTpKm05CZDjQQX12Ou2Fxa0BomZpZmhNgc4=.27b409eb-0453-45a3-ab8b-b31eefac43cb@github.com>
 <gx-oUJgRh4fcVb6-DNkh_SzEwWj7vNOBHtuJNpdOvZo=.7bf15ba1-c994-4aff-ad5f-224c320e25a1@github.com>
Message-ID: <SY2WwZ3RDvOsxkJfBm9E-F7VTiMLtie3zpQOTNUb0AU=.47f5c509-3f8d-414e-9a72-fd78d150dbef@github.com>

On Fri, 1 Dec 2023 12:09:14 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Hello Stefan, this is just for a tiny optimization to prevent multiple reads (in the same thread) on the `volatile` field `processExitCode` in this method.
>
> I don't think such an optimization is needed here. This is not performance-critical code.

That's true. I've now updated the PR to keep it simple and remove that optimization.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16919#discussion_r1412058767

From stefank at openjdk.org  Fri Dec  1 12:49:05 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 1 Dec 2023 12:49:05 GMT
Subject: RFR: 8321163: [test] OutputAnalyzer.getExitValue() unnecessarily
 logs even when process has already completed [v3]
In-Reply-To: <0GAdkVhk4e3WJp5bQuLdvtxHk5BtRguNmQ7PoQ5dH50=.4f01dd8f-e2f5-47f8-b66a-2801156d56f5@github.com>
References: <uZ77Eagw9Lxz1BKJ8fMnCzvp8Z5VVqsGnsLZtqKZDIo=.0fb8e6cf-7d79-4d4e-b99d-171e008210e9@github.com>
 <0GAdkVhk4e3WJp5bQuLdvtxHk5BtRguNmQ7PoQ5dH50=.4f01dd8f-e2f5-47f8-b66a-2801156d56f5@github.com>
Message-ID: <PmXFLyNUgd2YMe7a8jNGebQKdEN5Yhj1OA7DTMjDrLE=.3f75934e-b3b2-436f-b23d-c37d8ee7b7da@github.com>

On Fri, 1 Dec 2023 12:44:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change to the test library's `OutputAnalyzer` class, which proposes to remove some unnecessary logging from the `getExitValue()` call?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8321163, right now this method logs:
>> 
>> 
>> [2023-11-24T11:47:54.557561Z] Waiting for completion for process 24909
>> [2023-11-24T11:47:54.557873Z] Waiting for completion finished for process 24909
>> 
>> 
>> even when the process has already completed and the exit value already known. The change in this PR makes it such that if the exit value is available then we no longer log this (nor call `process.waitFor()`).
>> 
>> No new tests have been added given the nature of this change. tier1, tier2 and tier3 tests continue to pass with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove micro optimization

Looks good!

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16919#pullrequestreview-1759744755

From mbaesken at openjdk.org  Fri Dec  1 12:53:07 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 1 Dec 2023 12:53:07 GMT
Subject: RFR: 8320798: Console read line with zero out should zero out
 underlying buffer [v3]
In-Reply-To: <8mADwh5tk-5DhucpbLxUAiPDOgxSkJru210ndcjXWaU=.f1dbb46e-974a-4975-8b08-cb8d34bf92cc@github.com>
References: <CdG_iGykiGmAUIsoDTD7KBhH4pzbLDhFU5PVxiTwSNU=.10d379f6-427f-493a-9c24-a616e8d5f329@github.com>
 <8mADwh5tk-5DhucpbLxUAiPDOgxSkJru210ndcjXWaU=.f1dbb46e-974a-4975-8b08-cb8d34bf92cc@github.com>
Message-ID: <akz9GED-XXg-mxwWSSm8A-6Oo9GrL4AeEmvri7gY-Xg=.12feefe8-6642-4c6c-93fa-37e7e008f2e6@github.com>

On Thu, 30 Nov 2023 17:39:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> It is best practice to zero out the underlying buffer after use.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove ensureOpen()

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16861#pullrequestreview-1759751135

From jvernee at openjdk.org  Fri Dec  1 13:14:16 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 1 Dec 2023 13:14:16 GMT
Subject: Integrated: 8321130: Microbenchmarks do not build any more after
 8254693 on 32 bit platforms
In-Reply-To: <A4KrvO_fHfypgMMr50LTHkstsS4KgljMQH69q0pd4NA=.3ac73c6a-9491-4de3-bc89-980dfb253039@github.com>
References: <A4KrvO_fHfypgMMr50LTHkstsS4KgljMQH69q0pd4NA=.3ac73c6a-9491-4de3-bc89-980dfb253039@github.com>
Message-ID: <6ftN1tQdYMWzEfYrOxnSoGiLJbvsJL0hWmq37pMs9F4=.7206894d-557f-429c-861a-07299b7ec17f@github.com>

On Thu, 30 Nov 2023 20:59:01 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Need to use `jlong_to_ptr` instead of raw cast.
> 
> I've also fixed another latent issue in `CLayouts` where we were initializing `C_LONG_LONG` with the `long` layout. This was resulting in a class cast exception when running the XorTest benchmark. The size of `long` on Linux x86 32-bits is 4 bytes, so the returned layout has type `ValueLayout.OfInt` which we then try to cast to `ValueLayout.OfLong`, resulting in a CCE. This would also be an issue on Windows.
> 
> Testing: running XorTest benchmark on linux-x86 and windows-x64.

This pull request has now been integrated.

Changeset: 3b30095a
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3b30095a63bdf8224a5625507a69942210a203a0
Stats:     5 lines in 2 files changed: 2 ins; 0 del; 3 mod

8321130: Microbenchmarks do not build any more after 8254693 on 32 bit platforms

Reviewed-by: mcimadamore, tschatzl

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

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

From asotona at openjdk.org  Fri Dec  1 13:18:30 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 1 Dec 2023 13:18:30 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v32]
In-Reply-To: <e0eptru-lnzIXRfqrFBT1fy-oDsLORN-roOsdUzshUY=.68ff8e2b-68fb-4457-94fb-f0623eb3f96a@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <9-Fm-UXpDT0FLAxTw9xve00qurpqv01xw1uJwG0IXKQ=.06a9e0da-7a8c-462b-9b7a-b1be1b9bff5f@github.com>
 <8aNWssZUAmka3xQNMbRvY8P8ruJ0-7Eo5NTLeQGPko4=.ac8f1a19-8f0a-42fc-85cf-2fb540d194a7@github.com>
 <Fd3Aa-rvhh0iWNFsGnOMCAMPvI5JiesSWh0tvPhPg5M=.379e7492-46d4-41f2-94c6-393b6701cad2@github.com>
 <e0eptru-lnzIXRfqrFBT1fy-oDsLORN-roOsdUzshUY=.68ff8e2b-68fb-4457-94fb-f0623eb3f96a@github.com>
Message-ID: <JOJKj3mt-3DRIVKUTDXwMYvh_g-P9hVax9PZ0MiLcyU=.ab0b0bd2-6101-4f87-bac0-49cc401e8452@github.com>

On Wed, 29 Nov 2023 08:46:46 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This is explicit list of supported class file versions, so I don't see any other way.
>
> Would it not be possible to expose an immutable `Map<Integer, Integer>` that maps from Java version to major class version?

This is actually out of scope of this PR. Feel free to request a new ClassFile API feature.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1412090733

From duke at openjdk.org  Fri Dec  1 13:45:12 2023
From: duke at openjdk.org (Markus KARG)
Date: Fri, 1 Dec 2023 13:45:12 GMT
Subject: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter
 of transferTo() is trusted [v2]
In-Reply-To: <fv6-nbKivaxr2QQ_2khG1ssAum3isxx0-RA5wvwcD3Q=.4127e93f-1734-4b99-9c82-d35dbcb8ceb1@github.com>
References: <zRINQ_LiJh7Ifnt7UwL2Q0PcpestYwzx74fopLor_2w=.c93f3a3a-8172-40d2-9e5d-0530eb905f2a@github.com>
 <fv6-nbKivaxr2QQ_2khG1ssAum3isxx0-RA5wvwcD3Q=.4127e93f-1734-4b99-9c82-d35dbcb8ceb1@github.com>
Message-ID: <oiyEy74LQkgMgI19Fw0elB3tsgLw-VbTJmgcScqvB74=.990cecc6-8d67-4002-b79c-95b6b8a7205e@github.com>

On Thu, 30 Nov 2023 23:30:20 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Pass `ByteArrayInputStream.buf ` directly to the `OutputStream` parameter of `BAIS.transferTo` only if the target stream is in the `java.io` package.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8321053: Trust non-FilterOutputStreams in "java." packages

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

> 209:         if (len > 0) {
> 210:             byte[] tmp;
> 211:             if (out.getClass().getPackageName().startsWith("java.") &&

Has anybody actually estimated or measured if such an exception is actually useful / needed given the fact that System.arraycopy is fast native code and most buffers used by java.io-located streams are just few KB? Just asking as it could be the case that *interpreting* this Java bytecode could be slower than executing some ASM ops to create a few-KB copy, and we *might* do an "premature optimization" here.

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

> 219:                 int nbyte = Integer.min(len - nwritten, MAX_TRANSFER_SIZE);
> 220:                 if (tmp != null) {
> 221:                     System.arraycopy(buf, pos, tmp, 0, nbyte);

I assume the overall performance of transferTo will be faster if we use System.arraycopy *only once* in line 215 to create a safe copy of the *complete* buf instead of calling it multiple times in a loop to create copies *per slice*. In that case we can omit the tmp == null case but simply use tmp = buf, making the code in the loop if-free.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16893#discussion_r1412118013
PR Review Comment: https://git.openjdk.org/jdk/pull/16893#discussion_r1412107929

From asotona at openjdk.org  Fri Dec  1 13:46:25 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 1 Dec 2023 13:46:25 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v33]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <smvNLtt0YumYsmswb7vrmD5O9V2wVvfR7VCHgtrHg8k=.c6a7c0c7-2984-4041-8a3c-134c2180a318@github.com>

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> 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 371 commits:

 - Merge branch 'master' into JDK-8308753-preview
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
 - fixed SwitchBootstrapTest
 - fixed SwitchBootstrap and StackMapsTest
 - fixed SwtichBootstrapTest and ModuleVersionTest
 - Merge branch 'master' into JDK-8308753-preview
 - Merge branch 'master' into JDK-8308753-preview
   
   # Conflicts:
   #	test/jdk/jdk/classfile/StackMapsTest.java
 - Merge branch 'master' into JDK-8308753-preview
   
   # Conflicts:
   #	test/langtools/tools/javac/7199823/InnerClassCannotBeVerified.java
 - added new package-info snippets and fixed ClassFile::parse throws javadoc description
 - fixed lambda tests
 - Merge branch 'master' into JDK-8308753-preview
 - ... and 361 more: https://git.openjdk.org/jdk/compare/3b30095a...b7b2e4e4

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

Changes: https://git.openjdk.org/jdk/pull/15706/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=32
  Stats: 32362 lines in 787 files changed: 14660 ins; 14113 del; 3589 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

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

From duke at openjdk.org  Fri Dec  1 13:50:04 2023
From: duke at openjdk.org (Markus KARG)
Date: Fri, 1 Dec 2023 13:50:04 GMT
Subject: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter
 of transferTo() is trusted [v2]
In-Reply-To: <jQBQyMguCr22Ihi66y1Ub4pbCBVgYzDMqaPkj_FvIFM=.4ad14e27-50ff-4621-91cf-bfbf9cf726b9@github.com>
References: <zRINQ_LiJh7Ifnt7UwL2Q0PcpestYwzx74fopLor_2w=.c93f3a3a-8172-40d2-9e5d-0530eb905f2a@github.com>
 <qvDeG-fdlsLWk-rEcZHRMA3Mv0hJag2hvJlHqu4Y-yo=.3b0e1f6f-b69d-4471-909a-9d4dd45618b1@github.com>
 <KbgvHJmxFxcJSCf2iOvYxblmTvg8RDV1QtqhylX-bHo=.fe8878ab-7b19-4e72-81f3-d6a65965fa1b@github.com>
 <qzx0Xi4T398BV7qeBj6bLS-R7LcLA8JE-gMwxuD3lcI=.5d447f3b-328e-40df-b823-4a74eec3f1a4@github.com>
 <eyFDDWXEomWObizhgeIormpHtFAXmTrXbWkMOxK2ML4=.a3d6ca9d-5b73-456c-b997-78bc5894c136@github.com>
 <EC7_LI524HAiIY3cDlcVmoqKY4H4eMy7shWEyDU-td8=.b2f87afe-9d6b-41ab-9145-858f4deded60@github.com>
 <jQBQyMguCr22Ihi66y1Ub4pbCBVgYzDMqaPkj_FvIFM=.4ad14e27-50ff-4621-91cf-bfbf9cf726b9@github.com>
Message-ID: <r8PlLlJcB6KEF9fgGlrTYdRiUY6Ou5Q8klgZY2AQ49E=.7d4ee021-4138-4ca7-a116-db292a82934b@github.com>

On Fri, 1 Dec 2023 04:01:42 GMT, jmehrens <duke at openjdk.org> wrote:

>> I might have done this incorrectly, but with this version of the above `wolf` I do not see any corruption:
>> 
>>         java.nio.channels.WritableByteChannel wolf =
>>             new java.nio.channels.WritableByteChannel() {
>>                 private boolean closed = false;
>>                 
>>                 public int write(java.nio.ByteBuffer src) throws IOException {
>>                     int rem = src.remaining();
>>                     Arrays.fill(src.array(), src.arrayOffset() + src.position(),
>>                                 src.arrayOffset() + src.limit(),
>>                                 (byte)'0');
>>                     src.position(src.limit());
>>                     return rem;
>>                 }
>> 
>>                 public boolean isOpen() {
>>                     return !closed;
>>                 }
>> 
>>                 public void close() throws IOException {
>>                     closed = true;
>>                 }
>>             };
>
> @bplb You did it right.  The reason it works is because the ChannelOutputStream is in the "sun." package and not the "java." package.  That is not the case for Channels.newOutputStream(AsynchronousByteChannel ch) as that wrapper should be able to access the byte array.

I see the problem that unless we have an explicit whitelist, we do open the risk of accidentially adding another wrapper stream in future to the JDK somewhere and forget to add it to the blacklist. So for safety, I would pleae for not using .startsWith() but explitly mention the actively proven-as-safe classes only. That way, the code might be slower (sad but true) but inherently future-proof.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16893#discussion_r1412123464

From mbaesken at openjdk.org  Fri Dec  1 13:51:12 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 1 Dec 2023 13:51:12 GMT
Subject: RFR: JDK-8317307: test/jdk/com/sun/jndi/ldap/LdapPoolTimeoutTest.java
 fails with ConnectException: Connection timed out: no further
 information
Message-ID: <gpnWWUWLMZLI1YDcADf_P9QhEeCAkbEnksZabtRE57w=.3d07e7d8-dd4d-4478-bc7f-fa3b0f57aca1@github.com>

On Windows we recently run into this error rather often in the test LdapPoolTimeoutTest.java :

MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information]
MSG: Connect timed out
MSG: Timeout exceeded while waiting for a connection: 26984ms
MSG: Timed out waiting for lock
MSG: Timed out waiting for lock
MSG: Timed out waiting for lock
MSG: Timeout exceeded while waiting for a connection: 26984ms
MSG: Timeout exceeded while waiting for a connection: 26984ms
java.lang.Exception: failures: 1
at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:104)
at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:58)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
at java.base/java.lang.reflect.Method.invoke(Method.java:580)
at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
at java.base/java.lang.Thread.run(Thread.java:1570)

We should extend the accepted exception message strings and also also  'Connection timed out' .

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

Commit messages:
 - JDK-8317307

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

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

From clanger at openjdk.org  Fri Dec  1 13:56:05 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 1 Dec 2023 13:56:05 GMT
Subject: RFR: JDK-8317307:
 test/jdk/com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails with
 ConnectException: Connection timed out: no further information
In-Reply-To: <gpnWWUWLMZLI1YDcADf_P9QhEeCAkbEnksZabtRE57w=.3d07e7d8-dd4d-4478-bc7f-fa3b0f57aca1@github.com>
References: <gpnWWUWLMZLI1YDcADf_P9QhEeCAkbEnksZabtRE57w=.3d07e7d8-dd4d-4478-bc7f-fa3b0f57aca1@github.com>
Message-ID: <SsQ8M0LIw4wh5gmpmtPjWCU8KLUOxXfMUUEcWHFLrwQ=.82c19e24-7f18-4efa-b605-ac14cf1fb847@github.com>

On Fri, 1 Dec 2023 13:46:14 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On Windows we recently run into this error rather often in the test LdapPoolTimeoutTest.java :
> 
> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information]
> MSG: Connect timed out
> MSG: Timeout exceeded while waiting for a connection: 26984ms
> MSG: Timed out waiting for lock
> MSG: Timed out waiting for lock
> MSG: Timed out waiting for lock
> MSG: Timeout exceeded while waiting for a connection: 26984ms
> MSG: Timeout exceeded while waiting for a connection: 26984ms
> java.lang.Exception: failures: 1
> at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:104)
> at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:58)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> at java.base/java.lang.Thread.run(Thread.java:1570)
> 
> We should extend the accepted exception message strings and also also  'Connection timed out' .

Looks good and makes sense to accept this case as well since we see it occuring in real life.
Maybe move the `|| msg.contains("Connection timed out")` into the next line.

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

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16922#pullrequestreview-1759855858

From duke at openjdk.org  Fri Dec  1 14:08:06 2023
From: duke at openjdk.org (Bernd)
Date: Fri, 1 Dec 2023 14:08:06 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v2]
In-Reply-To: <U48ZF81iabBR6w6wBg6GIQUhuXEnffHTEHalld9eyQA=.0f421c36-ed36-4d49-a002-8ba6f4380247@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <TmqtdWpHvAd2pow8sROWR-4HXeb2MsDQwmJyisF0f20=.2601d277-d016-446b-92ef-8b878560ad45@github.com>
 <U48ZF81iabBR6w6wBg6GIQUhuXEnffHTEHalld9eyQA=.0f421c36-ed36-4d49-a002-8ba6f4380247@github.com>
Message-ID: <Xs6HwmxbmM_ar4VLBjyrTHEgTG9LnaPmib2HvUoPdIs=.65348170-948f-4098-bd6c-ea35bd729aa5@github.com>

On Thu, 30 Nov 2023 09:36:01 GMT, Bernd <duke at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8320971: Trust any OutputStream from java.*
>
> Did you review if all Java.* streams are safe?
> 
> There are a few stream adapters in sun.nio.ch, which would benefit this optimization too, unfortunately they wrap the arrays with ByteBuffer.wrap, I guess that?s not safe, so the package can?t be allowed?

> @ecki I've checked the streams in `java.*` and it looks like none of them modifies the incoming `byte[]`

i think modification is not the problem, the querstion is if they get exposed to user code. (but yes the readonly ByteBuffer wrapper looks like a good thing to use more).

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

PR Comment: https://git.openjdk.org/jdk/pull/16879#issuecomment-1836173674

From vsitnikov at openjdk.org  Fri Dec  1 14:12:06 2023
From: vsitnikov at openjdk.org (Vladimir Sitnikov)
Date: Fri, 1 Dec 2023 14:12:06 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v2]
In-Reply-To: <Xs6HwmxbmM_ar4VLBjyrTHEgTG9LnaPmib2HvUoPdIs=.65348170-948f-4098-bd6c-ea35bd729aa5@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <TmqtdWpHvAd2pow8sROWR-4HXeb2MsDQwmJyisF0f20=.2601d277-d016-446b-92ef-8b878560ad45@github.com>
 <U48ZF81iabBR6w6wBg6GIQUhuXEnffHTEHalld9eyQA=.0f421c36-ed36-4d49-a002-8ba6f4380247@github.com>
 <Xs6HwmxbmM_ar4VLBjyrTHEgTG9LnaPmib2HvUoPdIs=.65348170-948f-4098-bd6c-ea35bd729aa5@github.com>
Message-ID: <QXZgfjPnNh3bDUPON6j25Ef8FphjTnRkVRd7pKaQ1K4=.c97723a9-2ba9-4184-857a-36a03f2859ac@github.com>

On Fri, 1 Dec 2023 14:05:37 GMT, Bernd <duke at openjdk.org> wrote:

>> Did you review if all Java.* streams are safe?
>> 
>> There are a few stream adapters in sun.nio.ch, which would benefit this optimization too, unfortunately they wrap the arrays with ByteBuffer.wrap, I guess that?s not safe, so the package can?t be allowed?
>
>> @ecki I've checked the streams in `java.*` and it looks like none of them modifies the incoming `byte[]`
> 
> i think modification is not the problem, the querstion is if they get exposed to user code. (but yes the readonly ByteBuffer wrapper looks like a good thing to use more).

@ecki , what do you think of using read-only `ByteBuffer` instead?

See https://github.com/openjdk/jdk/pull/16879#discussion_r1410416823

It looks like there might be `OutputStream extends WritableByteChannel`. Then we won't need to perform deep analysis.

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

PR Comment: https://git.openjdk.org/jdk/pull/16879#issuecomment-1836180161

From duke at openjdk.org  Fri Dec  1 14:15:07 2023
From: duke at openjdk.org (Bernd)
Date: Fri, 1 Dec 2023 14:15:07 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v2]
In-Reply-To: <Xs6HwmxbmM_ar4VLBjyrTHEgTG9LnaPmib2HvUoPdIs=.65348170-948f-4098-bd6c-ea35bd729aa5@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <TmqtdWpHvAd2pow8sROWR-4HXeb2MsDQwmJyisF0f20=.2601d277-d016-446b-92ef-8b878560ad45@github.com>
 <U48ZF81iabBR6w6wBg6GIQUhuXEnffHTEHalld9eyQA=.0f421c36-ed36-4d49-a002-8ba6f4380247@github.com>
 <Xs6HwmxbmM_ar4VLBjyrTHEgTG9LnaPmib2HvUoPdIs=.65348170-948f-4098-bd6c-ea35bd729aa5@github.com>
Message-ID: <uL89CUJ_qxF7DS1ZNRUJAJP1R_r6k_s3hi8W_cyzxxI=.787254de-b36c-479b-9b41-4e901e705c50@github.com>

On Fri, 1 Dec 2023 14:05:37 GMT, Bernd <duke at openjdk.org> wrote:

>> Did you review if all Java.* streams are safe?
>> 
>> There are a few stream adapters in sun.nio.ch, which would benefit this optimization too, unfortunately they wrap the arrays with ByteBuffer.wrap, I guess that?s not safe, so the package can?t be allowed?
>
>> @ecki I've checked the streams in `java.*` and it looks like none of them modifies the incoming `byte[]`
> 
> i think modification is not the problem, the querstion is if they get exposed to user code. (but yes the readonly ByteBuffer wrapper looks like a good thing to use more).

> @ecki , what do you think of using read-only `ByteBuffer` instead?
> 
> See [#16879 (comment)](https://github.com/openjdk/jdk/pull/16879#discussion_r1410416823)
> 
> It looks like there might be `OutputStream extends WritableByteChannel`. Then we won't need to perform deep analysis.

i am not completely sure if exposing buffers is a problem in terms of dirty data and if thats an issue with those wrappers. Well honestly it cant be anissue since we dont have untrusted code, but I understand future undertakings need to take this into account (insert SecurityManager rant here :)

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

PR Comment: https://git.openjdk.org/jdk/pull/16879#issuecomment-1836184267

From cstein at openjdk.org  Fri Dec  1 14:33:19 2023
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 1 Dec 2023 14:33:19 GMT
Subject: Integrated: 8321127: ProblemList
 java/util/stream/GatherersTest.java
In-Reply-To: <a58ewftdxulGC-bzknlJ5np-JVayU_XVu5eT8Fm8UDA=.f841ce2d-4944-45c2-b77a-55dcb6d4593d@github.com>
References: <a58ewftdxulGC-bzknlJ5np-JVayU_XVu5eT8Fm8UDA=.f841ce2d-4944-45c2-b77a-55dcb6d4593d@github.com>
Message-ID: <Nl30HuAwktDhATaqMIX8HuMAFlFWdbuTLkxrq6bPOF0=.75f177e8-fe50-4bfc-9b35-b4e06768ed1a@github.com>

On Thu, 30 Nov 2023 16:08:54 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/util/stream/GatherersTest.java.

Seems to be a different issue with "linux-x86" (32-bit host) and `GathererTest::testMassivelyComposedGatherers`.

https://github.com/sormuras/jdk/actions/runs/7060090092#summary-19219883603

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

PR Comment: https://git.openjdk.org/jdk/pull/16909#issuecomment-1836211653

From duke at openjdk.org  Fri Dec  1 14:57:28 2023
From: duke at openjdk.org (Markus KARG)
Date: Fri, 1 Dec 2023 14:57:28 GMT
Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer
 when mark set [v6]
In-Reply-To: <10nz53uCtbguOoNZKUl2o2h_1sAvL2OBrMPsD-0HY30=.47617202-6926-4932-b4a8-0880d0585b66@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
 <6qdrcRAPKcCfsrKlrr91C6mXF9mVKXj3XmDfnvImR_s=.cdb7aac1-abe3-46ea-a573-fd4c0305987e@github.com>
 <Hu1t0rx6eugDQHJvUsbLCuPNeX7xP6ixWl-9JwXxGQ4=.5eedff7d-ca60-47cc-88c6-361fb291e30e@github.com>
 <bDtNNQWv2SENp5w4vz-2-vDFqRugjtLWAUUEWiB3G6M=.ea3529c2-f4ec-4cd1-935a-f9bade1c0193@github.com>
 <Ckrorc1PulDQ6gzW_U1YpGkl8aK5F4WfbQHLy2bYTM0=.1d0b9bad-843d-4252-a53a-82b6d0dfe56d@github.com>
 <xQyPyUpK4OO7zP1abvoTL7p2Xbq95oNiS2ka69nCGCU=.b7d8486d-e29b-4dfb-ae74-1aeffbb6dec4@github.com>
 <10nz53uCtbguOoNZKUl2o2h_1sAvL2OBrMPsD-0HY30=.47617202-6926-4932-b4a8-0880d0585b66@github.com>
Message-ID: <IDH4vLttnh2hrWICRhLXAhIybVFMRHFNLYaC5RjzREU=.7147f4c8-6bed-4e71-8bad-2527a7965d34@github.com>

On Wed, 29 Nov 2023 22:55:41 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> > As Alan pointed out, it is a bug (actually even a security risk), so BAIS should get fixed, too.
> 
> I am going to file an issue on this.

Thank you, I just planned to fix this today when I saw your existing PR! ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10525#discussion_r1412210184

From vklang at openjdk.org  Fri Dec  1 15:03:20 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 1 Dec 2023 15:03:20 GMT
Subject: Integrated: 8321127: ProblemList
 java/util/stream/GatherersTest.java
In-Reply-To: <Nl30HuAwktDhATaqMIX8HuMAFlFWdbuTLkxrq6bPOF0=.75f177e8-fe50-4bfc-9b35-b4e06768ed1a@github.com>
References: <a58ewftdxulGC-bzknlJ5np-JVayU_XVu5eT8Fm8UDA=.f841ce2d-4944-45c2-b77a-55dcb6d4593d@github.com>
 <Nl30HuAwktDhATaqMIX8HuMAFlFWdbuTLkxrq6bPOF0=.75f177e8-fe50-4bfc-9b35-b4e06768ed1a@github.com>
Message-ID: <VP1WREKo1mNFpCh5Ap1pmxK8jJ0mvnvrc_YMTJdIQuc=.3f53239a-c030-4eb0-8f4b-5b711d8be93b@github.com>

On Fri, 1 Dec 2023 14:30:12 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> A trivial fix to ProblemList java/util/stream/GatherersTest.java.
>
> Seems to be a different issue with "linux-x86" (32-bit host) and `GathererTest::testMassivelyComposedGatherers`.
> 
> https://github.com/sormuras/jdk/actions/runs/7060090092#summary-19219883603

@sormuras That's unfortunate. I'll lower the simulation threshold to give those with a stack disadvantage a chance to run that test.

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

PR Comment: https://git.openjdk.org/jdk/pull/16909#issuecomment-1836265115

From ihse at openjdk.org  Fri Dec  1 15:04:19 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 1 Dec 2023 15:04:19 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v6]
In-Reply-To: <3cK9QjVQNIgZoWWhrWKEb3XxfbLjprjRMBbStWegH7M=.6df92651-b97d-445a-aa42-302ea791bbea@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
 <3cK9QjVQNIgZoWWhrWKEb3XxfbLjprjRMBbStWegH7M=.6df92651-b97d-445a-aa42-302ea791bbea@github.com>
Message-ID: <ROpl3Wa_CZ9NF6W8RDqpx_OAEbFjREBP-56LHF7BO6M=.0cc8d311-a725-4642-87de-e7387a59d059@github.com>

On Fri, 1 Dec 2023 10:19:01 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request with a new target base 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:
>> 
>>  - Separate neon and sve functions into two source files
>>  - Merge branch 'jdk:master' into JDK-8312425
>>  - Rename vmath to sleef in configure
>>  - Address review comments in build system
>>  - Add a bundled native lib in jdk as a bridge to libsleef
>>  - Merge 'jdk:master' into JDK-8312425
>>  - Disable sleef by default
>>  - Merge 'jdk:master' into JDK-8312425
>>  - 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF
>
> Oh, and:
> 
> If we can't trust SLEEF not to break the ABI we're using, we should not be using SLEEF.

@theRealAph You are making good points. 

You are basically saying: "we don't need any configure support for libsleef, we can just hard-code the names and dispatch to them directly to a dlopened library at runtime".

That is technically correct, but I'd still like to argue that the current setup have some merits:

* It will check that there is no typo in the function names. I agree that the likelihood of getting this wrong is low, but it is still a good practice to use official include files to have the compiler help checking this.
* If we would like to bundle libsleef.so with the JVM, now we have the possibility do do so easily. (Especially if it is like you say that it is not commonly installed). (If licenses allow etc)
* If we want to incorporate/bundle the source code of libsleef into OpenJDK, and build it as part of our internal library, we will have a good starting position, compared to starting from a hard-coded assembly file in hotspot. (I thought I heard some noise about this prospect).

So at this point, I am okay with the general approach of this PR. There are still some build issues to sort out, though, I'll address them separately.

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1836266314

From redestad at openjdk.org  Fri Dec  1 16:23:17 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 1 Dec 2023 16:23:17 GMT
Subject: RFR: 8311906: Improve robustness of String constructors with
 mutable array inputs [v14]
In-Reply-To: <ipEQhT5ALrTTIFnVivtcHvCsHwIBfdZQqqSy5dh5DfA=.1894285d-0f87-42ba-8643-fcc9b647847f@github.com>
References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com>
 <ipEQhT5ALrTTIFnVivtcHvCsHwIBfdZQqqSy5dh5DfA=.1894285d-0f87-42ba-8643-fcc9b647847f@github.com>
Message-ID: <cTm5zr4fg9BgEDHJ-9DV-GRIj7i8J3xHB4e3YNqpw-8=.0fc72de3-394f-496e-9ce9-5d58bc727868@github.com>

On Thu, 30 Nov 2023 15:51:46 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers.
>> The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. 
>> 
>> The changes include:
>> 
>> - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate 
>>   if the input array is modified before the constructor returns. 
>>   The resulting string may contain any combination of characters sampled from the input array.
>> 
>> - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character.
>>   For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged.
>>   If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index.
>>   If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect.
>>   Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided.
>>   Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned.
>> 
>> - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character.
>> 
>> - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct jcc/jccb branches

Marked as reviewed by redestad (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16425#pullrequestreview-1760162195

From rriggs at openjdk.org  Fri Dec  1 16:23:19 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 1 Dec 2023 16:23:19 GMT
Subject: RFR: 8311906: Improve robustness of String constructors with
 mutable array inputs [v13]
In-Reply-To: <REe6wyDqn6w0Q8uQWeBctTqVIu3y_TMjxRBDtjq2U7Q=.6990e50c-49f2-4a71-942a-3a87c2c7852b@github.com>
References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com>
 <THrc4wRVDrJoaVnChACtv50zqhddIv86GgQt3ZUZxIs=.169591cb-5b06-4b3c-a384-f39fc509aae5@github.com>
 <REe6wyDqn6w0Q8uQWeBctTqVIu3y_TMjxRBDtjq2U7Q=.6990e50c-49f2-4a71-942a-3a87c2c7852b@github.com>
Message-ID: <Q48QtnP3uTQAXzgHk6BQWd_8VRsSAu4rWhsw_4FX2kE=.7e8e2cef-b9d9-43df-abb6-bd0e35ebf8c0@github.com>

On Thu, 30 Nov 2023 08:00:12 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use byte off branches in char_array_compress
>>   Verified by manual tests with "-XX:AVX3Threshold=0"
>>   And test in the PR test/hotspot/jtreg/compiler/intrinsics/string/TestStringConstructionIntrinsics.java
>
> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 8547:
> 
>> 8545:     // bail out when there is nothing to be done
>> 8546:     testl(tmp5, 0xFFFFFFFF);
>> 8547:     jcc(Assembler::zero, post_alignment);
> 
> @RogerRiggs I think you changed the wrong line ? 
> Suggestion:
> 
>     jccb(Assembler::zero, post_alignment);

Thanks for spotting that mistake, corrected in [b2fc385](https://github.com/openjdk/jdk/pull/16425/commits/b2fc38550ba95bcd7ec1ae4f52f22b220afcb045).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1410870186

From ihse at openjdk.org  Fri Dec  1 16:29:18 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 1 Dec 2023 16:29:18 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v6]
In-Reply-To: <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
Message-ID: <dxnGzEBuDdVHnuYm1AaoTYNjTQzdpHHamkgb3QxEpPc=.7671caf2-74f8-4d6f-8bcf-8f189488bd0a@github.com>

On Fri, 1 Dec 2023 08:48:52 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
>> 
>> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
>> 
>> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
>> 
>> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
>> 
>> [1] https://github.com/openjdk/jdk/pull/3638
>> [2] https://sleef.org/
>> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
>> [4] https://packages.debian.org/bookworm/libsleef3
>> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html
>
> Xiaohong Gong has updated the pull request with a new target base 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:
> 
>  - Separate neon and sve functions into two source files
>  - Merge branch 'jdk:master' into JDK-8312425
>  - Rename vmath to sleef in configure
>  - Address review comments in build system
>  - Add a bundled native lib in jdk as a bridge to libsleef
>  - Merge 'jdk:master' into JDK-8312425
>  - Disable sleef by default
>  - Merge 'jdk:master' into JDK-8312425
>  - 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF

doc/building.md line 639:

> 637: 
> 638: libsleef, the [SIMD Library for Evaluating Elementary Functions](
> 639: https://sleef.org/) is required when building libvmath.so on Linux/aarch64

This is incorrect. The library is not required, but if it is present, we will build libvmath with it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1412330808

From ihse at openjdk.org  Fri Dec  1 16:39:14 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 1 Dec 2023 16:39:14 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v5]
In-Reply-To: <aArEqABKvjZDCxOkkpKS1rlX9Q0aafCUY8ZS3L5OBek=.f009f07b-c9e4-437b-a6d3-c86fb29d75a0@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <nZFspjlPXfeQxrr5cKfbjeL3typf6DKSgNQUNszhufE=.caac471d-9c7b-4f8f-953f-04ee4a13f111@github.com>
 <9VeMdTAJPaPZDg9ZW7FVJOf9XGl4gGqAS-2g8SFc9c0=.36792cd5-66d9-4abc-ba0c-aee3478627f4@github.com>
 <mnf_hjWdemelALPlwcS8mnKIxR5ljIyGD6MHpqCPDsQ=.0cb49580-ed76-4728-a604-acff3dff42a5@github.com>
 <aArEqABKvjZDCxOkkpKS1rlX9Q0aafCUY8ZS3L5OBek=.f009f07b-c9e4-437b-a6d3-c86fb29d75a0@github.com>
Message-ID: <vlqKSuAKzKRTXWG_hLCEJixN8oFec68IuSnfb0u9OJ0=.6c926fc3-f0f3-4ccf-b373-555948c3702b@github.com>

On Fri, 1 Dec 2023 10:02:35 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Did you try to find the libsleef by passing `--with-libsleef=` ? Currently `--with-libsleef=` can only work for people manually built from sleef source code.
>
> Yes. It still failed.

You need to expand this logic to cover more instances. See e.g. lib-ffi.m4 for inspiration.

Basic flow:
* if user has specified libsleef root with argument, check both lib/ and lib64/ under that root.
* if user has not specified libsleef root, and we have no SYSROOT, try PKG_CHECK
* Otherwise, look in well-known directories which is $SYSROOT/usr/[local/]lib[64].

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1412340745

From ihse at openjdk.org  Fri Dec  1 16:39:15 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 1 Dec 2023 16:39:15 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v5]
In-Reply-To: <vlqKSuAKzKRTXWG_hLCEJixN8oFec68IuSnfb0u9OJ0=.6c926fc3-f0f3-4ccf-b373-555948c3702b@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <nZFspjlPXfeQxrr5cKfbjeL3typf6DKSgNQUNszhufE=.caac471d-9c7b-4f8f-953f-04ee4a13f111@github.com>
 <9VeMdTAJPaPZDg9ZW7FVJOf9XGl4gGqAS-2g8SFc9c0=.36792cd5-66d9-4abc-ba0c-aee3478627f4@github.com>
 <mnf_hjWdemelALPlwcS8mnKIxR5ljIyGD6MHpqCPDsQ=.0cb49580-ed76-4728-a604-acff3dff42a5@github.com>
 <aArEqABKvjZDCxOkkpKS1rlX9Q0aafCUY8ZS3L5OBek=.f009f07b-c9e4-437b-a6d3-c86fb29d75a0@github.com>
 <vlqKSuAKzKRTXWG_hLCEJixN8oFec68IuSnfb0u9OJ0=.6c926fc3-f0f3-4ccf-b373-555948c3702b@github.com>
Message-ID: <a0fi6KAaaVceRSRWzviR0W1iN-CjlkCIS9GjHAxRr5g=.324dd1aa-d4bd-48f1-8e23-604b09b75b4c@github.com>

On Fri, 1 Dec 2023 16:35:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Yes. It still failed.
>
> You need to expand this logic to cover more instances. See e.g. lib-ffi.m4 for inspiration.
> 
> Basic flow:
> * if user has specified libsleef root with argument, check both lib/ and lib64/ under that root.
> * if user has not specified libsleef root, and we have no SYSROOT, try PKG_CHECK
> * Otherwise, look in well-known directories which is $SYSROOT/usr/[local/]lib[64].

also, ideally, you will add the corresponding specific overrides like in ffi:

  AC_ARG_WITH(libffi-include, [AS_HELP_STRING([--with-libffi-include],
      [specify directory for the libffi include files])])
  AC_ARG_WITH(libffi-lib, [AS_HELP_STRING([--with-libffi-lib],
      [specify directory for the libffi library])])

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1412341451

From ihse at openjdk.org  Fri Dec  1 16:48:17 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 1 Dec 2023 16:48:17 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v6]
In-Reply-To: <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
Message-ID: <emidt6MaU3Owb2FMLA1EibqvQF4_zTtsA00ccPQAy4Y=.1b90ba32-ac3a-41db-acf9-f1c45704b203@github.com>

On Fri, 1 Dec 2023 08:48:52 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
>> 
>> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
>> 
>> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
>> 
>> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
>> 
>> [1] https://github.com/openjdk/jdk/pull/3638
>> [2] https://sleef.org/
>> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
>> [4] https://packages.debian.org/bookworm/libsleef3
>> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html
>
> Xiaohong Gong has updated the pull request with a new target base 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:
> 
>  - Separate neon and sve functions into two source files
>  - Merge branch 'jdk:master' into JDK-8312425
>  - Rename vmath to sleef in configure
>  - Address review comments in build system
>  - Add a bundled native lib in jdk as a bridge to libsleef
>  - Merge 'jdk:master' into JDK-8312425
>  - Disable sleef by default
>  - Merge 'jdk:master' into JDK-8312425
>  - 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF

The final thing we need to resolve properly is the SVE compiler test. 

@theRealAph says:
> arm_sve.h is part of GCC. It was added to GCC in 2019.

A more relevant question is what version of gcc it was added, and if that also implies that the compiler knows about `-march=armv8-a+sve`. If so, then this test could basically be framed as a gcc version check.

I'm still leaning towards failing configure if the SVE code cannot be compiled. Under what circumstances can this test possibly fail, so SVE_CFLAGS would not be set?

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1836444674

From aph at openjdk.org  Fri Dec  1 16:52:14 2023
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 1 Dec 2023 16:52:14 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v6]
In-Reply-To: <3cK9QjVQNIgZoWWhrWKEb3XxfbLjprjRMBbStWegH7M=.6df92651-b97d-445a-aa42-302ea791bbea@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
 <3cK9QjVQNIgZoWWhrWKEb3XxfbLjprjRMBbStWegH7M=.6df92651-b97d-445a-aa42-302ea791bbea@github.com>
Message-ID: <lQJoZ_hXjfLO-MRGDLar9L0yD6xAXF1QAu2AIAjwnKk=.390b6b58-3e5d-42af-90e6-2dd76b29172f@github.com>

On Fri, 1 Dec 2023 10:19:01 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request with a new target base 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:
>> 
>>  - Separate neon and sve functions into two source files
>>  - Merge branch 'jdk:master' into JDK-8312425
>>  - Rename vmath to sleef in configure
>>  - Address review comments in build system
>>  - Add a bundled native lib in jdk as a bridge to libsleef
>>  - Merge 'jdk:master' into JDK-8312425
>>  - Disable sleef by default
>>  - Merge 'jdk:master' into JDK-8312425
>>  - 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF
>
> Oh, and:
> 
> If we can't trust SLEEF not to break the ABI we're using, we should not be using SLEEF.

> @theRealAph You are making good points.
> 
> You are basically saying: "we don't need any configure support for libsleef, we can just hard-code the names and dispatch to them directly to a dlopened library at runtime".

Yep.

> That is technically correct, but I'd still like to argue that the current setup have some merits:
> 
>     * It will check that there is no typo in the function names. I agree that the likelihood of getting this wrong is low, but it is still a good practice to use official include files to have the compiler help checking this.
> 
>     * If we would like to bundle libsleef.so with the JVM, now we have the possibility do do so easily. (Especially if it is like you say that it is not commonly installed). (If licenses allow etc)
> 
>     * If we want to incorporate/bundle the source code of libsleef into OpenJDK, and build it as part of our internal library, we will have a good starting position, compared to starting from a hard-coded assembly file in hotspot. (I thought I heard some noise about this prospect).
> 
> 
> So at this point, I am okay with the general approach of this PR. There are still some build issues to sort out, though, I'll address them separately.

I see, OK. The question in my mind is whether the common builds of OpenJDK (Oracle, Adoptium, etc.) will support running with SLEEF. If by default SLEEF is not required, support won't be built, and (to an nth order approximation) no one will use it. But I guess it's better than nothing.

Or is there likely to be a plan to e.g. build Oracle's releases with SLEEF support?

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1836449876

From eirbjo at gmail.com  Fri Dec  1 17:00:17 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Fri, 1 Dec 2023 18:00:17 +0100
Subject: Revisiting JDK-4512189: ZipConstants leaking into public APIs
In-Reply-To: <128ad702-d589-4365-a62f-baea1ec9e73a@oracle.com>
References: <CA+pBWhu-ebsU3Rxdyyjn_dECVAzxV2-9ducH=htY4qhO8V6guA@mail.gmail.com>
 <128ad702-d589-4365-a62f-baea1ec9e73a@oracle.com>
Message-ID: <CA+pBWhtqCfuTRBs7XiN6P2FJkkoRExM8HqwNZMZ8=LZyXEJARA@mail.gmail.com>

On Tue, Nov 28, 2023 at 6:16?PM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> This is a JDK 1.1 era mistake. It would a source incompatible change to
> "remove" the constants. It would require corpus searches to gauge the
> impact.


Alan,

I've tried to assess the impact by using Github's Code Search. As far as I
can tell, this searches 141M Java source files across 5K repositories.

I searched for various combinations of {ZipEntry, ZipFile, ZipInputStream,
ZipOutputStream} and the fields of ZipConstants, weeding out things
clearly derived from OpenJDK sources, forks of other repositories and
repositories no longer maintained.

In the end I found usages of these constants in something like 10
repositories, including:

bazelbuild/bazel
h2oai/h2o-3
oracle/graal
apache/netbeans
facebook/buck
jbossas/jboss-vfs
jMonkeyEngine/jmonkeyengine

Most matches used just one or a few constants (checking magic numbers to
guess file formats), others used more constants when parsing and/or writing
ZIP files. All of them should be rather trivial to fix, the solution is for
the projects to define their own constants, copying those needed from
ZipConstants.

Based on the results of my search, my guess is that the disruption should
be fairly limited. Zip file format parsing is just not something Java
programmers do very often.


> I think the question is whether it's worth the disruption, is
> your motivation to cleanup this area or something stronger?
>

The reason I started looking at this was that I was looking into
refactoring ZipUtils. There is a good amount of code duplication in how
fields are read. These efforts were complicated by the constants being
"effectively public", since I can't rename them or remove them.

To summarize my motivations:

- These constants distract and confuse current and future users of the
APIs, stealing cycles better spent elsewhere
- Likewise, current and future maintainers of OpenJDK will also find them
confusing
- They limit or prevent certain code cleanups and improvements
- They are aesthetically unpleasing. This concern is perhaps not
typically appreciated in an engineering culture. But in this case, these
mysteriously named fields in a widely used public API just feels wrong.
Knowing they got there by mistake does not make this better. It's just
Matter Out Of Place". Every product or technology has a certain "weirdness
budget". These constants are eating into Java's. Fixing this will free up
some weirdness dollars, I'm sure we can find better use for them elsewhere
:-)

I think I'm done hammering this nail for now. I would love to deprecate the
constants and see them go some releases down the road. But that would need
a broader consensus which I'm not sure we have.

Thanks,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20231201/2a0e0ad5/attachment-0001.htm>

From lmesnik at openjdk.org  Fri Dec  1 17:03:06 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 1 Dec 2023 17:03:06 GMT
Subject: RFR: 8320129: "top" command during jtreg failure handler does not
 display CPU usage on OSX
In-Reply-To: <cylR98W-HGZUXrw7n5BMFLq-efMWfdg7ZcaW6OQaIa0=.edaa4e47-a216-4dde-be51-b5b47fd978e6@github.com>
References: <cylR98W-HGZUXrw7n5BMFLq-efMWfdg7ZcaW6OQaIa0=.edaa4e47-a216-4dde-be51-b5b47fd978e6@github.com>
Message-ID: <doIqsv16SO4hxE8AGbbr7eZrvakBa3l-gOMc87nUrsE=.d34ad398-f1a6-4b8d-a3e1-99481e2e817b@github.com>

On Fri, 1 Dec 2023 00:58:57 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Description of problem and propsed fix from @plummercj 
> '
> In test/failure_handler/src/share/conf/mac.properties we have:
> 
> process.top.app=top
> process.top.args=-l 1
> 
> So top is run with the "-l 1" args, causing it to do one iteration and then exit. Unfortunately the first iteration always shows all 0's for CPU usage. If you do at least 2 iterations, you do see the proper CPU usage on the 2nd iteration. The user just needs to know to scroll down to see it. I suggest we start using "-l 2" unless someone has a better idea.
> 
> BTW, for proper CPU usage you can instead look at the failure handler "ps" output, which seems to be correct. But it is nice to have "top" produce the correct output so all the CPU hogs are at the top of the list.
> '
> 
> I verified that top report contains now 2 samples.

The top problem is macos specific issue and no need to fix other OS.

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

PR Comment: https://git.openjdk.org/jdk/pull/16915#issuecomment-1836465281

From vklang at openjdk.org  Fri Dec  1 17:06:30 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 1 Dec 2023 17:06:30 GMT
Subject: RFR: 8321124: java/util/stream/GatherersTest.java times out
Message-ID: <NcgSgagzqKytU8dGSMKHUF_9ylICS5s6If5CoFRjPhw=.abef3a79-b429-47c5-b0b7-aa7b9f71ef31@github.com>

Renames GatherersTest to BuiltInGatherersTest for easier deduplication of GathererTest.

Fixes a test ordering issue in testMapConcurrentAPIandContract().

Adding increased maxOutputSize for Gatherer-related tests to improve debuggability.

Lowering the composition threshold of GathererTest.testMassivelyComposedGatherers to 256 to avoid SOE on low-specc:ed machines.

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

Commit messages:
 - Stabilization of GatherersTest and renaming it

Changes: https://git.openjdk.org/jdk/pull/16928/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16928&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321124
  Stats: 761 lines in 5 files changed: 391 ins; 369 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16928.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16928/head:pull/16928

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

From vklang at openjdk.org  Fri Dec  1 17:06:32 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 1 Dec 2023 17:06:32 GMT
Subject: RFR: 8321124: java/util/stream/GatherersTest.java times out
In-Reply-To: <NcgSgagzqKytU8dGSMKHUF_9ylICS5s6If5CoFRjPhw=.abef3a79-b429-47c5-b0b7-aa7b9f71ef31@github.com>
References: <NcgSgagzqKytU8dGSMKHUF_9ylICS5s6If5CoFRjPhw=.abef3a79-b429-47c5-b0b7-aa7b9f71ef31@github.com>
Message-ID: <Y4w-XW-jJHDznl9HQshDIdcgI_u5w2DHCBWrlaUh0QM=.98200d8c-9d5f-487e-9dde-a717dc4d414a@github.com>

On Fri, 1 Dec 2023 17:00:48 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Renames GatherersTest to BuiltInGatherersTest for easier deduplication of GathererTest.
> 
> Fixes a test ordering issue in testMapConcurrentAPIandContract().
> 
> Adding increased maxOutputSize for Gatherer-related tests to improve debuggability.
> 
> Lowering the composition threshold of GathererTest.testMassivelyComposedGatherers to 256 to avoid SOE on low-specc:ed machines.

test/jdk/java/util/stream/BuiltInGatherersTest.java line 331:

> 329:                                     case Integer n when n == config.streamSize - 1 -> {
> 330:                                         awaitSensibly(firstReady);
> 331:                                         while(tasksWaiting.getQueueLength() < tasksToCancel) {

@AlanBateman This is the only part of this I really don't like. Any better suggestion as to "wait for N things waiting" in a test? ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16928#discussion_r1412368710

From naoto at openjdk.org  Fri Dec  1 17:42:17 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 1 Dec 2023 17:42:17 GMT
Subject: RFR: 8320798: Console read line with zero out should zero out
 underlying buffer [v3]
In-Reply-To: <8mADwh5tk-5DhucpbLxUAiPDOgxSkJru210ndcjXWaU=.f1dbb46e-974a-4975-8b08-cb8d34bf92cc@github.com>
References: <CdG_iGykiGmAUIsoDTD7KBhH4pzbLDhFU5PVxiTwSNU=.10d379f6-427f-493a-9c24-a616e8d5f329@github.com>
 <8mADwh5tk-5DhucpbLxUAiPDOgxSkJru210ndcjXWaU=.f1dbb46e-974a-4975-8b08-cb8d34bf92cc@github.com>
Message-ID: <vBDUV0rYB62G6KtX2wXLhEq9kGL7zHosyMWe5ogJ0cY=.9c42e350-72d5-43ee-900c-c6cca9c3e768@github.com>

On Thu, 30 Nov 2023 17:39:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> It is best practice to zero out the underlying buffer after use.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove ensureOpen()

Thanks all for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/16861#issuecomment-1836517976

From naoto at openjdk.org  Fri Dec  1 17:42:18 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 1 Dec 2023 17:42:18 GMT
Subject: Integrated: 8320798: Console read line with zero out should zero out
 underlying buffer
In-Reply-To: <CdG_iGykiGmAUIsoDTD7KBhH4pzbLDhFU5PVxiTwSNU=.10d379f6-427f-493a-9c24-a616e8d5f329@github.com>
References: <CdG_iGykiGmAUIsoDTD7KBhH4pzbLDhFU5PVxiTwSNU=.10d379f6-427f-493a-9c24-a616e8d5f329@github.com>
Message-ID: <Gdf1wzvZCp8NRDdm0RQK-hq0ATEBWr52E4c65kcmw84=.bf9e5a5d-2a00-4642-9a82-47fc1dbd8c37@github.com>

On Tue, 28 Nov 2023 19:12:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> It is best practice to zero out the underlying buffer after use.

This pull request has now been integrated.

Changeset: d5685629
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d568562966e9a2020704eee3d67b8a106f647d9c
Stats:     30 lines in 2 files changed: 29 ins; 0 del; 1 mod

8320798: Console read line with zero out should zero out underlying buffer

Reviewed-by: bpb, lancea, joehw, alanb, jpai, mbaesken

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

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

From naoto at openjdk.org  Fri Dec  1 17:46:15 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 1 Dec 2023 17:46:15 GMT
Subject: Integrated: 8321059: Unneeded array assignments in MergeCollation and
 CompactByteArray
In-Reply-To: <XvjkCvV-ouUN4AXiU4UR3LtXqBdseHUi-kVKE_7SAXw=.93a61370-5aac-4101-b944-dac5583c9313@github.com>
References: <XvjkCvV-ouUN4AXiU4UR3LtXqBdseHUi-kVKE_7SAXw=.93a61370-5aac-4101-b944-dac5583c9313@github.com>
Message-ID: <h37B7DBqswx6Y2DZugu_iSz56veMHR63qM237m7LLsU=.97f3ddd8-21f9-4bf2-9bf6-5b169e03caf9@github.com>

On Thu, 30 Nov 2023 20:46:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing the unnecessary array assignments.

This pull request has now been integrated.

Changeset: f6be7fdf
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f6be7fdf22eede767a0ac29b4f1cb770cfdc0b0f
Stats:     8 lines in 2 files changed: 2 ins; 3 del; 3 mod

8321059: Unneeded array assignments in MergeCollation and CompactByteArray

Reviewed-by: jlu, bpb, rriggs

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

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

From uschindler at openjdk.org  Fri Dec  1 18:02:18 2023
From: uschindler at openjdk.org (Uwe Schindler)
Date: Fri, 1 Dec 2023 18:02:18 GMT
Subject: RFR: 8310644: Make panama memory segment close use async
 handshakes [v5]
In-Reply-To: <B_FOe26CGqtBI2_W5WCZjw1HDKVPJ7CCC96hCryN77o=.8c1704bc-de10-4026-bf7a-c75ee1139f02@github.com>
References: <Oa4am1eEQWDRQ3TmmPSNBDUqvsX-9f5uTqZK0PoLKKY=.922efad7-c67b-478b-804f-c4529f035cd6@github.com>
 <B_FOe26CGqtBI2_W5WCZjw1HDKVPJ7CCC96hCryN77o=.8c1704bc-de10-4026-bf7a-c75ee1139f02@github.com>
Message-ID: <nznQH1nHOummYa82gpXMEocei-suqOMDE10ZwR9tAFw=.b5a9e5d4-d2db-4c2a-9016-cb8a5b316a77@github.com>

On Fri, 24 Nov 2023 18:30:17 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> The current logic for closing memory in panama today is susceptible to live lock if we have a closing thread that wants to close the memory in a loop that keeps failing, and a bunch of accessing threads that want to perform accesses as long as the memory is alive. They can both create impediments for the other.
>> 
>> By using asynchronous handshakes to install an exception onto threads that are in @Scoped memory accesses, we can have close always succeed, and the accessing threads bail out. The idea is that we perform a synchronous handshake first to find threads that are in scoped methods. They might however be in the middle of throwing an exception or something wild like there, where an exception can't be delivered. We install an async handshake that will roll us forward to the first place where we can indeed install exceptions, then we reevaluate if we still need to do that, or if we have unwound out from the scoped method. If we are still inside of it, we ensure an exception is installed so we don't continue executing bytecodes that might access the memory that we have freed.
>> 
>> Tested tier 1-5 as well as running test/jdk/java/foreign/TestHandshake.java hundreds of times, which tests this API pretty well.
>
> Erik ?sterlund has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge pull request #3 from JornVernee/PR_async_close+NoToNativeTrans
>    
>  - don't transition to native state on Unsafe_CopySwapMemory0

I can confirm: This works fine with Lucene! The isAlive state is visible in other threads and closing the Arena's scope can no longer throw IllegalStateException. See comment here: https://github.com/apache/lucene/pull/12706#issuecomment-1836540146

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

PR Comment: https://git.openjdk.org/jdk/pull/16792#issuecomment-1836546089

From lancea at openjdk.org  Fri Dec  1 18:33:06 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 1 Dec 2023 18:33:06 GMT
Subject: RFR: JDK-8319626: Override toString() for ZipFile [v5]
In-Reply-To: <jTdmT2eHGx2qpT49lS1Kfc7qOREJ129QIV8NL9ZChXY=.920b6abb-4276-45aa-a418-005f3a414a12@github.com>
References: <UEVJDXC8Cs_RSBUEsWgmq8SPvI-T4LSydbPKr8u29iA=.fdce7d47-87a8-42ba-9cd4-119bf9023ad9@github.com>
 <wB4yFDlB09wPiTVnVh_c8D6CCd891DVhkXRhVYS6ds0=.39caf916-1699-4f55-a19a-769f99b6b03e@github.com>
 <lpGHlMeTl3m97zKwyq8KL42LrIgCLkF3eDBItZGnyZs=.8f751dfa-ad8e-4fab-bfee-13bfb320d0ea@github.com>
 <z2KCa_GpQ99W9mkXWDpfPeayo9p4GZSALbyXMcOUmis=.00ade9f7-5530-4b7e-914e-32e86fbc8df4@github.com>
 <kJg-Cqk1k9WG0O8ZmtzX4S1WmK1rDaPVI_oiKO04pTE=.e4087dbc-8cc0-403a-b62c-aa524005d849@github.com>
 <7Iv6zv2OJnMWtJLbxAm8UnyphN19jbbJ-FuzK4yzr58=.4f1d7891-9484-4e79-8bb0-922cdc094034@github.com>
 <jTdmT2eHGx2qpT49lS1Kfc7qOREJ129QIV8NL9ZChXY=.920b6abb-4276-45aa-a418-005f3a414a12@github.com>
Message-ID: <RCwljbkpkBi_W7N6cskFc_rVJN05lMnKmIFTiheKGww=.ce691617-da53-4b28-a154-82fb246ab460@github.com>

On Fri, 1 Dec 2023 08:49:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Thanks Jai, that makes sense. Replaced full path with just the base name in latest commit.
>
> I think the second paragraph of the method description is problematic. Documenting the representation and then saying it is subject to change is going to cause problems in the future? Can you just drop this paragraph?

I agree we should probably remove the 2nd paragraph

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16643#discussion_r1412442494

From vromero at openjdk.org  Fri Dec  1 18:34:05 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 1 Dec 2023 18:34:05 GMT
Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v4]
In-Reply-To: <P9uONCgJlH6ON2nqV1TxpJ5tn_XrGmBuFWKrU45JrKs=.4f773cc2-b13c-42c8-a7f4-2591af065743@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
 <P9uONCgJlH6ON2nqV1TxpJ5tn_XrGmBuFWKrU45JrKs=.4f773cc2-b13c-42c8-a7f4-2591af065743@github.com>
Message-ID: <xWX4clN3bYSCxLaE03Oi4g8D5jDDJNh9zdN5jN3CGmU=.9ee00d2d-6115-40a8-800a-5d5bb67ddf4d@github.com>

On Thu, 30 Nov 2023 23:49:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start making preparations for JDK 23.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update symbol files to JDK 22 b26.

looks good to me

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16505#pullrequestreview-1760367216

From jlu at openjdk.org  Fri Dec  1 18:40:18 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 1 Dec 2023 18:40:18 GMT
Subject: RFR: JDK-8319626: Override toString() for ZipFile [v6]
In-Reply-To: <UEVJDXC8Cs_RSBUEsWgmq8SPvI-T4LSydbPKr8u29iA=.fdce7d47-87a8-42ba-9cd4-119bf9023ad9@github.com>
References: <UEVJDXC8Cs_RSBUEsWgmq8SPvI-T4LSydbPKr8u29iA=.fdce7d47-87a8-42ba-9cd4-119bf9023ad9@github.com>
Message-ID: <1Vj_9p3Aq6oTWtgd8gXW8QttYpYtA5fkkRU1t-xEu9I=.7dce8b9e-dd68-4130-adfa-47f0ae8f7f29@github.com>

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319982) which overrides and provides an implementation of `toString()` in _java.util.zip.ZipFile_ (and by extension, _java.util.jar.JarFile_).

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

  drop 2nd paragraph

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16643/files
  - new: https://git.openjdk.org/jdk/pull/16643/files/3d8ed448..21762cd2

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

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

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

From duke at openjdk.org  Fri Dec  1 18:54:35 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 1 Dec 2023 18:54:35 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v8]
In-Reply-To: <YC-brtYplAtPMhbeW2nv1XxQRLNVMEKRHbJv8JFVQQM=.8d8c7d60-27c4-4a61-b9cf-45dad0da18c2@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <YC-brtYplAtPMhbeW2nv1XxQRLNVMEKRHbJv8JFVQQM=.8d8c7d60-27c4-4a61-b9cf-45dad0da18c2@github.com>
Message-ID: <p7nchdmmsLLGEepc2Zo1_GDjm2s9Sbzr8PsHqtBBQU0=.88eadba5-d0ab-4aa8-a148-1a4a23b13256@github.com>

On Wed, 15 Nov 2023 20:10:53 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the number of compressed or uncompressed bytes read from the inflater is larger than the Zip64 magic value.
>> 
>> While the ZIP format  mandates that the data descriptor `SHOULD be stored in ZIP64 format (as 8 byte values) when a file's size exceeds 0xFFFFFFFF`, it also states that `ZIP64 format MAY be used regardless of the size of a file`. For such small entries, the above assumption does not hold.
>> 
>> This PR augments ZipInputStream.readEnd to also assume 8-byte sizes if the ZipEntry includes a Zip64 extra information field. This brings ZipInputStream into alignment with the APPNOTE format spec:
>> 
>> 
>> When extracting, if the zip64 extended information extra 
>> field is present for the file the compressed and 
>> uncompressed sizes will be 8 byte values.
>> 
>> 
>> While small Zip64 files with 8-byte data descriptors are not commonly found in the wild, it is possible to create one using the Info-ZIP command line `-fd` flag:
>> 
>> `echo hello | zip -fd > hello.zip`
>> 
>> The PR also adds a test verifying that such a small Zip64 file can be parsed by ZipInputStream.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extract ZIP64_BLOCK_SIZE_OFFSET as a constant

Thanks for your patient and thorough review of this long-lived PR, Lance!

No worries, we can hold off the integration until after 22 is forked off mainline.

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

PR Comment: https://git.openjdk.org/jdk/pull/12524#issuecomment-1830464397

From iris at openjdk.org  Fri Dec  1 19:45:55 2023
From: iris at openjdk.org (Iris Clark)
Date: Fri, 1 Dec 2023 19:45:55 GMT
Subject: RFR: 8321131: Console read line with zero out should zero out
 underlying buffer in JLine
In-Reply-To: <PzHZPvbxGMfURD7JoaIocGRD8gkyJFh-i0oPeMx9zdc=.df1f2a34-527d-4e4a-b468-ddb51ad2d330@github.com>
References: <PzHZPvbxGMfURD7JoaIocGRD8gkyJFh-i0oPeMx9zdc=.df1f2a34-527d-4e4a-b468-ddb51ad2d330@github.com>
Message-ID: <IZPGupsindhLivBsL5xaeBcfy_YsKDXgF2FP2Qdov9k=.b18a71cf-de81-4a25-9bf3-08d637e651e8@github.com>

On Fri, 1 Dec 2023 18:24:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is the fix to JLine, which makes it on par with the built-in Console fix ([JDK-8320798](https://bugs.openjdk.org/browse/JDK-8320798)).

Marked as reviewed by iris (Reviewer).

src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 114:

> 112:                 return null;
> 113:             } finally {
> 114:                 jline.zeroOut();

The location of the `jline `declaration at new line 134 is unfortunate, but not a problem this PR needs to resolve.  The location makes sense if it was only used in `initJLineIfNeeded()` at some point in the past.

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

PR Review: https://git.openjdk.org/jdk/pull/16930#pullrequestreview-1760456573
PR Review Comment: https://git.openjdk.org/jdk/pull/16930#discussion_r1412504396

From lmesnik at openjdk.org  Fri Dec  1 20:03:54 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 1 Dec 2023 20:03:54 GMT
Subject: RFR: 8321163: [test] OutputAnalyzer.getExitValue() unnecessarily
 logs even when process has already completed [v3]
In-Reply-To: <0GAdkVhk4e3WJp5bQuLdvtxHk5BtRguNmQ7PoQ5dH50=.4f01dd8f-e2f5-47f8-b66a-2801156d56f5@github.com>
References: <uZ77Eagw9Lxz1BKJ8fMnCzvp8Z5VVqsGnsLZtqKZDIo=.0fb8e6cf-7d79-4d4e-b99d-171e008210e9@github.com>
 <0GAdkVhk4e3WJp5bQuLdvtxHk5BtRguNmQ7PoQ5dH50=.4f01dd8f-e2f5-47f8-b66a-2801156d56f5@github.com>
Message-ID: <WQTg0UCZOliuCoDkAlHUsav80kxcpqL9Gj_zDiJGDis=.feed38ca-424c-443d-975a-72f96e3db711@github.com>

On Fri, 1 Dec 2023 12:44:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change to the test library's `OutputAnalyzer` class, which proposes to remove some unnecessary logging from the `getExitValue()` call?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8321163, right now this method logs:
>> 
>> 
>> [2023-11-24T11:47:54.557561Z] Waiting for completion for process 24909
>> [2023-11-24T11:47:54.557873Z] Waiting for completion finished for process 24909
>> 
>> 
>> even when the process has already completed and the exit value already known. The change in this PR makes it such that if the exit value is available then we no longer log this (nor call `process.waitFor()`).
>> 
>> No new tests have been added given the nature of this change. tier1, tier2 and tier3 tests continue to pass with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove micro optimization

Technically, the volatile is not enough to avoid racy writing into exitValue. However, it doesn't affect logic.

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16919#pullrequestreview-1760491166

From naoto at openjdk.org  Fri Dec  1 21:24:47 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 1 Dec 2023 21:24:47 GMT
Subject: RFR: 8321131: Console read line with zero out should zero out
 underlying buffer in JLine [v2]
In-Reply-To: <PzHZPvbxGMfURD7JoaIocGRD8gkyJFh-i0oPeMx9zdc=.df1f2a34-527d-4e4a-b468-ddb51ad2d330@github.com>
References: <PzHZPvbxGMfURD7JoaIocGRD8gkyJFh-i0oPeMx9zdc=.df1f2a34-527d-4e4a-b468-ddb51ad2d330@github.com>
Message-ID: <JcV9pmabcFkPVlKlMgvzdhEvewSjQCiBPEhVpWTeM7w=.405a12bc-8f64-4210-94fd-4bd99c4f4fde@github.com>

> This is the fix to JLine, which makes it on par with the built-in Console fix ([JDK-8320798](https://bugs.openjdk.org/browse/JDK-8320798)).

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

  moved instance fields at the top of the class

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16930/files
  - new: https://git.openjdk.org/jdk/pull/16930/files/03e07d93..a3773d44

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

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

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

From naoto at openjdk.org  Fri Dec  1 21:24:49 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 1 Dec 2023 21:24:49 GMT
Subject: RFR: 8321131: Console read line with zero out should zero out
 underlying buffer in JLine [v2]
In-Reply-To: <IZPGupsindhLivBsL5xaeBcfy_YsKDXgF2FP2Qdov9k=.b18a71cf-de81-4a25-9bf3-08d637e651e8@github.com>
References: <PzHZPvbxGMfURD7JoaIocGRD8gkyJFh-i0oPeMx9zdc=.df1f2a34-527d-4e4a-b468-ddb51ad2d330@github.com>
 <IZPGupsindhLivBsL5xaeBcfy_YsKDXgF2FP2Qdov9k=.b18a71cf-de81-4a25-9bf3-08d637e651e8@github.com>
Message-ID: <gmVk5E-99Nq9cYT89uZGM3tdvrmvLglITrqYwUNoqwk=.60f445b4-9de1-46fd-bbe2-7f0c371a786c@github.com>

On Fri, 1 Dec 2023 19:40:39 GMT, Iris Clark <iris at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   moved instance fields at the top of the class
>
> src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 114:
> 
>> 112:                 return null;
>> 113:             } finally {
>> 114:                 jline.zeroOut();
> 
> The location of the `jline `declaration at new line 134 is unfortunate, but not a problem this PR needs to resolve.  The location makes sense if it was only used in `initJLineIfNeeded()` at some point in the past.

Thanks, Iris. Moved those instance fields to the top of the class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16930#discussion_r1412582527

From jlu at openjdk.org  Fri Dec  1 21:32:57 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 1 Dec 2023 21:32:57 GMT
Subject: RFR: JDK-8319626: Override toString() for ZipFile [v7]
In-Reply-To: <UEVJDXC8Cs_RSBUEsWgmq8SPvI-T4LSydbPKr8u29iA=.fdce7d47-87a8-42ba-9cd4-119bf9023ad9@github.com>
References: <UEVJDXC8Cs_RSBUEsWgmq8SPvI-T4LSydbPKr8u29iA=.fdce7d47-87a8-42ba-9cd4-119bf9023ad9@github.com>
Message-ID: <Iy4p9slUnyrWD5XUd6IER-MMmX0VgMyPdV6lYPWzLq4=.6e54f547-9bce-4469-8e37-3a2be9e02ac1@github.com>

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319982) which overrides and provides an implementation of `toString()` in _java.util.zip.ZipFile_ (and by extension, _java.util.jar.JarFile_).

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

  drop additional specification

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16643/files
  - new: https://git.openjdk.org/jdk/pull/16643/files/21762cd2..159c4c8f

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

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

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

From jlu at openjdk.org  Fri Dec  1 21:51:14 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 1 Dec 2023 21:51:14 GMT
Subject: RFR: 6230751: [Fmt-Ch] Recursive MessageFormats in ChoiceFormats
 ignore indicated subformats [v2]
In-Reply-To: <7wIjtUukVVmPac0CLynJTK8zIx7Difi9122zthoFj_w=.8e65ff5d-816b-4383-b833-0df272efaede@github.com>
References: <7wIjtUukVVmPac0CLynJTK8zIx7Difi9122zthoFj_w=.8e65ff5d-816b-4383-b833-0df272efaede@github.com>
Message-ID: <-Lejnw3KKbWnlUfNidurDt-ZeLcUzqZRoLZh9gl3_j0=.0de62ad0-89eb-434c-8780-5fe45cb86997@github.com>

> Please review this PR which updates an incorrect code example in _java/text/ChoiceFormat_.
> 
> ChoiceFormat (and MessageFormat) provide an example of how to produce a pattern that supports singular and plural forms. The ChoiceFormat example is incorrect, as recursive MessageFormats produced by a ChoiceFormat subformat only recognize subformats defined through the MessageFormat pattern syntax, not through the subformats contained within the top level MessageFormat. 
> 
> In the original example,
> `Format[] testFormats = {fileform, null, NumberFormat.getInstance()};` could have been replaced with 
> `Format[] testFormats = {fileform, null, new ChoiceFormat("0#BROKEN")};` and the original output would have been the same.
> 
> This PR replaces the example with the one used in MessageFormat, which is correct. 
> 
> This PR also includes a drive-by fix to remove leftover `<blockquote>`s from a previous `@snippet` conversion.

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

  clarify limitations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16891/files
  - new: https://git.openjdk.org/jdk/pull/16891/files/c8c597a6..f6722242

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

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

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

From jlu at openjdk.org  Fri Dec  1 22:14:20 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 1 Dec 2023 22:14:20 GMT
Subject: RFR: 6230751: [Fmt-Ch] Recursive MessageFormats in ChoiceFormats
 ignore indicated subformats [v2]
In-Reply-To: <-Lejnw3KKbWnlUfNidurDt-ZeLcUzqZRoLZh9gl3_j0=.0de62ad0-89eb-434c-8780-5fe45cb86997@github.com>
References: <7wIjtUukVVmPac0CLynJTK8zIx7Difi9122zthoFj_w=.8e65ff5d-816b-4383-b833-0df272efaede@github.com>
 <-Lejnw3KKbWnlUfNidurDt-ZeLcUzqZRoLZh9gl3_j0=.0de62ad0-89eb-434c-8780-5fe45cb86997@github.com>
Message-ID: <DJPopQSeW_NfJ640p5yz0Vf_3Lh6ZKz31pojaxzbUxE=.78445b45-6b39-49c9-b775-96afa5605ed5@github.com>

On Fri, 1 Dec 2023 21:51:14 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates an incorrect code example in _java/text/ChoiceFormat_.
>> 
>> ChoiceFormat (and MessageFormat) provide an example of how to produce a pattern that supports singular and plural forms. The ChoiceFormat example is incorrect, as recursive MessageFormats produced by a ChoiceFormat subformat only recognize subformats defined through the MessageFormat pattern syntax, not through the subformats contained within the top level MessageFormat. 
>> 
>> In the original example,
>> `Format[] testFormats = {fileform, null, NumberFormat.getInstance()};` could have been replaced with 
>> `Format[] testFormats = {fileform, null, new ChoiceFormat("0#BROKEN")};` and the original output would have been the same.
>> 
>> This PR replaces the example with the one used in MessageFormat, which is correct. 
>> 
>> This PR also includes a drive-by fix to remove leftover `<blockquote>`s from a previous `@snippet` conversion.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clarify limitations

src/java.base/share/classes/java/text/MessageFormat.java line 299:

> 297:  * the string produced by a {@code ChoiceFormat} in {@code MessageFormat} is
> 298:  * treated as special; occurrences of '{' are used to indicate subformats, and
> 299:  * cause recursion. A limitation to this behavior is that, if a {@code MessageFormat}

@naotoj Please let me know if the added limitations wording reads clearly to you. I would rather not have a whole dedicated code example to explain a _limitation_, but if needed for better understanding, I can add one.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16891#discussion_r1412604775

From vklang at openjdk.org  Fri Dec  1 22:16:45 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 1 Dec 2023 22:16:45 GMT
Subject: RFR: 8321124: java/util/stream/GatherersTest.java times out [v2]
In-Reply-To: <NcgSgagzqKytU8dGSMKHUF_9ylICS5s6If5CoFRjPhw=.abef3a79-b429-47c5-b0b7-aa7b9f71ef31@github.com>
References: <NcgSgagzqKytU8dGSMKHUF_9ylICS5s6If5CoFRjPhw=.abef3a79-b429-47c5-b0b7-aa7b9f71ef31@github.com>
Message-ID: <eRHU-J1zkepYoEtzJ9XyoFjibSEIBTdzk6LaAoT-d4w=.0af11429-436a-4dfd-b5f0-806f41ab8107@github.com>

> Renames GatherersTest to BuiltInGatherersTest for easier deduplication of GathererTest.
> 
> Fixes a test ordering issue in testMapConcurrentAPIandContract().
> 
> Adding increased maxOutputSize for Gatherer-related tests to improve debuggability.
> 
> Lowering the composition threshold of GathererTest.testMassivelyComposedGatherers to 256 to avoid SOE on low-specc:ed machines.

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

  Only run the cancellation tests for mapConcurrent for the shorter streams to conserve resources

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16928/files
  - new: https://git.openjdk.org/jdk/pull/16928/files/3605f959..a4ab3469

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

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

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

From vklang at openjdk.org  Fri Dec  1 22:16:47 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 1 Dec 2023 22:16:47 GMT
Subject: RFR: 8321124: java/util/stream/GatherersTest.java times out [v2]
In-Reply-To: <eRHU-J1zkepYoEtzJ9XyoFjibSEIBTdzk6LaAoT-d4w=.0af11429-436a-4dfd-b5f0-806f41ab8107@github.com>
References: <NcgSgagzqKytU8dGSMKHUF_9ylICS5s6If5CoFRjPhw=.abef3a79-b429-47c5-b0b7-aa7b9f71ef31@github.com>
 <eRHU-J1zkepYoEtzJ9XyoFjibSEIBTdzk6LaAoT-d4w=.0af11429-436a-4dfd-b5f0-806f41ab8107@github.com>
Message-ID: <DRKkxA6msb2IlV_JXkjMqvk8esYW1WchBjhz3tjkjQY=.0152f520-87b3-414b-8aec-3c6710ec84a8@github.com>

On Fri, 1 Dec 2023 22:06:14 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Renames GatherersTest to BuiltInGatherersTest for easier deduplication of GathererTest.
>> 
>> Fixes a test ordering issue in testMapConcurrentAPIandContract().
>> 
>> Adding increased maxOutputSize for Gatherer-related tests to improve debuggability.
>> 
>> Lowering the composition threshold of GathererTest.testMassivelyComposedGatherers to 256 to avoid SOE on low-specc:ed machines.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Only run the cancellation tests for mapConcurrent for the shorter streams to conserve resources

test/jdk/java/util/stream/BuiltInGatherersTest.java line 257:

> 255:         // Test cancellation after exception during processing
> 256:         // Only use reasonably sized streams to avoid excessive thread creation
> 257:         if (config.streamSize > 2 && config.streamSize < 100) {

@AlanBateman Decided to not run the cancellation tests for the larger streams as it creates a bunch of extra resource usage which makes GHA really unhappy.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16928#discussion_r1412617167

From naoto at openjdk.org  Fri Dec  1 22:19:23 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 1 Dec 2023 22:19:23 GMT
Subject: RFR: 6230751: [Fmt-Ch] Recursive MessageFormats in ChoiceFormats
 ignore indicated subformats [v2]
In-Reply-To: <DJPopQSeW_NfJ640p5yz0Vf_3Lh6ZKz31pojaxzbUxE=.78445b45-6b39-49c9-b775-96afa5605ed5@github.com>
References: <7wIjtUukVVmPac0CLynJTK8zIx7Difi9122zthoFj_w=.8e65ff5d-816b-4383-b833-0df272efaede@github.com>
 <-Lejnw3KKbWnlUfNidurDt-ZeLcUzqZRoLZh9gl3_j0=.0de62ad0-89eb-434c-8780-5fe45cb86997@github.com>
 <DJPopQSeW_NfJ640p5yz0Vf_3Lh6ZKz31pojaxzbUxE=.78445b45-6b39-49c9-b775-96afa5605ed5@github.com>
Message-ID: <l7S91AjFMhwZYG0LI2rwpOwpASu-7-A7xdbP35npBrU=.46dd7350-f626-49de-bfa8-ce338c79801f@github.com>

On Fri, 1 Dec 2023 21:53:06 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   clarify limitations
>
> src/java.base/share/classes/java/text/MessageFormat.java line 299:
> 
>> 297:  * the string produced by a {@code ChoiceFormat} in {@code MessageFormat} is
>> 298:  * treated as special; occurrences of '{' are used to indicate subformats, and
>> 299:  * cause recursion. A limitation to this behavior is that, if a {@code MessageFormat}
> 
> @naotoj Please let me know if the added limitations wording reads clearly to you. I would rather not have a whole dedicated code example to explain a _limitation_, but if needed for better understanding, I can add one.

Do you mean `{@code MessageFormat}{@code FormatElement}`?
Also, I would rather remove "A limitation to this behavior is that," as readers would know the following explanation explains a limitation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16891#discussion_r1412620378

From iris at openjdk.org  Fri Dec  1 22:26:32 2023
From: iris at openjdk.org (Iris Clark)
Date: Fri, 1 Dec 2023 22:26:32 GMT
Subject: RFR: 8321131: Console read line with zero out should zero out
 underlying buffer in JLine [v2]
In-Reply-To: <JcV9pmabcFkPVlKlMgvzdhEvewSjQCiBPEhVpWTeM7w=.405a12bc-8f64-4210-94fd-4bd99c4f4fde@github.com>
References: <PzHZPvbxGMfURD7JoaIocGRD8gkyJFh-i0oPeMx9zdc=.df1f2a34-527d-4e4a-b468-ddb51ad2d330@github.com>
 <JcV9pmabcFkPVlKlMgvzdhEvewSjQCiBPEhVpWTeM7w=.405a12bc-8f64-4210-94fd-4bd99c4f4fde@github.com>
Message-ID: <-UikhDCfyv0652dFnbjEv0DMdhp83YYPgBMyeyoBMa0=.e801fbd8-e6d2-4261-952c-b1879f30a20f@github.com>

On Fri, 1 Dec 2023 21:24:47 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is the fix to JLine, which makes it on par with the built-in Console fix ([JDK-8320798](https://bugs.openjdk.org/browse/JDK-8320798)).
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moved instance fields at the top of the class

Marked as reviewed by iris (Reviewer).

src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 72:

> 70:         private final Terminal terminal;
> 71:         private volatile LineReader jline;
> 72: 

Relocation looks good.  Thanks!

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

PR Review: https://git.openjdk.org/jdk/pull/16930#pullrequestreview-1760648178
PR Review Comment: https://git.openjdk.org/jdk/pull/16930#discussion_r1412624704

From bpb at openjdk.org  Fri Dec  1 22:29:27 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 1 Dec 2023 22:29:27 GMT
Subject: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter
 of transferTo() is trusted [v2]
In-Reply-To: <r8PlLlJcB6KEF9fgGlrTYdRiUY6Ou5Q8klgZY2AQ49E=.7d4ee021-4138-4ca7-a116-db292a82934b@github.com>
References: <zRINQ_LiJh7Ifnt7UwL2Q0PcpestYwzx74fopLor_2w=.c93f3a3a-8172-40d2-9e5d-0530eb905f2a@github.com>
 <qvDeG-fdlsLWk-rEcZHRMA3Mv0hJag2hvJlHqu4Y-yo=.3b0e1f6f-b69d-4471-909a-9d4dd45618b1@github.com>
 <KbgvHJmxFxcJSCf2iOvYxblmTvg8RDV1QtqhylX-bHo=.fe8878ab-7b19-4e72-81f3-d6a65965fa1b@github.com>
 <qzx0Xi4T398BV7qeBj6bLS-R7LcLA8JE-gMwxuD3lcI=.5d447f3b-328e-40df-b823-4a74eec3f1a4@github.com>
 <eyFDDWXEomWObizhgeIormpHtFAXmTrXbWkMOxK2ML4=.a3d6ca9d-5b73-456c-b997-78bc5894c136@github.com>
 <EC7_LI524HAiIY3cDlcVmoqKY4H4eMy7shWEyDU-td8=.b2f87afe-9d6b-41ab-9145-858f4deded60@github.com>
 <jQBQyMguCr22Ihi66y1Ub4pbCBVgYzDMqaPkj_FvIFM=.4ad14e27-50ff-4621-91cf-bfbf9cf726b9@github.com>
 <r8PlLlJcB6KEF9fgGlrTYdRiUY6Ou5Q8klgZY2AQ49E=.7d4ee021-4138-4ca7-a116-db292a82934b@github.com>
Message-ID: <T_XBQt0hI4kkK17LyLZUqE_60xDv5p0z3XZLW9LlvX0=.bc93c90f-284c-426d-85f1-57387a4b0a71@github.com>

On Fri, 1 Dec 2023 13:46:59 GMT, Markus KARG <duke at openjdk.org> wrote:

>> @bplb You did it right.  The reason it works is because the ChannelOutputStream is in the "sun." package and not the "java." package.  That is not the case for Channels.newOutputStream(AsynchronousByteChannel ch) as that wrapper should be able to access the byte array.
>
> I see the problem that unless we have an explicit whitelist, we do open the risk of accidentially adding another wrapper stream in future to the JDK somewhere and forget to add it to the blacklist. So for safety, I would pleae for not using .startsWith() but explitly mention the actively proven-as-safe classes only. That way, the code might be slower (sad but true) but inherently future-proof.

The case of `Channels.newOutputStream(AsynchronousByteChannel)` could be handled by changing the return value of that method. For example, `sun.nio.ch.Streams` could have a method `OutputStream of(AsynchronousByteChannel)` added to it which returned something like an `AsynChannelOutputStream` and we could use that.

That said, it is true that a deny list is not inherently future-proof like an allow list, as stated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16893#discussion_r1412626371

From bpb at openjdk.org  Fri Dec  1 22:29:31 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 1 Dec 2023 22:29:31 GMT
Subject: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter
 of transferTo() is trusted [v2]
In-Reply-To: <oiyEy74LQkgMgI19Fw0elB3tsgLw-VbTJmgcScqvB74=.990cecc6-8d67-4002-b79c-95b6b8a7205e@github.com>
References: <zRINQ_LiJh7Ifnt7UwL2Q0PcpestYwzx74fopLor_2w=.c93f3a3a-8172-40d2-9e5d-0530eb905f2a@github.com>
 <fv6-nbKivaxr2QQ_2khG1ssAum3isxx0-RA5wvwcD3Q=.4127e93f-1734-4b99-9c82-d35dbcb8ceb1@github.com>
 <oiyEy74LQkgMgI19Fw0elB3tsgLw-VbTJmgcScqvB74=.990cecc6-8d67-4002-b79c-95b6b8a7205e@github.com>
Message-ID: <CLaxrCx_IEgYAAvD8o56RGyDYwlaQhwg8gIR_sAIuso=.2f7b76ec-139a-490b-b542-59158240f3a5@github.com>

On Fri, 1 Dec 2023 13:33:01 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8321053: Trust non-FilterOutputStreams in "java." packages
>
> src/java.base/share/classes/java/io/ByteArrayInputStream.java line 221:
> 
>> 219:                 int nbyte = Integer.min(len - nwritten, MAX_TRANSFER_SIZE);
>> 220:                 if (tmp != null) {
>> 221:                     System.arraycopy(buf, pos, tmp, 0, nbyte);
> 
> I assume the overall performance of transferTo will be faster if we use System.arraycopy *only once* in line 215 to create a safe copy of the *complete* buf instead of calling it multiple times in a loop to create copies *per slice*. In that case we can omit the tmp == null case but simply use tmp = buf, making the code in the loop if-free.

There is a tradeoff here between number of invocations of `arraycopy` and amount of memory allocated for `tmp`. (We have seen this before in #14981 which I have allowed to languish.) The allocation limit is `MAX_TRANSFER_SIZE` which is presently 128 kB, so any transfer of size less than this will invoke `arraycopy` only once already.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16893#discussion_r1412626433

From jlu at openjdk.org  Fri Dec  1 22:42:16 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 1 Dec 2023 22:42:16 GMT
Subject: RFR: 6230751: [Fmt-Ch] Recursive MessageFormats in ChoiceFormats
 ignore indicated subformats [v3]
In-Reply-To: <7wIjtUukVVmPac0CLynJTK8zIx7Difi9122zthoFj_w=.8e65ff5d-816b-4383-b833-0df272efaede@github.com>
References: <7wIjtUukVVmPac0CLynJTK8zIx7Difi9122zthoFj_w=.8e65ff5d-816b-4383-b833-0df272efaede@github.com>
Message-ID: <ea7qiSs2790FU7Lp0BS5XyoAVjXgnOxek-p8LfM_Yws=.984252f3-7cdf-445b-9448-4bacf06196d0@github.com>

> Please review this PR which updates an incorrect code example in _java/text/ChoiceFormat_.
> 
> ChoiceFormat (and MessageFormat) provide an example of how to produce a pattern that supports singular and plural forms. The ChoiceFormat example is incorrect, as recursive MessageFormats produced by a ChoiceFormat subformat only recognize subformats defined through the MessageFormat pattern syntax, not through the subformats contained within the top level MessageFormat. 
> 
> In the original example,
> `Format[] testFormats = {fileform, null, NumberFormat.getInstance()};` could have been replaced with 
> `Format[] testFormats = {fileform, null, new ChoiceFormat("0#BROKEN")};` and the original output would have been the same.
> 
> This PR replaces the example with the one used in MessageFormat, which is correct. 
> 
> This PR also includes a drive-by fix to remove leftover `<blockquote>`s from a previous `@snippet` conversion.

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

  reflect review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16891/files
  - new: https://git.openjdk.org/jdk/pull/16891/files/f6722242..47e91b3d

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

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

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

From jlu at openjdk.org  Fri Dec  1 22:42:18 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 1 Dec 2023 22:42:18 GMT
Subject: RFR: 6230751: [Fmt-Ch] Recursive MessageFormats in ChoiceFormats
 ignore indicated subformats [v2]
In-Reply-To: <l7S91AjFMhwZYG0LI2rwpOwpASu-7-A7xdbP35npBrU=.46dd7350-f626-49de-bfa8-ce338c79801f@github.com>
References: <7wIjtUukVVmPac0CLynJTK8zIx7Difi9122zthoFj_w=.8e65ff5d-816b-4383-b833-0df272efaede@github.com>
 <-Lejnw3KKbWnlUfNidurDt-ZeLcUzqZRoLZh9gl3_j0=.0de62ad0-89eb-434c-8780-5fe45cb86997@github.com>
 <DJPopQSeW_NfJ640p5yz0Vf_3Lh6ZKz31pojaxzbUxE=.78445b45-6b39-49c9-b775-96afa5605ed5@github.com>
 <l7S91AjFMhwZYG0LI2rwpOwpASu-7-A7xdbP35npBrU=.46dd7350-f626-49de-bfa8-ce338c79801f@github.com>
Message-ID: <wu_NZQVRIFFv5d-ADMzimf373fsxGsoRsDXq4lzksbY=.76f129e0-29c0-48c1-b3cd-eb2268ae9a6e@github.com>

On Fri, 1 Dec 2023 22:16:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/MessageFormat.java line 299:
>> 
>>> 297:  * the string produced by a {@code ChoiceFormat} in {@code MessageFormat} is
>>> 298:  * treated as special; occurrences of '{' are used to indicate subformats, and
>>> 299:  * cause recursion. A limitation to this behavior is that, if a {@code MessageFormat}
>> 
>> @naotoj Please let me know if the added limitations wording reads clearly to you. I would rather not have a whole dedicated code example to explain a _limitation_, but if needed for better understanding, I can add one.
>
> Do you mean `{@code MessageFormat}{@code FormatElement}`?
> Also, I would rather remove "A limitation to this behavior is that," as readers would know the following explanation explains a limitation.

Right, no need for `{@code MessageFormat}` as it's already implied. Also removed "_A limitation to this behavior is that_" as suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16891#discussion_r1412631550

From bpb at openjdk.org  Fri Dec  1 23:24:35 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 1 Dec 2023 23:24:35 GMT
Subject: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter
 of transferTo() is trusted [v2]
In-Reply-To: <T_XBQt0hI4kkK17LyLZUqE_60xDv5p0z3XZLW9LlvX0=.bc93c90f-284c-426d-85f1-57387a4b0a71@github.com>
References: <zRINQ_LiJh7Ifnt7UwL2Q0PcpestYwzx74fopLor_2w=.c93f3a3a-8172-40d2-9e5d-0530eb905f2a@github.com>
 <qvDeG-fdlsLWk-rEcZHRMA3Mv0hJag2hvJlHqu4Y-yo=.3b0e1f6f-b69d-4471-909a-9d4dd45618b1@github.com>
 <KbgvHJmxFxcJSCf2iOvYxblmTvg8RDV1QtqhylX-bHo=.fe8878ab-7b19-4e72-81f3-d6a65965fa1b@github.com>
 <qzx0Xi4T398BV7qeBj6bLS-R7LcLA8JE-gMwxuD3lcI=.5d447f3b-328e-40df-b823-4a74eec3f1a4@github.com>
 <eyFDDWXEomWObizhgeIormpHtFAXmTrXbWkMOxK2ML4=.a3d6ca9d-5b73-456c-b997-78bc5894c136@github.com>
 <EC7_LI524HAiIY3cDlcVmoqKY4H4eMy7shWEyDU-td8=.b2f87afe-9d6b-41ab-9145-858f4deded60@github.com>
 <jQBQyMguCr22Ihi66y1Ub4pbCBVgYzDMqaPkj_FvIFM=.4ad14e27-50ff-4621-91cf-bfbf9cf726b9@github.com>
 <r8PlLlJcB6KEF9fgGlrTYdRiUY6Ou5Q8klgZY2AQ49E=.7d4ee021-4138-4ca7-a116-db292a82934b@github.com>
 <T_XBQt0hI4kkK17LyLZUqE_60xDv5p0z3XZLW9LlvX0=.bc93c90f-284c-426d-85f1-57387a4b0a71@github.com>
Message-ID: <13QWO-amjHOw9pd7mM_jU0iRS4QR5_KFo-BFNuv-l-U=.226d2e4c-1757-44e5-824d-2d120fc26937@github.com>

On Fri, 1 Dec 2023 22:26:51 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I see the problem that unless we have an explicit whitelist, we do open the risk of accidentially adding another wrapper stream in future to the JDK somewhere and forget to add it to the blacklist. So for safety, I would pleae for not using .startsWith() but explitly mention the actively proven-as-safe classes only. That way, the code might be slower (sad but true) but inherently future-proof.
>
> The case of `Channels.newOutputStream(AsynchronousByteChannel)` could be handled by changing the return value of that method. For example, `sun.nio.ch.Streams` could have a method `OutputStream of(AsynchronousByteChannel)` added to it which returned something like an `AsynChannelOutputStream` and we could use that.
> 
> That said, it is true that a deny list is not inherently future-proof like an allow list, as stated.

I think that a sufficiently future-proof deny list could be had by changing

211             if (out.getClass().getPackageName().startsWith("java.") &&

back to

211             if ("java.io".equals(out.getClass().getPackageName()) &&

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16893#discussion_r1412658236

From jpai at openjdk.org  Sat Dec  2 01:31:40 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 2 Dec 2023 01:31:40 GMT
Subject: RFR: 8321163: [test] OutputAnalyzer.getExitValue() unnecessarily
 logs even when process has already completed [v3]
In-Reply-To: <WQTg0UCZOliuCoDkAlHUsav80kxcpqL9Gj_zDiJGDis=.feed38ca-424c-443d-975a-72f96e3db711@github.com>
References: <uZ77Eagw9Lxz1BKJ8fMnCzvp8Z5VVqsGnsLZtqKZDIo=.0fb8e6cf-7d79-4d4e-b99d-171e008210e9@github.com>
 <0GAdkVhk4e3WJp5bQuLdvtxHk5BtRguNmQ7PoQ5dH50=.4f01dd8f-e2f5-47f8-b66a-2801156d56f5@github.com>
 <WQTg0UCZOliuCoDkAlHUsav80kxcpqL9Gj_zDiJGDis=.feed38ca-424c-443d-975a-72f96e3db711@github.com>
Message-ID: <-D6YIMqmjvidYjy63o4y3bF2Sq9Mm1w4FUSn27m6ZYA=.537ef1bd-6fb3-42df-99ad-7ad0d8a72d4a@github.com>

On Fri, 1 Dec 2023 20:01:42 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Technically, the volatile is not enough to avoid racy writing into exitValue. However, it doesn't affect logic.

Agreed.

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

PR Comment: https://git.openjdk.org/jdk/pull/16919#issuecomment-1836981670

From jpai at openjdk.org  Sat Dec  2 01:44:36 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 2 Dec 2023 01:44:36 GMT
Subject: RFR: 8320129: "top" command during jtreg failure handler does not
 display CPU usage on OSX
In-Reply-To: <cylR98W-HGZUXrw7n5BMFLq-efMWfdg7ZcaW6OQaIa0=.edaa4e47-a216-4dde-be51-b5b47fd978e6@github.com>
References: <cylR98W-HGZUXrw7n5BMFLq-efMWfdg7ZcaW6OQaIa0=.edaa4e47-a216-4dde-be51-b5b47fd978e6@github.com>
Message-ID: <Iy7q0bqxNX9D1DUcNn7JkptHC88W-lI910H_wBfsulg=.1e736b8c-432f-466a-bc4f-7ec83c6bae8d@github.com>

On Fri, 1 Dec 2023 00:58:57 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Description of problem and propsed fix from @plummercj 
> '
> In test/failure_handler/src/share/conf/mac.properties we have:
> 
> process.top.app=top
> process.top.args=-l 1
> 
> So top is run with the "-l 1" args, causing it to do one iteration and then exit. Unfortunately the first iteration always shows all 0's for CPU usage. If you do at least 2 iterations, you do see the proper CPU usage on the 2nd iteration. The user just needs to know to scroll down to see it. I suggest we start using "-l 2" unless someone has a better idea.
> 
> BTW, for proper CPU usage you can instead look at the failure handler "ps" output, which seems to be correct. But it is nice to have "top" produce the correct output so all the CPU hogs are at the top of the list.
> '
> 
> I verified that top report contains now 2 samples.

Looks OK to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16915#pullrequestreview-1760750921

From lmesnik at openjdk.org  Sat Dec  2 03:00:46 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 2 Dec 2023 03:00:46 GMT
Subject: Integrated: 8320129: "top" command during jtreg failure handler does
 not display CPU usage on OSX
In-Reply-To: <cylR98W-HGZUXrw7n5BMFLq-efMWfdg7ZcaW6OQaIa0=.edaa4e47-a216-4dde-be51-b5b47fd978e6@github.com>
References: <cylR98W-HGZUXrw7n5BMFLq-efMWfdg7ZcaW6OQaIa0=.edaa4e47-a216-4dde-be51-b5b47fd978e6@github.com>
Message-ID: <jFUWk35hB6PlogpYN2M3zu1hFO16NYcGszTDfvQAYMQ=.9370afed-61c3-4a30-9594-9bbf0cfe4fc3@github.com>

On Fri, 1 Dec 2023 00:58:57 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Description of problem and propsed fix from @plummercj 
> '
> In test/failure_handler/src/share/conf/mac.properties we have:
> 
> process.top.app=top
> process.top.args=-l 1
> 
> So top is run with the "-l 1" args, causing it to do one iteration and then exit. Unfortunately the first iteration always shows all 0's for CPU usage. If you do at least 2 iterations, you do see the proper CPU usage on the 2nd iteration. The user just needs to know to scroll down to see it. I suggest we start using "-l 2" unless someone has a better idea.
> 
> BTW, for proper CPU usage you can instead look at the failure handler "ps" output, which seems to be correct. But it is nice to have "top" produce the correct output so all the CPU hogs are at the top of the list.
> '
> 
> I verified that top report contains now 2 samples.

This pull request has now been integrated.

Changeset: 8be3e392
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8be3e39220cd64521f4e370011958e17e5fdeaf3
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8320129: "top" command during jtreg failure handler does not display CPU usage on OSX

Reviewed-by: cjplummer, jpai

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

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

From duke at openjdk.org  Sat Dec  2 03:57:34 2023
From: duke at openjdk.org (jmehrens)
Date: Sat, 2 Dec 2023 03:57:34 GMT
Subject: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter
 of transferTo() is trusted [v2]
In-Reply-To: <13QWO-amjHOw9pd7mM_jU0iRS4QR5_KFo-BFNuv-l-U=.226d2e4c-1757-44e5-824d-2d120fc26937@github.com>
References: <zRINQ_LiJh7Ifnt7UwL2Q0PcpestYwzx74fopLor_2w=.c93f3a3a-8172-40d2-9e5d-0530eb905f2a@github.com>
 <qvDeG-fdlsLWk-rEcZHRMA3Mv0hJag2hvJlHqu4Y-yo=.3b0e1f6f-b69d-4471-909a-9d4dd45618b1@github.com>
 <KbgvHJmxFxcJSCf2iOvYxblmTvg8RDV1QtqhylX-bHo=.fe8878ab-7b19-4e72-81f3-d6a65965fa1b@github.com>
 <qzx0Xi4T398BV7qeBj6bLS-R7LcLA8JE-gMwxuD3lcI=.5d447f3b-328e-40df-b823-4a74eec3f1a4@github.com>
 <eyFDDWXEomWObizhgeIormpHtFAXmTrXbWkMOxK2ML4=.a3d6ca9d-5b73-456c-b997-78bc5894c136@github.com>
 <EC7_LI524HAiIY3cDlcVmoqKY4H4eMy7shWEyDU-td8=.b2f87afe-9d6b-41ab-9145-858f4deded60@github.com>
 <jQBQyMguCr22Ihi66y1Ub4pbCBVgYzDMqaPkj_FvIFM=.4ad14e27-50ff-4621-91cf-bfbf9cf726b9@github.com>
 <r8PlLlJcB6KEF9fgGlrTYdRiUY6Ou5Q8klgZY2AQ49E=.7d4ee021-4138-4ca7-a116-db292a82934b@github.com>
 <T_XBQt0hI4kkK17LyLZUqE_60xDv5p0z3XZLW9LlvX0=.bc93c90f-284c-426d-85f1-57387a4b0a71@github.com>
 <13QWO-amjHOw9pd7mM_jU0iRS4QR5_KFo-BFNuv-l-U=.226d2e4c-1757-44e5-824d-2d120fc26937@github.com>
Message-ID: <13AK-_SxIYyOMx7xYHHU4p21Mg-aXN0p7aTMrIgeRZY=.e5956bf4-4c84-4476-8d40-66753d80b6c0@github.com>

On Fri, 1 Dec 2023 23:21:35 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> The case of `Channels.newOutputStream(AsynchronousByteChannel)` could be handled by changing the return value of that method. For example, `sun.nio.ch.Streams` could have a method `OutputStream of(AsynchronousByteChannel)` added to it which returned something like an `AsynChannelOutputStream` and we could use that.
>> 
>> That said, it is true that a deny list is not inherently future-proof like an allow list, as stated.
>
> I think that a sufficiently future-proof deny list could be had by changing
> 
> 211             if (out.getClass().getPackageName().startsWith("java.") &&
> 
> back to
> 
> 211             if ("java.io".equals(out.getClass().getPackageName()) &&
> 
> That would for example dispense with the problematic `Channels.newOutputStream(AynsynchronousByteChannel)` case:
> 
> jshell> AsynchronousSocketChannel asc = AsynchronousSocketChannel.open()
> asc ==> sun.nio.ch.UnixAsynchronousSocketChannelImpl[unconnected]
> 
> jshell> OutputStream out = Channels.newOutputStream(asc)
> out ==> java.nio.channels.Channels$2 at 58c1670b
> 
> jshell> Class outClass = out.getClass()
> outClass ==> class java.nio.channels.Channels$2
> 
> jshell> outClass.getPackageName()
> $5 ==> "java.nio.channels"

Even if scope is limited to `java.io` you have deal with FilterOutputStream and ObjectOutputStream.  I still haven't done a complete search so there could be other adapters I've yet to review.

Thinking of a different approach, what if ByteArrayInputStream actually recorded and used `readlimit` of the `mark` method?  This allows us to safely leak or poison 'this.data' because once transferTo is called we safely change owner of the byte array if we know this stream is allowed to forget it existed.  Effectively you could do optimizations like this (didn't test or compile this):


public synchronized long transferTo(OutputStream out) throws IOException {
     int len = count - pos;
     if (len > 0) {
         byte[] data = this.data;
         byte[] tmp = null;
         if (this.readLimit == 0) { //<- recorded by mark method, initial value on construction of this would be zero.
            data = this.data; //swap owner of bytes
            this.data = new byte[0];
            Arrays.fill(data, 0, mark, (byte) 0); // hide out of bounds data.
            Arrays.fill(data, count, data.length, (byte) 0); 
         } else {
            tmp = new byte[Integer.min(len, MAX_TRANSFER_SIZE)];
         }

             //original code could be optimized more given above.
            while (nwritten < len) {
                int nbyte = Integer.min(len - nwritten, MAX_TRANSFER_SIZE);
                out.write(buf, pos, nbyte);
                if (tmp != null) {
                    System.arraycopy(buf, pos, tmp, 0, nbyte);
               out.write(tmp, 0, nbyte);
                } else
                    out.write(buf, pos, nbyte);
                pos += nbyte;
                nwritten += nbyte; 
            }
            assert pos == count;
            if (data.length ==0) { //uphold rules of class.
                pos = count = mark = 0;
            }
        }
        return len;
}


This would approach avoids having to maintain an allow or deny list.  The downside of this approach and that is the constructor of ByteInputStream doesn't copy the byte[] parameter.  The caller is warned about this in the JavaDocs but it might be shocking to have data escape ByteArrayInputStream.  Maybe that is deal breaker?  Obviously there a compatibility issue with recording readLimit in the mark method as it states it does nothing.

Thoughts?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16893#discussion_r1412715845

From duke at openjdk.org  Sat Dec  2 05:39:39 2023
From: duke at openjdk.org (jmehrens)
Date: Sat, 2 Dec 2023 05:39:39 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v3]
In-Reply-To: <Gq71g3kwwNNp7onrE98XHdSjBHgJB7yytDfcKRsrbJY=.5c6c6448-8d9d-4370-84f9-4f39b6b3999e@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <Gq71g3kwwNNp7onrE98XHdSjBHgJB7yytDfcKRsrbJY=.5c6c6448-8d9d-4370-84f9-4f39b6b3999e@github.com>
Message-ID: <zE4zbKeED2RblCok7rE8AJRmufbrREh89XvkSNUEskE=.0bb74bdf-409c-4d99-b062-91228836891d@github.com>

On Thu, 30 Nov 2023 11:12:36 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`.
>> 
>> See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8320971: Add test

I think it is safe to poison and leak `this.buf` only while we are holding the lock on the BufferedInputStream and while the stream is not required to remember any bytes. However, the current `this.buf` must clear out of bounds data to avoid sharing old data and must be freed from this stream before the lock is released to prevent tampering with the next locking call to BufferedInputStream.


private long implTransferTo(OutputStream out) throws IOException {
    byte[] buffer;
    if (getClass() == BufferedInputStream.class && markpos == -1) {
        int avail = count - pos;
        if (avail > 0) {
            byte[] buffer = getBufIfOpen(false);
            try {
                Arrays.fill(buffer, 0, pos, (byte) 0);
                Arrays.fill(buffer, count, buffer.length, (byte) 0);
                out.write(buffer, pos, count);
                return Math.addExact(avail, getInIfOpen().transferTo(out));
            } catch (ArithmeticException ignore) {
                return Long.MAX_VALUE;
            } finally { //forget current buffer as it was leaked and poisoned
                if (U.compareAndSetReference(this, BUF_OFFSET, buffer, EMPTY)) {
                    pos = count = 0;
                }
            }
        } else {
            return super.transferTo(out);
        }
    }


Thoughts?

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

PR Comment: https://git.openjdk.org/jdk/pull/16879#issuecomment-1837049677

From duke at openjdk.org  Sat Dec  2 06:15:40 2023
From: duke at openjdk.org (jmehrens)
Date: Sat, 2 Dec 2023 06:15:40 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v3]
In-Reply-To: <Gq71g3kwwNNp7onrE98XHdSjBHgJB7yytDfcKRsrbJY=.5c6c6448-8d9d-4370-84f9-4f39b6b3999e@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <Gq71g3kwwNNp7onrE98XHdSjBHgJB7yytDfcKRsrbJY=.5c6c6448-8d9d-4370-84f9-4f39b6b3999e@github.com>
Message-ID: <D0peOQiKn_m3rPEWBim7yHjIG0r4E_Onr0A19iCYGwg=.db7e537c-2f25-4ce9-b88a-6e05d51bf385@github.com>

On Thu, 30 Nov 2023 11:12:36 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`.
>> 
>> See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8320971: Add test

I think I'm just reliving https://github.com/openjdk/jdk/pull/10525#issuecomment-1296756625

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

PR Comment: https://git.openjdk.org/jdk/pull/16879#issuecomment-1837056502

From svein.otto.solem at gmail.com  Sat Dec  2 07:52:15 2023
From: svein.otto.solem at gmail.com (Svein Otto Solem)
Date: Sat, 2 Dec 2023 08:52:15 +0100
Subject: Integrated: 8319123: Implement JEP 461: Stream Gatherers (Preview)
Message-ID: <3BD37C29-FDAC-4F0F-985B-8C5444D29D73@hxcore.ol>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20231202/fe0f2791/attachment.htm>

From alanb at openjdk.org  Sat Dec  2 09:07:45 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 2 Dec 2023 09:07:45 GMT
Subject: Integrated: 8320440: Implementation of Structured Concurrency (Second
 Preview)
In-Reply-To: <4t6NzmCd-0w-y7iT51fEttO7gEArgRuCeEl4yeNIzd0=.cd7bbed3-1117-4fc1-9241-255e6e10e2f1@github.com>
References: <4t6NzmCd-0w-y7iT51fEttO7gEArgRuCeEl4yeNIzd0=.cd7bbed3-1117-4fc1-9241-255e6e10e2f1@github.com>
Message-ID: <1pTku9Rd9DjfKvXre3uZZ5eXzTR14uN8UwZgcyOZcsQ=.ee6fbeb5-231f-4aa2-aab8-164b4480b3f2@github.com>

On Mon, 20 Nov 2023 19:48:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This API is sitting out JDK 22, meaning no API/implementation changes in this PR. We expect this API to do a third preview in JDK 23 with some API changes. 
> 
> So for now, we just need to bump JEP number/title that shows up in the preview section of the javadoc.

This pull request has now been integrated.

Changeset: 5dee2a36
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5dee2a36756caba28cf12920dc562278576f6de0
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8320440: Implementation of Structured Concurrency (Second Preview)

Reviewed-by: iris, jpai, mchung, mcimadamore

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

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

From alanb at openjdk.org  Sat Dec  2 09:56:36 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 2 Dec 2023 09:56:36 GMT
Subject: RFR: 8321131: Console read line with zero out should zero out
 underlying buffer in JLine [v2]
In-Reply-To: <JcV9pmabcFkPVlKlMgvzdhEvewSjQCiBPEhVpWTeM7w=.405a12bc-8f64-4210-94fd-4bd99c4f4fde@github.com>
References: <PzHZPvbxGMfURD7JoaIocGRD8gkyJFh-i0oPeMx9zdc=.df1f2a34-527d-4e4a-b468-ddb51ad2d330@github.com>
 <JcV9pmabcFkPVlKlMgvzdhEvewSjQCiBPEhVpWTeM7w=.405a12bc-8f64-4210-94fd-4bd99c4f4fde@github.com>
Message-ID: <-F76IvTWA1BO03poBAk3kWKy-vRCYR6TyKJ5ErVqhV0=.197369ea-6593-4398-9382-a3b097150368@github.com>

On Fri, 1 Dec 2023 21:24:47 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is the fix to JLine, which makes it on par with the built-in Console fix ([JDK-8320798](https://bugs.openjdk.org/browse/JDK-8320798)).
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moved instance fields at the top of the class

This looks okay. I think @MBaesken plan to try to some automated tests for this.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16930#pullrequestreview-1760848832

From duke at openjdk.org  Sat Dec  2 15:42:18 2023
From: duke at openjdk.org (fabioromano1)
Date: Sat, 2 Dec 2023 15:42:18 GMT
Subject: RFR: 8320759: Creation of random BigIntegers can be made faster
 [v3]
In-Reply-To: <wIuR7gaQWIRdb8DtEN1VXi9dNkUMuKn8zv3Myc4V2gc=.3356e893-5322-4bb4-aa37-731fb6e9a4b0@github.com>
References: <wIuR7gaQWIRdb8DtEN1VXi9dNkUMuKn8zv3Myc4V2gc=.3356e893-5322-4bb4-aa37-731fb6e9a4b0@github.com>
Message-ID: <KAD32In5r6VDU4e0LePqKTHv8bn7fc9xb9zAI1UBkHY=.acba81de-6332-4cf9-9a66-d6e0f488b61b@github.com>

> A faster and simpler way to generate random BigIntegers, avoiding eventually trimming of leading zeros in magnitude array.

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

  Create RandomBigIntegers.java
  
  Create a benchmark to measure the performance of BigInteger(int, Random) constructor implementation.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16817/files
  - new: https://git.openjdk.org/jdk/pull/16817/files/928a13a1..699b51b0

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

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

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

From duke at openjdk.org  Sat Dec  2 15:44:39 2023
From: duke at openjdk.org (fabioromano1)
Date: Sat, 2 Dec 2023 15:44:39 GMT
Subject: RFR: 8320759: Creation of random BigIntegers can be made faster
 [v2]
In-Reply-To: <t1UQkAWWD0O9aI_Fjt9wW-DRKLMmB09Bmp8PDWG_1FM=.c9e6b323-2807-44b7-bc7a-510cb6b159cd@github.com>
References: <wIuR7gaQWIRdb8DtEN1VXi9dNkUMuKn8zv3Myc4V2gc=.3356e893-5322-4bb4-aa37-731fb6e9a4b0@github.com>
 <kg6i9jq0_x3uqaduf9l0BdrGXPQ7N2ac2BW3Gy0hN_U=.95818b8c-6d01-4f84-9f92-996489451cb4@github.com>
 <t1UQkAWWD0O9aI_Fjt9wW-DRKLMmB09Bmp8PDWG_1FM=.c9e6b323-2807-44b7-bc7a-510cb6b159cd@github.com>
Message-ID: <G9rei0E8R9z6wiQJ5-DqmsFMIufs18pQtXgCLx-KluI=.429e32a6-b1b8-4e99-9025-f8755cd4af83@github.com>

On Thu, 30 Nov 2023 20:37:37 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update BigInteger(int, Random)
>>   
>>   Update a comment
>
> There are some JMH tests for BigInteger in test/micro/org/openjdk/bench/java/math/Big*.
> 
> Can you create a new benchmark for the computations above and include it in the PR.
> That will make it easier to keep track of the performance over time.
> Thanks

@RogerRiggs I added my benchmark class for BigInteger(int, Random) constructor to the package.

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

PR Comment: https://git.openjdk.org/jdk/pull/16817#issuecomment-1837185526

From darcy at openjdk.org  Sat Dec  2 20:34:36 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 2 Dec 2023 20:34:36 GMT
Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v4]
In-Reply-To: <Lx5ZzbGIV584QK73SK4GaA8OF-41M-BECYxzWGmh8Fk=.37a42cf6-50e9-48f4-9d76-b071c2ead567@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
 <P9uONCgJlH6ON2nqV1TxpJ5tn_XrGmBuFWKrU45JrKs=.4f773cc2-b13c-42c8-a7f4-2591af065743@github.com>
 <Lx5ZzbGIV584QK73SK4GaA8OF-41M-BECYxzWGmh8Fk=.37a42cf6-50e9-48f4-9d76-b071c2ead567@github.com>
Message-ID: <MvHasng-zgZGKUbkeFYM30zb2yO7day8Z3S0JOWSUEU=.a10c86e6-ce86-40a6-af22-b24e784aa243@github.com>

On Fri, 1 Dec 2023 08:54:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Looks good. I assume you'll bump the copyright header on the files that need it before integration, e.g. JavacTestingAbstractProcessor.

Right; I run a script to update the years of modified files.

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

PR Comment: https://git.openjdk.org/jdk/pull/16505#issuecomment-1837247101

From aturbanov at openjdk.org  Sat Dec  2 20:43:39 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 2 Dec 2023 20:43:39 GMT
Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v4]
In-Reply-To: <P9uONCgJlH6ON2nqV1TxpJ5tn_XrGmBuFWKrU45JrKs=.4f773cc2-b13c-42c8-a7f4-2591af065743@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
 <P9uONCgJlH6ON2nqV1TxpJ5tn_XrGmBuFWKrU45JrKs=.4f773cc2-b13c-42c8-a7f4-2591af065743@github.com>
Message-ID: <8B_EG0mwCKb3mRlrAoyz7vkzZhNPpZUAfY-EOQ1FlEo=.efbc5ce9-1a75-4aa2-8dfc-96a9c9fd03b7@github.com>

On Thu, 30 Nov 2023 23:49:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start making preparations for JDK 23.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update symbol files to JDK 22 b26.

test/langtools/tools/javac/versions/Versions.java line 97:

> 95:         TWENTY_ONE(false,"65.0", "21"),
> 96:         TWENTY_TWO(false,"66.0", "22"),
> 97:         TWENTY_THREE(false,"67.0", "23"),

As alignment is broken anyway, let's add space
Suggestion:

        TWENTY_THREE(false, "67.0", "23"),

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16505#discussion_r1412868557

From naoto at openjdk.org  Sat Dec  2 21:57:01 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Sat, 2 Dec 2023 21:57:01 GMT
Subject: RFR: 8321131: Console read line with zero out should zero out
 underlying buffer in JLine [v3]
In-Reply-To: <PzHZPvbxGMfURD7JoaIocGRD8gkyJFh-i0oPeMx9zdc=.df1f2a34-527d-4e4a-b468-ddb51ad2d330@github.com>
References: <PzHZPvbxGMfURD7JoaIocGRD8gkyJFh-i0oPeMx9zdc=.df1f2a34-527d-4e4a-b468-ddb51ad2d330@github.com>
Message-ID: <Bo0RreJ7-KY0CGwLMwNhl1bpwO78k91eziGVWS4hvRc=.d64cf82e-9546-40a8-8267-c0320f8afabc@github.com>

> This is the fix to JLine, which makes it on par with the built-in Console fix ([JDK-8320798](https://bugs.openjdk.org/browse/JDK-8320798)).

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

  Removed unnecessary modification in LineReader

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16930/files
  - new: https://git.openjdk.org/jdk/pull/16930/files/a3773d44..36ee3c84

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

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

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

From duke at openjdk.org  Sat Dec  2 22:10:37 2023
From: duke at openjdk.org (serge-sans-paille)
Date: Sat, 2 Dec 2023 22:10:37 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v6]
In-Reply-To: <-lVL7hp68aKNlBWHCxdKdPrPDe6NOAKD3zoX-u5ZMEM=.6164666f-7312-4f0c-b15b-2e01a331e820@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <SHBw8bY7vJuMY8yynW8EMqybSIuhhP5Up_EzESHzv2Y=.e9e34b30-77c6-4f04-a590-8363bfa834d5@github.com>
 <sFgQe4eGlWzzK-fU0r5d6ryaNRn4bg8TuyRIZpNRyDo=.16d81e31-4a20-4124-8a77-2cc1515f658d@github.com>
 <-lVL7hp68aKNlBWHCxdKdPrPDe6NOAKD3zoX-u5ZMEM=.6164666f-7312-4f0c-b15b-2e01a331e820@github.com>
Message-ID: <WsReFosxqMxV70m-OJLgiE7maABxc-LnxqJ1LlMZ5tY=.a864cbce-6c35-46fe-ba58-d09e53076dec@github.com>

On Wed, 29 Nov 2023 06:12:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Not listed here: https://oca.opensource.oracle.com/?ojr=contributors
>
> I take it he is not an Intel employee, in which case he has to be an OpenJDK contributor himself for code for which he holds a copyright to be contributed to OpenJDK. @robilad please correct me if I am wrong here.

hey o/ No problem on my side to either let go my copyright or fill the contributor agreement (where is it?)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1409280698

From robilad at openjdk.org  Sat Dec  2 22:10:38 2023
From: robilad at openjdk.org (Dalibor Topic)
Date: Sat, 2 Dec 2023 22:10:38 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v6]
In-Reply-To: <WsReFosxqMxV70m-OJLgiE7maABxc-LnxqJ1LlMZ5tY=.a864cbce-6c35-46fe-ba58-d09e53076dec@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <SHBw8bY7vJuMY8yynW8EMqybSIuhhP5Up_EzESHzv2Y=.e9e34b30-77c6-4f04-a590-8363bfa834d5@github.com>
 <sFgQe4eGlWzzK-fU0r5d6ryaNRn4bg8TuyRIZpNRyDo=.16d81e31-4a20-4124-8a77-2cc1515f658d@github.com>
 <-lVL7hp68aKNlBWHCxdKdPrPDe6NOAKD3zoX-u5ZMEM=.6164666f-7312-4f0c-b15b-2e01a331e820@github.com>
 <WsReFosxqMxV70m-OJLgiE7maABxc-LnxqJ1LlMZ5tY=.a864cbce-6c35-46fe-ba58-d09e53076dec@github.com>
Message-ID: <6gIzR7OWDjVSklcQD-PM7ng_maqv6IbhAjHfgm-hWEs=.45910411-ab20-4ef0-99fa-88a13f722b7b@github.com>

On Wed, 29 Nov 2023 13:26:58 GMT, serge-sans-paille <duke at openjdk.org> wrote:

>> I take it he is not an Intel employee, in which case he has to be an OpenJDK contributor himself for code for which he holds a copyright to be contributed to OpenJDK. @robilad please correct me if I am wrong here.
>
> hey o/ No problem on my side to either let go my copyright or fill the contributor agreement (where is it?)

Thanks Serge! And thank you for sending in an OCA for processing, which has now been done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1412885472

From alanb at openjdk.org  Sun Dec  3 09:53:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 3 Dec 2023 09:53:41 GMT
Subject: RFR: 8321124: java/util/stream/GatherersTest.java times out [v2]
In-Reply-To: <eRHU-J1zkepYoEtzJ9XyoFjibSEIBTdzk6LaAoT-d4w=.0af11429-436a-4dfd-b5f0-806f41ab8107@github.com>
References: <NcgSgagzqKytU8dGSMKHUF_9ylICS5s6If5CoFRjPhw=.abef3a79-b429-47c5-b0b7-aa7b9f71ef31@github.com>
 <eRHU-J1zkepYoEtzJ9XyoFjibSEIBTdzk6LaAoT-d4w=.0af11429-436a-4dfd-b5f0-806f41ab8107@github.com>
Message-ID: <wZJ9V1dN05SSh9iqC6mifk-n3_0VvZWvf1ZBZPZRF9U=.24b8dabb-cb60-4d49-a3b1-2c5efd5e91b1@github.com>

On Fri, 1 Dec 2023 22:16:45 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Renames GatherersTest to BuiltInGatherersTest for easier deduplication of GathererTest.
>> 
>> Fixes a test ordering issue in testMapConcurrentAPIandContract().
>> 
>> Adding increased maxOutputSize for Gatherer-related tests to improve debuggability.
>> 
>> Lowering the composition threshold of GathererTest.testMassivelyComposedGatherers to 256 to avoid SOE on low-specc:ed machines.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Only run the cancellation tests for mapConcurrent for the shorter streams to conserve resources

test/jdk/java/util/stream/BuiltInGatherersTest.java line 253:

> 251:                         throw new RuntimeException();
> 252:                     })).toList());
> 253:         }

mapConcurrent is specified throw RuntimeException if the mapper throws. I read this to mean an Error is wrapped, and ambiguous on whether a runtime exception thrown by the mapper is wrapped or not. So I think this is actually tests, Error, RuntimeException and another runtime exception. This would help with the "Test cancellation after exception during processing" test too as it's not clear if TestException or a wrapping RuntimeException is correct.

Not important for now but testMapConcurrentAPIandContract could benefit from being split into a number of `@Test` methods. These tests aren't parameterized.

test/jdk/java/util/stream/BuiltInGatherersTest.java line 272:

> 270:                                     case 1 -> {
> 271:                                         throwerReady.countDown();
> 272:                                         awaitSensibly(initiateThrow);

20s might not be enough to wait for the count down when running with a debug build, -Xcomp, ...  I would be tempted to just have it wait indefinitely. If there is an issue then jtreg will timeout the test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16928#discussion_r1413031877
PR Review Comment: https://git.openjdk.org/jdk/pull/16928#discussion_r1413033710

From alanb at openjdk.org  Sun Dec  3 09:53:44 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 3 Dec 2023 09:53:44 GMT
Subject: RFR: 8321124: java/util/stream/GatherersTest.java times out [v2]
In-Reply-To: <DRKkxA6msb2IlV_JXkjMqvk8esYW1WchBjhz3tjkjQY=.0152f520-87b3-414b-8aec-3c6710ec84a8@github.com>
References: <NcgSgagzqKytU8dGSMKHUF_9ylICS5s6If5CoFRjPhw=.abef3a79-b429-47c5-b0b7-aa7b9f71ef31@github.com>
 <eRHU-J1zkepYoEtzJ9XyoFjibSEIBTdzk6LaAoT-d4w=.0af11429-436a-4dfd-b5f0-806f41ab8107@github.com>
 <DRKkxA6msb2IlV_JXkjMqvk8esYW1WchBjhz3tjkjQY=.0152f520-87b3-414b-8aec-3c6710ec84a8@github.com>
Message-ID: <ZVtY1n8bmuPMNvSTWNBB5lDkWXovIo5TPn4uK0pK2ac=.c0128720-7840-4c50-843f-d9b17057b191@github.com>

On Fri, 1 Dec 2023 22:11:05 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Only run the cancellation tests for mapConcurrent for the shorter streams to conserve resources
>
> test/jdk/java/util/stream/BuiltInGatherersTest.java line 257:
> 
>> 255:         // Test cancellation after exception during processing
>> 256:         // Only use reasonably sized streams to avoid excessive thread creation
>> 257:         if (config.streamSize > 2 && config.streamSize < 100) {
> 
> @AlanBateman Decided to not run the cancellation tests for the larger streams as it creates a bunch of extra resource usage which makes GHA really unhappy.

Okay but it makes me wonder if this test should have its use method source with the stream sizes that are sensible to test.

> @AlanBateman This is the only part of this I really don't like. Any better suggestion as to "wait for N things waiting" in a test? ?

Semaphore::getQueueLength is more for monitoring purposes so the usual does seem a bit unusual here. There are a number of ways this could be done, maybe the simplest is for tasksWaiting to be an AtomicInteger and have the default just increment it and sleep-for-a-day.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16928#discussion_r1413032883
PR Review Comment: https://git.openjdk.org/jdk/pull/16928#discussion_r1413037258

From alanb at openjdk.org  Sun Dec  3 09:55:05 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 3 Dec 2023 09:55:05 GMT
Subject: RFR: 8321223: Implementation of Scoped Values (Second Preview)
Message-ID: <GHxmDbYHCZyBofn9smONv0FSebHOfYuLEeHzc8cLsMc=.2ad135d9-1ab1-49e3-8bf1-e9e0c0fac310@github.com>

This API is sitting out JDK 22, meaning no API/implementation changes in this PR. Some small API changes are likely for JDK 23.

For now, we just need to bump JEP number/title that shows up in the preview section of the javadoc.

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

Commit messages:
 - Initial commit

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

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

From dl at openjdk.org  Sun Dec  3 16:58:38 2023
From: dl at openjdk.org (Doug Lea)
Date: Sun, 3 Dec 2023 16:58:38 GMT
Subject: RFR: JDK-8319662 ForkJoinPool trims worker threads too slowly [v5]
In-Reply-To: <DhqCHd-Cgzk04u6lP7cAWPJYGWESQQx-CoIoI3N4qTI=.642cf1f8-5a71-464e-95c7-9a8880b643fd@github.com>
References: <EfYHyY5R-XjTMrOb7XJbe4Y0m9Zq7zYuI4BlS3T2k2w=.8682eec9-4cae-4004-85dc-923062ac1b5f@github.com>
 <G5l1P3BMMQOab1s1yNtWNYEdJ3niWQAb6aCZ2Yn7QJM=.1e137493-c97b-48dd-99eb-00ad6dde1571@github.com>
 <DhqCHd-Cgzk04u6lP7cAWPJYGWESQQx-CoIoI3N4qTI=.642cf1f8-5a71-464e-95c7-9a8880b643fd@github.com>
Message-ID: <NGTDAw0QQFPD-G9BUG1YjLJsuWxZs6BCJrsOuWWi_MU=.6df11f41-3a17-465f-ba1b-203ae5a001d9@github.com>

On Tue, 28 Nov 2023 14:04:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert 2 lines in method scan
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3123:
> 
>> 3121:             throw unchecked;
>> 3122:         } catch (Exception checked) {
>> 3123:             throw new RuntimeException(checked);
> 
> We should probably add a test that uses invoke(adaptInterruptible(callable)) to check that a checked exception is wrapped, just in case it breaks with some future change.

Yes, somehow a test for this has been missing since first release. I added it to tck/ForkJoinPoolTest.java

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16725#discussion_r1413154556

From dl at openjdk.org  Sun Dec  3 17:13:49 2023
From: dl at openjdk.org (Doug Lea)
Date: Sun, 3 Dec 2023 17:13:49 GMT
Subject: RFR: JDK-8319662 ForkJoinPool trims worker threads too slowly [v6]
In-Reply-To: <EfYHyY5R-XjTMrOb7XJbe4Y0m9Zq7zYuI4BlS3T2k2w=.8682eec9-4cae-4004-85dc-923062ac1b5f@github.com>
References: <EfYHyY5R-XjTMrOb7XJbe4Y0m9Zq7zYuI4BlS3T2k2w=.8682eec9-4cae-4004-85dc-923062ac1b5f@github.com>
Message-ID: <2gzR5w7heEb4Th-X4qX6fVw6R8kSaJBewKWzhKq7HKI=.7ae6246c-5606-4d2f-8e7b-b84317f1459d@github.com>

> This update cascades timeouts to trim subsequent workers after the first  keepAlive inactive period.

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

  Reduce oversignalling and contention; add test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16725/files
  - new: https://git.openjdk.org/jdk/pull/16725/files/e111166f..f6a51eb0

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

  Stats: 199 lines in 2 files changed: 65 ins; 47 del; 87 mod
  Patch: https://git.openjdk.org/jdk/pull/16725.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16725/head:pull/16725

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

From dl at openjdk.org  Sun Dec  3 18:36:53 2023
From: dl at openjdk.org (Doug Lea)
Date: Sun, 3 Dec 2023 18:36:53 GMT
Subject: RFR: JDK-8319662 ForkJoinPool trims worker threads too slowly [v7]
In-Reply-To: <EfYHyY5R-XjTMrOb7XJbe4Y0m9Zq7zYuI4BlS3T2k2w=.8682eec9-4cae-4004-85dc-923062ac1b5f@github.com>
References: <EfYHyY5R-XjTMrOb7XJbe4Y0m9Zq7zYuI4BlS3T2k2w=.8682eec9-4cae-4004-85dc-923062ac1b5f@github.com>
Message-ID: <qqR4ZLLevlbk9ZUT1STq7YA4HiE5ZTIX2lHuNNH91o4=.bff1f2b9-5459-4ac6-b5e0-e2d31db15732@github.com>

> This update cascades timeouts to trim subsequent workers after the first  keepAlive inactive period.

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

 - Merge branch 'openjdk:master' into JDK-8319662
 - Reduce oversignalling and contention; add test
 - Revert 2 lines in method scan
 - Merge branch 'openjdk:master' into JDK-8319662
 - Split up method awaitWork; other associated changes.
 - Merge branch 'openjdk:master' into JDK-8319662
 - tweak cascades; reinstate an @Contended; resolve JDK-8319498
 - Support cascading idle timeouts

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16725/files
  - new: https://git.openjdk.org/jdk/pull/16725/files/f6a51eb0..6f4b9bb3

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

  Stats: 17186 lines in 652 files changed: 12488 ins; 2879 del; 1819 mod
  Patch: https://git.openjdk.org/jdk/pull/16725.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16725/head:pull/16725

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

From psandoz at openjdk.org  Sun Dec  3 18:37:36 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Sun, 3 Dec 2023 18:37:36 GMT
Subject: RFR: 8321223: Implementation of Scoped Values (Second Preview)
In-Reply-To: <GHxmDbYHCZyBofn9smONv0FSebHOfYuLEeHzc8cLsMc=.2ad135d9-1ab1-49e3-8bf1-e9e0c0fac310@github.com>
References: <GHxmDbYHCZyBofn9smONv0FSebHOfYuLEeHzc8cLsMc=.2ad135d9-1ab1-49e3-8bf1-e9e0c0fac310@github.com>
Message-ID: <2VWZtdftDc6qdqgJYaghpZWwHS7weTrEZm4onN3VE_U=.2ef523a7-5876-4847-9ffc-c948564200db@github.com>

On Sun, 3 Dec 2023 08:46:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This API is sitting out JDK 22, meaning no API/implementation changes in this PR. Some small API changes are likely for JDK 23.
> 
> For now, we just need to bump JEP number/title that shows up in the preview section of the javadoc.

Marked as reviewed by psandoz (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16937#pullrequestreview-1761337322

From dholmes at openjdk.org  Mon Dec  4 03:06:39 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 4 Dec 2023 03:06:39 GMT
Subject: RFR: 8320699: Add parameter to skip progress logging of
 OutputAnalyzer [v2]
In-Reply-To: <-gLq1S8NvfT65BAJBv59gCbHv6kDsKYV-WszQLgYN1k=.7e0946f2-2cd2-43b4-b48b-93ce0ce86ed7@github.com>
References: <nMSAMM8k9aiAM3qiRuj-jmyIVugoNOI95xu2N48B0e8=.64a80b3c-cc0d-44c2-ab61-29a8068d4f3d@github.com>
 <-gLq1S8NvfT65BAJBv59gCbHv6kDsKYV-WszQLgYN1k=.7e0946f2-2cd2-43b4-b48b-93ce0ce86ed7@github.com>
Message-ID: <kBanalk29ZFyDCXtaNtN18UVtJRnDo30jbwhWwQSoAM=.38e93942-e446-4ae4-80f3-c73cd42d05a3@github.com>

On Thu, 30 Nov 2023 16:23:39 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Tests using ProcessTools.executeProcess gets the following output written to stdout:
>> [2023-11-24T09:58:16.797540608Z] Gathering output for process 2517117
>> [2023-11-24T09:58:23.070781345Z] Waiting for completion for process 2517117
>> [2023-11-24T09:58:23.071045055Z] Waiting for completion finished for process 2517117
>> 
>> This might be good for some use cases and debugging, but some tests spawns a large number of processes and for those this output fills up the log files.
>> 
>> I propose that we add a way to turn of this output for tests where we find this output to be too noisy.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update OutputBuffer.java copyright years

Okay.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16807#pullrequestreview-1761525078

From dholmes at openjdk.org  Mon Dec  4 03:20:38 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 4 Dec 2023 03:20:38 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v6]
In-Reply-To: <WsReFosxqMxV70m-OJLgiE7maABxc-LnxqJ1LlMZ5tY=.a864cbce-6c35-46fe-ba58-d09e53076dec@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <SHBw8bY7vJuMY8yynW8EMqybSIuhhP5Up_EzESHzv2Y=.e9e34b30-77c6-4f04-a590-8363bfa834d5@github.com>
 <sFgQe4eGlWzzK-fU0r5d6ryaNRn4bg8TuyRIZpNRyDo=.16d81e31-4a20-4124-8a77-2cc1515f658d@github.com>
 <-lVL7hp68aKNlBWHCxdKdPrPDe6NOAKD3zoX-u5ZMEM=.6164666f-7312-4f0c-b15b-2e01a331e820@github.com>
 <WsReFosxqMxV70m-OJLgiE7maABxc-LnxqJ1LlMZ5tY=.a864cbce-6c35-46fe-ba58-d09e53076dec@github.com>
Message-ID: <rswy0baj0j9UuOJ3baInw_iflZ6IMQSIC0C8iyF9fbM=.dc8dd26c-23e5-4803-a578-cb614d79e5ef@github.com>

On Wed, 29 Nov 2023 13:26:58 GMT, serge-sans-paille <duke at openjdk.org> wrote:

>> I take it he is not an Intel employee, in which case he has to be an OpenJDK contributor himself for code for which he holds a copyright to be contributed to OpenJDK. @robilad please correct me if I am wrong here.
>
> hey o/ No problem on my side to either let go my copyright or fill the contributor agreement (where is it?)

Thank you @serge-sans-paille !

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1413324819

From asotona at openjdk.org  Mon Dec  4 05:38:48 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 4 Dec 2023 05:38:48 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v34]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <ERznvvOEs71JrKcEoPMt9cLFbuN-TrBQwnv_gAssFsU=.27708813-1833-45e2-bbd3-b3dee338d691@github.com>

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> 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 372 commits:

 - Merge branch 'master' into JDK-8308753-preview
 - Merge branch 'master' into JDK-8308753-preview
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
 - fixed SwitchBootstrapTest
 - fixed SwitchBootstrap and StackMapsTest
 - fixed SwtichBootstrapTest and ModuleVersionTest
 - Merge branch 'master' into JDK-8308753-preview
 - Merge branch 'master' into JDK-8308753-preview
   
   # Conflicts:
   #	test/jdk/jdk/classfile/StackMapsTest.java
 - Merge branch 'master' into JDK-8308753-preview
   
   # Conflicts:
   #	test/langtools/tools/javac/7199823/InnerClassCannotBeVerified.java
 - added new package-info snippets and fixed ClassFile::parse throws javadoc description
 - fixed lambda tests
 - ... and 362 more: https://git.openjdk.org/jdk/compare/b9df827a...a908e805

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

Changes: https://git.openjdk.org/jdk/pull/15706/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=33
  Stats: 32362 lines in 787 files changed: 14660 ins; 14113 del; 3589 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

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

From asotona at openjdk.org  Mon Dec  4 07:11:11 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 4 Dec 2023 07:11:11 GMT
Subject: Integrated: 8308753: Class-File API transition to Preview
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <xmC7Jgr28c-rsclwW-tBVjPo26NDX9amo2Ns2ez1Wtw=.5e1dd353-28ec-4c14-8ad0-4944b93a1216@github.com>

On Wed, 13 Sep 2023 09:48:00 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 2b00ac0d
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2b00ac0d02a110326846c75ea7ea535dccbb1924
Stats:     32362 lines in 787 files changed: 14660 ins; 14113 del; 3589 mod

8308753: Class-File API transition to Preview

Reviewed-by: ihse, mchung, vromero

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

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

From xgong at openjdk.org  Mon Dec  4 07:32:42 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 4 Dec 2023 07:32:42 GMT
Subject: RFR: 8319872: AArch64: [vectorapi] Implementation of unsigned
 (zero extended) casts [v4]
In-Reply-To: <x7eEa8HhS-mFXYli_uL170SdNtYtvPANDfvickF-XaA=.e95e8efb-4311-48c3-9547-6da087f69b22@github.com>
References: <u4xzg5vm9SQGlgHr0Y7qmZkhQB2ywsudqnmcRKFrauU=.e7b3dd81-3276-4012-ab01-d0822adc6701@github.com>
 <x7eEa8HhS-mFXYli_uL170SdNtYtvPANDfvickF-XaA=.e95e8efb-4311-48c3-9547-6da087f69b22@github.com>
Message-ID: <VjhbAfU0CADL0C437HSJ5ydtVfKHlPdl3u2gwzpoOsI=.50d02592-2fe7-42ae-862c-76eeebae2504@github.com>

On Wed, 22 Nov 2023 07:05:21 GMT, Eric Liu <eliu at openjdk.org> wrote:

>> Vector API defines zero-extend operations [1], which are going to be intrinsified and generated to `VectorUCastNode` by C2. This patch adds backend implementation for `VectorUCastNode` on AArch64.
>> 
>> The micro benchmark shows significant performance improvement. In my test machine (SVE, 256-bit), the result is shown as below:
>> 
>> 
>> 
>>   Benchmark                     Before     After       Units   Gain
>>   VectorZeroExtend.byte2Int     3168.251   243012.399  ops/ms  75.70
>>   VectorZeroExtend.byte2Long    3212.201   216291.588  ops/ms  66.33
>>   VectorZeroExtend.byte2Short   3391.968   182655.365  ops/ms  52.85
>>   VectorZeroExtend.int2Long     1012.197    80448.553  ops/ms  78.48
>>   VectorZeroExtend.short2Int    1812.471   153416.828  ops/ms  83.65
>>   VectorZeroExtend.short2Long   1788.382   129794.814  ops/ms  71.58
>> 
>> 
>> On other Neon systems, we can get similar performance boost as a result of intrinsification success.
>> 
>> Since `VectorUCastNode` only used in Vector API's zero extension currently, this patch also adds assertion on nodes' definitions to clarify their usages.
>> 
>> [TEST]
>> compiler/vectorapi and jdk/incubator/vector passed on NEON and SVE machines.
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java#L726
>
> Eric Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   small fix
>   
>   Change-Id: Icfe9619af1c9e7d5ea8cac457ccebb4eec5c34ad

LGTM!

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

Marked as reviewed by xgong (Committer).

PR Review: https://git.openjdk.org/jdk/pull/16670#pullrequestreview-1761741783

From pminborg at openjdk.org  Mon Dec  4 07:35:47 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 4 Dec 2023 07:35:47 GMT
Subject: RFR: 8321159: SymbolLookup.libraryLookup(Path,
 Arena) Assumes default Filesystem
Message-ID: <sbkQW1a7NByueXA7Vm_JVE06P3queX4AkDE-rlFFbgg=.35168862-4033-4184-97c8-86ab21da922e@github.com>

This PR proposes to reject paths provided to the `SymbolLookup.libraryLookup(Path path, Arena arena)` method if a path is not in the default file system.

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

Commit messages:
 - Fix logic
 - Reject paths not in the default file system

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

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

From alanb at openjdk.org  Mon Dec  4 07:47:37 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 4 Dec 2023 07:47:37 GMT
Subject: RFR: 8321159: SymbolLookup.libraryLookup(Path,
 Arena) Assumes default Filesystem
In-Reply-To: <sbkQW1a7NByueXA7Vm_JVE06P3queX4AkDE-rlFFbgg=.35168862-4033-4184-97c8-86ab21da922e@github.com>
References: <sbkQW1a7NByueXA7Vm_JVE06P3queX4AkDE-rlFFbgg=.35168862-4033-4184-97c8-86ab21da922e@github.com>
Message-ID: <-YHvZtUrgYIz7WyEL8orbdzQ1eVe-HgvN19-RQ8Wjh0=.78a8a3c1-09b9-400e-a495-345ca2531ae6@github.com>

On Mon, 4 Dec 2023 07:29:37 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to reject paths provided to the `SymbolLookup.libraryLookup(Path path, Arena arena)` method if a path is not in the default file system.

src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 297:

> 295:         Reflection.ensureNativeAccess(Reflection.getCallerClass(),
> 296:                 SymbolLookup.class, "libraryLookup");
> 297:         if (!path.getFileSystem().equals(FileSystems.getDefault())) {

This trusts the custom provider's equals implementation, which might be okay but you can use == here instead.

I think I would probably expand the text of the existing IAE description to say that IAE is thrown if the path is not associated with the default file system or not a path to a valid library.

It's a new testable assertion so I assume we should add a new test and track the spec change with a CSR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16944#discussion_r1413475612

From dfenacci at openjdk.org  Mon Dec  4 07:48:54 2023
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Mon, 4 Dec 2023 07:48:54 GMT
Subject: RFR: 8311906: Improve robustness of String constructors with
 mutable array inputs [v14]
In-Reply-To: <ipEQhT5ALrTTIFnVivtcHvCsHwIBfdZQqqSy5dh5DfA=.1894285d-0f87-42ba-8643-fcc9b647847f@github.com>
References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com>
 <ipEQhT5ALrTTIFnVivtcHvCsHwIBfdZQqqSy5dh5DfA=.1894285d-0f87-42ba-8643-fcc9b647847f@github.com>
Message-ID: <AxytRvGWbt-NsgFBuxW8H-sxOZy6ThGIjFznWSuMQlo=.9d677c3d-1a1c-4f56-b6cc-59d0555c5038@github.com>

On Thu, 30 Nov 2023 15:51:46 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers.
>> The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. 
>> 
>> The changes include:
>> 
>> - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate 
>>   if the input array is modified before the constructor returns. 
>>   The resulting string may contain any combination of characters sampled from the input array.
>> 
>> - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character.
>>   For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged.
>>   If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index.
>>   If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect.
>>   Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided.
>>   Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned.
>> 
>> - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character.
>> 
>> - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct jcc/jccb branches

Intrinsics look OK to me.

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

Marked as reviewed by dfenacci (Committer).

PR Review: https://git.openjdk.org/jdk/pull/16425#pullrequestreview-1761763069

From mbaesken at openjdk.org  Mon Dec  4 08:11:48 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 4 Dec 2023 08:11:48 GMT
Subject: RFR: JDK-8317307:
 test/jdk/com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails with
 ConnectException: Connection timed out: no further information
In-Reply-To: <gpnWWUWLMZLI1YDcADf_P9QhEeCAkbEnksZabtRE57w=.3d07e7d8-dd4d-4478-bc7f-fa3b0f57aca1@github.com>
References: <gpnWWUWLMZLI1YDcADf_P9QhEeCAkbEnksZabtRE57w=.3d07e7d8-dd4d-4478-bc7f-fa3b0f57aca1@github.com>
Message-ID: <RUGw0LA9HAcuQOY7LhvijQfRC1EjYolhUk1gzTSGflY=.7805f885-44c9-49da-9869-d2c47338c1a4@github.com>

On Fri, 1 Dec 2023 13:46:14 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On Windows we recently run into this error rather often in the test LdapPoolTimeoutTest.java :
> 
> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information]
> MSG: Connect timed out
> MSG: Timeout exceeded while waiting for a connection: 26984ms
> MSG: Timed out waiting for lock
> MSG: Timed out waiting for lock
> MSG: Timed out waiting for lock
> MSG: Timeout exceeded while waiting for a connection: 26984ms
> MSG: Timeout exceeded while waiting for a connection: 26984ms
> java.lang.Exception: failures: 1
> at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:104)
> at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:58)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> at java.base/java.lang.Thread.run(Thread.java:1570)
> 
> We should extend the accepted exception message strings and also also  'Connection timed out' .

Thanks for the review !

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

PR Comment: https://git.openjdk.org/jdk/pull/16922#issuecomment-1838028594

From mbaesken at openjdk.org  Mon Dec  4 08:11:49 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 4 Dec 2023 08:11:49 GMT
Subject: Integrated: JDK-8317307:
 test/jdk/com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails with
 ConnectException: Connection timed out: no further information
In-Reply-To: <gpnWWUWLMZLI1YDcADf_P9QhEeCAkbEnksZabtRE57w=.3d07e7d8-dd4d-4478-bc7f-fa3b0f57aca1@github.com>
References: <gpnWWUWLMZLI1YDcADf_P9QhEeCAkbEnksZabtRE57w=.3d07e7d8-dd4d-4478-bc7f-fa3b0f57aca1@github.com>
Message-ID: <537MpzEByOviJ1f53K_7LF6a6PZKzJFjlIKnouXs-io=.e6161ba6-69f4-4abd-96d4-d08bc1df7f2c@github.com>

On Fri, 1 Dec 2023 13:46:14 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On Windows we recently run into this error rather often in the test LdapPoolTimeoutTest.java :
> 
> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information]
> MSG: Connect timed out
> MSG: Timeout exceeded while waiting for a connection: 26984ms
> MSG: Timed out waiting for lock
> MSG: Timed out waiting for lock
> MSG: Timed out waiting for lock
> MSG: Timeout exceeded while waiting for a connection: 26984ms
> MSG: Timeout exceeded while waiting for a connection: 26984ms
> java.lang.Exception: failures: 1
> at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:104)
> at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:58)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> at java.base/java.lang.Thread.run(Thread.java:1570)
> 
> We should extend the accepted exception message strings and also also  'Connection timed out' .

This pull request has now been integrated.

Changeset: b9b82631
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b9b82631bf75dc93d9e11536b6872df4c89e9592
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8317307: test/jdk/com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails with ConnectException: Connection timed out: no further information

Reviewed-by: clanger

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

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

From eliu at openjdk.org  Mon Dec  4 08:17:56 2023
From: eliu at openjdk.org (Eric Liu)
Date: Mon, 4 Dec 2023 08:17:56 GMT
Subject: Integrated: 8319872: AArch64: [vectorapi] Implementation of unsigned
 (zero extended) casts
In-Reply-To: <u4xzg5vm9SQGlgHr0Y7qmZkhQB2ywsudqnmcRKFrauU=.e7b3dd81-3276-4012-ab01-d0822adc6701@github.com>
References: <u4xzg5vm9SQGlgHr0Y7qmZkhQB2ywsudqnmcRKFrauU=.e7b3dd81-3276-4012-ab01-d0822adc6701@github.com>
Message-ID: <9H0QK5sdiSsreNc11CwQGpRnsW5p5__fHVrvmrLQMjs=.3599d4bd-0005-4db4-b11b-de2b9dff70dc@github.com>

On Wed, 15 Nov 2023 07:48:28 GMT, Eric Liu <eliu at openjdk.org> wrote:

> Vector API defines zero-extend operations [1], which are going to be intrinsified and generated to `VectorUCastNode` by C2. This patch adds backend implementation for `VectorUCastNode` on AArch64.
> 
> The micro benchmark shows significant performance improvement. In my test machine (SVE, 256-bit), the result is shown as below:
> 
> 
> 
>   Benchmark                     Before     After       Units   Gain
>   VectorZeroExtend.byte2Int     3168.251   243012.399  ops/ms  75.70
>   VectorZeroExtend.byte2Long    3212.201   216291.588  ops/ms  66.33
>   VectorZeroExtend.byte2Short   3391.968   182655.365  ops/ms  52.85
>   VectorZeroExtend.int2Long     1012.197    80448.553  ops/ms  78.48
>   VectorZeroExtend.short2Int    1812.471   153416.828  ops/ms  83.65
>   VectorZeroExtend.short2Long   1788.382   129794.814  ops/ms  71.58
> 
> 
> On other Neon systems, we can get similar performance boost as a result of intrinsification success.
> 
> Since `VectorUCastNode` only used in Vector API's zero extension currently, this patch also adds assertion on nodes' definitions to clarify their usages.
> 
> [TEST]
> compiler/vectorapi and jdk/incubator/vector passed on NEON and SVE machines.
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java#L726

This pull request has now been integrated.

Changeset: 9b8eaa2f
Author:    Eric Liu <eliu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9b8eaa2fc3c5127bc7828471916f5d881bf71228
Stats:     381 lines in 8 files changed: 299 ins; 23 del; 59 mod

8319872: AArch64: [vectorapi] Implementation of unsigned (zero extended) casts

Reviewed-by: aph, xgong

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

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

From xgong at openjdk.org  Mon Dec  4 08:33:49 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 4 Dec 2023 08:33:49 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v6]
In-Reply-To: <emidt6MaU3Owb2FMLA1EibqvQF4_zTtsA00ccPQAy4Y=.1b90ba32-ac3a-41db-acf9-f1c45704b203@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
 <emidt6MaU3Owb2FMLA1EibqvQF4_zTtsA00ccPQAy4Y=.1b90ba32-ac3a-41db-acf9-f1c45704b203@github.com>
Message-ID: <xVVii7I4RU8P9bpGqTdLnUqzD3LhrrXYhuN0URC6JAE=.5027c6d2-d75e-48bd-bcc2-57332216078e@github.com>

On Fri, 1 Dec 2023 16:45:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The final thing we need to resolve properly is the SVE compiler test.
> 
> @theRealAph says:
> 
> > arm_sve.h is part of GCC. It was added to GCC in 2019.
> 
> A more relevant question is what version of gcc it was added, and if that also implies that the compiler knows about `-march=armv8-a+sve`. If so, then this test could basically be framed as a gcc version check.
> 
> I'm still leaning towards failing configure if the SVE code cannot be compiled. Under what circumstances can this test possibly fail, so SVE_CFLAGS would not be set?

Yes, the SVE compiler test code could be treated as a gcc/clang version check. `arm_sve.h` which is included in `sleef.h` and then in `vect_math_sve.c` is the SVE ACLE (Arm C Language Extensions) header file. It was included in gcc start from version 10 (may not be exact, but gcc 8/9 would fail when compile c code including this header). We have to make sure the compiler supports the SVE ACLE before using it.  Here are the different scenarios:

1. The SVE compiler test success, and `SVE_CFLAGS` is set to `-march=armv8-a+sve`. All symbols in `libvmath.so` are built successfully including NEON/SVE. Hence, the vector math operations with all kinds of vector size on both NEON/SVE machines will be improved as expected.
2. The SVE compiler test fail, and `SVE_CFLAGS` is null. SVE symbols in `libvmath.so` cannot be built out. Only NEON symbols exist in `libvmath.so`. Hence, the enhancement for vector math operations with > 128-bit vector size on SVE machines are missing.

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1838061502

From vklang at openjdk.org  Mon Dec  4 08:46:43 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 4 Dec 2023 08:46:43 GMT
Subject: RFR: 8321124: java/util/stream/GatherersTest.java times out [v2]
In-Reply-To: <ZVtY1n8bmuPMNvSTWNBB5lDkWXovIo5TPn4uK0pK2ac=.c0128720-7840-4c50-843f-d9b17057b191@github.com>
References: <NcgSgagzqKytU8dGSMKHUF_9ylICS5s6If5CoFRjPhw=.abef3a79-b429-47c5-b0b7-aa7b9f71ef31@github.com>
 <eRHU-J1zkepYoEtzJ9XyoFjibSEIBTdzk6LaAoT-d4w=.0af11429-436a-4dfd-b5f0-806f41ab8107@github.com>
 <DRKkxA6msb2IlV_JXkjMqvk8esYW1WchBjhz3tjkjQY=.0152f520-87b3-414b-8aec-3c6710ec84a8@github.com>
 <ZVtY1n8bmuPMNvSTWNBB5lDkWXovIo5TPn4uK0pK2ac=.c0128720-7840-4c50-843f-d9b17057b191@github.com>
Message-ID: <auk1Dm3ImGVAHcD5qNKEDjcPw2_ewPYhkk9TWL5rLKA=.b06bfdb0-b6f8-4492-b38a-045ebd0211cd@github.com>

On Sun, 3 Dec 2023 09:20:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/jdk/java/util/stream/BuiltInGatherersTest.java line 257:
>> 
>>> 255:         // Test cancellation after exception during processing
>>> 256:         // Only use reasonably sized streams to avoid excessive thread creation
>>> 257:         if (config.streamSize > 2 && config.streamSize < 100) {
>> 
>> @AlanBateman Decided to not run the cancellation tests for the larger streams as it creates a bunch of extra resource usage which makes GHA really unhappy.
>
> Okay but it makes me wonder if this test should have its use method source with the stream sizes that are sensible to test.

Yeah, I have plans to split the tests out to separate files beyond the Preview.

>> test/jdk/java/util/stream/BuiltInGatherersTest.java line 331:
>> 
>>> 329:                                     case Integer n when n == config.streamSize - 1 -> {
>>> 330:                                         awaitSensibly(firstReady);
>>> 331:                                         while(tasksWaiting.getQueueLength() < tasksToCancel) {
>> 
>> @AlanBateman This is the only part of this I really don't like. Any better suggestion as to "wait for N things waiting" in a test? ?
>
>> @AlanBateman This is the only part of this I really don't like. Any better suggestion as to "wait for N things waiting" in a test? ?
> 
> Semaphore::getQueueLength is more for monitoring purposes so the usage does seem a bit unusual here. There are a number of ways this could be done, maybe the simplest is for tasksWaiting to be an AtomicInteger and have the default just increment it and sleep-for-a-day.

@AlanBateman Unfortunately that doesn't really work as there's then a window between incrementing the counter and going to sleep. So while it might execute correctly in 99.9999% of cases I don't want to have a jbs bug filed which will be one of those things where you can't recall it 6-12 months down the line ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16928#discussion_r1413534692
PR Review Comment: https://git.openjdk.org/jdk/pull/16928#discussion_r1413537391

From vklang at openjdk.org  Mon Dec  4 08:46:50 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 4 Dec 2023 08:46:50 GMT
Subject: RFR: 8321124: java/util/stream/GatherersTest.java times out [v2]
In-Reply-To: <wZJ9V1dN05SSh9iqC6mifk-n3_0VvZWvf1ZBZPZRF9U=.24b8dabb-cb60-4d49-a3b1-2c5efd5e91b1@github.com>
References: <NcgSgagzqKytU8dGSMKHUF_9ylICS5s6If5CoFRjPhw=.abef3a79-b429-47c5-b0b7-aa7b9f71ef31@github.com>
 <eRHU-J1zkepYoEtzJ9XyoFjibSEIBTdzk6LaAoT-d4w=.0af11429-436a-4dfd-b5f0-806f41ab8107@github.com>
 <wZJ9V1dN05SSh9iqC6mifk-n3_0VvZWvf1ZBZPZRF9U=.24b8dabb-cb60-4d49-a3b1-2c5efd5e91b1@github.com>
Message-ID: <hFh5S1ktQhkL7RnLjVoNCzWIJPQV28eJ5fVPymxXvJ0=.01930de8-5737-483c-a274-628010a6dd39@github.com>

On Sun, 3 Dec 2023 09:26:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Only run the cancellation tests for mapConcurrent for the shorter streams to conserve resources
>
> test/jdk/java/util/stream/BuiltInGatherersTest.java line 272:
> 
>> 270:                                     case 1 -> {
>> 271:                                         throwerReady.countDown();
>> 272:                                         awaitSensibly(initiateThrow);
> 
> 20s might not be enough to wait for the count down when running with a debug build, -Xcomp, ...  I would be tempted to just have it wait indefinitely. If there is an issue then jtreg will timeout the test.

I'll switch it back do indefinite wait and let jtreg report the timeout instead as you suggested. having bounded timeouts made debugging easier so I left that facility in in case the future has more timeouts in it...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16928#discussion_r1413535985

From alanb at openjdk.org  Mon Dec  4 08:57:45 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 4 Dec 2023 08:57:45 GMT
Subject: RFR: 8321124: java/util/stream/GatherersTest.java times out [v2]
In-Reply-To: <ZVtY1n8bmuPMNvSTWNBB5lDkWXovIo5TPn4uK0pK2ac=.c0128720-7840-4c50-843f-d9b17057b191@github.com>
References: <NcgSgagzqKytU8dGSMKHUF_9ylICS5s6If5CoFRjPhw=.abef3a79-b429-47c5-b0b7-aa7b9f71ef31@github.com>
 <eRHU-J1zkepYoEtzJ9XyoFjibSEIBTdzk6LaAoT-d4w=.0af11429-436a-4dfd-b5f0-806f41ab8107@github.com>
 <DRKkxA6msb2IlV_JXkjMqvk8esYW1WchBjhz3tjkjQY=.0152f520-87b3-414b-8aec-3c6710ec84a8@github.com>
 <ZVtY1n8bmuPMNvSTWNBB5lDkWXovIo5TPn4uK0pK2ac=.c0128720-7840-4c50-843f-d9b17057b191@github.com>
Message-ID: <_yBBa3hEIjCYo00FmBIL_EchnogIBQ0Kjuj_7sCGQL4=.7ba6ce2d-e8ef-40e2-b963-6cd84ba654df@github.com>

On Sun, 3 Dec 2023 09:50:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/jdk/java/util/stream/BuiltInGatherersTest.java line 331:
>> 
>>> 329:                                     case Integer n when n == config.streamSize - 1 -> {
>>> 330:                                         awaitSensibly(firstReady);
>>> 331:                                         while(tasksWaiting.getQueueLength() < tasksToCancel) {
>> 
>> @AlanBateman This is the only part of this I really don't like. Any better suggestion as to "wait for N things waiting" in a test? ?
>
>> @AlanBateman This is the only part of this I really don't like. Any better suggestion as to "wait for N things waiting" in a test? ?
> 
> Semaphore::getQueueLength is more for monitoring purposes so the usage does seem a bit unusual here. There are a number of ways this could be done, maybe the simplest is for tasksWaiting to be an AtomicInteger and have the default just increment it and sleep-for-a-day.

> @AlanBateman Unfortunately that doesn't really work as there's then a window between incrementing the counter and going to sleep. So while it might execute correctly in 99.9999% of cases I don't want to have a jbs bug filed which will be one of those things where you can't recall it 6-12 months down the line ?

Thread.sleep throws if called with the interrupt status set so a cancel in the window between before the sleep should be okay. I think in this case, it's whatever is simplest is reliable and easy to read/maintain.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16928#discussion_r1413551130

From pminborg at openjdk.org  Mon Dec  4 09:06:01 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 4 Dec 2023 09:06:01 GMT
Subject: RFR: 8321159: SymbolLookup.libraryLookup(Path,
 Arena) Assumes default Filesystem [v2]
In-Reply-To: <sbkQW1a7NByueXA7Vm_JVE06P3queX4AkDE-rlFFbgg=.35168862-4033-4184-97c8-86ab21da922e@github.com>
References: <sbkQW1a7NByueXA7Vm_JVE06P3queX4AkDE-rlFFbgg=.35168862-4033-4184-97c8-86ab21da922e@github.com>
Message-ID: <_1WdeDLGXsOD3O1-Kz5lzAR5q1E3daal9u-UBRHhDBg=.4968af3c-e20a-4a76-bc9d-90bb0bc79cef@github.com>

> This PR proposes to reject paths provided to the `SymbolLookup.libraryLookup(Path path, Arena arena)` method if a path is not in the default file system.

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

  Improve after comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16944/files
  - new: https://git.openjdk.org/jdk/pull/16944/files/100b4794..097c6ae7

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

  Stats: 38 lines in 2 files changed: 36 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16944.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16944/head:pull/16944

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

From pminborg at openjdk.org  Mon Dec  4 09:10:07 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 4 Dec 2023 09:10:07 GMT
Subject: RFR: 8321159: SymbolLookup.libraryLookup(Path,
 Arena) Assumes default Filesystem [v3]
In-Reply-To: <sbkQW1a7NByueXA7Vm_JVE06P3queX4AkDE-rlFFbgg=.35168862-4033-4184-97c8-86ab21da922e@github.com>
References: <sbkQW1a7NByueXA7Vm_JVE06P3queX4AkDE-rlFFbgg=.35168862-4033-4184-97c8-86ab21da922e@github.com>
Message-ID: <35Iwd7GHRGThxnsiWDmsvS9f0z2duLDpS_V70htRysA=.dd1b7024-aae6-47eb-ad17-3f1057b89bde@github.com>

> This PR proposes to reject paths provided to the `SymbolLookup.libraryLookup(Path path, Arena arena)` method if a path is not in the default file system.

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

  Add fail statement

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16944/files
  - new: https://git.openjdk.org/jdk/pull/16944/files/097c6ae7..f1693824

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

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

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

From alanb at openjdk.org  Mon Dec  4 10:15:43 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 4 Dec 2023 10:15:43 GMT
Subject: RFR: 8321159: SymbolLookup.libraryLookup(Path,
 Arena) Assumes default Filesystem [v3]
In-Reply-To: <35Iwd7GHRGThxnsiWDmsvS9f0z2duLDpS_V70htRysA=.dd1b7024-aae6-47eb-ad17-3f1057b89bde@github.com>
References: <sbkQW1a7NByueXA7Vm_JVE06P3queX4AkDE-rlFFbgg=.35168862-4033-4184-97c8-86ab21da922e@github.com>
 <35Iwd7GHRGThxnsiWDmsvS9f0z2duLDpS_V70htRysA=.dd1b7024-aae6-47eb-ad17-3f1057b89bde@github.com>
Message-ID: <UkseE1FDJJ-T2nS_ONbiBvfdlKrF2WY1rKoWh9EhJQE=.fccb67e8-a83d-4099-8abb-49b0d9335251@github.com>

On Mon, 4 Dec 2023 09:10:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to reject paths provided to the `SymbolLookup.libraryLookup(Path path, Arena arena)` method if a path is not in the default file system.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add fail statement

test/jdk/java/foreign/LibraryLookupTest.java line 128:

> 126:             }
> 127:         }
> 128:         throw new AssertionError("Unable to create file system from " + clazz);

Using a class from testng.jar is a good idea. An alternative to decoding the composite URL is to use the code source from the protection domain, e.g.

URI uri = clazz.getProtectionDomain().getCodeSource().getLocation().toURI();
return FileSystems.newFileSystem(Path.of(uri));

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16944#discussion_r1413645073

From dclarke at openjdk.org  Mon Dec  4 10:44:54 2023
From: dclarke at openjdk.org (Darragh Clarke)
Date: Mon, 4 Dec 2023 10:44:54 GMT
Subject: RFR: 8319647: Update or mark as vm.flagless tests that ignore external
 VM flags
Message-ID: <zOAssUyHlaTMKi-cdLp_YxE7Qdko-MfAnovE2cFR_9M=.269b68c9-57c5-4d32-bd3c-1874193ddefa@github.com>

Updated tests to use vm.flagless as they already ignore Vm flags

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

Commit messages:
 - ignore vm flags

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

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

From asotona at openjdk.org  Mon Dec  4 11:18:54 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 4 Dec 2023 11:18:54 GMT
Subject: RFR: 8321248: ClassFile API ClassModel::verify is inconsistent with
 the rest of the API
Message-ID: <ydm5vaSl_9iTojm2PkI5Z4pu9OkV8L663DFFuKOgINM=.6e7bd095-fc4c-4884-af15-137ef3565e17@github.com>

ClassFile API `ClassModel::verify` accepts `ClassHierarchyResolver` as an optional argument and does not respect `ClassFile.ClassHierarchyResolverOption` of the actual context.
Parsing, building and transforming take options from the actual `ClassFile` context and verification should follow the same API pattern.

This patch removes `ClassModel::verify` methods and introduces new top level methods:

List<VerifyError> ClassFile::verify(ClassModel model);
List<VerifyError> ClassFile::verify(byte[] bytes);
List<VerifyError> ClassFile::verify(Path path);


ClassFile API has been recently opened as a preview feature, so this bug technically requires a CSR (temporary unable to create).
Impact of the API change is none as the API has not been released yet.

Please review.

Thanks,
Adam

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

Commit messages:
 - tests fix
 - dependent code fix
 - implementation
 - 8321248: ClassFile API ClassModel::verify is inconsistent with the rest of the API

Changes: https://git.openjdk.org/jdk/pull/16947/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16947&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321248
  Stats: 122 lines in 11 files changed: 44 ins; 62 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/16947.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16947/head:pull/16947

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

From ihse at openjdk.org  Mon Dec  4 11:51:38 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Dec 2023 11:51:38 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v6]
In-Reply-To: <OJ1ZK4a8c_bZik60v503VUtZoweFFv6VhhGg1sp4qSY=.e8852bf1-2d7f-4164-b952-d88b294ec1f7@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <e5w5YZ0WD8S3UVFBYz6I0PdKZ6yOkD77BCq2arDd6i4=.7eecadcb-e627-4e9b-8f1e-3fc41c63243b@github.com>
 <bopxvLCquUtZQxt8kAJskzXBR2YE_I0PW13i3NBJNNY=.e65abf3d-0ff4-4450-875b-ca3717170485@github.com>
 <DeQgR1PaXlk2yzlxV15N3ViZY26wXtlgfVKxRY6vuWo=.6d38f729-0ca9-4f43-9e23-f5e73a01cc23@github.com>
 <b1Nv5Y7Klpvp5ACcHJTTblwGmnA64cyRg-3YzotaHvc=.0bd8a0f0-0844-44a9-a3bb-4af2e8514ee1@github.com>
 <t_23EA--aX8v2US9Lsib1ZF3bl4HQx_Z4RXqlgQo8LE=.6f1f2873-015c-4b69-ad47-b449e5b77a45@github.com>
 <pRcJlU1a4jG9gMaftLn5IerudMSDIrvr70KBefkpNSo=.f442f0d4-887f-4376-a66e-8254fa35927c@github.com>
 <OJ1ZK4a8c_bZik60v503VUtZoweFFv6VhhGg1sp4qSY=.e8852bf1-2d7f-4164-b952-d88b294ec1f7@github.com>
Message-ID: <_gSNXk0qGAtpY-WJ5OCHk_3-nuGrwwSn-ffK9f2TEcs=.40f785ba-83dd-40fe-8075-a7a7872ea600@github.com>

On Thu, 30 Nov 2023 20:19:56 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> Raising the minimum gcc version is not done willy-nilly. (I feel a "You just don't ..." meme coming up)
>> 
>> But you are saying that you want to skip building this library unless you have a gcc version that supports c++17? 
>> 
>> I still don't really like it. I'd like to hear someone else who can think clearly about this, if we want to go down this path, and start adding libraries that use C++17. Maybe @kimbarrett has some input?
>
>> But you are saying that you want to skip building this library unless you have a gcc version that supports c++17?
>> 
> Yes, the request is to skip building the simdsort library if GCC version is < 8 as only GCC >= 8 supports C++17 features.

Then you must add logic to check for this. Now the build will just fail if building with an older gcc. That is not acceptable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1413761798

From ihse at openjdk.org  Mon Dec  4 12:01:47 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Dec 2023 12:01:47 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v6]
In-Reply-To: <lQJoZ_hXjfLO-MRGDLar9L0yD6xAXF1QAu2AIAjwnKk=.390b6b58-3e5d-42af-90e6-2dd76b29172f@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
 <3cK9QjVQNIgZoWWhrWKEb3XxfbLjprjRMBbStWegH7M=.6df92651-b97d-445a-aa42-302ea791bbea@github.com>
 <lQJoZ_hXjfLO-MRGDLar9L0yD6xAXF1QAu2AIAjwnKk=.390b6b58-3e5d-42af-90e6-2dd76b29172f@github.com>
Message-ID: <AnHvp-NR-sLPEha8BivPv-pBAmquGjSge4TIludLVHM=.e2866a94-78bb-40d7-8506-9807c5a3d786@github.com>

On Fri, 1 Dec 2023 16:49:28 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Oh, and:
>> 
>> If we can't trust SLEEF not to break the ABI we're using, we should not be using SLEEF.
>
>> @theRealAph You are making good points.
>> 
>> You are basically saying: "we don't need any configure support for libsleef, we can just hard-code the names and dispatch to them directly to a dlopened library at runtime".
> 
> Yep.
> 
>> That is technically correct, but I'd still like to argue that the current setup have some merits:
>> 
>>     * It will check that there is no typo in the function names. I agree that the likelihood of getting this wrong is low, but it is still a good practice to use official include files to have the compiler help checking this.
>> 
>>     * If we would like to bundle libsleef.so with the JVM, now we have the possibility do do so easily. (Especially if it is like you say that it is not commonly installed). (If licenses allow etc)
>> 
>>     * If we want to incorporate/bundle the source code of libsleef into OpenJDK, and build it as part of our internal library, we will have a good starting position, compared to starting from a hard-coded assembly file in hotspot. (I thought I heard some noise about this prospect).
>> 
>> 
>> So at this point, I am okay with the general approach of this PR. There are still some build issues to sort out, though, I'll address them separately.
> 
> I see, OK. The question in my mind is whether the common builds of OpenJDK (Oracle, Adoptium, etc.) will support running with SLEEF. If by default SLEEF is not required, support won't be built, and (to an nth order approximation) no one will use it. But I guess it's better than nothing.
> 
> Or is there likely to be a plan to e.g. build Oracle's releases with SLEEF support?

@theRealAph 
> Or is there likely to be a plan to e.g. build Oracle's releases with SLEEF support?

I can't say anything for sure, but I picked up some positive vibes from our internal chat. I think the idea was that libsleef could potentially cover up vector math for all platforms that the current Intel lib solution is missing (basically, everything but linux+windows x64). So I this can be seen as a bit of a trial balloon if it is worth a more complete integration of libsleef in the JDK.

And I can't say anything at all about what Oracle JDKs are going to release with, but I am fully open towards adding libsleef to the GHA builds. And I'm guessing that Adoptium has no reason not to include libsleef, but then again, I cannot of course speak for them.

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1838489588

From ihse at openjdk.org  Mon Dec  4 12:04:45 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Dec 2023 12:04:45 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v6]
In-Reply-To: <xVVii7I4RU8P9bpGqTdLnUqzD3LhrrXYhuN0URC6JAE=.5027c6d2-d75e-48bd-bcc2-57332216078e@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
 <emidt6MaU3Owb2FMLA1EibqvQF4_zTtsA00ccPQAy4Y=.1b90ba32-ac3a-41db-acf9-f1c45704b203@github.com>
 <xVVii7I4RU8P9bpGqTdLnUqzD3LhrrXYhuN0URC6JAE=.5027c6d2-d75e-48bd-bcc2-57332216078e@github.com>
Message-ID: <_oX3Rqyygpj-612IlxZBZOZQnauEyTBjE4goHDa4Ov8=.0ccafde6-c95e-469d-aee6-77a2e75ee7a7@github.com>

On Mon, 4 Dec 2023 08:31:17 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> The final thing we need to resolve properly is the SVE compiler test. 
>> 
>> @theRealAph says:
>>> arm_sve.h is part of GCC. It was added to GCC in 2019.
>> 
>> A more relevant question is what version of gcc it was added, and if that also implies that the compiler knows about `-march=armv8-a+sve`. If so, then this test could basically be framed as a gcc version check.
>> 
>> I'm still leaning towards failing configure if the SVE code cannot be compiled. Under what circumstances can this test possibly fail, so SVE_CFLAGS would not be set?
>
>> The final thing we need to resolve properly is the SVE compiler test.
>> 
>> @theRealAph says:
>> 
>> > arm_sve.h is part of GCC. It was added to GCC in 2019.
>> 
>> A more relevant question is what version of gcc it was added, and if that also implies that the compiler knows about `-march=armv8-a+sve`. If so, then this test could basically be framed as a gcc version check.
>> 
>> I'm still leaning towards failing configure if the SVE code cannot be compiled. Under what circumstances can this test possibly fail, so SVE_CFLAGS would not be set?
> 
> Yes, the SVE compiler test code could be treated as a gcc/clang version check. `arm_sve.h` which is included in `sleef.h` and then in `vect_math_sve.c` is the SVE ACLE (Arm C Language Extensions) header file. It was included in gcc start from version 10 (may not be exact, but gcc 8/9 would fail when compile c code including this header). We have to make sure the compiler supports the SVE ACLE before using it.  Here are the different scenarios:
> 
> 1. The SVE compiler test success, and `SVE_CFLAGS` is set to `-march=armv8-a+sve`. All symbols in `libvmath.so` are built successfully including NEON/SVE. Hence, the vector math operations with all kinds of vector size on both NEON/SVE machines will be improved as expected.
> 2. The SVE compiler test fail, and `SVE_CFLAGS` is null. SVE symbols in `libvmath.so` cannot be built out. Only NEON symbols exist in `libvmath.so`. Hence, the enhancement for vector math operations with > 128-bit vector size on SVE machines are missing.

@XiaohongGong If we are sure that the SVE test will always succeed when running on gcc 10 or higher, then I guess I don't really need a way to enforce SVE support -- you'll just have to make sure you use a recent enough gcc.

But, then the entire test becomes a bit unnecessary. You can just replace it with a version check on gcc, or perhaps a FLAGS_COMPILER_CHECK_ARGUMENTS on `-march=armv8-a+sve`.

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1838495553

From alanb at openjdk.org  Mon Dec  4 13:18:38 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 4 Dec 2023 13:18:38 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v3]
In-Reply-To: <h3gsRz_Q935JguupcZqwssUazi6miz6k4RMFCULNPwg=.d1fe182b-1b04-4e19-803a-ce166ded27f4@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <vrdFV2cgL_pMuQWhcgLiV5STWcrxjahjiMq86qghuwM=.a2da54b7-0c22-4608-9857-d48bb207d7d4@github.com>
 <06dpAmRUHn4PyHDz2vZLZ9FyzF6u81qj_39hbqP7PnE=.2924f568-9021-46e7-b1fb-0c7a4d5f9c4d@github.com>
 <TRdmt9bEfMyCOTFYsvxvZSdfFPvnk0H_0SMPX5rqO0s=.028e96eb-52e0-4960-b955-1f12202978c9@github.com>
 <6IitbefHaaKPhCkB_FRZnBxTyZJi0i8jjh8Pr32jsb8=.956ea224-3aff-4c86-9e28-6399172bfc92@github.com>
 <NXUxb-lZvWnXhc0tuyHN4acnl24E0p6N9tjR6SRjocI=.feb4f5cc-b1ac-4b3f-bee2-c57e5fe101bf@github.com>
 <h3gsRz_Q935JguupcZqwssUazi6miz6k4RMFCULNPwg=.d1fe182b-1b04-4e19-803a-ce166ded27f4@github.com>
Message-ID: <5PkUvozvjQnOZ40SBRcdabaHwJFhHPl0I5UniEE_C3s=.9269db2b-e3cc-4487-b540-b8f90cbe6df7@github.com>

On Thu, 30 Nov 2023 17:24:47 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> What do you think of adding `OutputStream extends WritableByteChannel`, so `transferTo` could be implemented with `if (target instanceof WritableByteChannel) { target.write(ByteBuffer.wrap(buf, off, len).asReadOnly()); }`?
>> 
>> Read-only byte buffer will not allow modifying the data in the buffer, it would eliminate buffer copies, and adding `write(ByteBuffer)` to `OutputStream` seems reasonable.
>
>> It could be special cased for trusted targets but at the cost of auditing and complexity. So more thought needed on this [...]
> 
> Could the target additionally be checked to see whether it is a `FilterOutputStream` and if so not be trusted?

> What do you think of adding `OutputStream extends WritableByteChannel`, so `transferTo` could be implemented with `if (target instanceof WritableByteChannel) { target.write(ByteBuffer.wrap(buf, off, len).asReadOnly()); }`?

Interesting but I don't think that is workable as WBC specifies that writes executing serially and also specifies the exception when attempting to write to a closed channel, both of which are not compatible with OutputStream.

In any case, it doesn't solve the second part of the concern which is read-only view on the internal buffer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1413859006

From vsitnikov at openjdk.org  Mon Dec  4 13:33:47 2023
From: vsitnikov at openjdk.org (Vladimir Sitnikov)
Date: Mon, 4 Dec 2023 13:33:47 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v3]
In-Reply-To: <5PkUvozvjQnOZ40SBRcdabaHwJFhHPl0I5UniEE_C3s=.9269db2b-e3cc-4487-b540-b8f90cbe6df7@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <vrdFV2cgL_pMuQWhcgLiV5STWcrxjahjiMq86qghuwM=.a2da54b7-0c22-4608-9857-d48bb207d7d4@github.com>
 <06dpAmRUHn4PyHDz2vZLZ9FyzF6u81qj_39hbqP7PnE=.2924f568-9021-46e7-b1fb-0c7a4d5f9c4d@github.com>
 <TRdmt9bEfMyCOTFYsvxvZSdfFPvnk0H_0SMPX5rqO0s=.028e96eb-52e0-4960-b955-1f12202978c9@github.com>
 <6IitbefHaaKPhCkB_FRZnBxTyZJi0i8jjh8Pr32jsb8=.956ea224-3aff-4c86-9e28-6399172bfc92@github.com>
 <NXUxb-lZvWnXhc0tuyHN4acnl24E0p6N9tjR6SRjocI=.feb4f5cc-b1ac-4b3f-bee2-c57e5fe101bf@github.com>
 <h3gsRz_Q935JguupcZqwssUazi6miz6k4RMFCULNPwg=.d1fe182b-1b04-4e19-803a-ce166ded27f4@github.com>
 <5PkUvozvjQnOZ40SBRcdabaHwJFhHPl0I5UniEE_C3s=.9269db2b-e3cc-4487-b540-b8f90cbe6df7@github.com>
Message-ID: <7JHnl4QcbKEDH4V6rxX33WHoeTuyBGQG1z5a6jhNjjs=.45301468-a6c2-46bc-9c96-570ec8bdc887@github.com>

On Mon, 4 Dec 2023 13:16:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>it doesn't solve the second part of the concern which is read-only view on the internal buffer.

I think `ByteBuffer.asReadOnlyBuffer()` should resolve the issues regarding naked byte access. At least `ByteBuffer#array()` returns `null` for read-only buffers, and `ByteBuffer#hasArray()` returns `false`.
Am I missing something?

I've created https://bugs.openjdk.org/browse/JDK-8321271 to track `OutputStream.write(ByteBuffer)` as I think it would avoid mixing discussions on `transferTo` and `OutputStream.write(ByteBuffer)` which would be useful even beyond the scope of transferTo.

---

> WBC specifies that writes executing serially and also specifies the exception when attempting to write to a closed channel, both of which are not compatible with OutputStream

There's `Channel#isOpen` as well which is hard to tell for a generic `InputStream`.

On the other hand, what if `OutputStream` declares its own `write(ByteBuffer)` method? (that is JDK-8321271)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1413874663

From dl at openjdk.org  Mon Dec  4 13:56:55 2023
From: dl at openjdk.org (Doug Lea)
Date: Mon, 4 Dec 2023 13:56:55 GMT
Subject: RFR: JDK-8319662 ForkJoinPool trims worker threads too slowly [v8]
In-Reply-To: <EfYHyY5R-XjTMrOb7XJbe4Y0m9Zq7zYuI4BlS3T2k2w=.8682eec9-4cae-4004-85dc-923062ac1b5f@github.com>
References: <EfYHyY5R-XjTMrOb7XJbe4Y0m9Zq7zYuI4BlS3T2k2w=.8682eec9-4cae-4004-85dc-923062ac1b5f@github.com>
Message-ID: <4Uww87u_Iduao3i7nucJk8IMwfI_c14fEZ1xOUVsgHM=.87bdab09-4936-4fbd-afa0-bc02ead39d5d@github.com>

> This update cascades timeouts to trim subsequent workers after the first  keepAlive inactive period.

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

 - Merge branch 'openjdk:master' into JDK-8319662
 - Remove unnecessary re-interrupt
 - Merge branch 'openjdk:master' into JDK-8319662
 - Reduce oversignalling and contention; add test
 - Revert 2 lines in method scan
 - Merge branch 'openjdk:master' into JDK-8319662
 - Split up method awaitWork; other associated changes.
 - Merge branch 'openjdk:master' into JDK-8319662
 - tweak cascades; reinstate an @Contended; resolve JDK-8319498
 - Support cascading idle timeouts

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16725/files
  - new: https://git.openjdk.org/jdk/pull/16725/files/6f4b9bb3..980930c0

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

  Stats: 33384 lines in 815 files changed: 15447 ins; 14251 del; 3686 mod
  Patch: https://git.openjdk.org/jdk/pull/16725.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16725/head:pull/16725

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

From alanb at openjdk.org  Mon Dec  4 14:01:44 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 4 Dec 2023 14:01:44 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v3]
In-Reply-To: <7JHnl4QcbKEDH4V6rxX33WHoeTuyBGQG1z5a6jhNjjs=.45301468-a6c2-46bc-9c96-570ec8bdc887@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <vrdFV2cgL_pMuQWhcgLiV5STWcrxjahjiMq86qghuwM=.a2da54b7-0c22-4608-9857-d48bb207d7d4@github.com>
 <06dpAmRUHn4PyHDz2vZLZ9FyzF6u81qj_39hbqP7PnE=.2924f568-9021-46e7-b1fb-0c7a4d5f9c4d@github.com>
 <TRdmt9bEfMyCOTFYsvxvZSdfFPvnk0H_0SMPX5rqO0s=.028e96eb-52e0-4960-b955-1f12202978c9@github.com>
 <6IitbefHaaKPhCkB_FRZnBxTyZJi0i8jjh8Pr32jsb8=.956ea224-3aff-4c86-9e28-6399172bfc92@github.com>
 <NXUxb-lZvWnXhc0tuyHN4acnl24E0p6N9tjR6SRjocI=.feb4f5cc-b1ac-4b3f-bee2-c57e5fe101bf@github.com>
 <h3gsRz_Q935JguupcZqwssUazi6miz6k4RMFCULNPwg=.d1fe182b-1b04-4e19-803a-ce166ded27f4@github.com>
 <5PkUvozvjQnOZ40SBRcdabaHwJFhHPl0I5UniEE_C3s=.9269db2b-e3cc-4487-b540-b8f90cbe6df7@github.com>
 <7JHnl4QcbKEDH4V6rxX33WHoeTuyBGQG1z5a6jhNjjs=.45301468-a6c2-46bc-9c96-570ec8bdc887@github.com>
Message-ID: <0NmifS49RKzaRhohbMSEck5cW62UUnTTQGZc5L-2EL8=.1cba3343-1cab-4a31-873d-09356653391a@github.com>

On Mon, 4 Dec 2023 13:30:02 GMT, Vladimir Sitnikov <vsitnikov at openjdk.org> wrote:

> > it doesn't solve the second part of the concern which is read-only view on the internal buffer.
> 
> I think `ByteBuffer.asReadOnlyBuffer()` should resolve the issues regarding naked byte access. At least `ByteBuffer#array()` returns `null` for read-only buffers, and `ByteBuffer#hasArray()` returns `false`. Am I missing something?

The backing array is not frozen so a read-only view doesn't address the second part of the concern where the target keeps a reference.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1413912622

From vsitnikov at openjdk.org  Mon Dec  4 14:07:43 2023
From: vsitnikov at openjdk.org (Vladimir Sitnikov)
Date: Mon, 4 Dec 2023 14:07:43 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v3]
In-Reply-To: <0NmifS49RKzaRhohbMSEck5cW62UUnTTQGZc5L-2EL8=.1cba3343-1cab-4a31-873d-09356653391a@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <vrdFV2cgL_pMuQWhcgLiV5STWcrxjahjiMq86qghuwM=.a2da54b7-0c22-4608-9857-d48bb207d7d4@github.com>
 <06dpAmRUHn4PyHDz2vZLZ9FyzF6u81qj_39hbqP7PnE=.2924f568-9021-46e7-b1fb-0c7a4d5f9c4d@github.com>
 <TRdmt9bEfMyCOTFYsvxvZSdfFPvnk0H_0SMPX5rqO0s=.028e96eb-52e0-4960-b955-1f12202978c9@github.com>
 <6IitbefHaaKPhCkB_FRZnBxTyZJi0i8jjh8Pr32jsb8=.956ea224-3aff-4c86-9e28-6399172bfc92@github.com>
 <NXUxb-lZvWnXhc0tuyHN4acnl24E0p6N9tjR6SRjocI=.feb4f5cc-b1ac-4b3f-bee2-c57e5fe101bf@github.com>
 <h3gsRz_Q935JguupcZqwssUazi6miz6k4RMFCULNPwg=.d1fe182b-1b04-4e19-803a-ce166ded27f4@github.com>
 <5PkUvozvjQnOZ40SBRcdabaHwJFhHPl0I5UniEE_C3s=.9269db2b-e3cc-4487-b540-b8f90cbe6df7@github.com>
 <7JHnl4QcbKEDH4V6rxX33WHoeTuyBGQG1z5a6jhNjjs=.45301468-a6c2-46bc-9c96-570ec8bdc887@github.com>
 <0NmifS49RKzaRhohbMSEck5cW62UUnTTQGZc5L-2EL8=.1cba3343-1cab-4a31-873d-09356653391a@github.com>
Message-ID: <8Nndvje8ODVuIPgPEx9sqzj19OQNs18BGwTwtlSaMWQ=.c7f39ccd-6b12-4019-a212-8b3fc3e98df0@github.com>

On Mon, 4 Dec 2023 13:58:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>The backing array is not frozen so a read-only view doesn't address the second part of the concern where the target keeps a reference.

The users outside of OpenJDK would not have a reference to `byte[]`.
Do you mean a reference to `ByteBuffer`?
What if there was a `ByteBuffer#forbidReads()` method that would permanently forbid subsequent reads from the `ByteBuffer`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1413921224

From vklang at openjdk.org  Mon Dec  4 14:11:34 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 4 Dec 2023 14:11:34 GMT
Subject: RFR: 8321124: java/util/stream/GatherersTest.java times out [v3]
In-Reply-To: <NcgSgagzqKytU8dGSMKHUF_9ylICS5s6If5CoFRjPhw=.abef3a79-b429-47c5-b0b7-aa7b9f71ef31@github.com>
References: <NcgSgagzqKytU8dGSMKHUF_9ylICS5s6If5CoFRjPhw=.abef3a79-b429-47c5-b0b7-aa7b9f71ef31@github.com>
Message-ID: <jlIy7msHyO5ttShwChti6ymOVCAzFrab6fHv8iz69II=.4228032d-4795-490e-accd-ade7fbc68868@github.com>

> Renames GatherersTest to BuiltInGatherersTest for easier deduplication of GathererTest.
> 
> Fixes a test ordering issue in testMapConcurrentAPIandContract().
> 
> Adding increased maxOutputSize for Gatherer-related tests to improve debuggability.
> 
> Lowering the composition threshold of GathererTest.testMassivelyComposedGatherers to 256 to avoid SOE on low-specc:ed machines.

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

  Maintainability, correctness, and stability overhaul of Gatherers tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16928/files
  - new: https://git.openjdk.org/jdk/pull/16928/files/a4ab3469..59b82f38

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

  Stats: 1143 lines in 6 files changed: 750 ins; 393 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16928.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16928/head:pull/16928

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

From vklang at openjdk.org  Mon Dec  4 14:20:43 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 4 Dec 2023 14:20:43 GMT
Subject: RFR: 8321124: java/util/stream/GatherersTest.java times out [v3]
In-Reply-To: <jlIy7msHyO5ttShwChti6ymOVCAzFrab6fHv8iz69II=.4228032d-4795-490e-accd-ade7fbc68868@github.com>
References: <NcgSgagzqKytU8dGSMKHUF_9ylICS5s6If5CoFRjPhw=.abef3a79-b429-47c5-b0b7-aa7b9f71ef31@github.com>
 <jlIy7msHyO5ttShwChti6ymOVCAzFrab6fHv8iz69II=.4228032d-4795-490e-accd-ade7fbc68868@github.com>
Message-ID: <-jdU8vGyUllVaS-34x-pRzNYlfWrIG1VJw7TfsH3LTE=.da7da7b9-fde6-408c-84a1-f4078eabe40a@github.com>

On Mon, 4 Dec 2023 14:11:34 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Splits GatherersTest out to distinct files per built-in gatherer
>> 
>> Fixes a test ordering issue for mapConcurrent which placed GatherersTest on the ProblemList.
>> 
>> Adding increased maxOutputSize for Gatherer-related tests to improve debuggability.
>> 
>> Lowering the composition threshold of GathererTest.testMassivelyComposedGatherers to 256 to avoid SOE on low-specc:ed machines.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Maintainability, correctness, and stability overhaul of Gatherers tests

test/jdk/java/util/stream/GatherersFoldTest.java line 81:

> 79:             config.stream()
> 80:                     .sequential()
> 81:                     .reduce(0L, (acc, next) -> acc + next,(l, r) -> {

Modified this test to accumulate to a Long instead of appending to a String to reduce the allocation overhead of the test case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16928#discussion_r1413938440

From vklang at openjdk.org  Mon Dec  4 14:25:05 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 4 Dec 2023 14:25:05 GMT
Subject: RFR: 8321124: java/util/stream/GatherersTest.java times out [v4]
In-Reply-To: <NcgSgagzqKytU8dGSMKHUF_9ylICS5s6If5CoFRjPhw=.abef3a79-b429-47c5-b0b7-aa7b9f71ef31@github.com>
References: <NcgSgagzqKytU8dGSMKHUF_9ylICS5s6If5CoFRjPhw=.abef3a79-b429-47c5-b0b7-aa7b9f71ef31@github.com>
Message-ID: <fZlWSWZOW3WxqXnYmDQ0q2WiRpgoc9BpEHNaKKO30yQ=.2b66f9e5-cdcb-4054-91a0-f22a4b267c47@github.com>

> Splits GatherersTest out to distinct files per built-in gatherer
> 
> Fixes a test ordering issue for mapConcurrent which placed GatherersTest on the ProblemList.
> 
> Adding increased maxOutputSize for Gatherer-related tests to improve debuggability.
> 
> Lowering the composition threshold of GathererTest.testMassivelyComposedGatherers to 256 to avoid SOE on low-specc:ed machines.

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

  Removing extraneous built-in gatherer test output

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16928/files
  - new: https://git.openjdk.org/jdk/pull/16928/files/59b82f38..fd426ae7

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

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

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

From jvernee at openjdk.org  Mon Dec  4 14:52:43 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 4 Dec 2023 14:52:43 GMT
Subject: RFR: 8316641: VarHandle template classes can share code in the
 base class [v8]
In-Reply-To: <1GUypj2LaeTALx4trbeWcbY8JsAZFcx04hX1Mxp_Da8=.c6b9142c-5544-40b9-a7b5-5c0ac95976e7@github.com>
References: <AKBd8KmVCUr_J-aImmR3SV3YTRM1JjEm8RKNdNwsjf0=.7363b031-ad71-4ae4-a949-f58a75e28385@github.com>
 <1GUypj2LaeTALx4trbeWcbY8JsAZFcx04hX1Mxp_Da8=.c6b9142c-5544-40b9-a7b5-5c0ac95976e7@github.com>
Message-ID: <bSJe_GBS-EaGxf43TsXHPZnF8Bp6Wlu64hPz54PzcVY=.da275d44-f268-4857-a939-eddc9fe6d7d6@github.com>

On Mon, 6 Nov 2023 08:19:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> VarHandle implementations have many static fields and methods that can be pulled to the common superclass to avoid repeated initialization and code duplication.
>> 
>> In addition, the Unsafe-based Buffer field access are replaced by usage of public methods or JavaNioAccess.
>
> Chen Liang 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' of https://github.com/openjdk/jdk into cleanup/vh-template-share
>  - 8316641: VarHandle template classes can share code in the base class

Sorry, this fell off my radar.

src/java.base/share/classes/java/lang/invoke/X-VarHandleByteArrayView.java.template line 594:

> 592:         @ForceInline
> 593:         static int indexRO(ByteBuffer bb, int index) {
> 594:             if (bb.isReadOnly())

I have to think that there was a reason for using unsafe access in the current code. So, I'm not sure if it's safe to switch this to a direct method/field reference.

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

PR Review: https://git.openjdk.org/jdk/pull/15854#pullrequestreview-1762626598
PR Review Comment: https://git.openjdk.org/jdk/pull/15854#discussion_r1414012311

From jvernee at openjdk.org  Mon Dec  4 15:01:52 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 4 Dec 2023 15:01:52 GMT
Subject: RFR: 8316641: VarHandle template classes can share code in the
 base class [v8]
In-Reply-To: <bSJe_GBS-EaGxf43TsXHPZnF8Bp6Wlu64hPz54PzcVY=.da275d44-f268-4857-a939-eddc9fe6d7d6@github.com>
References: <AKBd8KmVCUr_J-aImmR3SV3YTRM1JjEm8RKNdNwsjf0=.7363b031-ad71-4ae4-a949-f58a75e28385@github.com>
 <1GUypj2LaeTALx4trbeWcbY8JsAZFcx04hX1Mxp_Da8=.c6b9142c-5544-40b9-a7b5-5c0ac95976e7@github.com>
 <bSJe_GBS-EaGxf43TsXHPZnF8Bp6Wlu64hPz54PzcVY=.da275d44-f268-4857-a939-eddc9fe6d7d6@github.com>
Message-ID: <GKPm9nsjPrSdP-hLCe_dDqKspLwKdwihMVIkHBTiiVw=.4364d5aa-b1c1-40bb-8989-2fc0dba7d517@github.com>

On Mon, 4 Dec 2023 14:49:39 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Chen Liang 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' of https://github.com/openjdk/jdk into cleanup/vh-template-share
>>  - 8316641: VarHandle template classes can share code in the base class
>
> src/java.base/share/classes/java/lang/invoke/X-VarHandleByteArrayView.java.template line 594:
> 
>> 592:         @ForceInline
>> 593:         static int indexRO(ByteBuffer bb, int index) {
>> 594:             if (bb.isReadOnly())
> 
> I have to think that there was a reason for using unsafe access in the current code. So, I'm not sure if it's safe to switch this to a direct method/field reference.

@PaulSandoz Do you remember the history here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15854#discussion_r1414026084

From jvernee at openjdk.org  Mon Dec  4 15:05:48 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 4 Dec 2023 15:05:48 GMT
Subject: RFR: 8321159: SymbolLookup.libraryLookup(Path,
 Arena) Assumes default Filesystem [v3]
In-Reply-To: <35Iwd7GHRGThxnsiWDmsvS9f0z2duLDpS_V70htRysA=.dd1b7024-aae6-47eb-ad17-3f1057b89bde@github.com>
References: <sbkQW1a7NByueXA7Vm_JVE06P3queX4AkDE-rlFFbgg=.35168862-4033-4184-97c8-86ab21da922e@github.com>
 <35Iwd7GHRGThxnsiWDmsvS9f0z2duLDpS_V70htRysA=.dd1b7024-aae6-47eb-ad17-3f1057b89bde@github.com>
Message-ID: <_WRQTB3S3tDeV4X1AFhFxifZg98D1UjHmrHBuKx-i_I=.b960c1c2-59fe-4351-88c4-79f85c0d9c76@github.com>

On Mon, 4 Dec 2023 09:10:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to reject paths provided to the `SymbolLookup.libraryLookup(Path path, Arena arena)` method if a path is not in the default file system.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add fail statement

src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 288:

> 286:      *         is called from a thread {@code T}, other than the arena's owner thread
> 287:      * @throws IllegalArgumentException if {@code path} is not in the default file system
> 288:      *         or if {@code path} does not point to a valid library

Please split this into separate `@throws IllegalArgumentException` tags, as that is what we do everywhere else in the FFM API.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16944#discussion_r1414029801

From liach at openjdk.org  Mon Dec  4 15:23:07 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 4 Dec 2023 15:23:07 GMT
Subject: RFR: 8319463: ClassSignature should have superclass and
 superinterfaces as ClassTypeSig [v2]
In-Reply-To: <2MCObzp9MbPwugbIm1pP80wU0OXlmrQMr7CRsgxah7s=.78d4b9a3-9f19-4bcf-ad03-58fb6faa64fb@github.com>
References: <2MCObzp9MbPwugbIm1pP80wU0OXlmrQMr7CRsgxah7s=.78d4b9a3-9f19-4bcf-ad03-58fb6faa64fb@github.com>
Message-ID: <Oe3nr5ldhn0dvhgUK80Q-Y1oQqjNY3yFlV_OIUIcAd4=.93bf26b1-e469-42f5-99e7-1eb3a26e6bf1@github.com>

> Discovered while writing a test for #16513 that `ClassSignature.superclassSignature()` does not return a `ClassTypeSig`, yet [JVM Spec](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html#jvms-4.7.9.1-4100) requires it to be one. This patch adds such a requirement to the accessors, factories, and the parsing logic.

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

 - Merge branch 'master' into feature/class-signature-elements
 - 8319463: ClassSignature should have superclass and superinterfaces as ClassTypeSig

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16514/files
  - new: https://git.openjdk.org/jdk/pull/16514/files/77464793..3db563c6

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

  Stats: 718541 lines in 3208 files changed: 139028 ins; 508573 del; 70940 mod
  Patch: https://git.openjdk.org/jdk/pull/16514.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16514/head:pull/16514

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

From alanb at openjdk.org  Mon Dec  4 16:00:39 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 4 Dec 2023 16:00:39 GMT
Subject: RFR: 8321159: SymbolLookup.libraryLookup(Path,
 Arena) Assumes default Filesystem [v3]
In-Reply-To: <_WRQTB3S3tDeV4X1AFhFxifZg98D1UjHmrHBuKx-i_I=.b960c1c2-59fe-4351-88c4-79f85c0d9c76@github.com>
References: <sbkQW1a7NByueXA7Vm_JVE06P3queX4AkDE-rlFFbgg=.35168862-4033-4184-97c8-86ab21da922e@github.com>
 <35Iwd7GHRGThxnsiWDmsvS9f0z2duLDpS_V70htRysA=.dd1b7024-aae6-47eb-ad17-3f1057b89bde@github.com>
 <_WRQTB3S3tDeV4X1AFhFxifZg98D1UjHmrHBuKx-i_I=.b960c1c2-59fe-4351-88c4-79f85c0d9c76@github.com>
Message-ID: <Whgmumaei8CYamFhF1MPU65utDW1IAtxMDarZKUc0u0=.f6c23137-ba90-4623-88a1-7204bc36b9a9@github.com>

On Mon, 4 Dec 2023 15:00:56 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add fail statement
>
> src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 288:
> 
>> 286:      *         is called from a thread {@code T}, other than the arena's owner thread
>> 287:      * @throws IllegalArgumentException if {@code path} is not in the default file system
>> 288:      *         or if {@code path} does not point to a valid library
> 
> Please split this into separate `@throws IllegalArgumentException` tags, as that is what we do everywhere else in the FFM API.

It depends on the wording. If changed to something like "not a path to a valid library in the default file system" then it avoid describing it as two cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16944#discussion_r1414118698

From jlahoda at openjdk.org  Mon Dec  4 16:40:41 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 4 Dec 2023 16:40:41 GMT
Subject: RFR: 8321131: Console read line with zero out should zero out
 underlying buffer in JLine [v3]
In-Reply-To: <Bo0RreJ7-KY0CGwLMwNhl1bpwO78k91eziGVWS4hvRc=.d64cf82e-9546-40a8-8267-c0320f8afabc@github.com>
References: <PzHZPvbxGMfURD7JoaIocGRD8gkyJFh-i0oPeMx9zdc=.df1f2a34-527d-4e4a-b468-ddb51ad2d330@github.com>
 <Bo0RreJ7-KY0CGwLMwNhl1bpwO78k91eziGVWS4hvRc=.d64cf82e-9546-40a8-8267-c0320f8afabc@github.com>
Message-ID: <UuFWXAKhGQ00LpcY0j71b-psUDdUStsCpsfxmxibZyA=.5a3303c1-a3a0-43c7-bac2-66230e04e27a@github.com>

On Sat, 2 Dec 2023 21:57:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is the fix to JLine, which makes it on par with the built-in Console fix ([JDK-8320798](https://bugs.openjdk.org/browse/JDK-8320798)).
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unnecessary modification in LineReader

Looks OK to me, thanks!

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16930#pullrequestreview-1762903500

From duke at openjdk.org  Mon Dec  4 16:45:06 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 4 Dec 2023 16:45:06 GMT
Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to
 ZipEntry.externalAttributes
Message-ID: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>

Please consider this PR which suggests we rename `ZipEntry.extraAttributes` to `ZipEntry.externalAttributes`.

This field was introduced in [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under the name `ZipEntry.posixPerms`. [JDK-8250968](https://bugs.openjdk.org/browse/JDK-8250968) later renamed the field to `ZipEntry.extraAttributes` and extended its semantics to hold the full two-byte value of the `external file attributes` field, as defined by `APPNOTE.TXT`

The name `extraAttributes` is misleading. It has nothing to do with the `extra field` (an unrelated structure defined in `APPNOTE.TXT`), although the name indicates it does.

To prevent confusion and make life easier for future maintainers, I suggest we rename this field to `ZipEntry.externalAttributes` and update related methods, parameters and comments accordingly.

While this change is a straightforward renaming, reviewers should consider whether it carries its weight, especially considering it might complicate future backports. 

As a note to reviewers, this PR includes the following intended updates:

- Rename `ZipEntry.extraAttributes` and any references to this field to `ZipEntry.externalAttributes`
- Update `JavaUtilZipFileAccess` to similarly rename methods to `setExternalAttributes` and `getExternalAttributes` 
- Rename the field `JarSigner.extraAttrsDetected` to `JarSigner.externalAttrsDetected`
- Rename a local variable in `JarSigner.writeEntry` to `externalAttrs`
- Rename `s.s.t.jarsigner.Main.extraAttrsDetected` to `externalAttrsDetected`
- Rename resource string key names in `s.s.t.jarsigner.Resources` from `extra.attributes.detected` to `external.attributes.detected`
- Rename method `SymlinkTest.verifyExtraAttrs` to `verifyExternalAttrs`, also updated two references to 'extra attributes' in this method
- Updated copyright in all affected files

If the resource file changes should be dropped and instead handled via `msgdop` updates, let me know and I can revert the non-default files.

I did a search across the code base to find 'extraAttrs', 'extra.attr' after these updates, and found nothing related to zip/jar. The `zip` and `jar` tests run clean:


make test TEST="test/jdk/java/util/jar"
make test TEST="test/jdk/java/util/zip"

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

Commit messages:
 - Rename ZipEntry.extraAttributes to ZipEntry.externalAttributes

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

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

From psandoz at openjdk.org  Mon Dec  4 16:53:44 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 4 Dec 2023 16:53:44 GMT
Subject: RFR: 8316641: VarHandle template classes can share code in the
 base class [v8]
In-Reply-To: <GKPm9nsjPrSdP-hLCe_dDqKspLwKdwihMVIkHBTiiVw=.4364d5aa-b1c1-40bb-8989-2fc0dba7d517@github.com>
References: <AKBd8KmVCUr_J-aImmR3SV3YTRM1JjEm8RKNdNwsjf0=.7363b031-ad71-4ae4-a949-f58a75e28385@github.com>
 <1GUypj2LaeTALx4trbeWcbY8JsAZFcx04hX1Mxp_Da8=.c6b9142c-5544-40b9-a7b5-5c0ac95976e7@github.com>
 <bSJe_GBS-EaGxf43TsXHPZnF8Bp6Wlu64hPz54PzcVY=.da275d44-f268-4857-a939-eddc9fe6d7d6@github.com>
 <GKPm9nsjPrSdP-hLCe_dDqKspLwKdwihMVIkHBTiiVw=.4364d5aa-b1c1-40bb-8989-2fc0dba7d517@github.com>
Message-ID: <y747Fdc0Bn4zXQ9y84ByjI6t7dpoOUKREXyw4WtoL9s=.b605555a-9f19-46b2-97ac-ed68f97ee329@github.com>

On Mon, 4 Dec 2023 14:58:34 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/X-VarHandleByteArrayView.java.template line 594:
>> 
>>> 592:         @ForceInline
>>> 593:         static int indexRO(ByteBuffer bb, int index) {
>>> 594:             if (bb.isReadOnly())
>> 
>> I have to think that there was a reason for using unsafe access in the current code. So, I'm not sure if it's safe to switch this to a direct method/field reference.
>
> @PaulSandoz Do you remember the history here?

I don't recall exactly but the unsafe usage is likely to avoid possible profile pollution due to the abstract method call.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15854#discussion_r1414197423

From never at openjdk.org  Mon Dec  4 17:52:56 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Mon, 4 Dec 2023 17:52:56 GMT
Subject: RFR: 8320198: some reference processing tests don't wait long enough
 for reference processing to complete
Message-ID: <8Gi1trYkUo7x5YiAURAeH3TdzpoJchvmrHyIm2WCHKk=.18df4d76-6ad9-40f9-a079-f271b5cd7272@github.com>

This slightly increases the wait for reference processing to complete to accommodate long Xcomp compile times.  Testing is underway.

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

Commit messages:
 - 8320198: some reference processing tests don't wait long enough for reference processing to complete

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

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

From lancea at openjdk.org  Mon Dec  4 18:12:37 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 4 Dec 2023 18:12:37 GMT
Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to
 ZipEntry.externalAttributes
In-Reply-To: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
Message-ID: <iC_hrsb4vkAHABDKAgx-wVtTEIWmwlUoUmFmnQ7vvWs=.3e9c1400-a461-4184-b5b6-a2f9675b0ae1@github.com>

On Mon, 4 Dec 2023 15:34:34 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Please consider this PR which suggests we rename `ZipEntry.extraAttributes` to `ZipEntry.externalAttributes`.
> 
> This field was introduced in [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under the name `ZipEntry.posixPerms`. [JDK-8250968](https://bugs.openjdk.org/browse/JDK-8250968) later renamed the field to `ZipEntry.extraAttributes` and extended its semantics to hold the full two-byte value of the `external file attributes` field, as defined by `APPNOTE.TXT`
> 
> The name `extraAttributes` is misleading. It has nothing to do with the `extra field` (an unrelated structure defined in `APPNOTE.TXT`), although the name indicates it does.
> 
> To prevent confusion and make life easier for future maintainers, I suggest we rename this field to `ZipEntry.externalAttributes` and update related methods, parameters and comments accordingly.
> 
> While this change is a straightforward renaming, reviewers should consider whether it carries its weight, especially considering it might complicate future backports. 
> 
> As a note to reviewers, this PR includes the following intended updates:
> 
> - Rename `ZipEntry.extraAttributes` and any references to this field to `ZipEntry.externalAttributes`
> - Update `JavaUtilZipFileAccess` to similarly rename methods to `setExternalAttributes` and `getExternalAttributes` 
> - Rename the field `JarSigner.extraAttrsDetected` to `JarSigner.externalAttrsDetected`
> - Rename a local variable in `JarSigner.writeEntry` to `externalAttrs`
> - Rename `s.s.t.jarsigner.Main.extraAttrsDetected` to `externalAttrsDetected`
> - Rename resource string key names in `s.s.t.jarsigner.Resources` from `extra.attributes.detected` to `external.attributes.detected`
> - Rename method `SymlinkTest.verifyExtraAttrs` to `verifyExternalAttrs`, also updated two references to 'extra attributes' in this method
> - Updated copyright in all affected files
> 
> If the resource file changes should be dropped and instead handled via `msgdop` updates, let me know and I can revert the non-default files.
> 
> I did a search across the code base to find 'extraAttrs', 'extra.attr' after these updates, and found nothing related to zip/jar. The `zip` and `jar` tests run clean:
> 
> 
> make test TEST="test/jdk/java/util/jar"
> make test TEST="test/jdk/java/util/zip"

Thank you for the contribution Eirik.  I will take a peek at this once we are able to push changes for JDK 23

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

PR Comment: https://git.openjdk.org/jdk/pull/16952#issuecomment-1839198963

From rriggs at openjdk.org  Mon Dec  4 18:31:59 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 4 Dec 2023 18:31:59 GMT
Subject: Integrated: 8311906: Improve robustness of String constructors with
 mutable array inputs
In-Reply-To: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com>
References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com>
Message-ID: <yc62-KsUaeWt7igdNBAXUb7ysUWZQtkqfV8LbaK0JEM=.ec79e6cd-a36e-465c-a526-530ce77deea3@github.com>

On Mon, 30 Oct 2023 18:34:44 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers.
> The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. 
> 
> The changes include:
> 
> - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate 
>   if the input array is modified before the constructor returns. 
>   The resulting string may contain any combination of characters sampled from the input array.
> 
> - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character.
>   For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged.
>   If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index.
>   If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect.
>   Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided.
>   Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned.
> 
> - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character.
> 
> - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction.

This pull request has now been integrated.

Changeset: 155abc57
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/155abc576a0212932825485380d4e2a9c7dd2fdc
Stats:     1415 lines in 15 files changed: 1162 ins; 110 del; 143 mod

8311906: Improve robustness of String constructors with mutable array inputs

Co-authored-by: Damon Fenacci <dfenacci at openjdk.org>
Co-authored-by: Claes Redestad <redestad at openjdk.org>
Co-authored-by: Amit Kumar <amitkumar at openjdk.org>
Co-authored-by: Martin Doerr <mdoerr at openjdk.org>
Reviewed-by: rgiulietti, thartmann, redestad, dfenacci

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

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

From naoto at openjdk.org  Mon Dec  4 19:05:54 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 4 Dec 2023 19:05:54 GMT
Subject: RFR: 8321131: Console read line with zero out should zero out
 underlying buffer in JLine [v3]
In-Reply-To: <Bo0RreJ7-KY0CGwLMwNhl1bpwO78k91eziGVWS4hvRc=.d64cf82e-9546-40a8-8267-c0320f8afabc@github.com>
References: <PzHZPvbxGMfURD7JoaIocGRD8gkyJFh-i0oPeMx9zdc=.df1f2a34-527d-4e4a-b468-ddb51ad2d330@github.com>
 <Bo0RreJ7-KY0CGwLMwNhl1bpwO78k91eziGVWS4hvRc=.d64cf82e-9546-40a8-8267-c0320f8afabc@github.com>
Message-ID: <0aL0l7SK2ZpxT9fQKsjC6MYrp5SndBIGKeDi_TlcirA=.355a6183-128a-4796-8c9d-35af8ee019db@github.com>

On Sat, 2 Dec 2023 21:57:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is the fix to JLine, which makes it on par with the built-in Console fix ([JDK-8320798](https://bugs.openjdk.org/browse/JDK-8320798)).
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unnecessary modification in LineReader

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/16930#issuecomment-1839281180

From sgehwolf at openjdk.org  Mon Dec  4 19:09:02 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 4 Dec 2023 19:09:02 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v10]
In-Reply-To: <gj2_DSig2sSAd7xph6imvIdcEyJrR_JgPDeYwV8fTv4=.782f256d-6265-4926-8c4f-aeb4c0e93007@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <SDcwfk1zKIk2TowVOL42C7LM8SfFraZiP5gKNLYxnpI=.bfdaed15-bdbf-4f65-8760-145f58e4513e@github.com>
 <gj2_DSig2sSAd7xph6imvIdcEyJrR_JgPDeYwV8fTv4=.782f256d-6265-4926-8c4f-aeb4c0e93007@github.com>
Message-ID: <pnxLGNmdUMGwEBXx70VSHuxXRrTjIO3Whjup9sa6Eag=.09d63243-7535-41fd-985d-339dfac3bb3b@github.com>

On Tue, 28 Nov 2023 21:46:58 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tighten ModifiedFilesExitTest
>>   
>>   Ensure the error message is reasonable and doesn't include
>>   Exceptions presented to the user.
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/AddRunImageResourcesPlugin.java line 67:
> 
>> 65:     // RunImageArchive for further processing.
>> 66:     private static final String RESPATH = RESPATH_PREFIX + "%s_resources";
>> 67:     private static final String JLINK_MOD_NAME = "jdk.jlink";
> 
> There are 2 other occurrences of "jdk.jlink".  I guess you plan to replace them with the constant variable?

I think I've replaced them in the latest update.

> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/AddRunImageResourcesPlugin.java line 116:
> 
>> 114:         if (platform == null) {
>> 115:             throw new IllegalStateException("java.base not part of the image?");
>> 116:         }
> 
> Can simply use `orElseThrow`.  It should not reach here and so it's ok to use InternalError or AssertionError (which is also used in this code).
> 
> Suggestion:
> 
>         String platform = in.moduleView().findModule("java.base")
>                 .map(ResourcePoolModule::targetPlatform)
>                 .orElseThrow(() -> new AssertionError("java.base not found"));

Done.

> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/AddRunImageResourcesPlugin.java line 121:
> 
>> 119: 
>> 120:     private void addModuleResourceEntries(ResourcePoolBuilder out) {
>> 121:         for (String module: keysInSortedOrder()) {
> 
> Suggestion:
> 
>               nonClassResEntries.keySet().stream().sorted().forEach(module -> {
> 
> 
> `keysInSortedOrder` can be removed.

removed.

> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/AddRunImageResourcesPlugin.java line 126:
> 
>> 124:             if (mResources == null) {
>> 125:                 throw new AssertionError("Module listed, but no resources?");
>> 126:             }
> 
> Since it is always non-null, this check can be dropped.  NPE will be thrown if such bug exists.

I've replaced this with `Object.requireNonNull()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1414357943
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1414358486
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1414359291
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1414359118

From sgehwolf at openjdk.org  Mon Dec  4 19:15:36 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 4 Dec 2023 19:15:36 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v10]
In-Reply-To: <gj2_DSig2sSAd7xph6imvIdcEyJrR_JgPDeYwV8fTv4=.782f256d-6265-4926-8c4f-aeb4c0e93007@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <SDcwfk1zKIk2TowVOL42C7LM8SfFraZiP5gKNLYxnpI=.bfdaed15-bdbf-4f65-8760-145f58e4513e@github.com>
 <gj2_DSig2sSAd7xph6imvIdcEyJrR_JgPDeYwV8fTv4=.782f256d-6265-4926-8c4f-aeb4c0e93007@github.com>
Message-ID: <_j1pIddtLHxwbcoLrnGcoz-bdviFzcz1CvUTimPB_bs=.6ea95b1f-be5d-4f5e-ad9f-bd64c2532c96@github.com>

On Tue, 28 Nov 2023 23:16:07 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tighten ModifiedFilesExitTest
>>   
>>   Ensure the error message is reasonable and doesn't include
>>   Exceptions presented to the user.
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java line 452:
> 
>> 450:                 String addOptionsGlob = "glob:" + AddOptionsPlugin.OPTS_FILE;
>> 451:                 String saveJlinkOptsGlob = "glob:/jdk.jlink/" + JlinkTask.OPTIONS_RESOURCE;
>> 452:                 String additionalPatterns = systemModulesPattern + "," +
> 
> Suggest to have each plugin to define `Plugin::excludeResourcesPattern` to return a non-empty string if linking from the run-time image.  Construct this pattern using the API.

OK. Each plugin returns the pattern it needs to exclude now.

> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java line 475:
> 
>> 473:                 // SystemModulesMap class isn't guaranteed to be correct for the
>> 474:                 // current module set.
>> 475:                 if (systemModulesPlugin == null) {
> 
> Suggest to fail if system modules plugin does not exist which should not happen.  The `disableFastPath` system property was added for testing only.

OK. `--disable-plugin system-modules` no longer allowed for run-time image links.

> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/AddRunImageResourcesPlugin.java line 56:
> 
>> 54:  * resources. Needed for the the run-time image based jlink.
>> 55:  */
>> 56: public final class AddRunImageResourcesPlugin extends AbstractPlugin {
> 
> This resource file is generated if jdk.jlink is linked in the resulting image.   Maybe this plugin can be named `GenerateJlinkResourcesListPlugin` or `JlinkResourcesListPlugin`???

I went with `JlinkResourcesListPlugin`.

> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/AddRunImageResourcesPlugin.java line 184:
> 
>> 182:         } catch (RunImageLinkException e) {
>> 183:             // RunImageArchive::RunImageFile.content() may throw this when
>> 184:             // getting the content(). Propagate this specific exeption.
> 
> Suggestion:
> 
>             // getting the content(). Propagate this specific exception.

Should be fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1414364516
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1414365118
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1414363725
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1414363091

From naoto at openjdk.org  Mon Dec  4 19:16:22 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 4 Dec 2023 19:16:22 GMT
Subject: Integrated: 8321131: Console read line with zero out should zero out
 underlying buffer in JLine
In-Reply-To: <PzHZPvbxGMfURD7JoaIocGRD8gkyJFh-i0oPeMx9zdc=.df1f2a34-527d-4e4a-b468-ddb51ad2d330@github.com>
References: <PzHZPvbxGMfURD7JoaIocGRD8gkyJFh-i0oPeMx9zdc=.df1f2a34-527d-4e4a-b468-ddb51ad2d330@github.com>
Message-ID: <74xCt0q64O6KJf-zVhW6DqqLtjNKrOiAA53cxsAqI4w=.508eec57-c297-4dec-a545-65f279641943@github.com>

On Fri, 1 Dec 2023 18:24:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is the fix to JLine, which makes it on par with the built-in Console fix ([JDK-8320798](https://bugs.openjdk.org/browse/JDK-8320798)).

This pull request has now been integrated.

Changeset: bd04f91e
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bd04f91e9103ee04f643f8d04553705c4d78fda3
Stats:     19 lines in 3 files changed: 16 ins; 3 del; 0 mod

8321131: Console read line with zero out should zero out underlying buffer in JLine

Reviewed-by: iris, alanb, jlahoda

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

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

From alanb at openjdk.org  Mon Dec  4 19:27:59 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 4 Dec 2023 19:27:59 GMT
Subject: RFR: 8321270: Virtual Thread.yield consumes parking permit
Message-ID: <lO0N190PTq5-xjJV0LlgHWm8srDw2K8aC_U0E5qf4gA=.057efa94-6e79-4c76-9273-32ca1449bf84@github.com>

When a virtual thread continues after Thread.yield it currently consumes thread's parking permit. This is an oversight, the parking permit should only be consumed when continuing after park.

The changes are straight-forward. The internal "RUNNABLE" state is replaced with UNPARKED and YIELDED state, effectively encoding the previous state. So for the most part, it's just replacing the usages of RUNNABLE. The additional states require refactoring tryGetStackTrace, this is the method that is used for Thread::getStackTrace when the virtual thread is unmounted. It is also changed to not not swallow the REE if the reesubmit fails (tryStackTrace has to resubmit as the task for the thread may run, or the thread unparked, while "suspended" and sampling its stack trace). The changes are a subset of larger changes in the loom repo, future PRs will propose to bring in other changes to get main line up to date.

For testing the existing ThreadAPI has new test cases.

Testing: test1-5. This includes the JVMTI tests as it maps the thread states to JVMTI thread states.

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

Commit messages:
 - Leave onPinned to another PR
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/16953/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16953&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321270
  Stats: 150 lines in 4 files changed: 79 ins; 19 del; 52 mod
  Patch: https://git.openjdk.org/jdk/pull/16953.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16953/head:pull/16953

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

From bpb at openjdk.org  Mon Dec  4 19:28:53 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 4 Dec 2023 19:28:53 GMT
Subject: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter
 of transferTo() is trusted [v3]
In-Reply-To: <zRINQ_LiJh7Ifnt7UwL2Q0PcpestYwzx74fopLor_2w=.c93f3a3a-8172-40d2-9e5d-0530eb905f2a@github.com>
References: <zRINQ_LiJh7Ifnt7UwL2Q0PcpestYwzx74fopLor_2w=.c93f3a3a-8172-40d2-9e5d-0530eb905f2a@github.com>
Message-ID: <noH8h0XHDsVq_cvVqWGO47j4nJni7tN5EVHASW6n0qQ=.4d85e3a5-606d-4f3c-a7bf-ed1a04ebe47d@github.com>

> Pass `ByteArrayInputStream.buf ` directly to the `OutputStream` parameter of `BAIS.transferTo` only if the target stream is in the `java.io` package.

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

  8321053: Constrain trusted OutputStreams to a limited set

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16893/files
  - new: https://git.openjdk.org/jdk/pull/16893/files/176d5165..29ee889b

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

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

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

From bpb at openjdk.org  Mon Dec  4 19:28:55 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 4 Dec 2023 19:28:55 GMT
Subject: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter
 of transferTo() is trusted [v3]
In-Reply-To: <13AK-_SxIYyOMx7xYHHU4p21Mg-aXN0p7aTMrIgeRZY=.e5956bf4-4c84-4476-8d40-66753d80b6c0@github.com>
References: <zRINQ_LiJh7Ifnt7UwL2Q0PcpestYwzx74fopLor_2w=.c93f3a3a-8172-40d2-9e5d-0530eb905f2a@github.com>
 <qvDeG-fdlsLWk-rEcZHRMA3Mv0hJag2hvJlHqu4Y-yo=.3b0e1f6f-b69d-4471-909a-9d4dd45618b1@github.com>
 <KbgvHJmxFxcJSCf2iOvYxblmTvg8RDV1QtqhylX-bHo=.fe8878ab-7b19-4e72-81f3-d6a65965fa1b@github.com>
 <qzx0Xi4T398BV7qeBj6bLS-R7LcLA8JE-gMwxuD3lcI=.5d447f3b-328e-40df-b823-4a74eec3f1a4@github.com>
 <eyFDDWXEomWObizhgeIormpHtFAXmTrXbWkMOxK2ML4=.a3d6ca9d-5b73-456c-b997-78bc5894c136@github.com>
 <EC7_LI524HAiIY3cDlcVmoqKY4H4eMy7shWEyDU-td8=.b2f87afe-9d6b-41ab-9145-858f4deded60@github.com>
 <jQBQyMguCr22Ihi66y1Ub4pbCBVgYzDMqaPkj_FvIFM=.4ad14e27-50ff-4621-91cf-bfbf9cf726b9@github.com>
 <r8PlLlJcB6KEF9fgGlrTYdRiUY6Ou5Q8klgZY2AQ49E=.7d4ee021-4138-4ca7-a116-db292a82934b@github.com>
 <T_XBQt0hI4kkK17LyLZUqE_60xDv5p0z3XZLW9LlvX0=.bc93c90f-284c-426d-85f1-57387a4b0a71@github.com>
 <13QWO-amjHOw9pd7mM_jU0iRS4QR5_KFo-BFNuv-l-U=.226d2e4c-1757-44e5-824d-2d120fc26937@github.com>
 <13AK-_SxIYyOMx7xYHHU4p21Mg-aXN0p7aT
 MrIgeRZY=.e5956bf4-4c84-4476-8d40-66753d80b6c0@github.com>
Message-ID: <KdrSeyXLyQ1FB-lJfjgB5xm3x1MvHzR9EQUNdQk7GcE=.73644c21-a233-428b-aed1-785eeec3c2a7@github.com>

On Sat, 2 Dec 2023 03:48:46 GMT, jmehrens <duke at openjdk.org> wrote:

>> I think that a sufficiently future-proof deny list could be had by changing
>> 
>> 211             if (out.getClass().getPackageName().startsWith("java.") &&
>> 
>> back to
>> 
>> 211             if ("java.io".equals(out.getClass().getPackageName()) &&
>> 
>> That would for example dispense with the problematic `Channels.newOutputStream(AynsynchronousByteChannel)` case:
>> 
>> jshell> AsynchronousSocketChannel asc = AsynchronousSocketChannel.open()
>> asc ==> sun.nio.ch.UnixAsynchronousSocketChannelImpl[unconnected]
>> 
>> jshell> OutputStream out = Channels.newOutputStream(asc)
>> out ==> java.nio.channels.Channels$2 at 58c1670b
>> 
>> jshell> Class outClass = out.getClass()
>> outClass ==> class java.nio.channels.Channels$2
>> 
>> jshell> outClass.getPackageName()
>> $5 ==> "java.nio.channels"
>
> Even if scope is limited to `java.io` you have deal with FilterOutputStream and ObjectOutputStream.  I still haven't done a complete search so there could be other adapters I've yet to review.
> 
> Thinking of a different approach, what if ByteArrayInputStream actually recorded and used `readlimit` of the `mark` method?  This allows us to safely leak or poison 'this.data' because once transferTo is called we safely change owner of the byte array if we know this stream is allowed to forget it existed.  Effectively you could do optimizations like this (didn't test or compile this):
> 
> 
> public synchronized long transferTo(OutputStream out) throws IOException {
>      int len = count - pos;
>      if (len > 0) {
>          byte[] data = this.data;
>          byte[] tmp = null;
>          if (this.readLimit == 0) { //<- recorded by mark method, initial value on construction of this would be zero.
>             data = this.data; //swap owner of bytes
>             this.data = new byte[0];
>             Arrays.fill(data, 0, pos, (byte) 0); // hide out of bounds data.
>             Arrays.fill(data, count, data.length, (byte) 0); 
>          } else {
>             tmp = new byte[Integer.min(len, MAX_TRANSFER_SIZE)];
>          }
> 
>             while (nwritten < len) {
>                 int nbyte = Integer.min(len - nwritten, MAX_TRANSFER_SIZE);
>                 out.write(buf, pos, nbyte);
>                 if (tmp != null) {
>                     System.arraycopy(buf, pos, tmp, 0, nbyte);
>                out.write(tmp, 0, nbyte);
>                 } else
>                     out.write(buf, pos, nbyte);
>                 pos += nbyte;
>                 nwritten += nbyte; 
>             }
>             assert pos == count;
>             if (data.length ==0) { //uphold rules of class.
>                 pos = count = mark = 0;
>             }
>         }
>         return len;
> }
> 
> 
> This would approach avoids having to maintain an allow or deny list.  The downside of this approach and that is the constructor of ByteInputStream doesn't copy the byte[] parameter.  The caller is warned about this in the JavaDocs but it might be shocking to have data escape ByteArrayInputStream.  Maybe that is deal breaker?  Obviously there a compatibility issue with recording readLimit in the mark method as it states it does nothing.
> 
> Thoughts?

I think that this is getting too complicated. For the time being, I think it would be better simply to have a conservative allow-list and trust only the classes in it. The approach can always be broadened at a later date, but at least for now there would be protection against untrustworthy `OutputStream`s

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16893#discussion_r1414382406

From sgehwolf at openjdk.org  Mon Dec  4 19:30:14 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 4 Dec 2023 19:30:14 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v10]
In-Reply-To: <vey3DUjlpRj3CYDf0WeniAmR8T5kC-xB0X4JjxNonSE=.1224fb2c-f934-4574-a007-ef96196bdbaa@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <SDcwfk1zKIk2TowVOL42C7LM8SfFraZiP5gKNLYxnpI=.bfdaed15-bdbf-4f65-8760-145f58e4513e@github.com>
 <PYo6Mc7WoS2PX3rcksdF-Z-svjgwi4sFnWDKpIOdhRY=.7bb8f8ec-98a7-426c-b879-b0b7f656c871@github.com>
 <GV8GxLTKsOL6Y9ZRKSgZScQf0CFAbsxh03OM4sqrjp0=.df3e1fd1-05ed-4f6b-9edc-e5f3e4a638ec@github.com>
 <jAQp_cCC06_NEbD7zEkfpkIYdWO6cDNxeSJJy8TR5po=.3353daa0-3322-4a2a-bba6-72c0d981841c@github.com>
 <vey3DUjlpRj3CYDf0WeniAmR8T5kC-xB0X4JjxNonSE=.1224fb2c-f934-4574-a007-ef96196bdbaa@github.com>
Message-ID: <JAY50uREhYP5lAUBSTD-quH_rt7WDTMBbtsY4vovJb4=.d175d1b0-d8cd-4475-895e-d5ca1156f67e@github.com>

On Thu, 30 Nov 2023 19:07:50 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Yes it's fine.  We can wait for more feedback and consider this future enhancement if desirable.  I just wanted to understand the reason.  Good to add a comment to explain.
>
> Makes sense.

comment added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1414386752

From sgehwolf at openjdk.org  Mon Dec  4 19:41:22 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 4 Dec 2023 19:41:22 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v10]
In-Reply-To: <z8LzYr1qxjvT-ejwoUcMfMHynGhvYycev8kH9ANeyiQ=.5d6ff6e9-68d6-4910-9f4c-4ab412425d9d@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <SDcwfk1zKIk2TowVOL42C7LM8SfFraZiP5gKNLYxnpI=.bfdaed15-bdbf-4f65-8760-145f58e4513e@github.com>
 <PYo6Mc7WoS2PX3rcksdF-Z-svjgwi4sFnWDKpIOdhRY=.7bb8f8ec-98a7-426c-b879-b0b7f656c871@github.com>
 <_U2g2Ejo3uiZ3BdWm-lMSFrZG0Bs8kaX-1TyUT-sasM=.8ba32a2b-9841-4912-b37a-40b281ddfe11@github.com>
 <z8LzYr1qxjvT-ejwoUcMfMHynGhvYycev8kH9ANeyiQ=.5d6ff6e9-68d6-4910-9f4c-4ab412425d9d@github.com>
Message-ID: <7yH1jcWCY_oTUnIJ3lVC7zbXTyWaQIsJ1PKjjX-dB0E=.f83a170e-fd52-4e38-8289-f3949c2797b5@github.com>

On Thu, 30 Nov 2023 17:22:49 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Happy to change the prefix. Having a (unique) prefix seems useful, though, since it eases filtering. Note: that file is not only there for the hash sums, but also to keep track of the path to the files in the filesystem, which we'd otherwise not know.
>
> Will see how a few suggested renames looks like and a better term to describe this may come out ? `runlink` is a bit confusing.

I just went with `fs` for `filesystem`. E.g. `fs_java.base_files` for `java.base`. Those files are taken from the filesystem so this naming makes some sense to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1414398799

From sgehwolf at openjdk.org  Mon Dec  4 19:41:25 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 4 Dec 2023 19:41:25 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v10]
In-Reply-To: <gj2_DSig2sSAd7xph6imvIdcEyJrR_JgPDeYwV8fTv4=.782f256d-6265-4926-8c4f-aeb4c0e93007@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <SDcwfk1zKIk2TowVOL42C7LM8SfFraZiP5gKNLYxnpI=.bfdaed15-bdbf-4f65-8760-145f58e4513e@github.com>
 <gj2_DSig2sSAd7xph6imvIdcEyJrR_JgPDeYwV8fTv4=.782f256d-6265-4926-8c4f-aeb4c0e93007@github.com>
Message-ID: <Vr9d-Eg6ASnkr2eAZSRVOaPdVm2VHPPBRJJEZorE49U=.4132f72b-a279-47c1-8590-200e4d960f66@github.com>

On Tue, 28 Nov 2023 22:00:33 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tighten ModifiedFilesExitTest
>>   
>>   Ensure the error message is reasonable and doesn't include
>>   Exceptions presented to the user.
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/AddRunImageResourcesPlugin.java line 159:
> 
>> 157:             // Filter internal runtime image based link resource file which we
>> 158:             // create later on-the-fly
>> 159:             return null;
> 
> why this one is not excluded in the same way as other plugins?

No specific reason. Updated to be excluded in the same way as other plugins exclude resources.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1414399483

From lmesnik at openjdk.org  Mon Dec  4 20:09:31 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 4 Dec 2023 20:09:31 GMT
Subject: RFR: 8319647: Update or mark as vm.flagless tests that ignore
 external VM flags
In-Reply-To: <zOAssUyHlaTMKi-cdLp_YxE7Qdko-MfAnovE2cFR_9M=.269b68c9-57c5-4d32-bd3c-1874193ddefa@github.com>
References: <zOAssUyHlaTMKi-cdLp_YxE7Qdko-MfAnovE2cFR_9M=.269b68c9-57c5-4d32-bd3c-1874193ddefa@github.com>
Message-ID: <iXSb-KDo1lxjfR4sZdTkP_yprxoEYJBKFpfPmgQoGLw=.982bed94-117d-4c3a-be08-49661ff5a670@github.com>

On Mon, 4 Dec 2023 10:39:05 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

> Updated tests to use vm.flagless as they already ignore Vm flags

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16946#pullrequestreview-1763304819

From bpb at openjdk.org  Mon Dec  4 20:16:12 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 4 Dec 2023 20:16:12 GMT
Subject: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter
 of transferTo() is trusted [v4]
In-Reply-To: <zRINQ_LiJh7Ifnt7UwL2Q0PcpestYwzx74fopLor_2w=.c93f3a3a-8172-40d2-9e5d-0530eb905f2a@github.com>
References: <zRINQ_LiJh7Ifnt7UwL2Q0PcpestYwzx74fopLor_2w=.c93f3a3a-8172-40d2-9e5d-0530eb905f2a@github.com>
Message-ID: <G1i2jgvLHa3whZRh-xQDs-cf0JoBTflxeKuUFR1qEGo=.2df02966-3131-4af9-bb9b-96480fc32859@github.com>

> Pass `ByteArrayInputStream.buf ` directly to the `OutputStream` parameter of `BAIS.transferTo` only if the target stream is in the `java.io` package.

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

  8321053: instanceof -> ==

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16893/files
  - new: https://git.openjdk.org/jdk/pull/16893/files/29ee889b..7aa37667

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

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

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

From asemenyuk at openjdk.org  Mon Dec  4 20:27:41 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 4 Dec 2023 20:27:41 GMT
Subject: RFR: 8294699: Launcher causes lingering busy cursor
Message-ID: <JLG7a6KUWw59tkZ8zRd5nDEeyXguqcc5JBvrRPW23Q4=.89e64bdb-e0b9-46ef-9971-87128a8f6ddf@github.com>

8294699: Launcher causes lingering busy cursor

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

Commit messages:
 - Make sure worker thread terminates before the main thread does.
 - 8294699: Launcher causes lingering busy cursor

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

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

From rriggs at openjdk.org  Mon Dec  4 20:32:38 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 4 Dec 2023 20:32:38 GMT
Subject: RFR: 8320759: Creation of random BigIntegers can be made faster
 [v3]
In-Reply-To: <KAD32In5r6VDU4e0LePqKTHv8bn7fc9xb9zAI1UBkHY=.acba81de-6332-4cf9-9a66-d6e0f488b61b@github.com>
References: <wIuR7gaQWIRdb8DtEN1VXi9dNkUMuKn8zv3Myc4V2gc=.3356e893-5322-4bb4-aa37-731fb6e9a4b0@github.com>
 <KAD32In5r6VDU4e0LePqKTHv8bn7fc9xb9zAI1UBkHY=.acba81de-6332-4cf9-9a66-d6e0f488b61b@github.com>
Message-ID: <ghOqvTjX-8prP8XZTJ4evFbdobaEbBrNIFm6KvJxo4k=.aa0ae4e7-797a-4978-8f1c-bfffd792026f@github.com>

On Sat, 2 Dec 2023 15:42:18 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> A faster and simpler way to generate random BigIntegers, avoiding eventually trimming of leading zeros in magnitude array.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Create RandomBigIntegers.java
>   
>   Create a benchmark to measure the performance of BigInteger(int, Random) constructor implementation.

test/micro/org/openjdk/bench/java/math/RandomBigIntegers.java line 31:

> 29:         }
> 30:     }
> 31: }

Can you convert the test to the JMH framework. It provides a solid framework for reliable performance measurement.  
An existing JMH test can be used as an example.  Thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16817#discussion_r1414454157

From darcy at openjdk.org  Mon Dec  4 20:53:34 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 4 Dec 2023 20:53:34 GMT
Subject: RFR: 8320198: some reference processing tests don't wait long
 enough for reference processing to complete
In-Reply-To: <8Gi1trYkUo7x5YiAURAeH3TdzpoJchvmrHyIm2WCHKk=.18df4d76-6ad9-40f9-a079-f271b5cd7272@github.com>
References: <8Gi1trYkUo7x5YiAURAeH3TdzpoJchvmrHyIm2WCHKk=.18df4d76-6ad9-40f9-a079-f271b5cd7272@github.com>
Message-ID: <M9cU1S347Eob9LgZ4JWSl80nVVXaO4LFobXQW2BnLg8=.9ddcedad-96cd-49eb-9ed3-f4005bda4df3@github.com>

On Mon, 4 Dec 2023 17:46:18 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> This slightly increases the wait for reference processing to complete to accommodate long Xcomp compile times.  Testing is underway.

test/jdk/java/lang/Object/FinalizationOption.java line 92:

> 90:             System.gc();
> 91:             try {
> 92:                 Thread.sleep(30L);

I think it would be better to scale these kinds of sleep time bounds by the timeout factor used to run the jtreg test, which should already to scaled up for known-to-be-slower testing scenarios.

There is a utility method to return this value in jdk/test/lib/Utils.java

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16956#discussion_r1414480356

From vklang at openjdk.org  Mon Dec  4 21:23:44 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 4 Dec 2023 21:23:44 GMT
Subject: RFR: 8318809: java/util/concurrent/ConcurrentLinkedQueue/WhiteBox.java
 shows intermittent failures on linux ppc64le and aarch64
Message-ID: <iA3gGFe3YwhNjdNk6ZoafPE7ak6VPp0qQ4cgT8R42qE=.30dc4dbc-c24a-4671-83f5-f7be232e1143@github.com>

We've seen some rare failures of the CLQ Whitebox test on "less-strong" architectures, and the only thing which -- given my research -- could be the culprit is spuriously failing weakCAS (which is correct in terms of the implementation of CLQ).

After discussion with @DougLea, it was decided as the CLQ implementation does not guarantee what the failing test tests, and modifying the test would mean that it would generally not be able to enforce anything, the test is invalid and should be removed -- hence this PR.

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

Commit messages:
 - Deleting CLQ.Whitebox.addActionsOneNodeSlack as the CLQ implementation does not guarantee what the test tests.

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

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

From alanb at openjdk.org  Mon Dec  4 21:23:45 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 4 Dec 2023 21:23:45 GMT
Subject: RFR: 8318809:
 java/util/concurrent/ConcurrentLinkedQueue/WhiteBox.java shows intermittent
 failures on linux ppc64le and aarch64
In-Reply-To: <iA3gGFe3YwhNjdNk6ZoafPE7ak6VPp0qQ4cgT8R42qE=.30dc4dbc-c24a-4671-83f5-f7be232e1143@github.com>
References: <iA3gGFe3YwhNjdNk6ZoafPE7ak6VPp0qQ4cgT8R42qE=.30dc4dbc-c24a-4671-83f5-f7be232e1143@github.com>
Message-ID: <GHPNGzo6YYeUQHxRGbNRbRcw5bK1ilyEr9rlQZ1AxzY=.bfeee16d-0b0c-498b-84ab-b4e225bb7443@github.com>

On Wed, 22 Nov 2023 20:48:05 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> We've seen some rare failures of the CLQ Whitebox test on "less-strong" architectures, and the only thing which -- given my research -- could be the culprit is spuriously failing weakCAS (which is correct in terms of the implementation of CLQ).
> 
> After discussion with @DougLea, it was decided as the CLQ implementation does not guarantee what the failing test tests, and modifying the test would mean that it would generally not be able to enforce anything, the test is invalid and should be removed -- hence this PR.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16786#pullrequestreview-1762984985

From vklang at openjdk.org  Mon Dec  4 21:23:46 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 4 Dec 2023 21:23:46 GMT
Subject: RFR: 8318809:
 java/util/concurrent/ConcurrentLinkedQueue/WhiteBox.java shows intermittent
 failures on linux ppc64le and aarch64
In-Reply-To: <iA3gGFe3YwhNjdNk6ZoafPE7ak6VPp0qQ4cgT8R42qE=.30dc4dbc-c24a-4671-83f5-f7be232e1143@github.com>
References: <iA3gGFe3YwhNjdNk6ZoafPE7ak6VPp0qQ4cgT8R42qE=.30dc4dbc-c24a-4671-83f5-f7be232e1143@github.com>
Message-ID: <-nCMMErQ4oHqowaGFDyX0PSEMNTS5d7D-uZ7PGFeW3c=.1ff944f5-e911-48dc-9aba-da2a2d0b8740@github.com>

On Wed, 22 Nov 2023 20:48:05 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> We've seen some rare failures of the CLQ Whitebox test on "less-strong" architectures, and the only thing which -- given my research -- could be the culprit is spuriously failing weakCAS (which is correct in terms of the implementation of CLQ).
> 
> After discussion with @DougLea, it was decided as the CLQ implementation does not guarantee what the failing test tests, and modifying the test would mean that it would generally not be able to enforce anything, the test is invalid and should be removed -- hence this PR.

@AlanBateman If you happen to have a couple of seconds to spare, would you mind reviewing this? ?

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

PR Comment: https://git.openjdk.org/jdk/pull/16786#issuecomment-1827798624

From dl at openjdk.org  Mon Dec  4 21:23:46 2023
From: dl at openjdk.org (Doug Lea)
Date: Mon, 4 Dec 2023 21:23:46 GMT
Subject: RFR: 8318809:
 java/util/concurrent/ConcurrentLinkedQueue/WhiteBox.java shows intermittent
 failures on linux ppc64le and aarch64
In-Reply-To: <iA3gGFe3YwhNjdNk6ZoafPE7ak6VPp0qQ4cgT8R42qE=.30dc4dbc-c24a-4671-83f5-f7be232e1143@github.com>
References: <iA3gGFe3YwhNjdNk6ZoafPE7ak6VPp0qQ4cgT8R42qE=.30dc4dbc-c24a-4671-83f5-f7be232e1143@github.com>
Message-ID: <OBVWBeqenbP3-DtvgSboJfwVNBiNyOvQRY1kUufEI0w=.f9d0090e-e1df-46f9-8afe-2f4daade2038@github.com>

On Wed, 22 Nov 2023 20:48:05 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> We've seen some rare failures of the CLQ Whitebox test on "less-strong" architectures, and the only thing which -- given my research -- could be the culprit is spuriously failing weakCAS (which is correct in terms of the implementation of CLQ).
> 
> After discussion with @DougLea, it was decided as the CLQ implementation does not guarantee what the failing test tests, and modifying the test would mean that it would generally not be able to enforce anything, the test is invalid and should be removed -- hence this PR.

Looks good to me!

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

PR Comment: https://git.openjdk.org/jdk/pull/16786#issuecomment-1827901138

From never at openjdk.org  Mon Dec  4 21:33:36 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Mon, 4 Dec 2023 21:33:36 GMT
Subject: RFR: 8320198: some reference processing tests don't wait long
 enough for reference processing to complete
In-Reply-To: <M9cU1S347Eob9LgZ4JWSl80nVVXaO4LFobXQW2BnLg8=.9ddcedad-96cd-49eb-9ed3-f4005bda4df3@github.com>
References: <8Gi1trYkUo7x5YiAURAeH3TdzpoJchvmrHyIm2WCHKk=.18df4d76-6ad9-40f9-a079-f271b5cd7272@github.com>
 <M9cU1S347Eob9LgZ4JWSl80nVVXaO4LFobXQW2BnLg8=.9ddcedad-96cd-49eb-9ed3-f4005bda4df3@github.com>
Message-ID: <NO_0qTKKt9bmkWL4BND-s0ynisy__G23u4RkPyUFvMQ=.cf039240-0540-465d-b854-bfc1b3e28259@github.com>

On Mon, 4 Dec 2023 20:51:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This slightly increases the wait for reference processing to complete to accommodate long Xcomp compile times.  Testing is underway.
>
> test/jdk/java/lang/Object/FinalizationOption.java line 92:
> 
>> 90:             System.gc();
>> 91:             try {
>> 92:                 Thread.sleep(30L);
> 
> I think it would be better to scale these kinds of sleep time bounds by the timeout factor used to run the jtreg test, which should already to scaled up for known-to-be-slower testing scenarios.
> 
> There is a utility method to return this value in jdk/test/lib/Utils.java

I guess that sort of makes sense.  The default timeout factor is 4 I think so I guess I descale the existing total wait of 1000 ms so that the total wait is now Utils.adjustTimeout(250)?  Maybe others might offer an opinion?  Since these waits are a fixed timeout with no early exit I don't think we want them to be too long but anything in 1-5 seconds really doesn't matter.  That's part of why I was just picking a static value.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16956#discussion_r1414525196

From mdoerr at openjdk.org  Mon Dec  4 21:36:13 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 4 Dec 2023 21:36:13 GMT
Subject: RFR: 8321300: Cleanup TestHFA
Message-ID: <vNC36XRrTzlaWGOAEBTQ9cGj6hihknqfwtabun5Id6Y=.e596f328-122a-4503-9121-800e31951901@github.com>

I'd like to clean this up: Use the canonical layouts which are available in JDK22. Use try-with-resources for `Arena.ofConfined()`.

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

Commit messages:
 - 8321300: Cleanup TestHFA

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

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

From sspitsyn at openjdk.org  Mon Dec  4 21:36:36 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 4 Dec 2023 21:36:36 GMT
Subject: RFR: 8321270: Virtual Thread.yield consumes parking permit
In-Reply-To: <lO0N190PTq5-xjJV0LlgHWm8srDw2K8aC_U0E5qf4gA=.057efa94-6e79-4c76-9273-32ca1449bf84@github.com>
References: <lO0N190PTq5-xjJV0LlgHWm8srDw2K8aC_U0E5qf4gA=.057efa94-6e79-4c76-9273-32ca1449bf84@github.com>
Message-ID: <Y9Veg32y7yuC3Li4u75pFlgrppBp84Y0qQXzAA7cS80=.76a90df6-66c6-4a81-9a83-6a336a02ed9d@github.com>

On Mon, 4 Dec 2023 16:08:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> When a virtual thread continues after Thread.yield it currently consumes thread's parking permit. This is an oversight, the parking permit should only be consumed when continuing after park.
> 
> The changes are straight-forward. The internal "RUNNABLE" state is replaced with UNPARKED and YIELDED state, effectively encoding the previous state. So for the most part, it's just replacing the usages of RUNNABLE. The additional states require refactoring tryGetStackTrace, this is the method that is used for Thread::getStackTrace when the virtual thread is unmounted. It is also changed to not not swallow the REE if the reesubmit fails (tryStackTrace has to resubmit as the task for the thread may run, or the thread unparked, while "suspended" and sampling its stack trace). The changes are a subset of larger changes in the loom repo, future PRs will propose to bring in other changes to get main line up to date.
> 
> For testing the existing ThreadAPI has new test cases.
> 
> Testing: test1-5. This includes the JVMTI tests as it maps the thread states to JVMTI thread states.

src/java.base/share/classes/java/lang/VirtualThread.java line 116:

> 114:     private static final int NEW      = 0;
> 115:     private static final int STARTED  = 1;
> 116:     private static final int RUNNING  = 2;     // runnable-unmounted

Just want to make sure this change is intentional.
Before the comment was:  `// runnable-mounted`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16953#discussion_r1414528008

From duke at openjdk.org  Mon Dec  4 21:55:36 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 4 Dec 2023 21:55:36 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v7]
In-Reply-To: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
Message-ID: <Wtw85e0b1KZvSOdEMPLMzJG89x4A3V1U3HVuUy-zWoE=.795cdd9c-cc64-4da2-829e-170d7c0889ba@github.com>

> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX2 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
> 
> For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
> 
> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
> 
> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
> <link rel=File-List
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
> 
> 
> </head>
> 
> <body link="#0563C1" vlink="#954F72">
> 
> 
> 
> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
> -- | -- | -- | -- | --
> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
> 
> </body>
> 
> </html>
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/...

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  add GCC version guards

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16534/files
  - new: https://git.openjdk.org/jdk/pull/16534/files/d957f413..bb5f711a

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

  Stats: 42 lines in 3 files changed: 42 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16534.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16534/head:pull/16534

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

From almatvee at openjdk.org  Mon Dec  4 22:00:38 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 4 Dec 2023 22:00:38 GMT
Subject: RFR: 8294699: Launcher causes lingering busy cursor
In-Reply-To: <JLG7a6KUWw59tkZ8zRd5nDEeyXguqcc5JBvrRPW23Q4=.89e64bdb-e0b9-46ef-9971-87128a8f6ddf@github.com>
References: <JLG7a6KUWw59tkZ8zRd5nDEeyXguqcc5JBvrRPW23Q4=.89e64bdb-e0b9-46ef-9971-87128a8f6ddf@github.com>
Message-ID: <5_WK34gsOnWcgmJrHxNnz5wPoLDGCHwCLz8DhM8ozIo=.225a0bad-7087-4267-8e14-14910992b99a@github.com>

On Mon, 4 Dec 2023 20:08:15 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> 8294699: Launcher causes lingering busy cursor

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16958#pullrequestreview-1763517307

From sspitsyn at openjdk.org  Mon Dec  4 22:06:34 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 4 Dec 2023 22:06:34 GMT
Subject: RFR: 8321270: Virtual Thread.yield consumes parking permit
In-Reply-To: <lO0N190PTq5-xjJV0LlgHWm8srDw2K8aC_U0E5qf4gA=.057efa94-6e79-4c76-9273-32ca1449bf84@github.com>
References: <lO0N190PTq5-xjJV0LlgHWm8srDw2K8aC_U0E5qf4gA=.057efa94-6e79-4c76-9273-32ca1449bf84@github.com>
Message-ID: <NKZhvmBV85GG-Q3crfXKpE26z1ZeSdIdHe1xpzoSsGc=.9a1548c3-5426-4785-b58c-297351a2b920@github.com>

On Mon, 4 Dec 2023 16:08:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> When a virtual thread continues after Thread.yield it currently consumes thread's parking permit. This is an oversight, the parking permit should only be consumed when continuing after park.
> 
> The changes are straight-forward. The internal "RUNNABLE" state is replaced with UNPARKED and YIELDED state, effectively encoding the previous state. So for the most part, it's just replacing the usages of RUNNABLE. The additional states require refactoring tryGetStackTrace, this is the method that is used for Thread::getStackTrace when the virtual thread is unmounted. It is also changed to not not swallow the REE if the reesubmit fails (tryStackTrace has to resubmit as the task for the thread may run, or the thread unparked, while "suspended" and sampling its stack trace). The changes are a subset of larger changes in the loom repo, future PRs will propose to bring in other changes to get main line up to date.
> 
> For testing the existing ThreadAPI has new test cases.
> 
> Testing: test1-5. This includes the JVMTI tests as it maps the thread states to JVMTI thread states.

src/hotspot/share/classfile/javaClasses.cpp line 1998:

> 1996:     case UNPARKED:
> 1997:     case YIELDING :
> 1998:     case YIELDED:

Is this new state `YIELDED` really needed?
It looks like `UNPARKED` is also appeared where `YIELDED` is used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16953#discussion_r1414561935

From duke at openjdk.org  Mon Dec  4 22:15:24 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 4 Dec 2023 22:15:24 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v8]
In-Reply-To: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
Message-ID: <7ocsRxaWjoU2vxwPUSE7BrnLSL1bF_7Pp8vReacNJvE=.1c044b21-b27e-4e94-8db0-6ae888a1e8b9@github.com>

> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX2 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
> 
> For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
> 
> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
> 
> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
> <link rel=File-List
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
> 
> 
> </head>
> 
> <body link="#0563C1" vlink="#954F72">
> 
> 
> 
> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
> -- | -- | -- | -- | --
> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
> 
> </body>
> 
> </html>
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/...

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

 - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
 - add GCC version guards
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
 - Remove C++17 from C flags
 - add avoid masked stores operation
 - update the code to check for supported simd sort cpus
 - Disable AVX2 sort for 64-bit types
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
 - fix jcheck failures due to windows encoding
 - fix carriage return and change insertion sort thresholds
 - ... and 7 more: https://git.openjdk.org/jdk/compare/0b17dc14...bc590d9f

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16534/files
  - new: https://git.openjdk.org/jdk/pull/16534/files/bb5f711a..bc590d9f

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

  Stats: 36176 lines in 1033 files changed: 17425 ins; 14551 del; 4200 mod
  Patch: https://git.openjdk.org/jdk/pull/16534.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16534/head:pull/16534

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

From duke at openjdk.org  Mon Dec  4 22:18:35 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 4 Dec 2023 22:18:35 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v8]
In-Reply-To: <_gSNXk0qGAtpY-WJ5OCHk_3-nuGrwwSn-ffK9f2TEcs=.40f785ba-83dd-40fe-8075-a7a7872ea600@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <e5w5YZ0WD8S3UVFBYz6I0PdKZ6yOkD77BCq2arDd6i4=.7eecadcb-e627-4e9b-8f1e-3fc41c63243b@github.com>
 <bopxvLCquUtZQxt8kAJskzXBR2YE_I0PW13i3NBJNNY=.e65abf3d-0ff4-4450-875b-ca3717170485@github.com>
 <DeQgR1PaXlk2yzlxV15N3ViZY26wXtlgfVKxRY6vuWo=.6d38f729-0ca9-4f43-9e23-f5e73a01cc23@github.com>
 <b1Nv5Y7Klpvp5ACcHJTTblwGmnA64cyRg-3YzotaHvc=.0bd8a0f0-0844-44a9-a3bb-4af2e8514ee1@github.com>
 <t_23EA--aX8v2US9Lsib1ZF3bl4HQx_Z4RXqlgQo8LE=.6f1f2873-015c-4b69-ad47-b449e5b77a45@github.com>
 <pRcJlU1a4jG9gMaftLn5IerudMSDIrvr70KBefkpNSo=.f442f0d4-887f-4376-a66e-8254fa35927c@github.com>
 <OJ1ZK4a8c_bZik60v503VUtZoweFFv6VhhGg1sp4qSY=.e8852bf1-2d7f-4164-b952-d88b294ec1f7@github.com>
 <_gSNXk0qGAtpY-WJ5OCHk_3-nuGrwwSn-ffK9f2TEcs=.40f785ba-83dd-40fe-8075-a7a7872ea600@github.com>
Message-ID: <v95kXnbADF5XriLfeg2v5yVYBo-BUzR-dhpcubuMDcI=.03d8e5a7-8b0c-4291-99df-2d3ec6cd356c@github.com>

On Mon, 4 Dec 2023 11:48:44 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>>> But you are saying that you want to skip building this library unless you have a gcc version that supports c++17?
>>> 
>> Yes, the request is to skip building the simdsort library if GCC version is < 8 as only GCC >= 8 supports C++17 features.
>
> Then you must add logic to check for this. Now the build will just fail if building with an older gcc. That is not acceptable.

Hi Marcus (@magicus), please see the updated code which added guards to check for GCC version >= 7.5 in `src/java.base/linux/native/libsimdsort/{avx2-linux-qsort.cpp, avx512-linux-qsort.cpp}`. GCC >= 7.5 is needed to compile libsimdsort using C++17 features. Made sure that OpenJDK builds without errors using both GCC 7.5 and GCC 6.4.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1414570644

From bpb at openjdk.org  Mon Dec  4 22:29:43 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 4 Dec 2023 22:29:43 GMT
Subject: RFR: 8320759: Creation of random BigIntegers can be made faster
 [v3]
In-Reply-To: <KAD32In5r6VDU4e0LePqKTHv8bn7fc9xb9zAI1UBkHY=.acba81de-6332-4cf9-9a66-d6e0f488b61b@github.com>
References: <wIuR7gaQWIRdb8DtEN1VXi9dNkUMuKn8zv3Myc4V2gc=.3356e893-5322-4bb4-aa37-731fb6e9a4b0@github.com>
 <KAD32In5r6VDU4e0LePqKTHv8bn7fc9xb9zAI1UBkHY=.acba81de-6332-4cf9-9a66-d6e0f488b61b@github.com>
Message-ID: <nwSbDzk8oUxuEnjahZkRUq0X-q4_344lWakgx3qKAak=.23d3f420-79c0-430b-ae98-9a88404dc43c@github.com>

On Sat, 2 Dec 2023 15:42:18 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> A faster and simpler way to generate random BigIntegers, avoiding eventually trimming of leading zeros in magnitude array.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Create RandomBigIntegers.java
>   
>   Create a benchmark to measure the performance of BigInteger(int, Random) constructor implementation.

Relaying comments from a colleague:

1. Half of the random bits are wasted by the use of `nextInt()`, which by default invokes `nextLong()` and throws away the lower 32 bits. Not sure if complicating the code to use all the 64 bits of `nextLong()` is worthwhile, though.

2. The way the random bits fill the magnitude array is different. This might break existing reproducible tests with seeded random number generators and fixed seed. Not sure if this is a real problem in practice, though.

3. There seems to be no test coverage that ensures the `BigInteger` invariant has either `mag.length == 0` or `mag[0] != 0`. While the code obviously ensures it, future changes might not, so it might make sense to have this aspect covered by a test.

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

PR Comment: https://git.openjdk.org/jdk/pull/16817#issuecomment-1839599463

From jvernee at openjdk.org  Mon Dec  4 23:25:32 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 4 Dec 2023 23:25:32 GMT
Subject: RFR: 8321300: Cleanup TestHFA
In-Reply-To: <vNC36XRrTzlaWGOAEBTQ9cGj6hihknqfwtabun5Id6Y=.e596f328-122a-4503-9121-800e31951901@github.com>
References: <vNC36XRrTzlaWGOAEBTQ9cGj6hihknqfwtabun5Id6Y=.e596f328-122a-4503-9121-800e31951901@github.com>
Message-ID: <e5Oawpecd8tiYwLAgsNGJKeqzWNOBMnWlQbfrSgvVbY=.567c0df0-c892-4967-a698-35967b2dad91@github.com>

On Mon, 4 Dec 2023 21:25:41 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> I'd like to clean this up: Use the canonical layouts which are available in JDK22. Use try-with-resources for `Arena.ofConfined()`.

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16959#pullrequestreview-1763626270

From sviswanathan at openjdk.org  Tue Dec  5 00:10:38 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 5 Dec 2023 00:10:38 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v8]
In-Reply-To: <7ocsRxaWjoU2vxwPUSE7BrnLSL1bF_7Pp8vReacNJvE=.1c044b21-b27e-4e94-8db0-6ae888a1e8b9@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <7ocsRxaWjoU2vxwPUSE7BrnLSL1bF_7Pp8vReacNJvE=.1c044b21-b27e-4e94-8db0-6ae888a1e8b9@github.com>
Message-ID: <5JnWpXMWKZ85mosrUdVrdNLRyHWF_HNW3h8krKWO63k=.63bf3ffa-63a1-4ce4-b972-278655e8a567@github.com>

On Mon, 4 Dec 2023 22:15:24 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX2 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
>> 
>> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
>> 
>> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId content=Excel.Sheet>
>> <meta name=Generator content="Microsoft Excel 15">
>> <link id=Main-File rel=Main-File
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
>> <link rel=File-List
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
>> 
>> 
>> </head>
>> 
>> <body link="#0563C1" vlink="#954F72">
>> 
>> 
>> 
>> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
>> -- | -- | -- | -- | --
>> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
>> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
>> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
>> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
>> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
>> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
>> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
>> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
>> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
>> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
>> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
>> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
>> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
>> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
>> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
>> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
>> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
>> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
>> 
>> </body>
>> 
>> </html>
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId cont...
>
> Srinivas Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>  - add GCC version guards
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>  - Remove C++17 from C flags
>  - add avoid masked stores operation
>  - update the code to check for supported simd sort cpus
>  - Disable AVX2 sort for 64-bit types
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>  - fix jcheck failures due to windows encoding
>  - fix carriage return and change insertion sort thresholds
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/d4804a12...bc590d9f

The PR looks good to me.

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

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16534#pullrequestreview-1763680754

From duke at openjdk.org  Tue Dec  5 00:18:47 2023
From: duke at openjdk.org (duke)
Date: Tue, 5 Dec 2023 00:18:47 GMT
Subject: Withdrawn: 6478546: FileInputStream.read() throws OutOfMemoryError
 when there is plenty available
In-Reply-To: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
Message-ID: <b5vV-j0U3ayOdDPsKjH0CrqNiahp_d5LfKPup_Fxeqc=.6e5dc86f-191c-4bf4-be1a-596812e8158d@github.com>

On Fri, 21 Jul 2023 22:40:00 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Limit native memory allocation and move write loop from the native layer into Java. This change should make the OOME reported in the issue much less likely.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Tue Dec  5 00:50:41 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 5 Dec 2023 00:50:41 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v8]
In-Reply-To: <7ocsRxaWjoU2vxwPUSE7BrnLSL1bF_7Pp8vReacNJvE=.1c044b21-b27e-4e94-8db0-6ae888a1e8b9@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <7ocsRxaWjoU2vxwPUSE7BrnLSL1bF_7Pp8vReacNJvE=.1c044b21-b27e-4e94-8db0-6ae888a1e8b9@github.com>
Message-ID: <QZ8yVYKm3kiatXbu13DaPLDGNHmhjgi28_fqzFnEwOU=.df19c109-f34c-4301-85b2-fbbe48a13dc0@github.com>

On Mon, 4 Dec 2023 22:15:24 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX2 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
>> 
>> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
>> 
>> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId content=Excel.Sheet>
>> <meta name=Generator content="Microsoft Excel 15">
>> <link id=Main-File rel=Main-File
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
>> <link rel=File-List
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
>> 
>> 
>> </head>
>> 
>> <body link="#0563C1" vlink="#954F72">
>> 
>> 
>> 
>> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
>> -- | -- | -- | -- | --
>> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
>> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
>> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
>> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
>> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
>> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
>> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
>> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
>> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
>> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
>> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
>> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
>> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
>> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
>> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
>> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
>> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
>> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
>> 
>> </body>
>> 
>> </html>
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId cont...
>
> Srinivas Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>  - add GCC version guards
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>  - Remove C++17 from C flags
>  - add avoid masked stores operation
>  - update the code to check for supported simd sort cpus
>  - Disable AVX2 sort for 64-bit types
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>  - fix jcheck failures due to windows encoding
>  - fix carriage return and change insertion sort thresholds
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/0dc47dcf...bc590d9f

Hello Vladimir (@vnkozlov),

Could you please review this PR?

Thanks,
Vamsi

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

PR Comment: https://git.openjdk.org/jdk/pull/16534#issuecomment-1839810768

From darcy at openjdk.org  Tue Dec  5 01:48:14 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 5 Dec 2023 01:48:14 GMT
Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v5]
In-Reply-To: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
Message-ID: <WT4hwqImuTyuIoTT1l7nJmD7pNjADyuLXYLWrOBK_lU=.11e17f95-9c77-4dc3-a9b4-26bbcfc63141@github.com>

> Time to start making preparations for JDK 23.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Merge branch 'master' into JDK-8319413
 - Add symbol files.
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Update symbol files to JDK 22 b26.
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Add symbol files for JDK 22 build 25.
 - ... and 5 more: https://git.openjdk.org/jdk/compare/30b5d427...2ee6cb96

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

Changes: https://git.openjdk.org/jdk/pull/16505/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16505&range=04
  Stats: 12598 lines in 97 files changed: 12560 ins; 0 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/16505.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16505/head:pull/16505

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

From bchristi at openjdk.org  Tue Dec  5 01:59:49 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 5 Dec 2023 01:59:49 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v2]
In-Reply-To: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
Message-ID: <1c_S-QEtaBeYhmy_OuGjx0KV2ArFOyHWn6vDjaamQgA=.ca0064f1-e432-4308-8186-f0e718e0214b@github.com>

> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing.
> 
> A couple key things we want to be able to say are:
> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'.
> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action.
> 
> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_

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

  Address a number of PR comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16644/files
  - new: https://git.openjdk.org/jdk/pull/16644/files/dfce0dd5..84d8b61f

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

  Stats: 54 lines in 2 files changed: 15 ins; 25 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/16644.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16644/head:pull/16644

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

From xgong at openjdk.org  Tue Dec  5 02:08:40 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 5 Dec 2023 02:08:40 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v6]
In-Reply-To: <xVVii7I4RU8P9bpGqTdLnUqzD3LhrrXYhuN0URC6JAE=.5027c6d2-d75e-48bd-bcc2-57332216078e@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
 <emidt6MaU3Owb2FMLA1EibqvQF4_zTtsA00ccPQAy4Y=.1b90ba32-ac3a-41db-acf9-f1c45704b203@github.com>
 <xVVii7I4RU8P9bpGqTdLnUqzD3LhrrXYhuN0URC6JAE=.5027c6d2-d75e-48bd-bcc2-57332216078e@github.com>
Message-ID: <DUOQVUOJwBpCSxB1JmS-pCfZhGQUfmHyNFbf2-aWj_I=.cea497eb-68d4-4b49-a228-ac73d52facd8@github.com>

On Mon, 4 Dec 2023 08:31:17 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> The final thing we need to resolve properly is the SVE compiler test. 
>> 
>> @theRealAph says:
>>> arm_sve.h is part of GCC. It was added to GCC in 2019.
>> 
>> A more relevant question is what version of gcc it was added, and if that also implies that the compiler knows about `-march=armv8-a+sve`. If so, then this test could basically be framed as a gcc version check.
>> 
>> I'm still leaning towards failing configure if the SVE code cannot be compiled. Under what circumstances can this test possibly fail, so SVE_CFLAGS would not be set?
>
>> The final thing we need to resolve properly is the SVE compiler test.
>> 
>> @theRealAph says:
>> 
>> > arm_sve.h is part of GCC. It was added to GCC in 2019.
>> 
>> A more relevant question is what version of gcc it was added, and if that also implies that the compiler knows about `-march=armv8-a+sve`. If so, then this test could basically be framed as a gcc version check.
>> 
>> I'm still leaning towards failing configure if the SVE code cannot be compiled. Under what circumstances can this test possibly fail, so SVE_CFLAGS would not be set?
> 
> Yes, the SVE compiler test code could be treated as a gcc/clang version check. `arm_sve.h` which is included in `sleef.h` and then in `vect_math_sve.c` is the SVE ACLE (Arm C Language Extensions) header file. It was included in gcc start from version 10 (may not be exact, but gcc 8/9 would fail when compile c code including this header). We have to make sure the compiler supports the SVE ACLE before using it.  Here are the different scenarios:
> 
> 1. The SVE compiler test success, and `SVE_CFLAGS` is set to `-march=armv8-a+sve`. All symbols in `libvmath.so` are built successfully including NEON/SVE. Hence, the vector math operations with all kinds of vector size on both NEON/SVE machines will be improved as expected.
> 2. The SVE compiler test fail, and `SVE_CFLAGS` is null. SVE symbols in `libvmath.so` cannot be built out. Only NEON symbols exist in `libvmath.so`. Hence, the enhancement for vector math operations with > 128-bit vector size on SVE machines are missing.

> @XiaohongGong If we are sure that the SVE test will always succeed when running on gcc 10 or higher, then I guess I don't really need a way to enforce SVE support -- you'll just have to make sure you use a recent enough gcc.
> 
> But, then the entire test becomes a bit unnecessary. You can just replace it with a version check on gcc, or perhaps a FLAGS_COMPILER_CHECK_ARGUMENTS on `-march=armv8-a+sve`.

Thanks for the suggestion @magicus ! Replacing with a version check for the c compiler seems fine. But I cannot see the advantange than current test. Here are the reasons:
1. `-march=armv8-a+sve` is the necessary cflag for the sve source, and only included start from some c compiler versions. The c compiler version check must happen before using it. So it should also happen in the make or configure stage? Hence, we still have to find a right place to check it (should be in `lib-sleef.m4` or otherwhere?).
2. We not only have to check the gcc version, but also have to check the clang version. Would this make the code more complex?

Regarding to using `FLAGS_COMPILER_CHECK_ARGUMENTS on "-march=armv8-a+sve"`, it is not right as well. Because we have to make sure the c compiler supports SVE ACLE completely which contains the sve header `arm_sve.h`. The compiler that supports option `-march=armv8-a+sve` cannot make sure the SVE ACLE is supported as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1839875881

From darcy at openjdk.org  Tue Dec  5 03:49:31 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 5 Dec 2023 03:49:31 GMT
Subject: RFR: 8320198: some reference processing tests don't wait long
 enough for reference processing to complete
In-Reply-To: <NO_0qTKKt9bmkWL4BND-s0ynisy__G23u4RkPyUFvMQ=.cf039240-0540-465d-b854-bfc1b3e28259@github.com>
References: <8Gi1trYkUo7x5YiAURAeH3TdzpoJchvmrHyIm2WCHKk=.18df4d76-6ad9-40f9-a079-f271b5cd7272@github.com>
 <M9cU1S347Eob9LgZ4JWSl80nVVXaO4LFobXQW2BnLg8=.9ddcedad-96cd-49eb-9ed3-f4005bda4df3@github.com>
 <NO_0qTKKt9bmkWL4BND-s0ynisy__G23u4RkPyUFvMQ=.cf039240-0540-465d-b854-bfc1b3e28259@github.com>
Message-ID: <v9fCUXqMtbj3tJ5Ya0V2Fgh92_BmHTUbyJ43-ptJk9M=.1043a8c5-6ecc-4a29-9518-a1d361793393@github.com>

On Mon, 4 Dec 2023 21:30:44 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> I guess that sort of makes sense. The default timeout factor is 4 I think so I guess I descale the existing total wait of 1000 ms so that the total wait is now Utils.adjustTimeout(250)? Maybe others might offer an opinion? Since these waits are a fixed timeout with no early exit I don't think we want them to be too long but anything in 1-5 seconds really doesn't matter. That's part of why I was just picking a static value.

Looking at running the test suite as a whole, especially for tier 1 tests which are run very frequently, a few seconds here, a few seconds there, over a few thousand tests starts to add up in terms of increasing the minimum time needed to run the sets of tests.

(Separate from this issue, I think it would be a useful exercise to more systematically examine the constant sleeps in the test suite and tune down the constant factor to let the timeout factor do more of the heavy lifting on avoiding spurious failures.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16956#discussion_r1414836607

From jpai at openjdk.org  Tue Dec  5 05:29:34 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 5 Dec 2023 05:29:34 GMT
Subject: RFR: 8318809:
 java/util/concurrent/ConcurrentLinkedQueue/WhiteBox.java shows intermittent
 failures on linux ppc64le and aarch64
In-Reply-To: <iA3gGFe3YwhNjdNk6ZoafPE7ak6VPp0qQ4cgT8R42qE=.30dc4dbc-c24a-4671-83f5-f7be232e1143@github.com>
References: <iA3gGFe3YwhNjdNk6ZoafPE7ak6VPp0qQ4cgT8R42qE=.30dc4dbc-c24a-4671-83f5-f7be232e1143@github.com>
Message-ID: <wRIsGClp3-o4uT6B0mdDlUIQY4K5nK_P-JBXlxvoefs=.d7bdbe03-3090-4e43-9541-c88cd325808c@github.com>

On Wed, 22 Nov 2023 20:48:05 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> We've seen some rare failures of the CLQ Whitebox test on "less-strong" architectures, and the only thing which -- given my research -- could be the culprit is spuriously failing weakCAS (which is correct in terms of the implementation of CLQ).
> 
> After discussion with @DougLea, it was decided as the CLQ implementation does not guarantee what the failing test tests, and modifying the test would mean that it would generally not be able to enforce anything, the test is invalid and should be removed -- hence this PR.

I see both Doug and Alan have reviewed this.

I'll go ahead and sponsor this now.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16786#pullrequestreview-1763992520

From vklang at openjdk.org  Tue Dec  5 05:32:43 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 5 Dec 2023 05:32:43 GMT
Subject: Integrated: 8318809:
 java/util/concurrent/ConcurrentLinkedQueue/WhiteBox.java shows intermittent
 failures on linux ppc64le and aarch64
In-Reply-To: <iA3gGFe3YwhNjdNk6ZoafPE7ak6VPp0qQ4cgT8R42qE=.30dc4dbc-c24a-4671-83f5-f7be232e1143@github.com>
References: <iA3gGFe3YwhNjdNk6ZoafPE7ak6VPp0qQ4cgT8R42qE=.30dc4dbc-c24a-4671-83f5-f7be232e1143@github.com>
Message-ID: <JLtF471ca1Kb0yKC7f_E-j6bBAzSSnWLTMliKuJDruw=.24f4276d-5959-48df-a591-a4a75e48967b@github.com>

On Wed, 22 Nov 2023 20:48:05 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> We've seen some rare failures of the CLQ Whitebox test on "less-strong" architectures, and the only thing which -- given my research -- could be the culprit is spuriously failing weakCAS (which is correct in terms of the implementation of CLQ).
> 
> After discussion with @DougLea, it was decided as the CLQ implementation does not guarantee what the failing test tests, and modifying the test would mean that it would generally not be able to enforce anything, the test is invalid and should be removed -- hence this PR.

This pull request has now been integrated.

Changeset: 50d1839d
Author:    Viktor Klang <vklang at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/50d1839d54f13631946925d8ecf03ce71f31bab8
Stats:     30 lines in 1 file changed: 0 ins; 30 del; 0 mod

8318809: java/util/concurrent/ConcurrentLinkedQueue/WhiteBox.java shows intermittent failures on linux ppc64le and aarch64

Reviewed-by: alanb, jpai

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

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

From iris at openjdk.org  Tue Dec  5 05:40:40 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 5 Dec 2023 05:40:40 GMT
Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v5]
In-Reply-To: <WT4hwqImuTyuIoTT1l7nJmD7pNjADyuLXYLWrOBK_lU=.11e17f95-9c77-4dc3-a9b4-26bbcfc63141@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
 <WT4hwqImuTyuIoTT1l7nJmD7pNjADyuLXYLWrOBK_lU=.11e17f95-9c77-4dc3-a9b4-26bbcfc63141@github.com>
Message-ID: <HioUyYK9DU0tuyxoIMtKjDiwDiOvkC3-89h9aUirlQU=.08a78467-afb7-497f-88b5-cce72a31dcd1@github.com>

On Tue, 5 Dec 2023 01:48:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start making preparations for JDK 23.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Merge branch 'master' into JDK-8319413
>  - Add symbol files.
>  - Merge branch 'master' into JDK-8319413
>  - Merge branch 'master' into JDK-8319413
>  - Merge branch 'master' into JDK-8319413
>  - Merge branch 'master' into JDK-8319413
>  - Update symbol files to JDK 22 b26.
>  - Merge branch 'master' into JDK-8319413
>  - Merge branch 'master' into JDK-8319413
>  - Add symbol files for JDK 22 build 25.
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/30b5d427...2ee6cb96

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16505#pullrequestreview-1764000855

From iris at openjdk.org  Tue Dec  5 05:40:44 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 5 Dec 2023 05:40:44 GMT
Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v4]
In-Reply-To: <8B_EG0mwCKb3mRlrAoyz7vkzZhNPpZUAfY-EOQ1FlEo=.efbc5ce9-1a75-4aa2-8dfc-96a9c9fd03b7@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
 <P9uONCgJlH6ON2nqV1TxpJ5tn_XrGmBuFWKrU45JrKs=.4f773cc2-b13c-42c8-a7f4-2591af065743@github.com>
 <8B_EG0mwCKb3mRlrAoyz7vkzZhNPpZUAfY-EOQ1FlEo=.efbc5ce9-1a75-4aa2-8dfc-96a9c9fd03b7@github.com>
Message-ID: <uBGC1h1iKx_-qR6p93-OjXCiNnyl8lqV8tTT0AaWjD8=.92e0ed23-2e7d-4ec0-952d-62aa768df14d@github.com>

On Sat, 2 Dec 2023 20:40:57 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update symbol files to JDK 22 b26.
>
> test/langtools/tools/javac/versions/Versions.java line 97:
> 
>> 95:         TWENTY_ONE(false,"65.0", "21"),
>> 96:         TWENTY_TWO(false,"66.0", "22"),
>> 97:         TWENTY_THREE(false,"67.0", "23"),
> 
> As alignment is broken anyway, let's add space
> Suggestion:
> 
>         TWENTY_THREE(false, "67.0", "23"),

If you're going to add the space, I'd consider establishing new alignment at TWENTY to accommodate the eventual space needed for "THREE", "SEVEN", and "EIGHT".  You wouldn't need to reset alignment for quite some time after that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16505#discussion_r1414904341

From pminborg at openjdk.org  Tue Dec  5 07:16:49 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 5 Dec 2023 07:16:49 GMT
Subject: RFR: 8321159: SymbolLookup.libraryLookup(Path,
 Arena) Assumes default Filesystem [v4]
In-Reply-To: <sbkQW1a7NByueXA7Vm_JVE06P3queX4AkDE-rlFFbgg=.35168862-4033-4184-97c8-86ab21da922e@github.com>
References: <sbkQW1a7NByueXA7Vm_JVE06P3queX4AkDE-rlFFbgg=.35168862-4033-4184-97c8-86ab21da922e@github.com>
Message-ID: <QC35Um-xsK_9ym9L8JbvpWw1Um4Wlget4uSau2Ri7kY=.9b537656-de02-43ac-81d0-2c26db6d46a8@github.com>

> This PR proposes to reject paths provided to the `SymbolLookup.libraryLookup(Path path, Arena arena)` method if a path is not in the default file system.

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

  Change @throws description

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16944/files
  - new: https://git.openjdk.org/jdk/pull/16944/files/f1693824..fae3db5d

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

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

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

From xgong at openjdk.org  Tue Dec  5 07:24:42 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 5 Dec 2023 07:24:42 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v5]
In-Reply-To: <a0fi6KAaaVceRSRWzviR0W1iN-CjlkCIS9GjHAxRr5g=.324dd1aa-d4bd-48f1-8e23-604b09b75b4c@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <nZFspjlPXfeQxrr5cKfbjeL3typf6DKSgNQUNszhufE=.caac471d-9c7b-4f8f-953f-04ee4a13f111@github.com>
 <9VeMdTAJPaPZDg9ZW7FVJOf9XGl4gGqAS-2g8SFc9c0=.36792cd5-66d9-4abc-ba0c-aee3478627f4@github.com>
 <mnf_hjWdemelALPlwcS8mnKIxR5ljIyGD6MHpqCPDsQ=.0cb49580-ed76-4728-a604-acff3dff42a5@github.com>
 <aArEqABKvjZDCxOkkpKS1rlX9Q0aafCUY8ZS3L5OBek=.f009f07b-c9e4-437b-a6d3-c86fb29d75a0@github.com>
 <vlqKSuAKzKRTXWG_hLCEJixN8oFec68IuSnfb0u9OJ0=.6c926fc3-f0f3-4ccf-b373-555948c3702b@github.com>
 <a0fi6KAaaVceRSRWzviR0W1iN-CjlkCIS9GjHAxRr5g=.324dd1aa-d4bd-48f1-8e23-604b09b75b4c@github.com>
Message-ID: <tHkg8-8CbvcHsfEhonfA4PxB_XXjonY5MbmunXEfFEI=.428e7a97-0bce-4f17-b93c-3275037e5a66@github.com>

On Fri, 1 Dec 2023 16:36:18 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> You need to expand this logic to cover more instances. See e.g. lib-ffi.m4 for inspiration.
>> 
>> Basic flow:
>> * if user has specified libsleef root with argument, check both lib/ and lib64/ under that root.
>> * if user has not specified libsleef root, and we have no SYSROOT, try PKG_CHECK
>> * Otherwise, look in well-known directories which is $SYSROOT/usr/[local/]lib[64].
>
> also, ideally, you will add the corresponding specific overrides like in ffi:
> 
>   AC_ARG_WITH(libffi-include, [AS_HELP_STRING([--with-libffi-include],
>       [specify directory for the libffi include files])])
>   AC_ARG_WITH(libffi-lib, [AS_HELP_STRING([--with-libffi-lib],
>       [specify directory for the libffi library])])

Thanks for the suggestion @magicus !

The check in current `lib-sleef.m4` is very common:

-  If user has specified libsleef root by '--with-libsleef', we assume it is the manually built sleef lib. So only `lib/` and `include/` is checked. And the flags are set based on that path.
- If user has not specified the libsleef root, and no `SYSROOT` is set, we try `PKG_CHECK` (like what you suggested)
- Otherwise, check `sleef.h`   
   - We assume the sleef module is installed under one of the valid system paths if the header can be found. So just linking with `-lsleef` will success.

It's an issue in current flow like what @theRealAph met. I will add the options like `--with-libsleef-lib` and `--with-libsleef-include` like ffi. Regarding to extending the check for`--with-libsleef`, I think we can just make it simple like what it is now. Or, we have to check all the potential valid lib paths like `lib/`, `lib64/`, or maybe `lib/aarch64-linux-gnu`. The same to the `include` part.  @theRealAph @magicus , WDYT?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1414980861

From duke at openjdk.org  Tue Dec  5 07:40:35 2023
From: duke at openjdk.org (Markus KARG)
Date: Tue, 5 Dec 2023 07:40:35 GMT
Subject: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter
 of transferTo() is trusted [v4]
In-Reply-To: <G1i2jgvLHa3whZRh-xQDs-cf0JoBTflxeKuUFR1qEGo=.2df02966-3131-4af9-bb9b-96480fc32859@github.com>
References: <zRINQ_LiJh7Ifnt7UwL2Q0PcpestYwzx74fopLor_2w=.c93f3a3a-8172-40d2-9e5d-0530eb905f2a@github.com>
 <G1i2jgvLHa3whZRh-xQDs-cf0JoBTflxeKuUFR1qEGo=.2df02966-3131-4af9-bb9b-96480fc32859@github.com>
Message-ID: <4bwttMfJ29GTFbt-8ob46PQjhiZUZi9xmCuajK7nM4U=.6b56d022-5867-4063-9486-4168f43d8bdc@github.com>

On Mon, 4 Dec 2023 20:16:12 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Pass `ByteArrayInputStream.buf ` directly to the `OutputStream` parameter of `BAIS.transferTo` only if the target stream is in the `java.io` package.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8321053: instanceof -> ==

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

> 211:             byte[] tmp;
> 212:             Class<?> outClass = out.getClass();
> 213:             if (outClass.getPackageName().equals("java.io") &&

For what do we need this string-based check here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16893#discussion_r1415005911

From alanb at openjdk.org  Tue Dec  5 08:29:36 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 5 Dec 2023 08:29:36 GMT
Subject: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter
 of transferTo() is trusted [v4]
In-Reply-To: <4bwttMfJ29GTFbt-8ob46PQjhiZUZi9xmCuajK7nM4U=.6b56d022-5867-4063-9486-4168f43d8bdc@github.com>
References: <zRINQ_LiJh7Ifnt7UwL2Q0PcpestYwzx74fopLor_2w=.c93f3a3a-8172-40d2-9e5d-0530eb905f2a@github.com>
 <G1i2jgvLHa3whZRh-xQDs-cf0JoBTflxeKuUFR1qEGo=.2df02966-3131-4af9-bb9b-96480fc32859@github.com>
 <4bwttMfJ29GTFbt-8ob46PQjhiZUZi9xmCuajK7nM4U=.6b56d022-5867-4063-9486-4168f43d8bdc@github.com>
Message-ID: <-TUIeF7snwbYVyxnHX_lSFbJJX8uZ9Q_fyeqZPvdBw8=.1763df2a-57f5-4930-94f8-c57f9f8144a3@github.com>

On Tue, 5 Dec 2023 07:37:39 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8321053: instanceof -> ==
>
> src/java.base/share/classes/java/io/ByteArrayInputStream.java line 213:
> 
>> 211:             byte[] tmp;
>> 212:             Class<?> outClass = out.getClass();
>> 213:             if (outClass.getPackageName().equals("java.io") &&
> 
> For what do we need this string-based check here?

I suspect it's left over from a previous iteration. In any case, limiting it to a small number of output streams makes this easier to look at. BAOS and FOS seem okay, POP seems okay too but legacy and not interesting.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16893#discussion_r1415121241

From alanb at openjdk.org  Tue Dec  5 08:45:34 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 5 Dec 2023 08:45:34 GMT
Subject: RFR: 8321270: Virtual Thread.yield consumes parking permit
In-Reply-To: <Y9Veg32y7yuC3Li4u75pFlgrppBp84Y0qQXzAA7cS80=.76a90df6-66c6-4a81-9a83-6a336a02ed9d@github.com>
References: <lO0N190PTq5-xjJV0LlgHWm8srDw2K8aC_U0E5qf4gA=.057efa94-6e79-4c76-9273-32ca1449bf84@github.com>
 <Y9Veg32y7yuC3Li4u75pFlgrppBp84Y0qQXzAA7cS80=.76a90df6-66c6-4a81-9a83-6a336a02ed9d@github.com>
Message-ID: <f6TYFsTq8jNhSgu5etAybxGaUeMNGj_ZMBdZJDKk-DQ=.c37c5318-09f6-4bbf-833b-b3476519e85e@github.com>

On Mon, 4 Dec 2023 21:33:52 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Just want to make sure this change is intentional. Before the comment was: `// runnable-mounted`.

Well spotted, the wrong comment was moved.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16953#discussion_r1415146065

From duke at openjdk.org  Tue Dec  5 08:55:34 2023
From: duke at openjdk.org (ExE Boss)
Date: Tue, 5 Dec 2023 08:55:34 GMT
Subject: RFR: 8321270: Virtual Thread.yield consumes parking permit
In-Reply-To: <lO0N190PTq5-xjJV0LlgHWm8srDw2K8aC_U0E5qf4gA=.057efa94-6e79-4c76-9273-32ca1449bf84@github.com>
References: <lO0N190PTq5-xjJV0LlgHWm8srDw2K8aC_U0E5qf4gA=.057efa94-6e79-4c76-9273-32ca1449bf84@github.com>
Message-ID: <AMwmr-JWpF7Hmpzvg--_-hSXRj0itvAvZG2ey5fk59A=.9047b8d0-0903-4e84-97c7-95eb4c72bdd3@github.com>

On Mon, 4 Dec 2023 16:08:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> When a virtual thread continues after Thread.yield it currently consumes thread's parking permit. This is an oversight, the parking permit should only be consumed when continuing after park.
> 
> The changes are straight-forward. The internal "RUNNABLE" state is replaced with UNPARKED and YIELDED state, effectively encoding the previous state. So for the most part, it's just replacing the usages of RUNNABLE. The additional states require refactoring tryGetStackTrace, this is the method that is used for Thread::getStackTrace when the virtual thread is unmounted. It is also changed to not not swallow the REE if the reesubmit fails (tryStackTrace has to resubmit as the task for the thread may run, or the thread unparked, while "suspended" and sampling its stack trace). The changes are a subset of larger changes in the loom repo, future PRs will propose to bring in other changes to get main line up to date.
> 
> For testing the existing ThreadAPI has new test cases.
> 
> Testing: test1-5. This includes the JVMTI tests as it maps the thread states to JVMTI thread states.

src/hotspot/share/classfile/javaClasses.cpp line 1998:

> 1996:     case UNPARKED:
> 1997:     case YIELDING :
> 1998:     case YIELDED:

Suggestion:

    case UNPARKED :
    case YIELDING :
    case YIELDED :

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16953#discussion_r1414448245

From alanb at openjdk.org  Tue Dec  5 09:08:35 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 5 Dec 2023 09:08:35 GMT
Subject: RFR: 8321270: Virtual Thread.yield consumes parking permit
In-Reply-To: <AMwmr-JWpF7Hmpzvg--_-hSXRj0itvAvZG2ey5fk59A=.9047b8d0-0903-4e84-97c7-95eb4c72bdd3@github.com>
References: <lO0N190PTq5-xjJV0LlgHWm8srDw2K8aC_U0E5qf4gA=.057efa94-6e79-4c76-9273-32ca1449bf84@github.com>
 <AMwmr-JWpF7Hmpzvg--_-hSXRj0itvAvZG2ey5fk59A=.9047b8d0-0903-4e84-97c7-95eb4c72bdd3@github.com>
Message-ID: <132Ng8DJvDqF0qU-n7S166K-uCMTm88bu_8W9JPNLTU=.4c560882-efa1-46e5-822e-09d7a6d849be@github.com>

On Mon, 4 Dec 2023 20:25:56 GMT, ExE Boss <duke at openjdk.org> wrote:

>> When a virtual thread continues after Thread.yield it currently consumes thread's parking permit. This is an oversight, the parking permit should only be consumed when continuing after park.
>> 
>> The changes are straight-forward. The internal "RUNNABLE" state is replaced with UNPARKED and YIELDED state, effectively encoding the previous state. So for the most part, it's just replacing the usages of RUNNABLE. The additional states require refactoring tryGetStackTrace, this is the method that is used for Thread::getStackTrace when the virtual thread is unmounted. It is also changed to not not swallow the REE if the reesubmit fails (tryStackTrace has to resubmit as the task for the thread may run, or the thread unparked, while "suspended" and sampling its stack trace). The changes are a subset of larger changes in the loom repo, future PRs will propose to bring in other changes to get main line up to date.
>> 
>> For testing the existing ThreadAPI has new test cases.
>> 
>> Testing: test1-5. This includes the JVMTI tests as it maps the thread states to JVMTI thread states.
>
> src/hotspot/share/classfile/javaClasses.cpp line 1998:
> 
>> 1996:     case UNPARKED:
>> 1997:     case YIELDING :
>> 1998:     case YIELDED:
> 
> Suggestion:
> 
>     case UNPARKED :
>     case YIELDING :
>     case YIELDED :

I need to check the Hotspot style guide but I think the prevailing convention is no space between the label and the colon.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16953#discussion_r1415177431

From aph at openjdk.org  Tue Dec  5 09:11:46 2023
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 5 Dec 2023 09:11:46 GMT
Subject: RFR: 8318809:
 java/util/concurrent/ConcurrentLinkedQueue/WhiteBox.java shows intermittent
 failures on linux ppc64le and aarch64
In-Reply-To: <iA3gGFe3YwhNjdNk6ZoafPE7ak6VPp0qQ4cgT8R42qE=.30dc4dbc-c24a-4671-83f5-f7be232e1143@github.com>
References: <iA3gGFe3YwhNjdNk6ZoafPE7ak6VPp0qQ4cgT8R42qE=.30dc4dbc-c24a-4671-83f5-f7be232e1143@github.com>
Message-ID: <ZfdB8dzmkemBibEXbgAePF-PLovEg5mA5FxSlAirn1Q=.36b84a9a-aa04-4f6d-9e56-0dfadd4cacef@github.com>

On Wed, 22 Nov 2023 20:48:05 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> We've seen some rare failures of the CLQ Whitebox test on "less-strong" architectures, and the only thing which -- given my research -- could be the culprit is spuriously failing weakCAS (which is correct in terms of the implementation of CLQ).
> 
> After discussion with @DougLea, it was decided as the CLQ implementation does not guarantee what the failing test tests, and modifying the test would mean that it would generally not be able to enforce anything, the test is invalid and should be removed -- hence this PR.

Few AArch64 HotSpot systems implement weak CAS as anything other than plain CAS. In order to get to the root cause of this problem, it would help to know on which AArch64 hardware this test failed.

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

PR Comment: https://git.openjdk.org/jdk/pull/16786#issuecomment-1840319541

From alanb at openjdk.org  Tue Dec  5 09:51:50 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 5 Dec 2023 09:51:50 GMT
Subject: RFR: 8321270: Virtual Thread.yield consumes parking permit [v2]
In-Reply-To: <lO0N190PTq5-xjJV0LlgHWm8srDw2K8aC_U0E5qf4gA=.057efa94-6e79-4c76-9273-32ca1449bf84@github.com>
References: <lO0N190PTq5-xjJV0LlgHWm8srDw2K8aC_U0E5qf4gA=.057efa94-6e79-4c76-9273-32ca1449bf84@github.com>
Message-ID: <T5KeYeQEEyCL1Rs45QmmVemdAOqMNZcQfTaDUS0xyOA=.0b984979-933d-4807-a109-49d22f09e98e@github.com>

> When a virtual thread continues after Thread.yield it currently consumes thread's parking permit. This is an oversight, the parking permit should only be consumed when continuing after park.
> 
> The changes are straight-forward. The internal "RUNNABLE" state is replaced with UNPARKED and YIELDED state, effectively encoding the previous state. So for the most part, it's just replacing the usages of RUNNABLE. The additional states require refactoring tryGetStackTrace, this is the method that is used for Thread::getStackTrace when the virtual thread is unmounted. It is also changed to not not swallow the REE if the reesubmit fails (tryStackTrace has to resubmit as the task for the thread may run, or the thread unparked, while "suspended" and sampling its stack trace). The changes are a subset of larger changes in the loom repo, future PRs will propose to bring in other changes to get main line up to date.
> 
> For testing the existing ThreadAPI has new test cases.
> 
> Testing: test1-5. This includes the JVMTI tests as it maps the thread states to JVMTI thread states.

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

 - Fix comment, remove space between case labels and colon
 - Merge
 - Leave onPinned to another PR
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16953/files
  - new: https://git.openjdk.org/jdk/pull/16953/files/45c6072a..057c9a57

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

  Stats: 2035 lines in 49 files changed: 1448 ins; 293 del; 294 mod
  Patch: https://git.openjdk.org/jdk/pull/16953.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16953/head:pull/16953

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

From mcimadamore at openjdk.org  Tue Dec  5 10:13:42 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 5 Dec 2023 10:13:42 GMT
Subject: RFR: 8321159: SymbolLookup.libraryLookup(Path,
 Arena) Assumes default Filesystem [v4]
In-Reply-To: <QC35Um-xsK_9ym9L8JbvpWw1Um4Wlget4uSau2Ri7kY=.9b537656-de02-43ac-81d0-2c26db6d46a8@github.com>
References: <sbkQW1a7NByueXA7Vm_JVE06P3queX4AkDE-rlFFbgg=.35168862-4033-4184-97c8-86ab21da922e@github.com>
 <QC35Um-xsK_9ym9L8JbvpWw1Um4Wlget4uSau2Ri7kY=.9b537656-de02-43ac-81d0-2c26db6d46a8@github.com>
Message-ID: <L4ZDMf5DhJK2rB1F0DPZHlBYb2wE7zsJ5zt1Hd7-1c4=.9c4adca2-1284-4753-8d3b-b9f910df1135@github.com>

On Tue, 5 Dec 2023 07:16:49 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to reject paths provided to the `SymbolLookup.libraryLookup(Path path, Arena arena)` method if a path is not in the default file system.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change @throws description

src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 297:

> 295:         Reflection.ensureNativeAccess(Reflection.getCallerClass(),
> 296:                 SymbolLookup.class, "libraryLookup");
> 297:         if (!(path.getFileSystem() == FileSystems.getDefault())) {

Shouldn't this be written as `path.getFileSystem() != FileSystems.getDefault()` ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16944#discussion_r1415288970

From jbechberger at openjdk.org  Tue Dec  5 10:14:33 2023
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 5 Dec 2023 10:14:33 GMT
Subject: RFR: 8321300: Cleanup TestHFA
In-Reply-To: <vNC36XRrTzlaWGOAEBTQ9cGj6hihknqfwtabun5Id6Y=.e596f328-122a-4503-9121-800e31951901@github.com>
References: <vNC36XRrTzlaWGOAEBTQ9cGj6hihknqfwtabun5Id6Y=.e596f328-122a-4503-9121-800e31951901@github.com>
Message-ID: <a_tLal-TBy6xBZcAJJyev5R9gMmcqiny2W2VFYqlJo8=.2e3ebe57-11e2-4a07-98dc-65b3aa2a45d1@github.com>

On Mon, 4 Dec 2023 21:25:41 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> I'd like to clean this up: Use the canonical layouts which are available in JDK22. Use try-with-resources for `Arena.ofConfined()`.

Marked as reviewed by jbechberger (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/16959#pullrequestreview-1764635012

From mcimadamore at openjdk.org  Tue Dec  5 10:14:34 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 5 Dec 2023 10:14:34 GMT
Subject: RFR: 8321223: Implementation of Scoped Values (Second Preview)
In-Reply-To: <GHxmDbYHCZyBofn9smONv0FSebHOfYuLEeHzc8cLsMc=.2ad135d9-1ab1-49e3-8bf1-e9e0c0fac310@github.com>
References: <GHxmDbYHCZyBofn9smONv0FSebHOfYuLEeHzc8cLsMc=.2ad135d9-1ab1-49e3-8bf1-e9e0c0fac310@github.com>
Message-ID: <vepPEQkbOH-amozCFrSNOjZzJJmsOSAxrPC3hWeVK2E=.7caeac14-24fd-43a2-9d0c-40be728d78a3@github.com>

On Sun, 3 Dec 2023 08:46:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This API is sitting out JDK 22, meaning no API/implementation changes in this PR. Some small API changes are likely for JDK 23.
> 
> For now, we just need to bump JEP number/title that shows up in the preview section of the javadoc.

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16937#pullrequestreview-1764638933

From mdoerr at openjdk.org  Tue Dec  5 10:14:34 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 5 Dec 2023 10:14:34 GMT
Subject: RFR: 8321300: Cleanup TestHFA
In-Reply-To: <vNC36XRrTzlaWGOAEBTQ9cGj6hihknqfwtabun5Id6Y=.e596f328-122a-4503-9121-800e31951901@github.com>
References: <vNC36XRrTzlaWGOAEBTQ9cGj6hihknqfwtabun5Id6Y=.e596f328-122a-4503-9121-800e31951901@github.com>
Message-ID: <jpcTENGYED_iKaib9jzJzZgEIATnJtjG8EWFBQaemms=.94043f42-4474-42d2-bbec-f89a53277246@github.com>

On Mon, 4 Dec 2023 21:25:41 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> I'd like to clean this up: Use the canonical layouts which are available in JDK22. Use try-with-resources for `Arena.ofConfined()`.

Thanks for the reviews! The Pre-submit test errors are unrelated.

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

PR Comment: https://git.openjdk.org/jdk/pull/16959#issuecomment-1840440238

From sgehwolf at openjdk.org  Tue Dec  5 10:15:44 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 5 Dec 2023 10:15:44 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v10]
In-Reply-To: <PYo6Mc7WoS2PX3rcksdF-Z-svjgwi4sFnWDKpIOdhRY=.7bb8f8ec-98a7-426c-b879-b0b7f656c871@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <SDcwfk1zKIk2TowVOL42C7LM8SfFraZiP5gKNLYxnpI=.bfdaed15-bdbf-4f65-8760-145f58e4513e@github.com>
 <PYo6Mc7WoS2PX3rcksdF-Z-svjgwi4sFnWDKpIOdhRY=.7bb8f8ec-98a7-426c-b879-b0b7f656c871@github.com>
Message-ID: <NXl46xvgLdGZCKJeltIGv7e4sK6NsXH_b7jnNduD6KI=.432cbcbd-2526-40cb-86f1-5cf3bcd95ea5@github.com>

On Wed, 29 Nov 2023 22:38:45 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tighten ModifiedFilesExitTest
>>   
>>   Ensure the error message is reasonable and doesn't include
>>   Exceptions presented to the user.
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/RunImageArchive.java line 47:
> 
>> 45: import jdk.tools.jlink.plugin.ResourcePoolEntry.Type;
>> 46: 
>> 47: public class RunImageArchive implements Archive {
> 
> What about `JimageArchive` or `JRTArchive`?   while jimage does not include the files not in the jimage, it may be okay since that contains most of the files.

Renamed it to `JRTArchive`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1415293858

From mcimadamore at openjdk.org  Tue Dec  5 10:27:39 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 5 Dec 2023 10:27:39 GMT
Subject: RFR: 8321159: SymbolLookup.libraryLookup(Path,
 Arena) Assumes default Filesystem [v4]
In-Reply-To: <QC35Um-xsK_9ym9L8JbvpWw1Um4Wlget4uSau2Ri7kY=.9b537656-de02-43ac-81d0-2c26db6d46a8@github.com>
References: <sbkQW1a7NByueXA7Vm_JVE06P3queX4AkDE-rlFFbgg=.35168862-4033-4184-97c8-86ab21da922e@github.com>
 <QC35Um-xsK_9ym9L8JbvpWw1Um4Wlget4uSau2Ri7kY=.9b537656-de02-43ac-81d0-2c26db6d46a8@github.com>
Message-ID: <e-QNXt2Cy60dwxul5FaWyeQj6YiL-JWURs5ZBpyiPb4=.3080df9a-cd30-4c13-ba75-b3e284e3128f@github.com>

On Tue, 5 Dec 2023 07:16:49 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to reject paths provided to the `SymbolLookup.libraryLookup(Path path, Arena arena)` method if a path is not in the default file system.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change @throws description

Note: this issue needs a CSR

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

PR Comment: https://git.openjdk.org/jdk/pull/16944#issuecomment-1840461321

From duke at openjdk.org  Tue Dec  5 10:51:36 2023
From: duke at openjdk.org (fabioromano1)
Date: Tue, 5 Dec 2023 10:51:36 GMT
Subject: RFR: 8320759: Creation of random BigIntegers can be made faster
 [v3]
In-Reply-To: <nwSbDzk8oUxuEnjahZkRUq0X-q4_344lWakgx3qKAak=.23d3f420-79c0-430b-ae98-9a88404dc43c@github.com>
References: <wIuR7gaQWIRdb8DtEN1VXi9dNkUMuKn8zv3Myc4V2gc=.3356e893-5322-4bb4-aa37-731fb6e9a4b0@github.com>
 <KAD32In5r6VDU4e0LePqKTHv8bn7fc9xb9zAI1UBkHY=.acba81de-6332-4cf9-9a66-d6e0f488b61b@github.com>
 <nwSbDzk8oUxuEnjahZkRUq0X-q4_344lWakgx3qKAak=.23d3f420-79c0-430b-ae98-9a88404dc43c@github.com>
Message-ID: <VBW7YanTP1WZE3HsJGv6A9ANeoq0MuRo4P2dfGlJKNM=.7c6f7e02-c31f-49e4-b0b1-afb557604cf6@github.com>

On Mon, 4 Dec 2023 22:26:32 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Create RandomBigIntegers.java
>>   
>>   Create a benchmark to measure the performance of BigInteger(int, Random) constructor implementation.
>
> Relaying comments from a colleague:
> 
> 1. Half of the random bits are wasted by the use of `nextInt()`, which by default invokes `nextLong()` and throws away the lower 32 bits. Not sure if complicating the code to use all the 64 bits of `nextLong()` is worthwhile, though.
> 
> 2. The way the random bits fill the magnitude array is different. This might break existing reproducible tests with seeded random number generators and fixed seed. Not sure if this is a real problem in practice, though.
> 
> 3. There seems to be no test coverage that ensures the `BigInteger` invariant has either `mag.length == 0` or `mag[0] != 0`. While the code obviously ensures it, future changes might not, so it might make sense to have this aspect covered by a test.

@bplb
1. It would complicate the code, but even use the Random generator less times, so the choice is between code more complicated or more calls to Random generator.

2. This would be a problem only when, to make some comparisons, a test uses the order of filling the magnitude used by the algorithm, I think.

3. If it has to be done, I think it should be by an assertion at the end of `ranfomBits(int, Random)` method, since there is no way to access the class fields for a method outside the package.

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

PR Comment: https://git.openjdk.org/jdk/pull/16817#issuecomment-1840496537

From sgehwolf at openjdk.org  Tue Dec  5 10:58:42 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 5 Dec 2023 10:58:42 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v10]
In-Reply-To: <PYo6Mc7WoS2PX3rcksdF-Z-svjgwi4sFnWDKpIOdhRY=.7bb8f8ec-98a7-426c-b879-b0b7f656c871@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <SDcwfk1zKIk2TowVOL42C7LM8SfFraZiP5gKNLYxnpI=.bfdaed15-bdbf-4f65-8760-145f58e4513e@github.com>
 <PYo6Mc7WoS2PX3rcksdF-Z-svjgwi4sFnWDKpIOdhRY=.7bb8f8ec-98a7-426c-b879-b0b7f656c871@github.com>
Message-ID: <RaJm_JXDXNhaZ9Sma1ZL4YZ0lVTD1G9S0enRDfy9KCI=.c51f32ec-7606-4b43-9fc6-9c0aa27a7d36@github.com>

On Wed, 29 Nov 2023 23:25:03 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tighten ModifiedFilesExitTest
>>   
>>   Ensure the error message is reasonable and doesn't include
>>   Exceptions presented to the user.
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/RunImageArchive.java line 52:
> 
>> 50:     // File marker in lib/modules file for java.base indicating it got created
>> 51:     // with a run-image-type link.
>> 52:     private static final String RUNIMAGE_SINGLE_HOP_STAMP = ".runtimeimage.stamp";
> 
> This marker file is only used by jlink.  So it can be in `jdk.jlink/jdk/tools/jlink/internal/runtimeimage.link.stamp`.

Sure. I've moved it there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1415358766

From jpai at openjdk.org  Tue Dec  5 11:00:53 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 5 Dec 2023 11:00:53 GMT
Subject: RFR: 8321163: [test] OutputAnalyzer.getExitValue() unnecessarily
 logs even when process has already completed [v3]
In-Reply-To: <0GAdkVhk4e3WJp5bQuLdvtxHk5BtRguNmQ7PoQ5dH50=.4f01dd8f-e2f5-47f8-b66a-2801156d56f5@github.com>
References: <uZ77Eagw9Lxz1BKJ8fMnCzvp8Z5VVqsGnsLZtqKZDIo=.0fb8e6cf-7d79-4d4e-b99d-171e008210e9@github.com>
 <0GAdkVhk4e3WJp5bQuLdvtxHk5BtRguNmQ7PoQ5dH50=.4f01dd8f-e2f5-47f8-b66a-2801156d56f5@github.com>
Message-ID: <fSRyNYExpR8nMatf2rIaEYY4X7oisImdgX3EdRmLPSQ=.4c34c0df-51b2-4ed9-9611-da6015a9ff8c@github.com>

On Fri, 1 Dec 2023 12:44:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change to the test library's `OutputAnalyzer` class, which proposes to remove some unnecessary logging from the `getExitValue()` call?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8321163, right now this method logs:
>> 
>> 
>> [2023-11-24T11:47:54.557561Z] Waiting for completion for process 24909
>> [2023-11-24T11:47:54.557873Z] Waiting for completion finished for process 24909
>> 
>> 
>> even when the process has already completed and the exit value already known. The change in this PR makes it such that if the exit value is available then we no longer log this (nor call `process.waitFor()`).
>> 
>> No new tests have been added given the nature of this change. tier1, tier2 and tier3 tests continue to pass with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove micro optimization

Thank you Stefan and Leonid for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/16919#issuecomment-1840512527

From jpai at openjdk.org  Tue Dec  5 11:00:54 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 5 Dec 2023 11:00:54 GMT
Subject: Integrated: 8321163: [test] OutputAnalyzer.getExitValue()
 unnecessarily logs even when process has already completed
In-Reply-To: <uZ77Eagw9Lxz1BKJ8fMnCzvp8Z5VVqsGnsLZtqKZDIo=.0fb8e6cf-7d79-4d4e-b99d-171e008210e9@github.com>
References: <uZ77Eagw9Lxz1BKJ8fMnCzvp8Z5VVqsGnsLZtqKZDIo=.0fb8e6cf-7d79-4d4e-b99d-171e008210e9@github.com>
Message-ID: <1Zx9HZ6ejuXso33ooAixXusPKJWtbE1TLXOfW_bfEpA=.fdfc0210-0a0f-439d-b9b1-df946b280c5b@github.com>

On Fri, 1 Dec 2023 09:48:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change to the test library's `OutputAnalyzer` class, which proposes to remove some unnecessary logging from the `getExitValue()` call?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8321163, right now this method logs:
> 
> 
> [2023-11-24T11:47:54.557561Z] Waiting for completion for process 24909
> [2023-11-24T11:47:54.557873Z] Waiting for completion finished for process 24909
> 
> 
> even when the process has already completed and the exit value already known. The change in this PR makes it such that if the exit value is available then we no longer log this (nor call `process.waitFor()`).
> 
> No new tests have been added given the nature of this change. tier1, tier2 and tier3 tests continue to pass with this change.

This pull request has now been integrated.

Changeset: 672f3732
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/672f37324f9f15ae3e03b9b3b86c7106e6a09eed
Stats:     7 lines in 1 file changed: 4 ins; 0 del; 3 mod

8321163: [test] OutputAnalyzer.getExitValue() unnecessarily logs even when process has already completed

Reviewed-by: stefank, lmesnik

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

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

From sgehwolf at openjdk.org  Tue Dec  5 11:11:39 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 5 Dec 2023 11:11:39 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v10]
In-Reply-To: <DJXEI0UeDXJQdxTyrsQiyqSwNGZMYoqeiH0DTEbRcPI=.2f7fa7cc-facb-460d-8783-23c9609198ba@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <SDcwfk1zKIk2TowVOL42C7LM8SfFraZiP5gKNLYxnpI=.bfdaed15-bdbf-4f65-8760-145f58e4513e@github.com>
 <PYo6Mc7WoS2PX3rcksdF-Z-svjgwi4sFnWDKpIOdhRY=.7bb8f8ec-98a7-426c-b879-b0b7f656c871@github.com>
 <wD1pw0vtU5rXq_B-Uj4rNa1ZlcwnBlqRTltDQVRlYjU=.fdee5780-1f84-4998-93d4-71ef15eb0c24@github.com>
 <DJXEI0UeDXJQdxTyrsQiyqSwNGZMYoqeiH0DTEbRcPI=.2f7fa7cc-facb-460d-8783-23c9609198ba@github.com>
Message-ID: <-fjrJO8j-FKZ10UoTnFLEhbEOBPBufdjIaVAl9BUykE=.7eea1cc6-62ea-4328-911e-8a0bb77c2347@github.com>

On Thu, 30 Nov 2023 17:19:14 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Sure this can be done. Makes the jimage a bit larger, but probably negligible as the total set of modules is usually small.
>
> It adds more empty files which I expect should be very small increase in size.   Since this is added by default, we can measure the difference and confirm from the JDK build.

Incidentally it won't save anything for the default JDK build, since all modules include legal files which end up being tracked in those files. So I don't think adding resource files unconditionally matters in practise.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1415377556

From ihse at openjdk.org  Tue Dec  5 11:21:36 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 5 Dec 2023 11:21:36 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v8]
In-Reply-To: <v95kXnbADF5XriLfeg2v5yVYBo-BUzR-dhpcubuMDcI=.03d8e5a7-8b0c-4291-99df-2d3ec6cd356c@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <e5w5YZ0WD8S3UVFBYz6I0PdKZ6yOkD77BCq2arDd6i4=.7eecadcb-e627-4e9b-8f1e-3fc41c63243b@github.com>
 <bopxvLCquUtZQxt8kAJskzXBR2YE_I0PW13i3NBJNNY=.e65abf3d-0ff4-4450-875b-ca3717170485@github.com>
 <DeQgR1PaXlk2yzlxV15N3ViZY26wXtlgfVKxRY6vuWo=.6d38f729-0ca9-4f43-9e23-f5e73a01cc23@github.com>
 <b1Nv5Y7Klpvp5ACcHJTTblwGmnA64cyRg-3YzotaHvc=.0bd8a0f0-0844-44a9-a3bb-4af2e8514ee1@github.com>
 <t_23EA--aX8v2US9Lsib1ZF3bl4HQx_Z4RXqlgQo8LE=.6f1f2873-015c-4b69-ad47-b449e5b77a45@github.com>
 <pRcJlU1a4jG9gMaftLn5IerudMSDIrvr70KBefkpNSo=.f442f0d4-887f-4376-a66e-8254fa35927c@github.com>
 <OJ1ZK4a8c_bZik60v503VUtZoweFFv6VhhGg1sp4qSY=.e8852bf1-2d7f-4164-b952-d88b294ec1f7@github.com>
 <_gSNXk0qGAtpY-WJ5OCHk_3-nuGrwwSn-ffK9f2TEcs=.40f785ba-83dd-40fe-8075-a7a7872ea600@github.com>
 <v95kXnbADF5XriLfeg2v5yVYBo-BUzR-dhpcubuMDcI=.03d8e5a7-8b0c-4291-99df-2d3ec6cd356c@github.com>
Message-ID: <D2AGAYSictxU124OSQMg3V5bpM1oKBdxKLdBS0X7ow8=.326a6f38-e9ab-4b24-a6d6-d8eebdb346f7@github.com>

On Mon, 4 Dec 2023 22:14:14 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> Then you must add logic to check for this. Now the build will just fail if building with an older gcc. That is not acceptable.
>
> Hi Marcus (@magicus), please see the updated code which added guards to check for GCC version >= 7.5 in `src/java.base/linux/native/libsimdsort/{avx2-linux-qsort.cpp, avx512-linux-qsort.cpp}`. GCC >= 7.5 is needed to compile libsimdsort using C++17 features. Made sure that OpenJDK builds without errors using both GCC 7.5 and GCC 6.4.

That sounds weird. You can't check for if compiler options should be enabled or not inside source code files.

Are you saying that when compiling with GCC 6, it will just silently ignore `-std=c++17`? I'd have assumed that it printed a warning or error about an unknown or invalid option, if C++17 is not supported.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1415392615

From rgiulietti at openjdk.org  Tue Dec  5 11:51:36 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 5 Dec 2023 11:51:36 GMT
Subject: RFR: 8320759: Creation of random BigIntegers can be made faster
 [v3]
In-Reply-To: <VBW7YanTP1WZE3HsJGv6A9ANeoq0MuRo4P2dfGlJKNM=.7c6f7e02-c31f-49e4-b0b1-afb557604cf6@github.com>
References: <wIuR7gaQWIRdb8DtEN1VXi9dNkUMuKn8zv3Myc4V2gc=.3356e893-5322-4bb4-aa37-731fb6e9a4b0@github.com>
 <KAD32In5r6VDU4e0LePqKTHv8bn7fc9xb9zAI1UBkHY=.acba81de-6332-4cf9-9a66-d6e0f488b61b@github.com>
 <nwSbDzk8oUxuEnjahZkRUq0X-q4_344lWakgx3qKAak=.23d3f420-79c0-430b-ae98-9a88404dc43c@github.com>
 <VBW7YanTP1WZE3HsJGv6A9ANeoq0MuRo4P2dfGlJKNM=.7c6f7e02-c31f-49e4-b0b1-afb557604cf6@github.com>
Message-ID: <rT4VwYtoNwnsiODyZKJHWBtCmUFMe880CXLbIBsQJsA=.12841990-81f4-4899-ba9c-c30a6b7cbf6e@github.com>

On Tue, 5 Dec 2023 10:46:41 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> Relaying comments from a colleague:
>> 
>> 1. Half of the random bits are wasted by the use of `nextInt()`, which by default invokes `nextLong()` and throws away the lower 32 bits. Not sure if complicating the code to use all the 64 bits of `nextLong()` is worthwhile, though.
>> 
>> 2. The way the random bits fill the magnitude array is different. This might break existing reproducible tests with seeded random number generators and fixed seed. Not sure if this is a real problem in practice, though.
>> 
>> 3. There seems to be no test coverage that ensures the `BigInteger` invariant has either `mag.length == 0` or `mag[0] != 0`. While the code obviously ensures it, future changes might not, so it might make sense to have this aspect covered by a test.
>
> @bplb
> 1. It would complicate the code, but even use the Random generator less times, so the choice is between code more complicated or more calls to Random generator.
> 
> 2. This would be a problem only when, to make some comparisons, a test uses the order of filling the magnitude used by the algorithm, I think.
> 
> 3. If it has to be done, I think it should be by an assertion at the end of `ranfomBits(int, Random)` method, since there is no way to access the class fields for a method outside the package.

@fabioromano1 

About item 2. If a test external to OpenJDK uses a seedable random generator and initializes it with a fixed seed, and if it then compares the result with an expected value, after the change the test breaks. As mentioned, this might not be a problem in practice.

About item 3. You can take a look at [this test](https://github.com/openjdk/jdk/blob/master/test/jdk/java/math/BigInteger/ByteArrayConstructorTest.java) to see how to access the fields using [this class](https://github.com/openjdk/jdk/blob/master/test/jdk/java/math/BigInteger/java.base/java/math/Accessor.java).

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

PR Comment: https://git.openjdk.org/jdk/pull/16817#issuecomment-1840635876

From vklang at openjdk.org  Tue Dec  5 12:01:35 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 5 Dec 2023 12:01:35 GMT
Subject: RFR: 8321124: java/util/stream/GatherersTest.java times out [v4]
In-Reply-To: <fZlWSWZOW3WxqXnYmDQ0q2WiRpgoc9BpEHNaKKO30yQ=.2b66f9e5-cdcb-4054-91a0-f22a4b267c47@github.com>
References: <NcgSgagzqKytU8dGSMKHUF_9ylICS5s6If5CoFRjPhw=.abef3a79-b429-47c5-b0b7-aa7b9f71ef31@github.com>
 <fZlWSWZOW3WxqXnYmDQ0q2WiRpgoc9BpEHNaKKO30yQ=.2b66f9e5-cdcb-4054-91a0-f22a4b267c47@github.com>
Message-ID: <CwERMfQc82ErqzKOfveATGGbOU7F8J3jYIQb9b4vZbY=.6f75a5a9-f16a-4d45-ab8a-1948a835ac54@github.com>

On Mon, 4 Dec 2023 14:25:05 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Splits GatherersTest out to distinct files per built-in gatherer
>> 
>> Fixes a test ordering issue for mapConcurrent which placed GatherersTest on the ProblemList.
>> 
>> Adding increased maxOutputSize for Gatherer-related tests to improve debuggability.
>> 
>> Lowering the composition threshold of GathererTest.testMassivelyComposedGatherers to 256 to avoid SOE on low-specc:ed machines.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing extraneous built-in gatherer test output

test/jdk/java/util/stream/GatherersScanTest.java line 42:

> 40:  */
> 41: 
> 42: public class GatherersScanTest {

@AlanBateman This restores the scan tests, which somehow were missing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16928#discussion_r1415480754

From pminborg at openjdk.org  Tue Dec  5 12:02:59 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 5 Dec 2023 12:02:59 GMT
Subject: RFR: 8321159: SymbolLookup.libraryLookup(Path,
 Arena) Assumes default Filesystem [v5]
In-Reply-To: <sbkQW1a7NByueXA7Vm_JVE06P3queX4AkDE-rlFFbgg=.35168862-4033-4184-97c8-86ab21da922e@github.com>
References: <sbkQW1a7NByueXA7Vm_JVE06P3queX4AkDE-rlFFbgg=.35168862-4033-4184-97c8-86ab21da922e@github.com>
Message-ID: <bO-z1_vyEjDritmqDQtGgUz5MTywhoHfZRXIoZshsYg=.f6cb57a8-d0e6-4445-8f10-0ee0987a2c57@github.com>

> This PR proposes to reject paths provided to the `SymbolLookup.libraryLookup(Path path, Arena arena)` method if a path is not in the default file system.

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

  Fix double negation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16944/files
  - new: https://git.openjdk.org/jdk/pull/16944/files/fae3db5d..42208da2

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

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

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

From duke at openjdk.org  Tue Dec  5 12:51:39 2023
From: duke at openjdk.org (fabioromano1)
Date: Tue, 5 Dec 2023 12:51:39 GMT
Subject: RFR: 8320759: Creation of random BigIntegers can be made faster
 [v3]
In-Reply-To: <nwSbDzk8oUxuEnjahZkRUq0X-q4_344lWakgx3qKAak=.23d3f420-79c0-430b-ae98-9a88404dc43c@github.com>
References: <wIuR7gaQWIRdb8DtEN1VXi9dNkUMuKn8zv3Myc4V2gc=.3356e893-5322-4bb4-aa37-731fb6e9a4b0@github.com>
 <KAD32In5r6VDU4e0LePqKTHv8bn7fc9xb9zAI1UBkHY=.acba81de-6332-4cf9-9a66-d6e0f488b61b@github.com>
 <nwSbDzk8oUxuEnjahZkRUq0X-q4_344lWakgx3qKAak=.23d3f420-79c0-430b-ae98-9a88404dc43c@github.com>
Message-ID: <VxebsrgBYPN7t77aYda6L3KGp7RptLXn_LfOWFW92Oo=.5d0e5098-b722-4de4-be67-009f76014a08@github.com>

On Mon, 4 Dec 2023 22:26:32 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Create RandomBigIntegers.java
>>   
>>   Create a benchmark to measure the performance of BigInteger(int, Random) constructor implementation.
>
> Relaying comments from a colleague:
> 
> 1. Half of the random bits are wasted by the use of `nextInt()`, which by default invokes `nextLong()` and throws away the lower 32 bits. Not sure if complicating the code to use all the 64 bits of `nextLong()` is worthwhile, though.
> 
> 2. The way the random bits fill the magnitude array is different. This might break existing reproducible tests with seeded random number generators and fixed seed. Not sure if this is a real problem in practice, though.
> 
> 3. There seems to be no test coverage that ensures the `BigInteger` invariant has either `mag.length == 0` or `mag[0] != 0`. While the code obviously ensures it, future changes might not, so it might make sense to have this aspect covered by a test.

@bplb
About point 1. The behavior of `nextInt()` depends by the implementation of the Random object specified, which of course is not predictable. Furthermore, the claim that `nextInt()` invokes `nextLong()` by default and throws away the lower 32 bits is evidently denied by the facts: simply look at the last version of the method implementation in the class Random: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/Random.java#L494
So, in the light of that, I think it's not worthwhile using `nextLong()` instead of `nextInt()`, it would only complicate the code.

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

PR Comment: https://git.openjdk.org/jdk/pull/16817#issuecomment-1840727834

From duke at openjdk.org  Tue Dec  5 13:01:35 2023
From: duke at openjdk.org (Markus KARG)
Date: Tue, 5 Dec 2023 13:01:35 GMT
Subject: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter
 of transferTo() is trusted [v4]
In-Reply-To: <-TUIeF7snwbYVyxnHX_lSFbJJX8uZ9Q_fyeqZPvdBw8=.1763df2a-57f5-4930-94f8-c57f9f8144a3@github.com>
References: <zRINQ_LiJh7Ifnt7UwL2Q0PcpestYwzx74fopLor_2w=.c93f3a3a-8172-40d2-9e5d-0530eb905f2a@github.com>
 <G1i2jgvLHa3whZRh-xQDs-cf0JoBTflxeKuUFR1qEGo=.2df02966-3131-4af9-bb9b-96480fc32859@github.com>
 <4bwttMfJ29GTFbt-8ob46PQjhiZUZi9xmCuajK7nM4U=.6b56d022-5867-4063-9486-4168f43d8bdc@github.com>
 <-TUIeF7snwbYVyxnHX_lSFbJJX8uZ9Q_fyeqZPvdBw8=.1763df2a-57f5-4930-94f8-c57f9f8144a3@github.com>
Message-ID: <qcFIqCTdbAp4OW_TTFnXLcqIfEEPv7jI1i8k9Clb82A=.3c8e1c48-0a4c-4e42-99c3-111dc0aa2c79@github.com>

On Tue, 5 Dec 2023 08:27:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I suspect it's left over from a previous iteration. In any case, limiting it to a small number of output streams makes this easier to look at. BAOS and FOS seem okay, POP seems okay too but legacy and not interesting.

Agreed for a rather short list of explicitly whitelisted implementations. We should get rid of the package check.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16893#discussion_r1415569212

From ihse at openjdk.org  Tue Dec  5 13:02:47 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 5 Dec 2023 13:02:47 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v6]
In-Reply-To: <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
Message-ID: <yB8Wm-5B6h7aHyZyF0zgoc8Bem8Q0FCO5HDo9dlAiCI=.c19369f6-d48e-4c92-9ae4-83d1478be11f@github.com>

On Fri, 1 Dec 2023 08:48:52 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
>> 
>> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
>> 
>> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
>> 
>> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
>> 
>> [1] https://github.com/openjdk/jdk/pull/3638
>> [2] https://sleef.org/
>> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
>> [4] https://packages.debian.org/bookworm/libsleef3
>> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html
>
> Xiaohong Gong has updated the pull request with a new target base 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:
> 
>  - Separate neon and sve functions into two source files
>  - Merge branch 'jdk:master' into JDK-8312425
>  - Rename vmath to sleef in configure
>  - Address review comments in build system
>  - Add a bundled native lib in jdk as a bridge to libsleef
>  - Merge 'jdk:master' into JDK-8312425
>  - Disable sleef by default
>  - Merge 'jdk:master' into JDK-8312425
>  - 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF

So you need to check both the flag and the header file? Oh well, then this is probably as good as it gets.

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1840748314

From ihse at openjdk.org  Tue Dec  5 13:05:48 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 5 Dec 2023 13:05:48 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v5]
In-Reply-To: <tHkg8-8CbvcHsfEhonfA4PxB_XXjonY5MbmunXEfFEI=.428e7a97-0bce-4f17-b93c-3275037e5a66@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <nZFspjlPXfeQxrr5cKfbjeL3typf6DKSgNQUNszhufE=.caac471d-9c7b-4f8f-953f-04ee4a13f111@github.com>
 <9VeMdTAJPaPZDg9ZW7FVJOf9XGl4gGqAS-2g8SFc9c0=.36792cd5-66d9-4abc-ba0c-aee3478627f4@github.com>
 <mnf_hjWdemelALPlwcS8mnKIxR5ljIyGD6MHpqCPDsQ=.0cb49580-ed76-4728-a604-acff3dff42a5@github.com>
 <aArEqABKvjZDCxOkkpKS1rlX9Q0aafCUY8ZS3L5OBek=.f009f07b-c9e4-437b-a6d3-c86fb29d75a0@github.com>
 <vlqKSuAKzKRTXWG_hLCEJixN8oFec68IuSnfb0u9OJ0=.6c926fc3-f0f3-4ccf-b373-555948c3702b@github.com>
 <a0fi6KAaaVceRSRWzviR0W1iN-CjlkCIS9GjHAxRr5g=.324dd1aa-d4bd-48f1-8e23-604b09b75b4c@github.com>
 <tHkg8-8CbvcHsfEhonfA4PxB_XXjonY5MbmunXEfFEI=.428e7a97-0bce-4f17-b93c-3275037e5a66@github.com>
Message-ID: <Zhu-7NV4dgrBXks4CoC1tNs-4WFmoQvBo-tzqYjbY50=.210204f3-7ed2-4d40-a7c7-c1989530dca0@github.com>

On Tue, 5 Dec 2023 07:21:32 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> also, ideally, you will add the corresponding specific overrides like in ffi:
>> 
>>   AC_ARG_WITH(libffi-include, [AS_HELP_STRING([--with-libffi-include],
>>       [specify directory for the libffi include files])])
>>   AC_ARG_WITH(libffi-lib, [AS_HELP_STRING([--with-libffi-lib],
>>       [specify directory for the libffi library])])
>
> Thanks for the suggestion @magicus !
> 
> The check in current `lib-sleef.m4` is very common:
> 
> -  If user has specified libsleef root by '--with-libsleef', we assume it is the manually built sleef lib. So only `lib/` and `include/` is checked. And the flags are set based on that path.
> - If user has not specified the libsleef root, and no `SYSROOT` is set, we try `PKG_CHECK` (like what you suggested)
> - Otherwise, check `sleef.h`   
>    - We assume the sleef module is installed under one of the valid system paths if the header can be found. So just linking with `-lsleef` will success.
> 
> It's an issue in current flow like what @theRealAph met. I will add the options like `--with-libsleef-lib` and `--with-libsleef-include` like ffi. Regarding to extending the check for`--with-libsleef`, I think we can just make it simple like what it is now. Or, we have to check all the potential valid lib paths like `lib/`, `lib64/`, or maybe `lib/aarch64-linux-gnu`. The same to the `include` part.  @theRealAph @magicus , WDYT?

I'm fine with adding just --with-libsleef-lib and --with-libsleef-include to specify them directly. This makes it at least possible to use, if not overly convenient, for people using a system like Andrew's. If it annoys someone too much, we can extend it later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1415576201

From mdoerr at openjdk.org  Tue Dec  5 14:01:46 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 5 Dec 2023 14:01:46 GMT
Subject: Integrated: 8321300: Cleanup TestHFA
In-Reply-To: <vNC36XRrTzlaWGOAEBTQ9cGj6hihknqfwtabun5Id6Y=.e596f328-122a-4503-9121-800e31951901@github.com>
References: <vNC36XRrTzlaWGOAEBTQ9cGj6hihknqfwtabun5Id6Y=.e596f328-122a-4503-9121-800e31951901@github.com>
Message-ID: <vIBs1JI9-ZyPt_F2XCOTQ40z2fUW31iTagcNNNHNw_w=.e8575710-c676-4e87-8b77-551f8d11488e@github.com>

On Mon, 4 Dec 2023 21:25:41 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> I'd like to clean this up: Use the canonical layouts which are available in JDK22. Use try-with-resources for `Arena.ofConfined()`.

This pull request has now been integrated.

Changeset: a1fe16b5
Author:    Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a1fe16b5ecb3cbb42ecb4135260c6ba191a25a87
Stats:     141 lines in 1 file changed: 1 ins; 10 del; 130 mod

8321300: Cleanup TestHFA

Reviewed-by: jvernee, jbechberger

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

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

From alanb at openjdk.org  Tue Dec  5 14:13:39 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 5 Dec 2023 14:13:39 GMT
Subject: RFR: 8321124: java/util/stream/GatherersTest.java times out [v4]
In-Reply-To: <fZlWSWZOW3WxqXnYmDQ0q2WiRpgoc9BpEHNaKKO30yQ=.2b66f9e5-cdcb-4054-91a0-f22a4b267c47@github.com>
References: <NcgSgagzqKytU8dGSMKHUF_9ylICS5s6If5CoFRjPhw=.abef3a79-b429-47c5-b0b7-aa7b9f71ef31@github.com>
 <fZlWSWZOW3WxqXnYmDQ0q2WiRpgoc9BpEHNaKKO30yQ=.2b66f9e5-cdcb-4054-91a0-f22a4b267c47@github.com>
Message-ID: <ug9KVMbmN9hV4riUYVF5Ephd-W2ZvulBzHLaP6PT1SY=.2719c457-d1f5-436f-8d48-b90516346839@github.com>

On Mon, 4 Dec 2023 14:25:05 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Splits GatherersTest out to distinct files per built-in gatherer
>> 
>> Fixes a test ordering issue for mapConcurrent which placed GatherersTest on the ProblemList.
>> 
>> Adding increased maxOutputSize for Gatherer-related tests to improve debuggability.
>> 
>> Lowering the composition threshold of GathererTest.testMassivelyComposedGatherers to 256 to avoid SOE on low-specc:ed machines.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing extraneous built-in gatherer test output

test/jdk/java/util/stream/GatherersMapConcurrentTest.java line 106:

> 104:             );
> 105:         assertEquals("expected", exception.getMessage());
> 106:         assertNull(exception.getCause());

I assume it would be possible to add a comrade to this test for the wrapping case too, e.g. if the mapper throws an Error.

test/jdk/java/util/stream/GatherersMapConcurrentTest.java line 245:

> 243:     public void behavesAsExpected(Config config) {
> 244:         for (var concurrency : List.of(1, 2, 3, 10, 1000)) {
> 245:             final var expectedResult = config.stream()

I assume the loop is here because you can't have both a MethodSource and ValueSource. I think I'd probably create a new method source for this, e.g.


    static Stream<Arguments> configutatonAndConcurrency() {
        return IntStream.of(1, 2, 3, 10, 1000)
                .mapToObj(i -> i)
                .flatMap(i -> configurations().map(c -> new Arguments(c, i)));
    }


The advantage is that you'll have the parameter in the .jtr in the event of a failure.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16928#discussion_r1415671564
PR Review Comment: https://git.openjdk.org/jdk/pull/16928#discussion_r1415665826

From vklang at openjdk.org  Tue Dec  5 14:22:40 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 5 Dec 2023 14:22:40 GMT
Subject: RFR: 8321124: java/util/stream/GatherersTest.java times out [v4]
In-Reply-To: <ug9KVMbmN9hV4riUYVF5Ephd-W2ZvulBzHLaP6PT1SY=.2719c457-d1f5-436f-8d48-b90516346839@github.com>
References: <NcgSgagzqKytU8dGSMKHUF_9ylICS5s6If5CoFRjPhw=.abef3a79-b429-47c5-b0b7-aa7b9f71ef31@github.com>
 <fZlWSWZOW3WxqXnYmDQ0q2WiRpgoc9BpEHNaKKO30yQ=.2b66f9e5-cdcb-4054-91a0-f22a4b267c47@github.com>
 <ug9KVMbmN9hV4riUYVF5Ephd-W2ZvulBzHLaP6PT1SY=.2719c457-d1f5-436f-8d48-b90516346839@github.com>
Message-ID: <6bmSckBExOoqr5QoB_YK5VPtwZ9Vc0L8gFxA4QQf92A=.bfb79608-c897-4df8-aefd-1619153f6aa2@github.com>

On Tue, 5 Dec 2023 14:07:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removing extraneous built-in gatherer test output
>
> test/jdk/java/util/stream/GatherersMapConcurrentTest.java line 106:
> 
>> 104:             );
>> 105:         assertEquals("expected", exception.getMessage());
>> 106:         assertNull(exception.getCause());
> 
> I assume it would be possible to add a comrade to this test for the wrapping case too, e.g. if the mapper throws an Error.

@AlanBateman Yes, good point. I'll add that as well now ?

> test/jdk/java/util/stream/GatherersMapConcurrentTest.java line 245:
> 
>> 243:     public void behavesAsExpected(Config config) {
>> 244:         for (var concurrency : List.of(1, 2, 3, 10, 1000)) {
>> 245:             final var expectedResult = config.stream()
> 
> I assume the loop is here because you can't have both a MethodSource and ValueSource. I think I'd probably create a new method source for this, e.g.
> 
> 
>     static Stream<Arguments> configutatonAndConcurrency() {
>         return IntStream.of(1, 2, 3, 10, 1000)
>                 .mapToObj(i -> i)
>                 .flatMap(i -> configurations().map(c -> new Arguments(c, i)));
>     }
> 
> 
> The advantage is that you'll have the parameter in the .jtr in the event of a failure.

@AlanBateman Yeah, it's an unfortunate limitation of JUnit. Ideally I'd like to have an annotation per argument and being able to specify that I'd like the framework to execute it as a cartesian product.

Do you want me to make this change as a part of this PR or does it make more sense to get this one integrated first?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16928#discussion_r1415691074
PR Review Comment: https://git.openjdk.org/jdk/pull/16928#discussion_r1415690167

From alanb at openjdk.org  Tue Dec  5 14:28:36 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 5 Dec 2023 14:28:36 GMT
Subject: RFR: 8321124: java/util/stream/GatherersTest.java times out [v4]
In-Reply-To: <6bmSckBExOoqr5QoB_YK5VPtwZ9Vc0L8gFxA4QQf92A=.bfb79608-c897-4df8-aefd-1619153f6aa2@github.com>
References: <NcgSgagzqKytU8dGSMKHUF_9ylICS5s6If5CoFRjPhw=.abef3a79-b429-47c5-b0b7-aa7b9f71ef31@github.com>
 <fZlWSWZOW3WxqXnYmDQ0q2WiRpgoc9BpEHNaKKO30yQ=.2b66f9e5-cdcb-4054-91a0-f22a4b267c47@github.com>
 <ug9KVMbmN9hV4riUYVF5Ephd-W2ZvulBzHLaP6PT1SY=.2719c457-d1f5-436f-8d48-b90516346839@github.com>
 <6bmSckBExOoqr5QoB_YK5VPtwZ9Vc0L8gFxA4QQf92A=.bfb79608-c897-4df8-aefd-1619153f6aa2@github.com>
Message-ID: <kG4LX940p6uvR_Z-H21duFgEwA7Q5yImNTwFWappHn4=.726acddc-ff97-4659-a048-40135a3def30@github.com>

On Tue, 5 Dec 2023 14:19:34 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Do you want me to make this change as a part of this PR or does it make more sense to get this one integrated first?

I think it's okay to leave it to another time, I assume these tests be updated a few times before the feature becomes permanent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16928#discussion_r1415699661

From vklang at openjdk.org  Tue Dec  5 14:55:02 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 5 Dec 2023 14:55:02 GMT
Subject: RFR: 8321124: java/util/stream/GatherersTest.java times out [v5]
In-Reply-To: <NcgSgagzqKytU8dGSMKHUF_9ylICS5s6If5CoFRjPhw=.abef3a79-b429-47c5-b0b7-aa7b9f71ef31@github.com>
References: <NcgSgagzqKytU8dGSMKHUF_9ylICS5s6If5CoFRjPhw=.abef3a79-b429-47c5-b0b7-aa7b9f71ef31@github.com>
Message-ID: <pegi_30MseGhnGUE2sEvUEz0fqiKJFKTQMZK0_WcjjY=.6ba87409-d5e4-4e5e-a836-bcbfaded061f@github.com>

> Splits GatherersTest out to distinct files per built-in gatherer
> 
> Fixes a test ordering issue for mapConcurrent which placed GatherersTest on the ProblemList.
> 
> Adding increased maxOutputSize for Gatherer-related tests to improve debuggability.
> 
> Lowering the composition threshold of GathererTest.testMassivelyComposedGatherers to 256 to avoid SOE on low-specc:ed machines.

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

  Addressing review feedback: improving test coverage and debuggability

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16928/files
  - new: https://git.openjdk.org/jdk/pull/16928/files/fd426ae7..663a7b64

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

  Stats: 76 lines in 1 file changed: 49 ins; 9 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/16928.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16928/head:pull/16928

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

From jlaskey at openjdk.org  Tue Dec  5 15:03:30 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 5 Dec 2023 15:03:30 GMT
Subject: RFR: JDK-8320570 NegativeArraySizeException decoding >1G UTF8 bytes
 with non-ascii characters
Message-ID: <wK-u3PPhgDfuUAGIWQNgYs_gxKrDVjsNs8ImLonZObU=.49b3b03b-6deb-418a-9ab0-9c9fc563b33a@github.com>

A regression is found in Java9+ creating String instance from UTF8 bytes, a side effect of string compactation https://openjdk.org/jeps/254 that changed the decoding logic. Specifically, when constructing a string from bytes: 

``` 
String str = new String(largeBytes, StandardCharsets.UTF_8); 
``` 

if the size of largeBytes is greater than 2^30 (>1 GB) but smaller than INT_MAX (2 GB), it fails on Java9+ (including 11, 17, 21, though the stack trace is slightly different, see below), regardless of jvm heap size. In Java8, it succeeded when jvm heap size is set to be sufficient.

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

Commit messages:
 - Initial commit

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

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

From rriggs at openjdk.org  Tue Dec  5 15:05:36 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 5 Dec 2023 15:05:36 GMT
Subject: RFR: JDK-8320570 NegativeArraySizeException decoding >1G UTF8
 bytes with non-ascii characters
In-Reply-To: <wK-u3PPhgDfuUAGIWQNgYs_gxKrDVjsNs8ImLonZObU=.49b3b03b-6deb-418a-9ab0-9c9fc563b33a@github.com>
References: <wK-u3PPhgDfuUAGIWQNgYs_gxKrDVjsNs8ImLonZObU=.49b3b03b-6deb-418a-9ab0-9c9fc563b33a@github.com>
Message-ID: <5oAI50l-WXpEtHXBZxKxqnOY5ADTfvPhIwpfRxYzaVk=.1806cf50-3bbc-4aa8-91d9-1f0b0631a8b7@github.com>

On Tue, 5 Dec 2023 14:57:09 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> A regression is found in Java9+ creating String instance from UTF8 bytes, a side effect of string compactation https://openjdk.org/jeps/254 that changed the decoding logic. Specifically, when constructing a string from bytes: 
> 
> ``` 
> String str = new String(largeBytes, StandardCharsets.UTF_8); 
> ``` 
> 
> if the size of largeBytes is greater than 2^30 (>1 GB) but smaller than INT_MAX (2 GB), it fails on Java9+ (including 11, 17, 21, though the stack trace is slightly different, see below), regardless of jvm heap size. In Java8, it succeeded when jvm heap size is set to be sufficient.

Looks good; thanks for the new test.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16974#pullrequestreview-1765330621

From rgiulietti at openjdk.org  Tue Dec  5 15:21:38 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 5 Dec 2023 15:21:38 GMT
Subject: RFR: 8320759: Creation of random BigIntegers can be made faster
 [v3]
In-Reply-To: <VxebsrgBYPN7t77aYda6L3KGp7RptLXn_LfOWFW92Oo=.5d0e5098-b722-4de4-be67-009f76014a08@github.com>
References: <wIuR7gaQWIRdb8DtEN1VXi9dNkUMuKn8zv3Myc4V2gc=.3356e893-5322-4bb4-aa37-731fb6e9a4b0@github.com>
 <KAD32In5r6VDU4e0LePqKTHv8bn7fc9xb9zAI1UBkHY=.acba81de-6332-4cf9-9a66-d6e0f488b61b@github.com>
 <nwSbDzk8oUxuEnjahZkRUq0X-q4_344lWakgx3qKAak=.23d3f420-79c0-430b-ae98-9a88404dc43c@github.com>
 <VxebsrgBYPN7t77aYda6L3KGp7RptLXn_LfOWFW92Oo=.5d0e5098-b722-4de4-be67-009f76014a08@github.com>
Message-ID: <Vl5D2psfAHNAPvBJh3RvZlPCgpwFUmgqOC0Y9AVBs6k=.14067821-5211-4e21-a8c6-e74cb96e7b3c@github.com>

On Tue, 5 Dec 2023 12:46:49 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> Relaying comments from a colleague:
>> 
>> 1. Half of the random bits are wasted by the use of `nextInt()`, which by default invokes `nextLong()` and throws away the lower 32 bits. Not sure if complicating the code to use all the 64 bits of `nextLong()` is worthwhile, though.
>> 
>> 2. The way the random bits fill the magnitude array is different. This might break existing reproducible tests with seeded random number generators and fixed seed. Not sure if this is a real problem in practice, though.
>> 
>> 3. There seems to be no test coverage that ensures the `BigInteger` invariant has either `mag.length == 0` or `mag[0] != 0`. While the code obviously ensures it, future changes might not, so it might make sense to have this aspect covered by a test.
>
> @bplb
> About point 1. The behavior of `nextInt()` depends by the implementation of the Random object specified, which of course is not predictable. Furthermore, the claim that `nextInt()` invokes `nextLong()` by default and throws away the lower 32 bits is evidently denied by the facts: simply look at the last version of the method implementation in the class Random: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/Random.java#L494
> So, in the light of that, I think it's not worthwhile using `nextLong()` instead of `nextInt()`, it would only complicate the code.

@fabioromano1

I made the original observations reported by @bplb.
You are right about item 1: I was erroneously looking at the implementation in interface `RandomGenerator`, not in class `Random`.

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

PR Comment: https://git.openjdk.org/jdk/pull/16817#issuecomment-1841002629

From sgehwolf at openjdk.org  Tue Dec  5 15:28:08 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 5 Dec 2023 15:28:08 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v11]
In-Reply-To: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
Message-ID: <dLC5X7-Rgk0I0Rx_QKeQLf3--NHxERBg8rSJRw6Vr0Q=.abc3fb5d-eaec-4b18-b92e-62d98398154d@github.com>

> Please review this patch which adds a "jmodless" jlink mode to the JDK. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app being modularized).
> 
> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JmodLessArchive` class which has all the info of what constitutes the final jlinked runtime.
> 
> Basic usage example:
> 
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
> $ ls ../linux-x86_64-server-release/images/jdk/jmods
> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.internal.vm.compiler.management.jmod  jdk.jlink.jmod       jdk.naming.dns.jmod        jdk.unsupported...

Severin Gehwolf has updated the pull request incrementally with 12 additional commits since the last revision:

 - Don't show the verbose hint when already verbose
 - Use '_files' over '_resources' as the suffix for listing resources
 - Remove the hidden option hint.
   
   Also adjust the messages being printed when performing
   a run-time image link.
 - Localize messages, switch expression
 - Rename RunImageArchive => JRTArchive and RunImageLinkException => RuntimeImageLinkException
   
   Also moved the stamp file to jdk.jlink module. The resources files per
   module now get unconditionally created (empty if no resources not in the
   jimage).
 - First round of addressing review feedback.
   
   - Share resource names (JlinkTask and JlinkResourcesListPlugin)
   - Exclude resources in JlinkResourcesListPlugin the same way
     as done for other plugins.
 - Rename AddRunImageResourcesPlugin => JlinkResourcesListPlugin
 - Use merged CLI args to persist
 - Add runTimeImageLinkPersistent() API to Plugin interface
   
   - Add quoting for CLI args that contain space when persisting
   - Add null-passing parseConfiguration() method to
     ImagePluginConfiguration to ease testing.
 - Initial work to track base image link and plugin options
 - ... and 2 more: https://git.openjdk.org/jdk/compare/f1130d1c...3745cb8e

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14787/files
  - new: https://git.openjdk.org/jdk/pull/14787/files/f1130d1c..3745cb8e

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

  Stats: 1653 lines in 21 files changed: 962 ins; 649 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/14787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787

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

From sgehwolf at openjdk.org  Tue Dec  5 15:42:42 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 5 Dec 2023 15:42:42 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v10]
In-Reply-To: <PYo6Mc7WoS2PX3rcksdF-Z-svjgwi4sFnWDKpIOdhRY=.7bb8f8ec-98a7-426c-b879-b0b7f656c871@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <SDcwfk1zKIk2TowVOL42C7LM8SfFraZiP5gKNLYxnpI=.bfdaed15-bdbf-4f65-8760-145f58e4513e@github.com>
 <PYo6Mc7WoS2PX3rcksdF-Z-svjgwi4sFnWDKpIOdhRY=.7bb8f8ec-98a7-426c-b879-b0b7f656c871@github.com>
Message-ID: <Agvm3rPLY704W8u6qTZ8944531HClThdgvX4yEGZvBY=.12b9d840-ff38-4689-b3e2-c9a56f38b410@github.com>

On Wed, 29 Nov 2023 23:31:56 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Thanks. I'll continue the review on the revised version.

@mlchung I've pushed the updates now. Please take another look. I'll merge latest master in the next couple of hours.

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

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1841046792

From mcimadamore at openjdk.org  Tue Dec  5 15:54:37 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 5 Dec 2023 15:54:37 GMT
Subject: RFR: 8321159: SymbolLookup.libraryLookup(Path,
 Arena) Assumes default Filesystem [v5]
In-Reply-To: <bO-z1_vyEjDritmqDQtGgUz5MTywhoHfZRXIoZshsYg=.f6cb57a8-d0e6-4445-8f10-0ee0987a2c57@github.com>
References: <sbkQW1a7NByueXA7Vm_JVE06P3queX4AkDE-rlFFbgg=.35168862-4033-4184-97c8-86ab21da922e@github.com>
 <bO-z1_vyEjDritmqDQtGgUz5MTywhoHfZRXIoZshsYg=.f6cb57a8-d0e6-4445-8f10-0ee0987a2c57@github.com>
Message-ID: <jqpEYyLbtOERBz94Sjq5Y6MD6hpDoKBXu4-vq291OGc=.1999c2ff-7e59-4ea7-9b59-2e36a65e2567@github.com>

On Tue, 5 Dec 2023 12:02:59 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to reject paths provided to the `SymbolLookup.libraryLookup(Path path, Arena arena)` method if a path is not in the default file system.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix double negation

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16944#pullrequestreview-1765457060

From vklang at openjdk.org  Tue Dec  5 16:18:37 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 5 Dec 2023 16:18:37 GMT
Subject: RFR: JDK-8319662 ForkJoinPool trims worker threads too slowly [v6]
In-Reply-To: <2gzR5w7heEb4Th-X4qX6fVw6R8kSaJBewKWzhKq7HKI=.7ae6246c-5606-4d2f-8e7b-b84317f1459d@github.com>
References: <EfYHyY5R-XjTMrOb7XJbe4Y0m9Zq7zYuI4BlS3T2k2w=.8682eec9-4cae-4004-85dc-923062ac1b5f@github.com>
 <2gzR5w7heEb4Th-X4qX6fVw6R8kSaJBewKWzhKq7HKI=.7ae6246c-5606-4d2f-8e7b-b84317f1459d@github.com>
Message-ID: <XIwpi3WxTzkJsf239R3xVCuY5oqYOigiVhTQt2eDEl8=.2d49d059-aa2d-4db6-8eae-bee9b91a1323@github.com>

On Sun, 3 Dec 2023 17:13:49 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This update cascades timeouts to trim subsequent workers after the first  keepAlive inactive period.
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reduce oversignalling and contention; add test

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1970:

> 1968:                 Thread t = v.owner;
> 1969:                 v.phase = sp;
> 1970:                 if (v.parking != 0&& t != null) {

`if (v.parking != 0 && t != null) {`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16725#discussion_r1415894444

From vklang at openjdk.org  Tue Dec  5 16:23:40 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 5 Dec 2023 16:23:40 GMT
Subject: RFR: JDK-8319662 ForkJoinPool trims worker threads too slowly [v6]
In-Reply-To: <2gzR5w7heEb4Th-X4qX6fVw6R8kSaJBewKWzhKq7HKI=.7ae6246c-5606-4d2f-8e7b-b84317f1459d@github.com>
References: <EfYHyY5R-XjTMrOb7XJbe4Y0m9Zq7zYuI4BlS3T2k2w=.8682eec9-4cae-4004-85dc-923062ac1b5f@github.com>
 <2gzR5w7heEb4Th-X4qX6fVw6R8kSaJBewKWzhKq7HKI=.7ae6246c-5606-4d2f-8e7b-b84317f1459d@github.com>
Message-ID: <iaRllRwfE9R03HezdrYFtUyG4rSd8Gy1Pb_7Xvf675A=.f9989ed9-f082-45a2-bc84-3db56c0cc5a2@github.com>

On Sun, 3 Dec 2023 17:13:49 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This update cascades timeouts to trim subsequent workers after the first  keepAlive inactive period.
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reduce oversignalling and contention; add test

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2096:

> 2094:      * Tries to inactivate, and if successful, awaits signal or termination.
> 2095:      *
> 2096:      * @param w the worker (may be null if already terminated)

Technically `w` is `WorkQueue` not `ForkJoinWorkerThread` so perhaps s/worker/work queue?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16725#discussion_r1415905526

From vklang at openjdk.org  Tue Dec  5 16:34:39 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 5 Dec 2023 16:34:39 GMT
Subject: RFR: JDK-8319662 ForkJoinPool trims worker threads too slowly [v8]
In-Reply-To: <4Uww87u_Iduao3i7nucJk8IMwfI_c14fEZ1xOUVsgHM=.87bdab09-4936-4fbd-afa0-bc02ead39d5d@github.com>
References: <EfYHyY5R-XjTMrOb7XJbe4Y0m9Zq7zYuI4BlS3T2k2w=.8682eec9-4cae-4004-85dc-923062ac1b5f@github.com>
 <4Uww87u_Iduao3i7nucJk8IMwfI_c14fEZ1xOUVsgHM=.87bdab09-4936-4fbd-afa0-bc02ead39d5d@github.com>
Message-ID: <h5yHHBl_a9t22y2gkebU0nfvbm0uTNvNTwLxTVZr-u8=.7edc87bb-e933-4734-82ed-ee9f6be24535@github.com>

On Mon, 4 Dec 2023 13:56:55 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This update cascades timeouts to trim subsequent workers after the first  keepAlive inactive period.
>
> Doug Lea has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8319662
>  - Remove unnecessary re-interrupt
>  - Merge branch 'openjdk:master' into JDK-8319662
>  - Reduce oversignalling and contention; add test
>  - Revert 2 lines in method scan
>  - Merge branch 'openjdk:master' into JDK-8319662
>  - Split up method awaitWork; other associated changes.
>  - Merge branch 'openjdk:master' into JDK-8319662
>  - tweak cascades; reinstate an @Contended; resolve JDK-8319498
>  - Support cascading idle timeouts

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1226:

> 1224:         int nsteals;               // number of steals from other queues
> 1225:         @jdk.internal.vm.annotation.Contended("w")
> 1226:         volatile int parking;      // nonzero if parked in awaitWork

@DougLea Nice. Seems preferable not to have to track another volatile reference (parker) and instead going the route you did with a marker + owner.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16725#discussion_r1415930663

From vklang at openjdk.org  Tue Dec  5 16:34:43 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 5 Dec 2023 16:34:43 GMT
Subject: RFR: JDK-8319662 ForkJoinPool trims worker threads too slowly [v6]
In-Reply-To: <XIwpi3WxTzkJsf239R3xVCuY5oqYOigiVhTQt2eDEl8=.2d49d059-aa2d-4db6-8eae-bee9b91a1323@github.com>
References: <EfYHyY5R-XjTMrOb7XJbe4Y0m9Zq7zYuI4BlS3T2k2w=.8682eec9-4cae-4004-85dc-923062ac1b5f@github.com>
 <2gzR5w7heEb4Th-X4qX6fVw6R8kSaJBewKWzhKq7HKI=.7ae6246c-5606-4d2f-8e7b-b84317f1459d@github.com>
 <XIwpi3WxTzkJsf239R3xVCuY5oqYOigiVhTQt2eDEl8=.2d49d059-aa2d-4db6-8eae-bee9b91a1323@github.com>
Message-ID: <1sNEkOcdZm3zm__Bv2lTy9iec7pozmcydIzAYl_wLYQ=.28f5097b-8756-4569-a27a-4e6fa3700a2a@github.com>

On Tue, 5 Dec 2023 16:15:31 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reduce oversignalling and contention; add test
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1970:
> 
>> 1968:                 Thread t = v.owner;
>> 1969:                 v.phase = sp;
>> 1970:                 if (v.parking != 0&& t != null) {
> 
> `if (v.parking != 0 && t != null) {`

Outdated :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16725#discussion_r1415926014

From bpb at openjdk.org  Tue Dec  5 16:40:59 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 5 Dec 2023 16:40:59 GMT
Subject: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter
 of transferTo() is trusted [v5]
In-Reply-To: <zRINQ_LiJh7Ifnt7UwL2Q0PcpestYwzx74fopLor_2w=.c93f3a3a-8172-40d2-9e5d-0530eb905f2a@github.com>
References: <zRINQ_LiJh7Ifnt7UwL2Q0PcpestYwzx74fopLor_2w=.c93f3a3a-8172-40d2-9e5d-0530eb905f2a@github.com>
Message-ID: <UpPnS_jZZoyzKFRDo4zRlvWA9F35e4l49H24Fxe9kWs=.d54e2cb0-132d-4c00-9e40-b85f646de073@github.com>

> Pass `ByteArrayInputStream.buf ` directly to the `OutputStream` parameter of `BAIS.transferTo` only if the target stream is in the `java.io` package.

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

  8321053: Remove package check in trustworthiness verification

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16893/files
  - new: https://git.openjdk.org/jdk/pull/16893/files/7aa37667..8a13b553

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

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

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

From bpb at openjdk.org  Tue Dec  5 16:41:01 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 5 Dec 2023 16:41:01 GMT
Subject: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter
 of transferTo() is trusted [v4]
In-Reply-To: <qcFIqCTdbAp4OW_TTFnXLcqIfEEPv7jI1i8k9Clb82A=.3c8e1c48-0a4c-4e42-99c3-111dc0aa2c79@github.com>
References: <zRINQ_LiJh7Ifnt7UwL2Q0PcpestYwzx74fopLor_2w=.c93f3a3a-8172-40d2-9e5d-0530eb905f2a@github.com>
 <G1i2jgvLHa3whZRh-xQDs-cf0JoBTflxeKuUFR1qEGo=.2df02966-3131-4af9-bb9b-96480fc32859@github.com>
 <4bwttMfJ29GTFbt-8ob46PQjhiZUZi9xmCuajK7nM4U=.6b56d022-5867-4063-9486-4168f43d8bdc@github.com>
 <-TUIeF7snwbYVyxnHX_lSFbJJX8uZ9Q_fyeqZPvdBw8=.1763df2a-57f5-4930-94f8-c57f9f8144a3@github.com>
 <qcFIqCTdbAp4OW_TTFnXLcqIfEEPv7jI1i8k9Clb82A=.3c8e1c48-0a4c-4e42-99c3-111dc0aa2c79@github.com>
Message-ID: <O4zxc74p3-uQrg8bXyhais5yXscZ59Qt-tiudEBunnE=.56b0c2d0-7a7d-47d1-9e50-0a676f66845e@github.com>

On Tue, 5 Dec 2023 12:58:45 GMT, Markus KARG <duke at openjdk.org> wrote:

>> I suspect it's left over from a previous iteration. In any case, limiting it to a small number of output streams makes this easier to look at. BAOS and FOS seem okay, POP seems okay too but legacy and not interesting.
>
>> I suspect it's left over from a previous iteration. In any case, limiting it to a small number of output streams makes this easier to look at. BAOS and FOS seem okay, POP seems okay too but legacy and not interesting.
> 
> Agreed for a rather short list of explicitly whitelisted implementations. We should get rid of the package check.

I checked all the `OutputStreams` in the list for trustworthiness. The package check is vestigial; will remove. It could be useful if multiple packages were involved with multiple trusted classes in each.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16893#discussion_r1415944621

From vklang at openjdk.org  Tue Dec  5 16:44:38 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 5 Dec 2023 16:44:38 GMT
Subject: RFR: JDK-8319662 ForkJoinPool trims worker threads too slowly [v8]
In-Reply-To: <4Uww87u_Iduao3i7nucJk8IMwfI_c14fEZ1xOUVsgHM=.87bdab09-4936-4fbd-afa0-bc02ead39d5d@github.com>
References: <EfYHyY5R-XjTMrOb7XJbe4Y0m9Zq7zYuI4BlS3T2k2w=.8682eec9-4cae-4004-85dc-923062ac1b5f@github.com>
 <4Uww87u_Iduao3i7nucJk8IMwfI_c14fEZ1xOUVsgHM=.87bdab09-4936-4fbd-afa0-bc02ead39d5d@github.com>
Message-ID: <eaBQ_i6zP8xViFIw_FTP4vSQZfg4SUe9fIh1Z982j84=.4572b714-cb18-4c43-855a-f9c124a486c6@github.com>

On Mon, 4 Dec 2023 13:56:55 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This update cascades timeouts to trim subsequent workers after the first  keepAlive inactive period.
>
> Doug Lea has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8319662
>  - Remove unnecessary re-interrupt
>  - Merge branch 'openjdk:master' into JDK-8319662
>  - Reduce oversignalling and contention; add test
>  - Revert 2 lines in method scan
>  - Merge branch 'openjdk:master' into JDK-8319662
>  - Split up method awaitWork; other associated changes.
>  - Merge branch 'openjdk:master' into JDK-8319662
>  - tweak cascades; reinstate an @Contended; resolve JDK-8319498
>  - Support cascading idle timeouts

@DougLea I've had a look at this PR, nothing to add but the comment(s) I made ?

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

PR Comment: https://git.openjdk.org/jdk/pull/16725#issuecomment-1841179817

From alanb at openjdk.org  Tue Dec  5 16:55:40 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 5 Dec 2023 16:55:40 GMT
Subject: RFR: 8321124: java/util/stream/GatherersTest.java times out [v5]
In-Reply-To: <pegi_30MseGhnGUE2sEvUEz0fqiKJFKTQMZK0_WcjjY=.6ba87409-d5e4-4e5e-a836-bcbfaded061f@github.com>
References: <NcgSgagzqKytU8dGSMKHUF_9ylICS5s6If5CoFRjPhw=.abef3a79-b429-47c5-b0b7-aa7b9f71ef31@github.com>
 <pegi_30MseGhnGUE2sEvUEz0fqiKJFKTQMZK0_WcjjY=.6ba87409-d5e4-4e5e-a836-bcbfaded061f@github.com>
Message-ID: <UNkhsJFYjdWW-GHn7UTwWHVetUmgzaymI0Xm8PnNFH8=.6fdc8568-0bba-4877-96ae-4d9fbe797ee8@github.com>

On Tue, 5 Dec 2023 14:55:02 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Splits GatherersTest out to distinct files per built-in gatherer
>> 
>> Fixes a test ordering issue for mapConcurrent which placed GatherersTest on the ProblemList.
>> 
>> Adding increased maxOutputSize for Gatherer-related tests to improve debuggability.
>> 
>> Lowering the composition threshold of GathererTest.testMassivelyComposedGatherers to 256 to avoid SOE on low-specc:ed machines.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing review feedback: improving test coverage and debuggability

Thanks for the updates/refactoring, I don't have any more comments to add.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16928#pullrequestreview-1765642282

From duke at openjdk.org  Tue Dec  5 17:28:39 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 5 Dec 2023 17:28:39 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v8]
In-Reply-To: <D2AGAYSictxU124OSQMg3V5bpM1oKBdxKLdBS0X7ow8=.326a6f38-e9ab-4b24-a6d6-d8eebdb346f7@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <e5w5YZ0WD8S3UVFBYz6I0PdKZ6yOkD77BCq2arDd6i4=.7eecadcb-e627-4e9b-8f1e-3fc41c63243b@github.com>
 <bopxvLCquUtZQxt8kAJskzXBR2YE_I0PW13i3NBJNNY=.e65abf3d-0ff4-4450-875b-ca3717170485@github.com>
 <DeQgR1PaXlk2yzlxV15N3ViZY26wXtlgfVKxRY6vuWo=.6d38f729-0ca9-4f43-9e23-f5e73a01cc23@github.com>
 <b1Nv5Y7Klpvp5ACcHJTTblwGmnA64cyRg-3YzotaHvc=.0bd8a0f0-0844-44a9-a3bb-4af2e8514ee1@github.com>
 <t_23EA--aX8v2US9Lsib1ZF3bl4HQx_Z4RXqlgQo8LE=.6f1f2873-015c-4b69-ad47-b449e5b77a45@github.com>
 <pRcJlU1a4jG9gMaftLn5IerudMSDIrvr70KBefkpNSo=.f442f0d4-887f-4376-a66e-8254fa35927c@github.com>
 <OJ1ZK4a8c_bZik60v503VUtZoweFFv6VhhGg1sp4qSY=.e8852bf1-2d7f-4164-b952-d88b294ec1f7@github.com>
 <_gSNXk0qGAtpY-WJ5OCHk_3-nuGrwwSn-ffK9f2TEcs=.40f785ba-83dd-40fe-8075-a7a7872ea600@github.com>
 <v95kXnbADF5XriLfeg2v5yVYBo-BUzR-dhpcubuMDcI=.03d8e5a7-8b0c-4291-99df-2d3ec6cd356c@github.com>
 <D2AGAYSictxU124OSQMg3V5bpM1oKBdxKLd
 BS0X7ow8=.326a6f38-e9ab-4b24-a6d6-d8eebdb346f7@github.com>
Message-ID: <wpFxnb5dr5v2UHZYPPdi4XsBUiLtFXGxRySgr6xCmJM=.74175d6e-0f30-464e-9c76-cc4e8bd6f36a@github.com>

On Tue, 5 Dec 2023 11:19:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Hi Marcus (@magicus), please see the updated code which added guards to check for GCC version >= 7.5 in `src/java.base/linux/native/libsimdsort/{avx2-linux-qsort.cpp, avx512-linux-qsort.cpp}`. GCC >= 7.5 is needed to compile libsimdsort using C++17 features. Made sure that OpenJDK builds without errors using both GCC 7.5 and GCC 6.4.
>
> That sounds weird. You can't check for if compiler options should be enabled or not inside source code files.
> 
> Are you saying that when compiling with GCC 6, it will just silently ignore `-std=c++17`? I'd have assumed that it printed a warning or error about an unknown or invalid option, if C++17 is not supported.

Hi Magnus (@magicus),
 
> Are you saying that when compiling with GCC 6, it will just silently ignore `-std=c++17`? I'd have assumed that it printed a warning or error about an unknown or invalid option, if C++17 is not supported.

The GCC complier for versions 6 (and even 5) silently ignores the flag `-std=c++17`. It does not print any warning or error. I tested it with a toy C++ program and also by building OpenJDK using GCC 6. 

> You can't check for if compiler options should be enabled or not inside source code files.

 what I meant was, there are #ifdef guards using predefined macros in the C++ source code to check for GCC version and make the simdsort code available for compilation or not based on the GCC version


// src/java.base/linux/native/libsimdsort/simdsort-support.hpp
#if defined(_LP64) && (defined(__GNUC__) && ((__GNUC__ > 7) || ((__GNUC__ == 7) && (__GNUC_MINOR__ >= 5))))
        #define __SIMDSORT_SUPPORTED_LINUX
#endif



//src/java.base/linux/native/libsimdsort/avx2-linux-qsort.cpp
#include "simdsort-support.hpp"
#ifdef __SIMDSORT_SUPPORTED_LINUX
            <simdsort functions>
#endif

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1416037340

From alanb at openjdk.org  Tue Dec  5 17:37:39 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 5 Dec 2023 17:37:39 GMT
Subject: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter
 of transferTo() is trusted [v5]
In-Reply-To: <UpPnS_jZZoyzKFRDo4zRlvWA9F35e4l49H24Fxe9kWs=.d54e2cb0-132d-4c00-9e40-b85f646de073@github.com>
References: <zRINQ_LiJh7Ifnt7UwL2Q0PcpestYwzx74fopLor_2w=.c93f3a3a-8172-40d2-9e5d-0530eb905f2a@github.com>
 <UpPnS_jZZoyzKFRDo4zRlvWA9F35e4l49H24Fxe9kWs=.d54e2cb0-132d-4c00-9e40-b85f646de073@github.com>
Message-ID: <CyhCoKepEvJeyKgm96awzKRNkN6sdj6APf-X8RUd4Zs=.ce013dee-1cb2-4dc4-aaab-6b82ec76c871@github.com>

On Tue, 5 Dec 2023 16:40:59 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Pass `ByteArrayInputStream.buf ` directly to the `OutputStream` parameter of `BAIS.transferTo` only if the target stream is in the `java.io` package.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8321053: Remove package check in trustworthiness verification

Marked as reviewed by alanb (Reviewer).

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

> 216:                 tmp = null;
> 217:             else
> 218:                 tmp = new byte[Integer.min(len, MAX_TRANSFER_SIZE)];

Looks okay, I'd probably rename tmp to something better, maybe tmpbuf.

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

PR Review: https://git.openjdk.org/jdk/pull/16893#pullrequestreview-1765665329
PR Review Comment: https://git.openjdk.org/jdk/pull/16893#discussion_r1415998481

From bpb at openjdk.org  Tue Dec  5 17:47:54 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 5 Dec 2023 17:47:54 GMT
Subject: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter
 of transferTo() is trusted [v6]
In-Reply-To: <zRINQ_LiJh7Ifnt7UwL2Q0PcpestYwzx74fopLor_2w=.c93f3a3a-8172-40d2-9e5d-0530eb905f2a@github.com>
References: <zRINQ_LiJh7Ifnt7UwL2Q0PcpestYwzx74fopLor_2w=.c93f3a3a-8172-40d2-9e5d-0530eb905f2a@github.com>
Message-ID: <gg9iF1NfA8HC2a8csXJRD3SRuVzf8_U4HkRUUzSk9lg=.9c474748-e21a-42d3-8bef-45d2e00319a8@github.com>

> Pass `ByteArrayInputStream.buf ` directly to the `OutputStream` parameter of `BAIS.transferTo` only if the target stream is in the `java.io` package.

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

  8321053: s/tmp/tmpbuf/

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16893/files
  - new: https://git.openjdk.org/jdk/pull/16893/files/8a13b553..b0d4cb96

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

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

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

From bpb at openjdk.org  Tue Dec  5 17:52:56 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 5 Dec 2023 17:52:56 GMT
Subject: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter
 of transferTo() is trusted [v7]
In-Reply-To: <zRINQ_LiJh7Ifnt7UwL2Q0PcpestYwzx74fopLor_2w=.c93f3a3a-8172-40d2-9e5d-0530eb905f2a@github.com>
References: <zRINQ_LiJh7Ifnt7UwL2Q0PcpestYwzx74fopLor_2w=.c93f3a3a-8172-40d2-9e5d-0530eb905f2a@github.com>
Message-ID: <ms8tSSXFqs8lwJ6sQ9Nvo-gxBmm3s03NLkmdnI1Bt78=.0e1a8a1d-71f3-413b-942f-533790e48b93@github.com>

> Pass `ByteArrayInputStream.buf ` directly to the `OutputStream` parameter of `BAIS.transferTo` only if the target stream is in the `java.io` package.

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

  8321053: Fix overlooked comment update in previous commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16893/files
  - new: https://git.openjdk.org/jdk/pull/16893/files/b0d4cb96..0e14c973

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

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

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

From kvn at openjdk.org  Tue Dec  5 18:08:36 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 5 Dec 2023 18:08:36 GMT
Subject: RFR: 8321124: java/util/stream/GatherersTest.java times out [v5]
In-Reply-To: <pegi_30MseGhnGUE2sEvUEz0fqiKJFKTQMZK0_WcjjY=.6ba87409-d5e4-4e5e-a836-bcbfaded061f@github.com>
References: <NcgSgagzqKytU8dGSMKHUF_9ylICS5s6If5CoFRjPhw=.abef3a79-b429-47c5-b0b7-aa7b9f71ef31@github.com>
 <pegi_30MseGhnGUE2sEvUEz0fqiKJFKTQMZK0_WcjjY=.6ba87409-d5e4-4e5e-a836-bcbfaded061f@github.com>
Message-ID: <v1fuPpW2UqSAHwKwQHGcs6zELbODxVj1f3BkIXmaOoc=.1257519d-284f-4b86-bff2-6fdd24b8537f@github.com>

On Tue, 5 Dec 2023 14:55:02 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Splits GatherersTest out to distinct files per built-in gatherer
>> 
>> Fixes a test ordering issue for mapConcurrent which placed GatherersTest on the ProblemList.
>> 
>> Adding increased maxOutputSize for Gatherer-related tests to improve debuggability.
>> 
>> Lowering the composition threshold of GathererTest.testMassivelyComposedGatherers to 256 to avoid SOE on low-specc:ed machines.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing review feedback: improving test coverage and debuggability

Thank you for fixing GHA failure.
I am not doing review since I am not expert.

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

PR Comment: https://git.openjdk.org/jdk/pull/16928#issuecomment-1841337736

From asemenyuk at openjdk.org  Tue Dec  5 18:44:50 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 5 Dec 2023 18:44:50 GMT
Subject: Integrated: 8294699: Launcher causes lingering busy cursor
In-Reply-To: <JLG7a6KUWw59tkZ8zRd5nDEeyXguqcc5JBvrRPW23Q4=.89e64bdb-e0b9-46ef-9971-87128a8f6ddf@github.com>
References: <JLG7a6KUWw59tkZ8zRd5nDEeyXguqcc5JBvrRPW23Q4=.89e64bdb-e0b9-46ef-9971-87128a8f6ddf@github.com>
Message-ID: <NFRDzG0_R6DxuWKQBnoLQBxTG60MNikGbWnyuW-H2wA=.0259616d-a915-4af2-8207-98c7f18fb7eb@github.com>

On Mon, 4 Dec 2023 20:08:15 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> 8294699: Launcher causes lingering busy cursor

This pull request has now been integrated.

Changeset: d3df3eb5
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d3df3eb5d7f5537ade917db7a36caba028f94111
Stats:     78 lines in 1 file changed: 76 ins; 0 del; 2 mod

8294699: Launcher causes lingering busy cursor

Reviewed-by: almatvee

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

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

From sgehwolf at openjdk.org  Tue Dec  5 19:15:53 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 5 Dec 2023 19:15:53 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v12]
In-Reply-To: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
Message-ID: <iHvfP1CJRkBYTMEyCGUHvsyWxPHdVp36g49nxbxZfXU=.db86d493-f32e-4faf-a3e5-cf414ac9abbb@github.com>

> Please review this patch which adds a "jmodless" jlink mode to the JDK. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app being modularized).
> 
> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JmodLessArchive` class which has all the info of what constitutes the final jlinked runtime.
> 
> Basic usage example:
> 
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
> $ ls ../linux-x86_64-server-release/images/jdk/jmods
> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.internal.vm.compiler.management.jmod  jdk.jlink.jmod       jdk.naming.dns.jmod        jdk.unsupported...

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

 - Add @enablePreview for JImageValidator that uses classfile API
 - Fix SystemModulesPlugin after merge
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Don't show the verbose hint when already verbose
 - Use '_files' over '_resources' as the suffix for listing resources
 - Remove the hidden option hint.
   
   Also adjust the messages being printed when performing
   a run-time image link.
 - Localize messages, switch expression
 - Rename RunImageArchive => JRTArchive and RunImageLinkException => RuntimeImageLinkException
   
   Also moved the stamp file to jdk.jlink module. The resources files per
   module now get unconditionally created (empty if no resources not in the
   jimage).
 - First round of addressing review feedback.
   
   - Share resource names (JlinkTask and JlinkResourcesListPlugin)
   - Exclude resources in JlinkResourcesListPlugin the same way
     as done for other plugins.
 - Rename AddRunImageResourcesPlugin => JlinkResourcesListPlugin
 - ... and 36 more: https://git.openjdk.org/jdk/compare/87516e29...a797ea69

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

Changes: https://git.openjdk.org/jdk/pull/14787/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=11
  Stats: 3069 lines in 39 files changed: 2976 ins; 48 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/14787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787

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

From aturbanov at openjdk.org  Tue Dec  5 19:19:36 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 5 Dec 2023 19:19:36 GMT
Subject: RFR: 8321124: java/util/stream/GatherersTest.java times out [v5]
In-Reply-To: <pegi_30MseGhnGUE2sEvUEz0fqiKJFKTQMZK0_WcjjY=.6ba87409-d5e4-4e5e-a836-bcbfaded061f@github.com>
References: <NcgSgagzqKytU8dGSMKHUF_9ylICS5s6If5CoFRjPhw=.abef3a79-b429-47c5-b0b7-aa7b9f71ef31@github.com>
 <pegi_30MseGhnGUE2sEvUEz0fqiKJFKTQMZK0_WcjjY=.6ba87409-d5e4-4e5e-a836-bcbfaded061f@github.com>
Message-ID: <Ko3hSqPHalFIelVNIx6644VY8CZeX4mqa2xUVxfOC-E=.a3a823ae-c4a1-4b24-8844-2213348b5aff@github.com>

On Tue, 5 Dec 2023 14:55:02 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Splits GatherersTest out to distinct files per built-in gatherer
>> 
>> Fixes a test ordering issue for mapConcurrent which placed GatherersTest on the ProblemList.
>> 
>> Adding increased maxOutputSize for Gatherer-related tests to improve debuggability.
>> 
>> Lowering the composition threshold of GathererTest.testMassivelyComposedGatherers to 256 to avoid SOE on low-specc:ed machines.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing review feedback: improving test coverage and debuggability

test/jdk/java/util/stream/GatherersMapConcurrentTest.java line 254:

> 252:                                     fail("Unexpected!");
> 253:                                 }
> 254:                                 while(tasksWaiting.getQueueLength() < tasksToCancel) {

Suggestion:

                                while (tasksWaiting.getQueueLength() < tasksToCancel) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16928#discussion_r1416171352

From jbhateja at openjdk.org  Tue Dec  5 19:22:49 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 5 Dec 2023 19:22:49 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v8]
In-Reply-To: <7ocsRxaWjoU2vxwPUSE7BrnLSL1bF_7Pp8vReacNJvE=.1c044b21-b27e-4e94-8db0-6ae888a1e8b9@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <7ocsRxaWjoU2vxwPUSE7BrnLSL1bF_7Pp8vReacNJvE=.1c044b21-b27e-4e94-8db0-6ae888a1e8b9@github.com>
Message-ID: <bfQ06T6iTnowcGtYhxroMpFD7c9SIconr-AaWliY7Us=.c85c0dbb-0c57-4565-81ac-bf9ad4cbeb5e@github.com>

On Mon, 4 Dec 2023 22:15:24 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX2 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
>> 
>> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
>> 
>> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId content=Excel.Sheet>
>> <meta name=Generator content="Microsoft Excel 15">
>> <link id=Main-File rel=Main-File
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
>> <link rel=File-List
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
>> 
>> 
>> </head>
>> 
>> <body link="#0563C1" vlink="#954F72">
>> 
>> 
>> 
>> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
>> -- | -- | -- | -- | --
>> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
>> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
>> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
>> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
>> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
>> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
>> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
>> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
>> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
>> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
>> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
>> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
>> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
>> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
>> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
>> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
>> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
>> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
>> 
>> </body>
>> 
>> </html>
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId cont...
>
> Srinivas Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>  - add GCC version guards
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>  - Remove C++17 from C flags
>  - add avoid masked stores operation
>  - update the code to check for supported simd sort cpus
>  - Disable AVX2 sort for 64-bit types
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>  - fix jcheck failures due to windows encoding
>  - fix carriage return and change insertion sort thresholds
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/fc7d33f2...bc590d9f

src/java.base/linux/native/libsimdsort/avx2-linux-qsort.cpp line 50:

> 48:             case JVM_T_DOUBLE:
> 49:                 avx2_fast_sort((double*)array, from_index, to_index, INSERTION_SORT_THRESHOLD_64BIT);
> 50:                 break;

Please add safe assertions for missing types.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1416173543

From bpb at openjdk.org  Tue Dec  5 19:43:56 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 5 Dec 2023 19:43:56 GMT
Subject: Integrated: 8321053: Use ByteArrayInputStream.buf directly when
 parameter of transferTo() is trusted
In-Reply-To: <zRINQ_LiJh7Ifnt7UwL2Q0PcpestYwzx74fopLor_2w=.c93f3a3a-8172-40d2-9e5d-0530eb905f2a@github.com>
References: <zRINQ_LiJh7Ifnt7UwL2Q0PcpestYwzx74fopLor_2w=.c93f3a3a-8172-40d2-9e5d-0530eb905f2a@github.com>
Message-ID: <OgCvB4maFO93oE9Dg7KA7uHQIqrieChpzVwjJpQSuf8=.75b2d5a6-7247-4c4a-9ffe-ecf3877d29ef@github.com>

On Thu, 30 Nov 2023 00:03:21 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Pass `ByteArrayInputStream.buf ` directly to the `OutputStream` parameter of `BAIS.transferTo` only if the target stream is in the `java.io` package.

This pull request has now been integrated.

Changeset: b0d14509
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b0d145097cdc61e4bab19393a125e63aa3bc29b9
Stats:     108 lines in 2 files changed: 107 ins; 0 del; 1 mod

8321053: Use ByteArrayInputStream.buf directly when parameter of transferTo() is trusted

Reviewed-by: alanb

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

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

From rriggs at openjdk.org  Tue Dec  5 19:45:38 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 5 Dec 2023 19:45:38 GMT
Subject: RFR: JDK-8320570 NegativeArraySizeException decoding >1G UTF8
 bytes with non-ascii characters
In-Reply-To: <wK-u3PPhgDfuUAGIWQNgYs_gxKrDVjsNs8ImLonZObU=.49b3b03b-6deb-418a-9ab0-9c9fc563b33a@github.com>
References: <wK-u3PPhgDfuUAGIWQNgYs_gxKrDVjsNs8ImLonZObU=.49b3b03b-6deb-418a-9ab0-9c9fc563b33a@github.com>
Message-ID: <fHCABwNJ1VBX8JMY9Cv9bUucvjqSPomf4cepc9mRbTg=.a03f813e-3d80-42bd-89d9-d6b62e181d38@github.com>

On Tue, 5 Dec 2023 14:57:09 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> A regression is found in Java9+ creating String instance from UTF8 bytes, a side effect of string compactation https://openjdk.org/jeps/254 that changed the decoding logic. Specifically, when constructing a string from bytes: 
> 
> ``` 
> String str = new String(largeBytes, StandardCharsets.UTF_8); 
> ``` 
> 
> if the size of largeBytes is greater than 2^30 (>1 GB) but smaller than INT_MAX (2 GB), it fails on Java9+ (including 11, 17, 21, though the stack trace is slightly different, see below), regardless of jvm heap size. In Java8, it succeeded when jvm heap size is set to be sufficient.

Changes requested by rriggs (Reviewer).

test/jdk/java/lang/String/CompactString/NegativeSize.java line 36:

> 34: 
> 35: public class NegativeSize {
> 36: 

Why is there a `public class Main` inside `public class NegativeSize`?
The `@run testng/othervm` would indicate a testng test but there are no `@Test` annotations
and/or the tests in NegativeSize.Main.

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

PR Review: https://git.openjdk.org/jdk/pull/16974#pullrequestreview-1765972981
PR Review Comment: https://git.openjdk.org/jdk/pull/16974#discussion_r1416195950

From jbhateja at openjdk.org  Tue Dec  5 19:47:49 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 5 Dec 2023 19:47:49 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v8]
In-Reply-To: <7ocsRxaWjoU2vxwPUSE7BrnLSL1bF_7Pp8vReacNJvE=.1c044b21-b27e-4e94-8db0-6ae888a1e8b9@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <7ocsRxaWjoU2vxwPUSE7BrnLSL1bF_7Pp8vReacNJvE=.1c044b21-b27e-4e94-8db0-6ae888a1e8b9@github.com>
Message-ID: <gvK1FxA_Bm_0ZVahS1S7Gr9GMXVmDYeRejiv3T51jVE=.9506e127-d11c-4c56-a6de-bef6d61d3cc3@github.com>

On Mon, 4 Dec 2023 22:15:24 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX2 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
>> 
>> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
>> 
>> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId content=Excel.Sheet>
>> <meta name=Generator content="Microsoft Excel 15">
>> <link id=Main-File rel=Main-File
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
>> <link rel=File-List
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
>> 
>> 
>> </head>
>> 
>> <body link="#0563C1" vlink="#954F72">
>> 
>> 
>> 
>> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
>> -- | -- | -- | -- | --
>> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
>> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
>> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
>> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
>> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
>> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
>> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
>> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
>> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
>> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
>> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
>> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
>> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
>> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
>> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
>> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
>> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
>> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
>> 
>> </body>
>> 
>> </html>
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId cont...
>
> Srinivas Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>  - add GCC version guards
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>  - Remove C++17 from C flags
>  - add avoid masked stores operation
>  - update the code to check for supported simd sort cpus
>  - Disable AVX2 sort for 64-bit types
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>  - fix jcheck failures due to windows encoding
>  - fix carriage return and change insertion sort thresholds
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/021f5063...bc590d9f

src/java.base/linux/native/libsimdsort/avx2-emu-funcs.hpp line 64:

> 62:     }
> 63:     return lut;
> 64: }();

Lut64 is needed for compress64 emulation, can be removed.

src/java.base/linux/native/libsimdsort/avx2-emu-funcs.hpp line 234:

> 232: 
> 233:     vtype::mask_storeu(leftStore, left, temp);
> 234: }

Can be removed if not being used.

src/java.base/linux/native/libsimdsort/avx2-emu-funcs.hpp line 277:

> 275: 
> 276:     return _mm_popcnt_u32(shortMask);
> 277: }

Can be removed if not being used.

src/java.base/linux/native/libsimdsort/avx2-linux-qsort.cpp line 44:

> 42:                 break;
> 43:             case JVM_T_FLOAT:
> 44:                 avx2_fast_sort((float*)array, from_index, to_index, INSERTION_SORT_THRESHOLD_32BIT);

Assertions for unsupported types.

src/java.base/linux/native/libsimdsort/avx2-linux-qsort.cpp line 56:

> 54:             case JVM_T_FLOAT:
> 55:                 avx2_fast_partition((float*)array, from_index, to_index, pivot_indices, index_pivot1, index_pivot2);
> 56:                 break;

Please add assertion for unsupported types.

src/java.base/linux/native/libsimdsort/avx512-32bit-qsort.hpp line 235:

> 233:         return avx512_double_compressstore<zmm_vector<type_t>>(
> 234:             left_addr, right_addr, k, reg);
> 235:     }

Can be removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1416191049
PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1416186096
PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1416186814
PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1416189371
PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1416189115
PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1416187350

From joehw at openjdk.org  Tue Dec  5 19:51:05 2023
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 5 Dec 2023 19:51:05 GMT
Subject: RFR: 8321406: Null IDs should be resolved as before catalogs are added
Message-ID: <lvmCXcYxR1DC_irK81Vtc7M7MErBnLSm1OvPUHljHww=.12f4ee22-3cc4-41fe-a5d8-b2f5e4318782@github.com>

Improve null handling. When both the public and system IDs are null, this change lets the resolution process continue as usual, before the catalogs were added. This is consistent with the process on the other part of the program where a CatalogResolver is used only when the IDs are not null.

Test: existing XML tests passed.

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

Commit messages:
 - 8321406: Null IDs should be resolved as before catalogs are added

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

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

From brett.okken.os at gmail.com  Tue Dec  5 20:02:24 2023
From: brett.okken.os at gmail.com (Brett Okken)
Date: Tue, 5 Dec 2023 14:02:24 -0600
Subject: ThreadLocal nextHashCode
Message-ID: <CANBJVOE8wQy3jHWGXqSYFyQbWdZN-HrxMsY1ZGRGSDJepVmtWg@mail.gmail.com>

Should the private static AtomicInteger nextHashCode also be final?

https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/ThreadLocal.java#L100

From shipilev at amazon.de  Tue Dec  5 20:08:46 2023
From: shipilev at amazon.de (Aleksey Shipilev)
Date: Tue, 5 Dec 2023 21:08:46 +0100
Subject: ThreadLocal nextHashCode
In-Reply-To: <CANBJVOE8wQy3jHWGXqSYFyQbWdZN-HrxMsY1ZGRGSDJepVmtWg@mail.gmail.com>
References: <CANBJVOE8wQy3jHWGXqSYFyQbWdZN-HrxMsY1ZGRGSDJepVmtWg@mail.gmail.com>
Message-ID: <06d17045-00cc-44eb-ab4c-1bc5933d555e@amazon.de>

On 05.12.23 21:02, Brett Okken wrote:
> Should the private static AtomicInteger nextHashCode also be final?
> 
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/ThreadLocal.java#L100

Yes, I think so. Feel free to submit a PR!

-Aleksey



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



From jlaskey at openjdk.org  Tue Dec  5 20:13:06 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 5 Dec 2023 20:13:06 GMT
Subject: RFR: JDK-8320570 NegativeArraySizeException decoding >1G UTF8
 bytes with non-ascii characters [v2]
In-Reply-To: <wK-u3PPhgDfuUAGIWQNgYs_gxKrDVjsNs8ImLonZObU=.49b3b03b-6deb-418a-9ab0-9c9fc563b33a@github.com>
References: <wK-u3PPhgDfuUAGIWQNgYs_gxKrDVjsNs8ImLonZObU=.49b3b03b-6deb-418a-9ab0-9c9fc563b33a@github.com>
Message-ID: <G94Cz5zFGejqY9uiERlz-DE8reEg_dg3Jcv_LEWI-q4=.f5b1ea8b-ad17-4e6d-a687-e6ab30207100@github.com>

> A regression is found in Java9+ creating String instance from UTF8 bytes, a side effect of string compactation https://openjdk.org/jeps/254 that changed the decoding logic. Specifically, when constructing a string from bytes: 
> 
> ``` 
> String str = new String(largeBytes, StandardCharsets.UTF_8); 
> ``` 
> 
> if the size of largeBytes is greater than 2^30 (>1 GB) but smaller than INT_MAX (2 GB), it fails on Java9+ (including 11, 17, 21, though the stack trace is slightly different, see below), regardless of jvm heap size. In Java8, it succeeded when jvm heap size is set to be sufficient.

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

 - Bump up memory
 - Cotrrect NegativeSize.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16974/files
  - new: https://git.openjdk.org/jdk/pull/16974/files/46863242..ddc7acc2

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

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

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

From jlaskey at openjdk.org  Tue Dec  5 20:16:35 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 5 Dec 2023 20:16:35 GMT
Subject: RFR: JDK-8320570 NegativeArraySizeException decoding >1G UTF8
 bytes with non-ascii characters [v2]
In-Reply-To: <fHCABwNJ1VBX8JMY9Cv9bUucvjqSPomf4cepc9mRbTg=.a03f813e-3d80-42bd-89d9-d6b62e181d38@github.com>
References: <wK-u3PPhgDfuUAGIWQNgYs_gxKrDVjsNs8ImLonZObU=.49b3b03b-6deb-418a-9ab0-9c9fc563b33a@github.com>
 <fHCABwNJ1VBX8JMY9Cv9bUucvjqSPomf4cepc9mRbTg=.a03f813e-3d80-42bd-89d9-d6b62e181d38@github.com>
Message-ID: <UA5WeSotFDRDZqI9NUrAkUs0IsMUIfWWd79QcKwZk0c=.a203c649-3eff-4010-a3b4-36ac60641be8@github.com>

On Tue, 5 Dec 2023 19:42:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Bump up memory
>>  - Cotrrect NegativeSize.java
>
> test/jdk/java/lang/String/CompactString/NegativeSize.java line 36:
> 
>> 34: 
>> 35: public class NegativeSize {
>> 36: 
> 
> Why is there a `public class Main` inside `public class NegativeSize`?
> The `@run testng/othervm` would indicate a testng test but there are no `@Test` annotations
> and/or the tests in NegativeSize.Main.

Updated

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16974#discussion_r1416229057

From vklang at openjdk.org  Tue Dec  5 20:29:45 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 5 Dec 2023 20:29:45 GMT
Subject: RFR: 8318809:
 java/util/concurrent/ConcurrentLinkedQueue/WhiteBox.java shows intermittent
 failures on linux ppc64le and aarch64
In-Reply-To: <ZfdB8dzmkemBibEXbgAePF-PLovEg5mA5FxSlAirn1Q=.36b84a9a-aa04-4f6d-9e56-0dfadd4cacef@github.com>
References: <iA3gGFe3YwhNjdNk6ZoafPE7ak6VPp0qQ4cgT8R42qE=.30dc4dbc-c24a-4671-83f5-f7be232e1143@github.com>
 <ZfdB8dzmkemBibEXbgAePF-PLovEg5mA5FxSlAirn1Q=.36b84a9a-aa04-4f6d-9e56-0dfadd4cacef@github.com>
Message-ID: <4kS5WdfHztY_c81vDdCbsThskxWBHgZaPnypTGfmjdA=.3de0a1e8-db3e-4338-939f-ac55d70afb49@github.com>

On Tue, 5 Dec 2023 09:08:59 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> We've seen some rare failures of the CLQ Whitebox test on "less-strong" architectures, and the only thing which -- given my research -- could be the culprit is spuriously failing weakCAS (which is correct in terms of the implementation of CLQ).
>> 
>> After discussion with @DougLea, it was decided as the CLQ implementation does not guarantee what the failing test tests, and modifying the test would mean that it would generally not be able to enforce anything, the test is invalid and should be removed -- hence this PR.
>
> Few AArch64 HotSpot systems implement weak CAS as anything other than plain CAS. In order to get to the root cause of this problem, it would help to know on which AArch64 hardware this test failed.

@theRealAph I think the problem in this case was that the whitebox test in this case relied on a presumption that was only true for stronger consistency architectures, and rewriting the test would essentially be asserting that "a lot of permutations are valid, and only internally observable" which is a low-value test.

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

PR Comment: https://git.openjdk.org/jdk/pull/16786#issuecomment-1841562374

From sspitsyn at openjdk.org  Tue Dec  5 20:33:40 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 5 Dec 2023 20:33:40 GMT
Subject: RFR: 8321270: Virtual Thread.yield consumes parking permit [v2]
In-Reply-To: <T5KeYeQEEyCL1Rs45QmmVemdAOqMNZcQfTaDUS0xyOA=.0b984979-933d-4807-a109-49d22f09e98e@github.com>
References: <lO0N190PTq5-xjJV0LlgHWm8srDw2K8aC_U0E5qf4gA=.057efa94-6e79-4c76-9273-32ca1449bf84@github.com>
 <T5KeYeQEEyCL1Rs45QmmVemdAOqMNZcQfTaDUS0xyOA=.0b984979-933d-4807-a109-49d22f09e98e@github.com>
Message-ID: <tX65tTnr3-7U5vFBIE8eJLBFA0WaYGuUkjRdS-b0JdM=.70866eeb-ca1b-4ef9-b38a-3935f7995990@github.com>

On Tue, 5 Dec 2023 09:51:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> When a virtual thread continues after Thread.yield it currently consumes thread's parking permit. This is an oversight, the parking permit should only be consumed when continuing after park.
>> 
>> The changes are straight-forward. The internal "RUNNABLE" state is replaced with UNPARKED and YIELDED state, effectively encoding the previous state. So for the most part, it's just replacing the usages of RUNNABLE. The additional states require refactoring tryGetStackTrace, this is the method that is used for Thread::getStackTrace when the virtual thread is unmounted. It is also changed to not not swallow the REE if the reesubmit fails (tryStackTrace has to resubmit as the task for the thread may run, or the thread unparked, while "suspended" and sampling its stack trace). The changes are a subset of larger changes in the loom repo, future PRs will propose to bring in other changes to get main line up to date.
>> 
>> For testing the existing ThreadAPI has new test cases.
>> 
>> Testing: test1-5. This includes the JVMTI tests as it maps the thread states to JVMTI thread states.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Fix comment, remove space between case labels and colon
>  - Merge
>  - Leave onPinned to another PR
>  - Initial commit

The fix looks good to me.
Also, it can be more safe to run mach5 tier6 as well.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16953#pullrequestreview-1766053224

From rriggs at openjdk.org  Tue Dec  5 20:48:37 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 5 Dec 2023 20:48:37 GMT
Subject: RFR: JDK-8320570 NegativeArraySizeException decoding >1G UTF8
 bytes with non-ascii characters [v2]
In-Reply-To: <G94Cz5zFGejqY9uiERlz-DE8reEg_dg3Jcv_LEWI-q4=.f5b1ea8b-ad17-4e6d-a687-e6ab30207100@github.com>
References: <wK-u3PPhgDfuUAGIWQNgYs_gxKrDVjsNs8ImLonZObU=.49b3b03b-6deb-418a-9ab0-9c9fc563b33a@github.com>
 <G94Cz5zFGejqY9uiERlz-DE8reEg_dg3Jcv_LEWI-q4=.f5b1ea8b-ad17-4e6d-a687-e6ab30207100@github.com>
Message-ID: <yO5UsjnCkkkYl60K5TjkNKcyI1ZS7NZsJtOwWGlhh44=.2379ba37-840a-433f-91a1-0b45fa0c54b3@github.com>

On Tue, 5 Dec 2023 20:13:06 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> A regression is found in Java9+ creating String instance from UTF8 bytes, a side effect of string compactation https://openjdk.org/jeps/254 that changed the decoding logic. Specifically, when constructing a string from bytes: 
>> 
>> ``` 
>> String str = new String(largeBytes, StandardCharsets.UTF_8); 
>> ``` 
>> 
>> if the size of largeBytes is greater than 2^30 (>1 GB) but smaller than INT_MAX (2 GB), it fails on Java9+ (including 11, 17, 21, though the stack trace is slightly different, see below), regardless of jvm heap size. In Java8, it succeeded when jvm heap size is set to be sufficient.
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Bump up memory
>  - Cotrrect NegativeSize.java

test/jdk/java/lang/String/CompactString/NegativeSize.java line 30:

> 28:  * @test
> 29:  * @bug 8077559
> 30:  * @summary Tests Compact String for negative size.

It might be useful to require the larger memory; to avoid getting run when there's insufficient memory available.

 * @requires os.maxMemory >= 4G

test/jdk/java/lang/String/CompactString/NegativeSize.java line 63:

> 61:             System.out.println(inStr.substring(1_200_000_000));
> 62:         } catch (OutOfMemoryError ex) {
> 63:             System.out.println("Succeeded with OutOfMemoryError");

It might be good to check that it is the expected OOME whose message starts with `UTF16 String size is `.
No just any "Java heap memory" OOME.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16974#discussion_r1416257145
PR Review Comment: https://git.openjdk.org/jdk/pull/16974#discussion_r1416256370

From naoto at openjdk.org  Tue Dec  5 22:01:35 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 5 Dec 2023 22:01:35 GMT
Subject: RFR: 8321406: Null IDs should be resolved as before catalogs are
 added
In-Reply-To: <lvmCXcYxR1DC_irK81Vtc7M7MErBnLSm1OvPUHljHww=.12f4ee22-3cc4-41fe-a5d8-b2f5e4318782@github.com>
References: <lvmCXcYxR1DC_irK81Vtc7M7MErBnLSm1OvPUHljHww=.12f4ee22-3cc4-41fe-a5d8-b2f5e4318782@github.com>
Message-ID: <KQLMVhW4Po4SgaV2V-EX5ob9KB_Pl7qMgjq4EViFNXM=.3e4d16cf-878e-4850-87ef-619b97430b0f@github.com>

On Tue, 5 Dec 2023 19:34:58 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Improve null handling. When both the public and system IDs are null, this change lets the resolution process continue as usual, before the catalogs were added. This is consistent with the process on the other part of the program where a CatalogResolver is used only when the IDs are not null.
> 
> Test: existing XML tests passed.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16983#pullrequestreview-1766186819

From bpb at openjdk.org  Tue Dec  5 22:03:38 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 5 Dec 2023 22:03:38 GMT
Subject: RFR: 8320759: Creation of random BigIntegers can be made faster
 [v3]
In-Reply-To: <KAD32In5r6VDU4e0LePqKTHv8bn7fc9xb9zAI1UBkHY=.acba81de-6332-4cf9-9a66-d6e0f488b61b@github.com>
References: <wIuR7gaQWIRdb8DtEN1VXi9dNkUMuKn8zv3Myc4V2gc=.3356e893-5322-4bb4-aa37-731fb6e9a4b0@github.com>
 <KAD32In5r6VDU4e0LePqKTHv8bn7fc9xb9zAI1UBkHY=.acba81de-6332-4cf9-9a66-d6e0f488b61b@github.com>
Message-ID: <xeIs7PX3HXqTdu2tRHwcZ8MUMqwQ2-npMve0hR1Kpm8=.3b639c80-f5fd-4445-a682-b1a656c8a278@github.com>

On Sat, 2 Dec 2023 15:42:18 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> A faster and simpler way to generate random BigIntegers, avoiding eventually trimming of leading zeros in magnitude array.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Create RandomBigIntegers.java
>   
>   Create a benchmark to measure the performance of BigInteger(int, Random) constructor implementation.

So, item 1 is a non-issue and item 2 is not likely a problem in practice. What, if anything, will be done about item 3?

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

PR Comment: https://git.openjdk.org/jdk/pull/16817#issuecomment-1841688735

From iris at openjdk.org  Tue Dec  5 22:31:33 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 5 Dec 2023 22:31:33 GMT
Subject: RFR: 8321406: Null IDs should be resolved as before catalogs are
 added
In-Reply-To: <lvmCXcYxR1DC_irK81Vtc7M7MErBnLSm1OvPUHljHww=.12f4ee22-3cc4-41fe-a5d8-b2f5e4318782@github.com>
References: <lvmCXcYxR1DC_irK81Vtc7M7MErBnLSm1OvPUHljHww=.12f4ee22-3cc4-41fe-a5d8-b2f5e4318782@github.com>
Message-ID: <oDMoKEFiBalgz-rnXqAvowhVZCZ4Q6RX_3MmREDaDMI=.fa5eba89-f95d-4f24-a7a7-a760ee4526db@github.com>

On Tue, 5 Dec 2023 19:34:58 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Improve null handling. When both the public and system IDs are null, this change lets the resolution process continue as usual, before the catalogs were added. This is consistent with the process on the other part of the program where a CatalogResolver is used only when the IDs are not null.
> 
> Test: existing XML tests passed.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16983#pullrequestreview-1766224226

From lancea at openjdk.org  Tue Dec  5 22:50:33 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 5 Dec 2023 22:50:33 GMT
Subject: RFR: 8321406: Null IDs should be resolved as before catalogs are
 added
In-Reply-To: <lvmCXcYxR1DC_irK81Vtc7M7MErBnLSm1OvPUHljHww=.12f4ee22-3cc4-41fe-a5d8-b2f5e4318782@github.com>
References: <lvmCXcYxR1DC_irK81Vtc7M7MErBnLSm1OvPUHljHww=.12f4ee22-3cc4-41fe-a5d8-b2f5e4318782@github.com>
Message-ID: <hzqCgIxjnn_s9OCLlprM-2PX6AiDuTL6gN8ket1IqVk=.6476ecc2-dce2-47fe-82b1-a399f8e10119@github.com>

On Tue, 5 Dec 2023 19:34:58 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Improve null handling. When both the public and system IDs are null, this change lets the resolution process continue as usual, before the catalogs were added. This is consistent with the process on the other part of the program where a CatalogResolver is used only when the IDs are not null.
> 
> Test: existing XML tests passed.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16983#pullrequestreview-1766249605

From naoto at openjdk.org  Tue Dec  5 23:09:51 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 5 Dec 2023 23:09:51 GMT
Subject: RFR: 8321206: Make Locale related system properties static properties
Message-ID: <EKzdSEIjrFq0mXKLGOdRCePeu29DWWQnpAY5FDVAK40=.3bcd4037-e3e5-4cf1-948d-665355914106@github.com>

Currently, Locale-related system properties, such as `user.language` or `user.country`, are initialized when the `Locale` class is loaded. Making them static properties is safer than relying on the class initialization timing, which could potentially be changed depending on the implementation.

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

Commit messages:
 - Add exclusions in cdsHeapVerifier for new StaticProperties
 - initial commit

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

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

From bchristi at openjdk.org  Wed Dec  6 01:27:39 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 6 Dec 2023 01:27:39 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v2]
In-Reply-To: <UNyY7EdguPAlR3_bfP_NY8PBBD0FXiriyIDNRaThH80=.1b0d3af0-e04c-47ca-944b-2b788ba47ae1@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <CdQYa3Tc8iq8VyFtdloSXvT1SVIYMqjOYmnNK22KT7I=.5a3063c6-9341-44e7-a051-156c5c67f479@github.com>
 <UNyY7EdguPAlR3_bfP_NY8PBBD0FXiriyIDNRaThH80=.1b0d3af0-e04c-47ca-944b-2b788ba47ae1@github.com>
Message-ID: <uSL1mFzmt9GfK56i5WpFtSJWgGJeXeFcm6Z-f_kHuOc=.98ca0e53-fd63-415d-a079-001932b582f2@github.com>

On Tue, 21 Nov 2023 09:16:17 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/ref/Reference.java line 564:
>> 
>>> 562:      * {@code reachabilityFence(x)}
>>> 563:      * <a href="{@docRoot}/java.base/java/util/concurrent/package-summary.html#MemoryVisibility"><i>happen-before</i></a>
>>> 564:      * the garbage collector clears any reference to {code x}.
>> 
>> This is a fairly low-level specification, so the relationship described here is "reachabilityFence **hb** clearing". The relationships "clearing **hb** enqueue" and "enqueue **hb** dequeue" are described elsewhere. Thus the mention of Cleaner above seems misplaced.
>> 
>> However, the whole chain of relationships
>> 
>>> RF **hb** clearing **hb** enqueue **hb** dequeue **hb** cleaning-action
>> 
>> is important. Should this be described somewhere?
>
> Perhaps in each of these places add a link to #Memory Consistency Properties

I can flesh out the new Memory Consistency Properties section in the package info to cover the whole chain. Adding links to it sounds like a good idea.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1416512195

From xgong at openjdk.org  Wed Dec  6 01:29:42 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 6 Dec 2023 01:29:42 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v6]
In-Reply-To: <yB8Wm-5B6h7aHyZyF0zgoc8Bem8Q0FCO5HDo9dlAiCI=.c19369f6-d48e-4c92-9ae4-83d1478be11f@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
 <yB8Wm-5B6h7aHyZyF0zgoc8Bem8Q0FCO5HDo9dlAiCI=.c19369f6-d48e-4c92-9ae4-83d1478be11f@github.com>
Message-ID: <k5MReh19bzIF4GiLM_NhTBwGi8nwDHGfg_-hiSPWT5s=.001a7075-2815-4ad1-92bf-d7313bd8b2d3@github.com>

On Tue, 5 Dec 2023 13:00:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> So you need to check both the flag and the header file? Oh well, then this is probably as good as it gets.

Yes, we have to check both the flag and the header file.

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1841926432

From dholmes at openjdk.org  Wed Dec  6 01:59:48 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Dec 2023 01:59:48 GMT
Subject: RFR: 8321163: [test] OutputAnalyzer.getExitValue() unnecessarily
 logs even when process has already completed [v3]
In-Reply-To: <fSRyNYExpR8nMatf2rIaEYY4X7oisImdgX3EdRmLPSQ=.4c34c0df-51b2-4ed9-9611-da6015a9ff8c@github.com>
References: <uZ77Eagw9Lxz1BKJ8fMnCzvp8Z5VVqsGnsLZtqKZDIo=.0fb8e6cf-7d79-4d4e-b99d-171e008210e9@github.com>
 <0GAdkVhk4e3WJp5bQuLdvtxHk5BtRguNmQ7PoQ5dH50=.4f01dd8f-e2f5-47f8-b66a-2801156d56f5@github.com>
 <fSRyNYExpR8nMatf2rIaEYY4X7oisImdgX3EdRmLPSQ=.4c34c0df-51b2-4ed9-9611-da6015a9ff8c@github.com>
Message-ID: <Pl1fe2z8qywqeQ7xuv-PEKgsw3JkgPRN2e3gW7yQAOE=.2b6ff083-310d-4e16-9ab2-3efddda758fc@github.com>

On Tue, 5 Dec 2023 10:56:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove micro optimization
>
> Thank you Stefan and Leonid for the reviews.

Sorry I missed this party :) Thanks for finding and fixing @jaikiran .

FWIW `exitCode` out numbers `exitValue` in source code 3:1 (and > 5:1 in test code).

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

PR Comment: https://git.openjdk.org/jdk/pull/16919#issuecomment-1841951455

From dholmes at openjdk.org  Wed Dec  6 02:18:33 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Dec 2023 02:18:33 GMT
Subject: RFR: 8321206: Make Locale related system properties static
 properties
In-Reply-To: <EKzdSEIjrFq0mXKLGOdRCePeu29DWWQnpAY5FDVAK40=.3bcd4037-e3e5-4cf1-948d-665355914106@github.com>
References: <EKzdSEIjrFq0mXKLGOdRCePeu29DWWQnpAY5FDVAK40=.3bcd4037-e3e5-4cf1-948d-665355914106@github.com>
Message-ID: <84iT7QgD8wSQoFnFQrKSsYAuG9HLxHZQYfWKeINibiA=.ec2589e5-dd56-4ee5-b3ea-b08e01373ed2@github.com>

On Tue, 5 Dec 2023 23:04:55 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Currently, Locale-related system properties, such as `user.language` or `user.country`, are initialized when the `Locale` class is loaded. Making them static properties is safer than relying on the class initialization timing, which could potentially be changed depending on the implementation.

I'm not following the changes to cdsHeapVerifier.cpp. You've marked the new entries as `C` but the definition is:

// [C] A non-final static string that is assigned a string literal during class
// initialization; this string is never changed during -Xshare:dump.

and these are final static strings not non-final. ???

You also have a large number of test failures with this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/16986#issuecomment-1841972901
PR Comment: https://git.openjdk.org/jdk/pull/16986#issuecomment-1841973970

From dholmes at openjdk.org  Wed Dec  6 02:24:36 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Dec 2023 02:24:36 GMT
Subject: RFR: 8321206: Make Locale related system properties static
 properties
In-Reply-To: <EKzdSEIjrFq0mXKLGOdRCePeu29DWWQnpAY5FDVAK40=.3bcd4037-e3e5-4cf1-948d-665355914106@github.com>
References: <EKzdSEIjrFq0mXKLGOdRCePeu29DWWQnpAY5FDVAK40=.3bcd4037-e3e5-4cf1-948d-665355914106@github.com>
Message-ID: <wNvuHRfgtphZeQjTMc4SXeGdz-z_kYYkHw6vJ2MbaL8=.b0de0809-b019-4cae-ac2b-d95e2a67688e@github.com>

On Tue, 5 Dec 2023 23:04:55 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Currently, Locale-related system properties, such as `user.language` or `user.country`, are initialized when the `Locale` class is loaded. Making them static properties is safer than relying on the class initialization timing, which could potentially be changed depending on the implementation.

Can I also suggest that you change the bug and PR synopsis to say `StaticProperty` rather than `static properties` as I found it quite confusing to understand the issue.

> Making them static properties is safer than relying on the class initialization timing

"class initialization" refers to the static initialization of a class. I assume that is not what you mean here but the creation of the instance of the class? Even `StaticProperty` still initializes these things during class initialization, so I'm unclear exactly what this is trying to say.

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

PR Comment: https://git.openjdk.org/jdk/pull/16986#issuecomment-1841978376

From dholmes at openjdk.org  Wed Dec  6 02:49:35 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Dec 2023 02:49:35 GMT
Subject: RFR: 8321270: Virtual Thread.yield consumes parking permit [v2]
In-Reply-To: <T5KeYeQEEyCL1Rs45QmmVemdAOqMNZcQfTaDUS0xyOA=.0b984979-933d-4807-a109-49d22f09e98e@github.com>
References: <lO0N190PTq5-xjJV0LlgHWm8srDw2K8aC_U0E5qf4gA=.057efa94-6e79-4c76-9273-32ca1449bf84@github.com>
 <T5KeYeQEEyCL1Rs45QmmVemdAOqMNZcQfTaDUS0xyOA=.0b984979-933d-4807-a109-49d22f09e98e@github.com>
Message-ID: <RGE-NUb8u8wpWs_tO2nMvBpsl91nhW2vRUXDUD0tcfY=.df14489e-8a91-456f-b0b7-e23b89cf1c18@github.com>

On Tue, 5 Dec 2023 09:51:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> When a virtual thread continues after Thread.yield it currently consumes thread's parking permit. This is an oversight, the parking permit should only be consumed when continuing after park.
>> 
>> The changes are straight-forward. The internal "RUNNABLE" state is replaced with UNPARKED and YIELDED state, effectively encoding the previous state. So for the most part, it's just replacing the usages of RUNNABLE. The additional states require refactoring tryGetStackTrace, this is the method that is used for Thread::getStackTrace when the virtual thread is unmounted. It is also changed to not not swallow the REE if the reesubmit fails (tryStackTrace has to resubmit as the task for the thread may run, or the thread unparked, while "suspended" and sampling its stack trace). The changes are a subset of larger changes in the loom repo, future PRs will propose to bring in other changes to get main line up to date.
>> 
>> For testing the existing ThreadAPI has new test cases.
>> 
>> Testing: test1-5. This includes the JVMTI tests as it maps the thread states to JVMTI thread states.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Fix comment, remove space between case labels and colon
>  - Merge
>  - Leave onPinned to another PR
>  - Initial commit

I find the switch from `RUNNABLE` to `UNPARKED` somewhat unnecessary. I don't see any problem with `RUNNABLE` that needed fixing. I found the distinction and transition between `RUNNABLE` and `RUNNING` to be very clear. ??

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

PR Review: https://git.openjdk.org/jdk/pull/16953#pullrequestreview-1766538038

From dholmes at openjdk.org  Wed Dec  6 03:00:38 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Dec 2023 03:00:38 GMT
Subject: RFR: 8321270: Virtual Thread.yield consumes parking permit [v2]
In-Reply-To: <T5KeYeQEEyCL1Rs45QmmVemdAOqMNZcQfTaDUS0xyOA=.0b984979-933d-4807-a109-49d22f09e98e@github.com>
References: <lO0N190PTq5-xjJV0LlgHWm8srDw2K8aC_U0E5qf4gA=.057efa94-6e79-4c76-9273-32ca1449bf84@github.com>
 <T5KeYeQEEyCL1Rs45QmmVemdAOqMNZcQfTaDUS0xyOA=.0b984979-933d-4807-a109-49d22f09e98e@github.com>
Message-ID: <Yv_3qgkjlO6pUf1A0NDf8WwJdioUvb08DRdoNyNzrrY=.a5b6aa23-ea85-4270-9d65-7c79c22898b8@github.com>

On Tue, 5 Dec 2023 09:51:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> When a virtual thread continues after Thread.yield it currently consumes thread's parking permit. This is an oversight, the parking permit should only be consumed when continuing after park.
>> 
>> The changes are straight-forward. The internal "RUNNABLE" state is replaced with UNPARKED and YIELDED state, effectively encoding the previous state. So for the most part, it's just replacing the usages of RUNNABLE. The additional states require refactoring tryGetStackTrace, this is the method that is used for Thread::getStackTrace when the virtual thread is unmounted. It is also changed to not not swallow the REE if the reesubmit fails (tryStackTrace has to resubmit as the task for the thread may run, or the thread unparked, while "suspended" and sampling its stack trace). The changes are a subset of larger changes in the loom repo, future PRs will propose to bring in other changes to get main line up to date.
>> 
>> For testing the existing ThreadAPI has new test cases.
>> 
>> Testing: test1-5. This includes the JVMTI tests as it maps the thread states to JVMTI thread states.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Fix comment, remove space between case labels and colon
>  - Merge
>  - Leave onPinned to another PR
>  - Initial commit

Sorry I've deleted my earlier embarassingly stupid comment. The key point of this change is to split RUNNABLE into two states to indicated "runnable after yielding" and "runnable after being unparked".

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

PR Comment: https://git.openjdk.org/jdk/pull/16953#issuecomment-1842005657

From joehw at openjdk.org  Wed Dec  6 04:27:44 2023
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 6 Dec 2023 04:27:44 GMT
Subject: Integrated: 8321406: Null IDs should be resolved as before catalogs
 are added
In-Reply-To: <lvmCXcYxR1DC_irK81Vtc7M7MErBnLSm1OvPUHljHww=.12f4ee22-3cc4-41fe-a5d8-b2f5e4318782@github.com>
References: <lvmCXcYxR1DC_irK81Vtc7M7MErBnLSm1OvPUHljHww=.12f4ee22-3cc4-41fe-a5d8-b2f5e4318782@github.com>
Message-ID: <IJtmBfA6u6kFFbfHOjaaP-Rjbah8Df-YC9WlKtnk26o=.b06550b5-7502-4d8d-8599-db7232eadfa3@github.com>

On Tue, 5 Dec 2023 19:34:58 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Improve null handling. When both the public and system IDs are null, this change lets the resolution process continue as usual, before the catalogs were added. This is consistent with the process on the other part of the program where a CatalogResolver is used only when the IDs are not null.
> 
> Test: existing XML tests passed.

This pull request has now been integrated.

Changeset: 78d09584
Author:    Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/78d09584c9ade967e55865c9d3a8146ae01d208d
Stats:     12 lines in 1 file changed: 6 ins; 0 del; 6 mod

8321406: Null IDs should be resolved as before catalogs are added

Reviewed-by: naoto, iris, lancea

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

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

From vklang at openjdk.org  Wed Dec  6 07:14:49 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 6 Dec 2023 07:14:49 GMT
Subject: Integrated: 8321124: java/util/stream/GatherersTest.java times out
In-Reply-To: <NcgSgagzqKytU8dGSMKHUF_9ylICS5s6If5CoFRjPhw=.abef3a79-b429-47c5-b0b7-aa7b9f71ef31@github.com>
References: <NcgSgagzqKytU8dGSMKHUF_9ylICS5s6If5CoFRjPhw=.abef3a79-b429-47c5-b0b7-aa7b9f71ef31@github.com>
Message-ID: <twB2pACXmHZGJ1eM0hurpMfyi5j1GtzbclxSZi41Fx8=.306c8273-ad6d-4676-95e4-595b8dfc66bf@github.com>

On Fri, 1 Dec 2023 17:00:48 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Splits GatherersTest out to distinct files per built-in gatherer
> 
> Fixes a test ordering issue for mapConcurrent which placed GatherersTest on the ProblemList.
> 
> Adding increased maxOutputSize for Gatherer-related tests to improve debuggability.
> 
> Lowering the composition threshold of GathererTest.testMassivelyComposedGatherers to 256 to avoid SOE on low-specc:ed machines.

This pull request has now been integrated.

Changeset: 9d776777
Author:    Viktor Klang <vklang at openjdk.org>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9d776777c503ede4410ae3fe744cb267e9175433
Stats:     1155 lines in 9 files changed: 785 ins; 369 del; 1 mod

8321124: java/util/stream/GatherersTest.java times out

Reviewed-by: alanb

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

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

From alanb at openjdk.org  Wed Dec  6 07:58:35 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Dec 2023 07:58:35 GMT
Subject: RFR: 8321270: Virtual Thread.yield consumes parking permit [v2]
In-Reply-To: <Yv_3qgkjlO6pUf1A0NDf8WwJdioUvb08DRdoNyNzrrY=.a5b6aa23-ea85-4270-9d65-7c79c22898b8@github.com>
References: <lO0N190PTq5-xjJV0LlgHWm8srDw2K8aC_U0E5qf4gA=.057efa94-6e79-4c76-9273-32ca1449bf84@github.com>
 <T5KeYeQEEyCL1Rs45QmmVemdAOqMNZcQfTaDUS0xyOA=.0b984979-933d-4807-a109-49d22f09e98e@github.com>
 <Yv_3qgkjlO6pUf1A0NDf8WwJdioUvb08DRdoNyNzrrY=.a5b6aa23-ea85-4270-9d65-7c79c22898b8@github.com>
Message-ID: <pFcqSpfXhmxJRqiQmuU_7VxbHTrBYGg7MR8T2-cJOGo=.b28e8d59-38fa-479b-ae30-e0fea0ba5ce0@github.com>

On Wed, 6 Dec 2023 02:58:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The key point of this change is to split RUNNABLE into two states to indicated "runnable after yielding" and "runnable after being unparked".

That's right. This comes up with upcoming changes for monitors too - in that case it is important that a virtual thread that continues after blocking on monitorenter doesn't consume its parking permit.

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

PR Comment: https://git.openjdk.org/jdk/pull/16953#issuecomment-1842310534

From pminborg at openjdk.org  Wed Dec  6 08:05:45 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 6 Dec 2023 08:05:45 GMT
Subject: Integrated: 8321159: SymbolLookup.libraryLookup(Path,
 Arena) Assumes default Filesystem
In-Reply-To: <sbkQW1a7NByueXA7Vm_JVE06P3queX4AkDE-rlFFbgg=.35168862-4033-4184-97c8-86ab21da922e@github.com>
References: <sbkQW1a7NByueXA7Vm_JVE06P3queX4AkDE-rlFFbgg=.35168862-4033-4184-97c8-86ab21da922e@github.com>
Message-ID: <nqMGvnSX_lN8ieG1uc5QT6IE-l1xDnSSENcUiysD3AA=.83a7aeae-439a-46ad-8529-50b28380e19e@github.com>

On Mon, 4 Dec 2023 07:29:37 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to reject paths provided to the `SymbolLookup.libraryLookup(Path path, Arena arena)` method if a path is not in the default file system.

This pull request has now been integrated.

Changeset: a0920aa4
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a0920aa436943b88b53a81f46752e8c4bb0a0fc7
Stats:     42 lines in 2 files changed: 42 ins; 0 del; 0 mod

8321159: SymbolLookup.libraryLookup(Path, Arena) Assumes default Filesystem

Reviewed-by: mcimadamore

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

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

From alanb at openjdk.org  Wed Dec  6 08:16:34 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Dec 2023 08:16:34 GMT
Subject: RFR: 8321206: Make Locale related system properties static
 properties
In-Reply-To: <EKzdSEIjrFq0mXKLGOdRCePeu29DWWQnpAY5FDVAK40=.3bcd4037-e3e5-4cf1-948d-665355914106@github.com>
References: <EKzdSEIjrFq0mXKLGOdRCePeu29DWWQnpAY5FDVAK40=.3bcd4037-e3e5-4cf1-948d-665355914106@github.com>
Message-ID: <797rwHmV9jH9-73C5QISVPprqdl2245BQn0M5h8L5DE=.58daf90d-4828-488f-8bd9-acd100580bee@github.com>

On Tue, 5 Dec 2023 23:04:55 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Currently, Locale-related system properties, such as `user.language` or `user.country`, are initialized when the `Locale` class is loaded. Making them static properties is safer than relying on the class initialization timing, which could potentially be changed depending on the implementation.

src/java.base/share/classes/java/util/Locale.java line 1099:

> 1097:             StaticProperty.userCountry(category.ordinal() + 1),
> 1098:             StaticProperty.userVariant(category.ordinal() + 1),
> 1099:             getDefaultExtensions(StaticProperty.userExtensions(category.ordinal() + 1))

I suspect this would be more readable, and maintainable, if you add non-public languageKey/scriptKey/countryKey/variantKey methods to Locale.Category. That would change this to getInstance(category.languageKey(), ...) so no sight of the ordinal at the use-site.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16986#discussion_r1416885432

From xgong at openjdk.org  Wed Dec  6 09:15:05 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 6 Dec 2023 09:15:05 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v5]
In-Reply-To: <Zhu-7NV4dgrBXks4CoC1tNs-4WFmoQvBo-tzqYjbY50=.210204f3-7ed2-4d40-a7c7-c1989530dca0@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <nZFspjlPXfeQxrr5cKfbjeL3typf6DKSgNQUNszhufE=.caac471d-9c7b-4f8f-953f-04ee4a13f111@github.com>
 <9VeMdTAJPaPZDg9ZW7FVJOf9XGl4gGqAS-2g8SFc9c0=.36792cd5-66d9-4abc-ba0c-aee3478627f4@github.com>
 <mnf_hjWdemelALPlwcS8mnKIxR5ljIyGD6MHpqCPDsQ=.0cb49580-ed76-4728-a604-acff3dff42a5@github.com>
 <aArEqABKvjZDCxOkkpKS1rlX9Q0aafCUY8ZS3L5OBek=.f009f07b-c9e4-437b-a6d3-c86fb29d75a0@github.com>
 <vlqKSuAKzKRTXWG_hLCEJixN8oFec68IuSnfb0u9OJ0=.6c926fc3-f0f3-4ccf-b373-555948c3702b@github.com>
 <a0fi6KAaaVceRSRWzviR0W1iN-CjlkCIS9GjHAxRr5g=.324dd1aa-d4bd-48f1-8e23-604b09b75b4c@github.com>
 <tHkg8-8CbvcHsfEhonfA4PxB_XXjonY5MbmunXEfFEI=.428e7a97-0bce-4f17-b93c-3275037e5a66@github.com>
 <Zhu-7NV4dgrBXks4CoC1tNs-4WFmoQvBo-tzqYjbY50=.210204f3-7ed2-4d40-a7c7-c1989530dca0@github.com>
Message-ID: <81tcSvaI8RdngSM-Nq051Vwl81u9NyEgVr8BCV44KYw=.74051087-23af-441f-825a-83dfa70c9426@github.com>

On Tue, 5 Dec 2023 13:03:22 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Thanks for the suggestion @magicus !
>> 
>> The check in current `lib-sleef.m4` is very common:
>> 
>> -  If user has specified libsleef root by '--with-libsleef', we assume it is the manually built sleef lib. So only `lib/` and `include/` is checked. And the flags are set based on that path.
>> - If user has not specified the libsleef root, and no `SYSROOT` is set, we try `PKG_CHECK` (like what you suggested)
>> - Otherwise, check `sleef.h`   
>>    - We assume the sleef module is installed under one of the valid system paths if the header can be found. So just linking with `-lsleef` will success.
>> 
>> It's an issue in current flow like what @theRealAph met. I will add the options like `--with-libsleef-lib` and `--with-libsleef-include` like ffi. Regarding to extending the check for`--with-libsleef`, I think we can just make it simple like what it is now. Or, we have to check all the potential valid lib paths like `lib/`, `lib64/`, or maybe `lib/aarch64-linux-gnu`. The same to the `include` part.  @theRealAph @magicus , WDYT?
>
> I'm fine with adding just --with-libsleef-lib and --with-libsleef-include to specify them directly. This makes it at least possible to use, if not overly convenient, for people using a system like Andrew's. If it annoys someone too much, we can extend it later.

Added these two options in latest commit. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1416962901

From xgong at openjdk.org  Wed Dec  6 09:14:58 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 6 Dec 2023 09:14:58 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v7]
In-Reply-To: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
Message-ID: <VaRAGqDPyx-9MRdtDUT1EwN2bEwJM0V3o0_AJpmNdBU=.0af098f2-aedf-43e2-a7b1-d127b02f14ba@github.com>

> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
> 
> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
> 
> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
> 
> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
> 
> [1] https://github.com/openjdk/jdk/pull/3638
> [2] https://sleef.org/
> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
> [4] https://packages.debian.org/bookworm/libsleef3
> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html

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

  Add "--with-libsleef-lib" and "--with-libsleef-include" options

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16234/files
  - new: https://git.openjdk.org/jdk/pull/16234/files/ee5caf6d..f3ff0672

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

  Stats: 124 lines in 3 files changed: 67 ins; 33 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/16234.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16234/head:pull/16234

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

From xgong at openjdk.org  Wed Dec  6 09:15:03 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 6 Dec 2023 09:15:03 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v6]
In-Reply-To: <dxnGzEBuDdVHnuYm1AaoTYNjTQzdpHHamkgb3QxEpPc=.7671caf2-74f8-4d6f-8bcf-8f189488bd0a@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
 <dxnGzEBuDdVHnuYm1AaoTYNjTQzdpHHamkgb3QxEpPc=.7671caf2-74f8-4d6f-8bcf-8f189488bd0a@github.com>
Message-ID: <NkqVZRkKYcpkdOOYPeRzMoLLMogCGlrgytimezITYQk=.2643ccd9-aba5-4bf0-bf41-5a09e9a25495@github.com>

On Fri, 1 Dec 2023 16:26:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request with a new target base 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:
>> 
>>  - Separate neon and sve functions into two source files
>>  - Merge branch 'jdk:master' into JDK-8312425
>>  - Rename vmath to sleef in configure
>>  - Address review comments in build system
>>  - Add a bundled native lib in jdk as a bridge to libsleef
>>  - Merge 'jdk:master' into JDK-8312425
>>  - Disable sleef by default
>>  - Merge 'jdk:master' into JDK-8312425
>>  - 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF
>
> doc/building.md line 639:
> 
>> 637: 
>> 638: libsleef, the [SIMD Library for Evaluating Elementary Functions](
>> 639: https://sleef.org/) is required when building libvmath.so on Linux/aarch64
> 
> This is incorrect. The library is not required, but if it is present, we will build libvmath with it.
> 
> Edit: Or rather, this is misleading. Technically it is correct, since you state that it is required when building libvmath.so, but it is easy to mistake for being required for building the JDK. The reader presumably does not know what libvmath.so is or how it is used.
> 
> Please rephrase this to so that it is clear that this is optional, but will provide performance benefits to the resulting JDK if present. You do not need to mention libvmath.so here, for no other dependency do we declare what parts of the JDK that require it -- it is not essential for this document.
> 
> Also see if you can make this paragraph and the one at the end be a bit more tighter, not the last paragraph seems to be both repeat and contradict this one.

Hi @magicus , the doc is updated. Thanks for your comment on this!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1416964362

From stefank at openjdk.org  Wed Dec  6 09:21:46 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 6 Dec 2023 09:21:46 GMT
Subject: RFR: 8321163: [test] OutputAnalyzer.getExitValue() unnecessarily
 logs even when process has already completed [v3]
In-Reply-To: <Pl1fe2z8qywqeQ7xuv-PEKgsw3JkgPRN2e3gW7yQAOE=.2b6ff083-310d-4e16-9ab2-3efddda758fc@github.com>
References: <uZ77Eagw9Lxz1BKJ8fMnCzvp8Z5VVqsGnsLZtqKZDIo=.0fb8e6cf-7d79-4d4e-b99d-171e008210e9@github.com>
 <0GAdkVhk4e3WJp5bQuLdvtxHk5BtRguNmQ7PoQ5dH50=.4f01dd8f-e2f5-47f8-b66a-2801156d56f5@github.com>
 <fSRyNYExpR8nMatf2rIaEYY4X7oisImdgX3EdRmLPSQ=.4c34c0df-51b2-4ed9-9611-da6015a9ff8c@github.com>
 <Pl1fe2z8qywqeQ7xuv-PEKgsw3JkgPRN2e3gW7yQAOE=.2b6ff083-310d-4e16-9ab2-3efddda758fc@github.com>
Message-ID: <xx4fDFwQXX8PBJdF1O2K9ryRmeivncys_hCkeF_5aBo=.f28687b7-ffb4-47f3-a153-c9a3e308604d@github.com>

On Wed, 6 Dec 2023 01:56:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

> FWIW exitCode out numbers exitValue in source code 3:1 (and > 5:1 in test code).

That might be the case, but both the called function returning the value and the function we are changing uses the name exitValue. It seems irrelevant that other places in the code uses exitCode.

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

PR Comment: https://git.openjdk.org/jdk/pull/16919#issuecomment-1842489162

From mcimadamore at openjdk.org  Wed Dec  6 09:29:37 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 6 Dec 2023 09:29:37 GMT
Subject: RFR: 8321248: ClassFile API ClassModel::verify is inconsistent
 with the rest of the API
In-Reply-To: <ydm5vaSl_9iTojm2PkI5Z4pu9OkV8L663DFFuKOgINM=.6e7bd095-fc4c-4884-af15-137ef3565e17@github.com>
References: <ydm5vaSl_9iTojm2PkI5Z4pu9OkV8L663DFFuKOgINM=.6e7bd095-fc4c-4884-af15-137ef3565e17@github.com>
Message-ID: <WxYS-yipn_I7LEdNIF0TC-2VZC_f6qGL6c0MFi2j_P8=.647cf914-20c7-4b3f-a011-43350469da24@github.com>

On Mon, 4 Dec 2023 11:12:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> ClassFile API `ClassModel::verify` accepts `ClassHierarchyResolver` as an optional argument and does not respect `ClassFile.ClassHierarchyResolverOption` of the actual context.
> Parsing, building and transforming take options from the actual `ClassFile` context and verification should follow the same API pattern.
> 
> This patch removes `ClassModel::verify` methods and introduces new top level methods:
> 
> List<VerifyError> ClassFile::verify(ClassModel model);
> List<VerifyError> ClassFile::verify(byte[] bytes);
> List<VerifyError> ClassFile::verify(Path path);
> 
> 
> Impact of the API change is minimal as the API has not been released yet.
> 
> Please review.
> 
> Thanks,
> Adam

test/jdk/jdk/classfile/VerifierSelfTest.java line 62:

> 60: 
> 61:     @Test
> 62:     void testFailedDump() throws IOException {

Why is this removed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16947#discussion_r1416985296

From sgehwolf at openjdk.org  Wed Dec  6 09:37:47 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 6 Dec 2023 09:37:47 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v12]
In-Reply-To: <iHvfP1CJRkBYTMEyCGUHvsyWxPHdVp36g49nxbxZfXU=.db86d493-f32e-4faf-a3e5-cf414ac9abbb@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <iHvfP1CJRkBYTMEyCGUHvsyWxPHdVp36g49nxbxZfXU=.db86d493-f32e-4faf-a3e5-cf414ac9abbb@github.com>
Message-ID: <ZBaCyBTRa1orGe41rzKM9PvQ27UrH86r5jdHPILcZxE=.9c20f85f-233b-4ca1-b662-e349519fbcc5@github.com>

On Tue, 5 Dec 2023 19:15:53 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a "jmodless" jlink mode to the JDK. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JmodLessArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.internal.vm.compiler.management.jmod  jdk.jlink.jmod       jdk.naming.dns.j...
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:
> 
>  - Add @enablePreview for JImageValidator that uses classfile API
>  - Fix SystemModulesPlugin after merge
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Don't show the verbose hint when already verbose
>  - Use '_files' over '_resources' as the suffix for listing resources
>  - Remove the hidden option hint.
>    
>    Also adjust the messages being printed when performing
>    a run-time image link.
>  - Localize messages, switch expression
>  - Rename RunImageArchive => JRTArchive and RunImageLinkException => RuntimeImageLinkException
>    
>    Also moved the stamp file to jdk.jlink module. The resources files per
>    module now get unconditionally created (empty if no resources not in the
>    jimage).
>  - First round of addressing review feedback.
>    
>    - Share resource names (JlinkTask and JlinkResourcesListPlugin)
>    - Exclude resources in JlinkResourcesListPlugin the same way
>      as done for other plugins.
>  - Rename AddRunImageResourcesPlugin => JlinkResourcesListPlugin
>  - ... and 36 more: https://git.openjdk.org/jdk/compare/87516e29...a797ea69

The x86 test failure related to stream gatherers seems unrelated.

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

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1842514733

From asotona at openjdk.org  Wed Dec  6 09:45:36 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Dec 2023 09:45:36 GMT
Subject: RFR: 8321248: ClassFile API ClassModel::verify is inconsistent
 with the rest of the API
In-Reply-To: <WxYS-yipn_I7LEdNIF0TC-2VZC_f6qGL6c0MFi2j_P8=.647cf914-20c7-4b3f-a011-43350469da24@github.com>
References: <ydm5vaSl_9iTojm2PkI5Z4pu9OkV8L663DFFuKOgINM=.6e7bd095-fc4c-4884-af15-137ef3565e17@github.com>
 <WxYS-yipn_I7LEdNIF0TC-2VZC_f6qGL6c0MFi2j_P8=.647cf914-20c7-4b3f-a011-43350469da24@github.com>
Message-ID: <PJrqZc52eH1BfKJ1Yh8SZkhzbD28NiWqIXVK7S9P-Jc=.5bedc151-28ce-4502-9b10-f3f6d09c3bcf@github.com>

On Wed, 6 Dec 2023 09:26:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> ClassFile API `ClassModel::verify` accepts `ClassHierarchyResolver` as an optional argument and does not respect `ClassFile.ClassHierarchyResolverOption` of the actual context.
>> Parsing, building and transforming take options from the actual `ClassFile` context and verification should follow the same API pattern.
>> 
>> This patch removes `ClassModel::verify` methods and introduces new top level methods:
>> 
>> List<VerifyError> ClassFile::verify(ClassModel model);
>> List<VerifyError> ClassFile::verify(byte[] bytes);
>> List<VerifyError> ClassFile::verify(Path path);
>> 
>> 
>> Impact of the API change is minimal as the API has not been released yet.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> test/jdk/jdk/classfile/VerifierSelfTest.java line 62:
> 
>> 60: 
>> 61:     @Test
>> 62:     void testFailedDump() throws IOException {
> 
> Why is this removed?

Dump (print) of the classfile to an optional log (Consumer&lt;String&gt; argument) has been removed from the API.
It was a relic from early phase of the ClassFile API development and it has no use except for this test.
This functionality can be replaced by explicit use of ClassPrinter.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16947#discussion_r1417008753

From asotona at openjdk.org  Wed Dec  6 09:49:43 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Dec 2023 09:49:43 GMT
Subject: RFR: 8321248: ClassFile API ClassModel::verify is inconsistent
 with the rest of the API
In-Reply-To: <PJrqZc52eH1BfKJ1Yh8SZkhzbD28NiWqIXVK7S9P-Jc=.5bedc151-28ce-4502-9b10-f3f6d09c3bcf@github.com>
References: <ydm5vaSl_9iTojm2PkI5Z4pu9OkV8L663DFFuKOgINM=.6e7bd095-fc4c-4884-af15-137ef3565e17@github.com>
 <WxYS-yipn_I7LEdNIF0TC-2VZC_f6qGL6c0MFi2j_P8=.647cf914-20c7-4b3f-a011-43350469da24@github.com>
 <PJrqZc52eH1BfKJ1Yh8SZkhzbD28NiWqIXVK7S9P-Jc=.5bedc151-28ce-4502-9b10-f3f6d09c3bcf@github.com>
Message-ID: <mNGwG43JKaxUDjwodKDC4fvfOvEtpTX5bDuLf8h8ETU=.96a67af9-ab10-47ca-977c-d3290e27569a@github.com>

On Wed, 6 Dec 2023 09:42:49 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> test/jdk/jdk/classfile/VerifierSelfTest.java line 62:
>> 
>>> 60: 
>>> 61:     @Test
>>> 62:     void testFailedDump() throws IOException {
>> 
>> Why is this removed?
>
> Dump (print) of the classfile to an optional log (Consumer&lt;String&gt; argument) has been removed from the API.
> It was a relic from early phase of the ClassFile API development and it has no use except for this test.
> This functionality can be replaced by explicit use of ClassPrinter.

I'll rename the test to "testFailed" and keep it without the "dump" part.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16947#discussion_r1417013768

From aph at openjdk.org  Wed Dec  6 10:20:45 2023
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 6 Dec 2023 10:20:45 GMT
Subject: RFR: 8318809:
 java/util/concurrent/ConcurrentLinkedQueue/WhiteBox.java shows intermittent
 failures on linux ppc64le and aarch64
In-Reply-To: <ZfdB8dzmkemBibEXbgAePF-PLovEg5mA5FxSlAirn1Q=.36b84a9a-aa04-4f6d-9e56-0dfadd4cacef@github.com>
References: <iA3gGFe3YwhNjdNk6ZoafPE7ak6VPp0qQ4cgT8R42qE=.30dc4dbc-c24a-4671-83f5-f7be232e1143@github.com>
 <ZfdB8dzmkemBibEXbgAePF-PLovEg5mA5FxSlAirn1Q=.36b84a9a-aa04-4f6d-9e56-0dfadd4cacef@github.com>
Message-ID: <9oxcKGPFwC1V43R7ryYPieEMDIqu6U6tW4AuNrNUST4=.5d383339-6a3f-48ee-9703-1edc2c4ff554@github.com>

On Tue, 5 Dec 2023 09:08:59 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> We've seen some rare failures of the CLQ Whitebox test on "less-strong" architectures, and the only thing which -- given my research -- could be the culprit is spuriously failing weakCAS (which is correct in terms of the implementation of CLQ).
>> 
>> After discussion with @DougLea, it was decided as the CLQ implementation does not guarantee what the failing test tests, and modifying the test would mean that it would generally not be able to enforce anything, the test is invalid and should be removed -- hence this PR.
>
> Few AArch64 HotSpot systems implement weak CAS as anything other than plain CAS. In order to get to the root cause of this problem, it would help to know on which AArch64 hardware this test failed.

> @theRealAph I think the problem in this case was that the whitebox test in this case relied on a presumption that was only true for stronger consistency architectures, and rewriting the test would essentially be asserting that "a lot of permutations are valid, and only internally observable" which is a low-value test.

Oh right, so nothing to do with weak CAS, then. Fair enough.

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

PR Comment: https://git.openjdk.org/jdk/pull/16786#issuecomment-1842584686

From asotona at openjdk.org  Wed Dec  6 10:40:51 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Dec 2023 10:40:51 GMT
Subject: RFR: 8321248: ClassFile API ClassModel::verify is inconsistent
 with the rest of the API [v2]
In-Reply-To: <ydm5vaSl_9iTojm2PkI5Z4pu9OkV8L663DFFuKOgINM=.6e7bd095-fc4c-4884-af15-137ef3565e17@github.com>
References: <ydm5vaSl_9iTojm2PkI5Z4pu9OkV8L663DFFuKOgINM=.6e7bd095-fc4c-4884-af15-137ef3565e17@github.com>
Message-ID: <GiTWQ6BA8jSxOyLiVMbQJkr4lPdbDML2PbaQv2B6aus=.830242ed-5daf-4d09-85db-562cfee6e109@github.com>

> ClassFile API `ClassModel::verify` accepts `ClassHierarchyResolver` as an optional argument and does not respect `ClassFile.ClassHierarchyResolverOption` of the actual context.
> Parsing, building and transforming take options from the actual `ClassFile` context and verification should follow the same API pattern.
> 
> This patch removes `ClassModel::verify` methods and introduces new top level methods:
> 
> List<VerifyError> ClassFile::verify(ClassModel model);
> List<VerifyError> ClassFile::verify(byte[] bytes);
> List<VerifyError> ClassFile::verify(Path path);
> 
> 
> Impact of the API change is minimal as the API has not been released yet.
> 
> Please review.
> 
> Thanks,
> Adam

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

  reverted modified test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16947/files
  - new: https://git.openjdk.org/jdk/pull/16947/files/4485a369..bacdf481

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

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

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

From jlaskey at openjdk.org  Wed Dec  6 11:47:13 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 6 Dec 2023 11:47:13 GMT
Subject: RFR: JDK-8320570 NegativeArraySizeException decoding >1G UTF8
 bytes with non-ascii characters [v3]
In-Reply-To: <wK-u3PPhgDfuUAGIWQNgYs_gxKrDVjsNs8ImLonZObU=.49b3b03b-6deb-418a-9ab0-9c9fc563b33a@github.com>
References: <wK-u3PPhgDfuUAGIWQNgYs_gxKrDVjsNs8ImLonZObU=.49b3b03b-6deb-418a-9ab0-9c9fc563b33a@github.com>
Message-ID: <VPQVYI_8jeogmxQqB1xkmrH82TDTqq_1lmoodVUK-bY=.0d8a9796-6a08-48d9-91c5-d53c31e05a1d@github.com>

> A regression is found in Java9+ creating String instance from UTF8 bytes, a side effect of string compactation https://openjdk.org/jeps/254 that changed the decoding logic. Specifically, when constructing a string from bytes: 
> 
> ``` 
> String str = new String(largeBytes, StandardCharsets.UTF_8); 
> ``` 
> 
> if the size of largeBytes is greater than 2^30 (>1 GB) but smaller than INT_MAX (2 GB), it fails on Java9+ (including 11, 17, 21, though the stack trace is slightly different, see below), regardless of jvm heap size. In Java8, it succeeded when jvm heap size is set to be sufficient.

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

  Requested changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16974/files
  - new: https://git.openjdk.org/jdk/pull/16974/files/ddc7acc2..144b5161

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

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

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

From jlaskey at openjdk.org  Wed Dec  6 11:47:13 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 6 Dec 2023 11:47:13 GMT
Subject: RFR: JDK-8320570 NegativeArraySizeException decoding >1G UTF8
 bytes with non-ascii characters [v2]
In-Reply-To: <yO5UsjnCkkkYl60K5TjkNKcyI1ZS7NZsJtOwWGlhh44=.2379ba37-840a-433f-91a1-0b45fa0c54b3@github.com>
References: <wK-u3PPhgDfuUAGIWQNgYs_gxKrDVjsNs8ImLonZObU=.49b3b03b-6deb-418a-9ab0-9c9fc563b33a@github.com>
 <G94Cz5zFGejqY9uiERlz-DE8reEg_dg3Jcv_LEWI-q4=.f5b1ea8b-ad17-4e6d-a687-e6ab30207100@github.com>
 <yO5UsjnCkkkYl60K5TjkNKcyI1ZS7NZsJtOwWGlhh44=.2379ba37-840a-433f-91a1-0b45fa0c54b3@github.com>
Message-ID: <U1iHArPhoD-jgjQke6-nLd7m74dZEnpGW_q-s89WCLg=.a5fdc290-e679-4c4c-a36e-e2fb8c6a24e5@github.com>

On Tue, 5 Dec 2023 20:44:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Bump up memory
>>  - Cotrrect NegativeSize.java
>
> test/jdk/java/lang/String/CompactString/NegativeSize.java line 30:
> 
>> 28:  * @test
>> 29:  * @bug 8077559
>> 30:  * @summary Tests Compact String for negative size.
> 
> It might be useful to require the larger memory; to avoid getting run when there's insufficient memory available.
> 
>  * @requires os.maxMemory >= 4G

Updated

> test/jdk/java/lang/String/CompactString/NegativeSize.java line 63:
> 
>> 61:             System.out.println(inStr.substring(1_200_000_000));
>> 62:         } catch (OutOfMemoryError ex) {
>> 63:             System.out.println("Succeeded with OutOfMemoryError");
> 
> It might be good to check that it is the expected OOME whose message starts with `UTF16 String size is `.
> No just any "Java heap memory" OOME.

Updated

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16974#discussion_r1417154205
PR Review Comment: https://git.openjdk.org/jdk/pull/16974#discussion_r1417154093

From ihse at openjdk.org  Wed Dec  6 11:48:44 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 6 Dec 2023 11:48:44 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v7]
In-Reply-To: <VaRAGqDPyx-9MRdtDUT1EwN2bEwJM0V3o0_AJpmNdBU=.0af098f2-aedf-43e2-a7b1-d127b02f14ba@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <VaRAGqDPyx-9MRdtDUT1EwN2bEwJM0V3o0_AJpmNdBU=.0af098f2-aedf-43e2-a7b1-d127b02f14ba@github.com>
Message-ID: <0ya82eFBzsE0U96QMoP7OKmd7PAvW7GFXYP_iD_HTqE=.f12ca572-4a4e-4fbd-947b-e11f0aad81a1@github.com>

On Wed, 6 Dec 2023 09:14:58 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
>> 
>> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
>> 
>> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
>> 
>> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
>> 
>> [1] https://github.com/openjdk/jdk/pull/3638
>> [2] https://sleef.org/
>> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
>> [4] https://packages.debian.org/bookworm/libsleef3
>> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add "--with-libsleef-lib" and "--with-libsleef-include" options

make/modules/jdk.incubator.vector/Lib.gmk line 45:

> 43:   $(eval $(call SetupJdkLibrary, BUILD_LIBVMATH, \
> 44:       NAME := vmath, \
> 45:       CFLAGS := $(CFLAGS_JDKLIB) $(LIBSLEEF_CFLAGS) -fvisibility=default, \

Why `-fvisibility=default`? (Sorry, only noticed this now)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1417156921

From ihse at openjdk.org  Wed Dec  6 11:53:42 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 6 Dec 2023 11:53:42 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v7]
In-Reply-To: <VaRAGqDPyx-9MRdtDUT1EwN2bEwJM0V3o0_AJpmNdBU=.0af098f2-aedf-43e2-a7b1-d127b02f14ba@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <VaRAGqDPyx-9MRdtDUT1EwN2bEwJM0V3o0_AJpmNdBU=.0af098f2-aedf-43e2-a7b1-d127b02f14ba@github.com>
Message-ID: <UFlHjCC7UqA5FCAjn2v5lmzML8cYEbMERY6GW2CYs3Q=.c814b409-4cd1-4e6a-b3d6-f660c24b5487@github.com>

On Wed, 6 Dec 2023 09:14:58 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
>> 
>> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
>> 
>> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
>> 
>> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
>> 
>> [1] https://github.com/openjdk/jdk/pull/3638
>> [2] https://sleef.org/
>> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
>> [4] https://packages.debian.org/bookworm/libsleef3
>> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add "--with-libsleef-lib" and "--with-libsleef-include" options

All the makefile changes we've discussed previously now look good. However, I just noticed the additional -f flag. Why are you not exporting the functions from source code instead? That is the way we normally do it in JDK libraries. In your case, it seems like you only need to add the export to the macro.

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1842720243

From ihse at openjdk.org  Wed Dec  6 12:02:42 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 6 Dec 2023 12:02:42 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v8]
In-Reply-To: <7ocsRxaWjoU2vxwPUSE7BrnLSL1bF_7Pp8vReacNJvE=.1c044b21-b27e-4e94-8db0-6ae888a1e8b9@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <7ocsRxaWjoU2vxwPUSE7BrnLSL1bF_7Pp8vReacNJvE=.1c044b21-b27e-4e94-8db0-6ae888a1e8b9@github.com>
Message-ID: <rh_4hxMmK37EYUk21sIZIgKff3FLD9u29HCz0b3sNts=.bfdf3f5f-686c-4b13-971e-edb321b3ea2d@github.com>

On Mon, 4 Dec 2023 22:15:24 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX2 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
>> 
>> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
>> 
>> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId content=Excel.Sheet>
>> <meta name=Generator content="Microsoft Excel 15">
>> <link id=Main-File rel=Main-File
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
>> <link rel=File-List
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
>> 
>> 
>> </head>
>> 
>> <body link="#0563C1" vlink="#954F72">
>> 
>> 
>> 
>> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
>> -- | -- | -- | -- | --
>> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
>> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
>> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
>> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
>> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
>> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
>> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
>> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
>> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
>> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
>> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
>> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
>> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
>> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
>> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
>> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
>> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
>> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
>> 
>> </body>
>> 
>> </html>
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId cont...
>
> Srinivas Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>  - add GCC version guards
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>  - Remove C++17 from C flags
>  - add avoid masked stores operation
>  - update the code to check for supported simd sort cpus
>  - Disable AVX2 sort for 64-bit types
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>  - fix jcheck failures due to windows encoding
>  - fix carriage return and change insertion sort thresholds
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/dbbc5f0a...bc590d9f

Build changes look fine. You will still need the usual 2 reviewers from hotspot.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16534#pullrequestreview-1767374468

From ihse at openjdk.org  Wed Dec  6 12:02:43 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 6 Dec 2023 12:02:43 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v8]
In-Reply-To: <wpFxnb5dr5v2UHZYPPdi4XsBUiLtFXGxRySgr6xCmJM=.74175d6e-0f30-464e-9c76-cc4e8bd6f36a@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <e5w5YZ0WD8S3UVFBYz6I0PdKZ6yOkD77BCq2arDd6i4=.7eecadcb-e627-4e9b-8f1e-3fc41c63243b@github.com>
 <bopxvLCquUtZQxt8kAJskzXBR2YE_I0PW13i3NBJNNY=.e65abf3d-0ff4-4450-875b-ca3717170485@github.com>
 <DeQgR1PaXlk2yzlxV15N3ViZY26wXtlgfVKxRY6vuWo=.6d38f729-0ca9-4f43-9e23-f5e73a01cc23@github.com>
 <b1Nv5Y7Klpvp5ACcHJTTblwGmnA64cyRg-3YzotaHvc=.0bd8a0f0-0844-44a9-a3bb-4af2e8514ee1@github.com>
 <t_23EA--aX8v2US9Lsib1ZF3bl4HQx_Z4RXqlgQo8LE=.6f1f2873-015c-4b69-ad47-b449e5b77a45@github.com>
 <pRcJlU1a4jG9gMaftLn5IerudMSDIrvr70KBefkpNSo=.f442f0d4-887f-4376-a66e-8254fa35927c@github.com>
 <OJ1ZK4a8c_bZik60v503VUtZoweFFv6VhhGg1sp4qSY=.e8852bf1-2d7f-4164-b952-d88b294ec1f7@github.com>
 <_gSNXk0qGAtpY-WJ5OCHk_3-nuGrwwSn-ffK9f2TEcs=.40f785ba-83dd-40fe-8075-a7a7872ea600@github.com>
 <v95kXnbADF5XriLfeg2v5yVYBo-BUzR-dhpcubuMDcI=.03d8e5a7-8b0c-4291-99df-2d3ec6cd356c@github.com>
 <D2AGAYSictxU124OSQMg3V5bpM1oKBdxKLd
 BS0X7ow8=.326a6f38-e9ab-4b24-a6d6-d8eebdb346f7@github.com>
 <wpFxnb5dr5v2UHZYPPdi4XsBUiLtFXGxRySgr6xCmJM=.74175d6e-0f30-464e-9c76-cc4e8bd6f36a@github.com>
Message-ID: <7_T6sM3wjbSzZ0ab9FsptbpPnlQ2J4NNctQNkdbDFdI=.b595a8cc-4b14-44c6-8319-00e68fea21c3@github.com>

On Tue, 5 Dec 2023 17:26:06 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> That sounds weird. You can't check for if compiler options should be enabled or not inside source code files.
>> 
>> Are you saying that when compiling with GCC 6, it will just silently ignore `-std=c++17`? I'd have assumed that it printed a warning or error about an unknown or invalid option, if C++17 is not supported.
>
> Hi Magnus (@magicus),
>  
>> Are you saying that when compiling with GCC 6, it will just silently ignore `-std=c++17`? I'd have assumed that it printed a warning or error about an unknown or invalid option, if C++17 is not supported.
> 
> The GCC complier for versions 6 (and even 5) silently ignores the flag `-std=c++17`. It does not print any warning or error. I tested it with a toy C++ program and also by building OpenJDK using GCC 6. 
> 
>> You can't check for if compiler options should be enabled or not inside source code files.
> 
>  what I meant was, there are #ifdef guards using predefined macros in the C++ source code to check for GCC version and make the simdsort code available for compilation or not based on the GCC version
> 
> 
> // src/java.base/linux/native/libsimdsort/simdsort-support.hpp
> #if defined(_LP64) && (defined(__GNUC__) && ((__GNUC__ > 7) || ((__GNUC__ == 7) && (__GNUC_MINOR__ >= 5))))
>         #define __SIMDSORT_SUPPORTED_LINUX
> #endif
> 
> 
> 
> //src/java.base/linux/native/libsimdsort/avx2-linux-qsort.cpp
> #include "simdsort-support.hpp"
> #ifdef __SIMDSORT_SUPPORTED_LINUX
>             <simdsort functions>
> #endif

Okay, then I guess I am fine with this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1417170882

From alanb at openjdk.org  Wed Dec  6 12:26:36 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Dec 2023 12:26:36 GMT
Subject: RFR: JDK-8319662 ForkJoinPool trims worker threads too slowly [v8]
In-Reply-To: <4Uww87u_Iduao3i7nucJk8IMwfI_c14fEZ1xOUVsgHM=.87bdab09-4936-4fbd-afa0-bc02ead39d5d@github.com>
References: <EfYHyY5R-XjTMrOb7XJbe4Y0m9Zq7zYuI4BlS3T2k2w=.8682eec9-4cae-4004-85dc-923062ac1b5f@github.com>
 <4Uww87u_Iduao3i7nucJk8IMwfI_c14fEZ1xOUVsgHM=.87bdab09-4936-4fbd-afa0-bc02ead39d5d@github.com>
Message-ID: <aktqkdqWc-eP5oWRes0SBuri_7khQZqNoub2TRjhUVE=.8115613e-e298-4145-aeaf-cca2672b27b0@github.com>

On Mon, 4 Dec 2023 13:56:55 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This update cascades timeouts to trim subsequent workers after the first  keepAlive inactive period.
>
> Doug Lea has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8319662
>  - Remove unnecessary re-interrupt
>  - Merge branch 'openjdk:master' into JDK-8319662
>  - Reduce oversignalling and contention; add test
>  - Revert 2 lines in method scan
>  - Merge branch 'openjdk:master' into JDK-8319662
>  - Split up method awaitWork; other associated changes.
>  - Merge branch 'openjdk:master' into JDK-8319662
>  - tweak cascades; reinstate an @Contended; resolve JDK-8319498
>  - Support cascading idle timeouts

I've done some testing with the latest changes. The changes to trimming workers looks okay to me. When Viktor is done reviewing then I think we should integrate this.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16725#pullrequestreview-1767414023

From vklang at openjdk.org  Wed Dec  6 13:01:39 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 6 Dec 2023 13:01:39 GMT
Subject: RFR: JDK-8319662 ForkJoinPool trims worker threads too slowly [v8]
In-Reply-To: <4Uww87u_Iduao3i7nucJk8IMwfI_c14fEZ1xOUVsgHM=.87bdab09-4936-4fbd-afa0-bc02ead39d5d@github.com>
References: <EfYHyY5R-XjTMrOb7XJbe4Y0m9Zq7zYuI4BlS3T2k2w=.8682eec9-4cae-4004-85dc-923062ac1b5f@github.com>
 <4Uww87u_Iduao3i7nucJk8IMwfI_c14fEZ1xOUVsgHM=.87bdab09-4936-4fbd-afa0-bc02ead39d5d@github.com>
Message-ID: <T9s2nz0UUZauFmFaM0DKx3V_hK3x9hmC9u01Vdp8Pnk=.002127d7-f574-4673-a8ea-ba08071f11e4@github.com>

On Mon, 4 Dec 2023 13:56:55 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This update cascades timeouts to trim subsequent workers after the first  keepAlive inactive period.
>
> Doug Lea has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8319662
>  - Remove unnecessary re-interrupt
>  - Merge branch 'openjdk:master' into JDK-8319662
>  - Reduce oversignalling and contention; add test
>  - Revert 2 lines in method scan
>  - Merge branch 'openjdk:master' into JDK-8319662
>  - Split up method awaitWork; other associated changes.
>  - Merge branch 'openjdk:master' into JDK-8319662
>  - tweak cascades; reinstate an @Contended; resolve JDK-8319498
>  - Support cascading idle timeouts

@DougLea @AlanBateman I've had a look and I think we should integrate.

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

PR Comment: https://git.openjdk.org/jdk/pull/16725#issuecomment-1842832564

From pminborg at openjdk.org  Wed Dec  6 13:57:43 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 6 Dec 2023 13:57:43 GMT
Subject: RFR: 8321387: SegmentAllocator:allocateFrom(AddressLayout,
 MemorySegment) does not throw stated UnsupportedOperationException
Message-ID: <f7av5DIVPpT40yTe3Lsk66GxhTQCLXCoCVe1TJH9hjg=.049eba24-4bf8-4ddc-a1a0-e8db117d72b8@github.com>

This PR proposes to change the exception type for exceptions thrown for certain methods with a parameter of type `MemorySegment` when it is `MemorySegment::isReadOnly`. Previously an `UnsupportedOperationException` was specified but in some cases, in reality, an `IllegalArgumentException` was thrown. 

The principle used in this PR is that operations acting on an MS where the MS is `this` should throw an `UnsupportedOperationException` whereas in cases where the MS is a *parameter* an `IllegalArgumentException` should be thrown.

It should be noted that this PR retains the previous behavior for MS VarHandle access (even though the MS is a parameter to the accessor methods, the first parameter can be said to represent `this`).

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

Commit messages:
 - Retain old behavior for MS VarHandle access
 - Change some throws from UOE to IAE

Changes: https://git.openjdk.org/jdk/pull/16993/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16993&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321387
  Stats: 94 lines in 8 files changed: 39 ins; 4 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/16993.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16993/head:pull/16993

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

From mcimadamore at openjdk.org  Wed Dec  6 14:05:37 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 6 Dec 2023 14:05:37 GMT
Subject: RFR: 8321387: SegmentAllocator:allocateFrom(AddressLayout,
 MemorySegment) does not throw stated UnsupportedOperationException
In-Reply-To: <f7av5DIVPpT40yTe3Lsk66GxhTQCLXCoCVe1TJH9hjg=.049eba24-4bf8-4ddc-a1a0-e8db117d72b8@github.com>
References: <f7av5DIVPpT40yTe3Lsk66GxhTQCLXCoCVe1TJH9hjg=.049eba24-4bf8-4ddc-a1a0-e8db117d72b8@github.com>
Message-ID: <DyLSboVXqhsKcoWJdozIXL1MQ4zzkHSRMRTLBXeBWWI=.98e943dd-79a0-4020-bb38-253bfea3c31d@github.com>

On Wed, 6 Dec 2023 13:52:37 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to change the exception type for exceptions thrown for certain methods with a parameter of type `MemorySegment` when it is `MemorySegment::isReadOnly`. Previously an `UnsupportedOperationException` was specified but in some cases, in reality, an `IllegalArgumentException` was thrown. 
> 
> The principle used in this PR is that operations acting on an MS where the MS is `this` should throw an `UnsupportedOperationException` whereas in cases where the MS is a *parameter* an `IllegalArgumentException` should be thrown.
> 
> It should be noted that this PR retains the previous behavior for MS VarHandle access (even though the MS is a parameter to the accessor methods, the first parameter can be said to represent `this`).

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 363:

> 361: 
> 362:     public enum AccessConstraint {
> 363:         READ_ONLY, ON_WRITE_UOE, ON_WRITE_IAE

I think the names are a bit confusing. Perhaps having NONE instead of READ_ONLY would be better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16993#discussion_r1417378162

From mcimadamore at openjdk.org  Wed Dec  6 14:08:35 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 6 Dec 2023 14:08:35 GMT
Subject: RFR: 8321387: SegmentAllocator:allocateFrom(AddressLayout,
 MemorySegment) does not throw stated UnsupportedOperationException
In-Reply-To: <f7av5DIVPpT40yTe3Lsk66GxhTQCLXCoCVe1TJH9hjg=.049eba24-4bf8-4ddc-a1a0-e8db117d72b8@github.com>
References: <f7av5DIVPpT40yTe3Lsk66GxhTQCLXCoCVe1TJH9hjg=.049eba24-4bf8-4ddc-a1a0-e8db117d72b8@github.com>
Message-ID: <bsJW-GDslUYvVhD6CdP0ReWcEls0eSRB1TKzIJKO9_A=.b0d62b50-fbe8-4775-9717-1c787d2fdfe8@github.com>

On Wed, 6 Dec 2023 13:52:37 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to change the exception type for exceptions thrown for certain methods with a parameter of type `MemorySegment` when it is `MemorySegment::isReadOnly`. Previously an `UnsupportedOperationException` was specified but in some cases, in reality, an `IllegalArgumentException` was thrown. 
> 
> The principle used in this PR is that operations acting on an MS where the MS is `this` should throw an `UnsupportedOperationException` whereas in cases where the MS is a *parameter* an `IllegalArgumentException` should be thrown.
> 
> It should be noted that this PR retains the previous behavior for MS VarHandle access (even though the MS is a parameter to the accessor methods, the first parameter can be said to represent `this`).

src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 153:

> 151:     static void set(VarHandle ob, Object obb, long base, $type$ value) {
> 152:         VarHandleSegmentViewBase handle = (VarHandleSegmentViewBase)ob;
> 153:         AbstractMemorySegmentImpl bb = checkAddress(obb, base, handle.length, ON_WRITE_UOE);

I don't think this should throw UOE. It should throw IAE, because the bad segment is passed to the var handle. I also realize that this exception is not captured in the documentation of MemoryLayout::varHandle. So that should be fixed as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16993#discussion_r1417381854

From mcimadamore at openjdk.org  Wed Dec  6 14:12:36 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 6 Dec 2023 14:12:36 GMT
Subject: RFR: 8321387: SegmentAllocator:allocateFrom(AddressLayout,
 MemorySegment) does not throw stated UnsupportedOperationException
In-Reply-To: <bsJW-GDslUYvVhD6CdP0ReWcEls0eSRB1TKzIJKO9_A=.b0d62b50-fbe8-4775-9717-1c787d2fdfe8@github.com>
References: <f7av5DIVPpT40yTe3Lsk66GxhTQCLXCoCVe1TJH9hjg=.049eba24-4bf8-4ddc-a1a0-e8db117d72b8@github.com>
 <bsJW-GDslUYvVhD6CdP0ReWcEls0eSRB1TKzIJKO9_A=.b0d62b50-fbe8-4775-9717-1c787d2fdfe8@github.com>
Message-ID: <JBjgVqhUMsBuGM079KKMQOoPleVzN26QBclxH1Y83m8=.68a3b1ad-98dd-43b5-84de-06eafd3e0c12@github.com>

On Wed, 6 Dec 2023 14:06:00 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR proposes to change the exception type for exceptions thrown for certain methods with a parameter of type `MemorySegment` when it is `MemorySegment::isReadOnly`. Previously an `UnsupportedOperationException` was specified but in some cases, in reality, an `IllegalArgumentException` was thrown. 
>> 
>> The principle used in this PR is that operations acting on an MS where the MS is `this` should throw an `UnsupportedOperationException` whereas in cases where the MS is a *parameter* an `IllegalArgumentException` should be thrown.
>> 
>> It should be noted that this PR retains the previous behavior for MS VarHandle access (even though the MS is a parameter to the accessor methods, the first parameter can be said to represent `this`).
>
> src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 153:
> 
>> 151:     static void set(VarHandle ob, Object obb, long base, $type$ value) {
>> 152:         VarHandleSegmentViewBase handle = (VarHandleSegmentViewBase)ob;
>> 153:         AbstractMemorySegmentImpl bb = checkAddress(obb, base, handle.length, ON_WRITE_UOE);
> 
> I don't think this should throw UOE. It should throw IAE, because the bad segment is passed to the var handle. I also realize that this exception is not captured in the documentation of MemoryLayout::varHandle. So that should be fixed as well.

This is actually tricky: for var handles it seems like the right exception is IAE - but then for MemorySegment::get the right exception is UOE (because the receiver itself is read-only). We might need to give up consistency a bit, as otherwise I don't think memory segment getter/setter can reuse the VarHandle implementation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16993#discussion_r1417386458

From mcimadamore at openjdk.org  Wed Dec  6 14:38:33 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 6 Dec 2023 14:38:33 GMT
Subject: RFR: 8321387: SegmentAllocator:allocateFrom(AddressLayout,
 MemorySegment) does not throw stated UnsupportedOperationException
In-Reply-To: <JBjgVqhUMsBuGM079KKMQOoPleVzN26QBclxH1Y83m8=.68a3b1ad-98dd-43b5-84de-06eafd3e0c12@github.com>
References: <f7av5DIVPpT40yTe3Lsk66GxhTQCLXCoCVe1TJH9hjg=.049eba24-4bf8-4ddc-a1a0-e8db117d72b8@github.com>
 <bsJW-GDslUYvVhD6CdP0ReWcEls0eSRB1TKzIJKO9_A=.b0d62b50-fbe8-4775-9717-1c787d2fdfe8@github.com>
 <JBjgVqhUMsBuGM079KKMQOoPleVzN26QBclxH1Y83m8=.68a3b1ad-98dd-43b5-84de-06eafd3e0c12@github.com>
Message-ID: <xjKzZ0vi2bRUfZzLVm0AvQx7gZQMzQat_jVuwEmnpA8=.ab38965c-aedd-4c4f-9fd6-6837f13ca5a6@github.com>

On Wed, 6 Dec 2023 14:09:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 153:
>> 
>>> 151:     static void set(VarHandle ob, Object obb, long base, $type$ value) {
>>> 152:         VarHandleSegmentViewBase handle = (VarHandleSegmentViewBase)ob;
>>> 153:         AbstractMemorySegmentImpl bb = checkAddress(obb, base, handle.length, ON_WRITE_UOE);
>> 
>> I don't think this should throw UOE. It should throw IAE, because the bad segment is passed to the var handle. I also realize that this exception is not captured in the documentation of MemoryLayout::varHandle. So that should be fixed as well.
>
> This is actually tricky: for var handles it seems like the right exception is IAE - but then for MemorySegment::get the right exception is UOE (because the receiver itself is read-only). We might need to give up consistency a bit, as otherwise I don't think memory segment getter/setter can reuse the VarHandle implementation.

After offline discussion: the distinction between UOE and IAE is mostly fictional and doesn't add much. In fact, such distinction is harmful because it would mean that code written using var handles cannot cleanly migrate to use memory segment getter/setter (and vice-versa). As such, I recommend that the implementation is left alone, and IAE is thrown by the var handle accessors for read-only segments. Memory segment setters should similarly throw IAE for read-only, because the setters are just thin easy to use wrappers around the var handle.

A similar argument holds for MemorySegment::copyFrom - here throwing UOE would be more apt, but given we explain this method as calling the static MemorySegment::copy (which throws IAE) I would again avoid exception mismatch which would be detrimental to refactoring.

At which point we're left with MemorySegment::fill. While UOE would be better here, it would be the only method in MS issuing UOE for a read-only issue, so I think it would be just best to regularize and use IAE here too.

tl;dr; the implementation is already throwing the correct set of exceptions (which is not perfect, but better than the alternatives). The javadoc should be updated to reflect that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16993#discussion_r1417426024

From jlahoda at openjdk.org  Wed Dec  6 14:51:41 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 6 Dec 2023 14:51:41 GMT
Subject: RFR: 8321248: ClassFile API ClassModel::verify is inconsistent
 with the rest of the API [v2]
In-Reply-To: <GiTWQ6BA8jSxOyLiVMbQJkr4lPdbDML2PbaQv2B6aus=.830242ed-5daf-4d09-85db-562cfee6e109@github.com>
References: <ydm5vaSl_9iTojm2PkI5Z4pu9OkV8L663DFFuKOgINM=.6e7bd095-fc4c-4884-af15-137ef3565e17@github.com>
 <GiTWQ6BA8jSxOyLiVMbQJkr4lPdbDML2PbaQv2B6aus=.830242ed-5daf-4d09-85db-562cfee6e109@github.com>
Message-ID: <ps2A1xR3XSEKSG6FWZfYaygtOfEEifQ4G1w0IQHzlEI=.30280238-43d0-43d5-bae7-ea74b64fca3d@github.com>

On Wed, 6 Dec 2023 10:40:51 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ClassFile API `ClassModel::verify` accepts `ClassHierarchyResolver` as an optional argument and does not respect `ClassFile.ClassHierarchyResolverOption` of the actual context.
>> Parsing, building and transforming take options from the actual `ClassFile` context and verification should follow the same API pattern.
>> 
>> This patch removes `ClassModel::verify` methods and introduces new top level methods:
>> 
>> List<VerifyError> ClassFile::verify(ClassModel model);
>> List<VerifyError> ClassFile::verify(byte[] bytes);
>> List<VerifyError> ClassFile::verify(Path path);
>> 
>> 
>> Impact of the API change is minimal as the API has not been released yet.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted modified test

I guess the tests could be made much more tight. E.g. by not only checking passes/fails verification, but also checking the exact errors reported (for tests that just check that verify "failed", without checking the exact errors, it may happen the verification fails for a wrong reason). And the tests could probably be made much broader.

But I don't think that needs to happen here.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16947#pullrequestreview-1767775716

From mcimadamore at openjdk.org  Wed Dec  6 14:55:38 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 6 Dec 2023 14:55:38 GMT
Subject: RFR: 8321248: ClassFile API ClassModel::verify is inconsistent
 with the rest of the API [v2]
In-Reply-To: <GiTWQ6BA8jSxOyLiVMbQJkr4lPdbDML2PbaQv2B6aus=.830242ed-5daf-4d09-85db-562cfee6e109@github.com>
References: <ydm5vaSl_9iTojm2PkI5Z4pu9OkV8L663DFFuKOgINM=.6e7bd095-fc4c-4884-af15-137ef3565e17@github.com>
 <GiTWQ6BA8jSxOyLiVMbQJkr4lPdbDML2PbaQv2B6aus=.830242ed-5daf-4d09-85db-562cfee6e109@github.com>
Message-ID: <JwWZV6IFgpnn9CsrHDXjzapJg7dWgaUX0m6guUMpoEk=.b836d2e9-e223-4202-acdb-c492ce9f9950@github.com>

On Wed, 6 Dec 2023 10:40:51 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ClassFile API `ClassModel::verify` accepts `ClassHierarchyResolver` as an optional argument and does not respect `ClassFile.ClassHierarchyResolverOption` of the actual context.
>> Parsing, building and transforming take options from the actual `ClassFile` context and verification should follow the same API pattern.
>> 
>> This patch removes `ClassModel::verify` methods and introduces new top level methods:
>> 
>> List<VerifyError> ClassFile::verify(ClassModel model);
>> List<VerifyError> ClassFile::verify(byte[] bytes);
>> List<VerifyError> ClassFile::verify(Path path);
>> 
>> 
>> Impact of the API change is minimal as the API has not been released yet.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted modified test

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16947#pullrequestreview-1767786746

From rriggs at openjdk.org  Wed Dec  6 14:58:35 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 6 Dec 2023 14:58:35 GMT
Subject: RFR: JDK-8320570 NegativeArraySizeException decoding >1G UTF8
 bytes with non-ascii characters [v3]
In-Reply-To: <VPQVYI_8jeogmxQqB1xkmrH82TDTqq_1lmoodVUK-bY=.0d8a9796-6a08-48d9-91c5-d53c31e05a1d@github.com>
References: <wK-u3PPhgDfuUAGIWQNgYs_gxKrDVjsNs8ImLonZObU=.49b3b03b-6deb-418a-9ab0-9c9fc563b33a@github.com>
 <VPQVYI_8jeogmxQqB1xkmrH82TDTqq_1lmoodVUK-bY=.0d8a9796-6a08-48d9-91c5-d53c31e05a1d@github.com>
Message-ID: <i1aEwHt4gPc9XHqmw4FTFNLkJrgI8LnLAusELCTln4E=.110da00b-83dd-446c-a820-405af2c0397d@github.com>

On Wed, 6 Dec 2023 11:47:13 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> A regression is found in Java9+ creating String instance from UTF8 bytes, a side effect of string compactation https://openjdk.org/jeps/254 that changed the decoding logic. Specifically, when constructing a string from bytes: 
>> 
>> ``` 
>> String str = new String(largeBytes, StandardCharsets.UTF_8); 
>> ``` 
>> 
>> if the size of largeBytes is greater than 2^30 (>1 GB) but smaller than INT_MAX (2 GB), it fails on Java9+ (including 11, 17, 21, though the stack trace is slightly different, see below), regardless of jvm heap size. In Java8, it succeeded when jvm heap size is set to be sufficient.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Requested changes

Looks good, thanks for the updates.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16974#pullrequestreview-1767792457

From duke at openjdk.org  Wed Dec  6 15:10:45 2023
From: duke at openjdk.org (fabioromano1)
Date: Wed, 6 Dec 2023 15:10:45 GMT
Subject: RFR: 8320759: Creation of random BigIntegers can be made faster
 [v3]
In-Reply-To: <xeIs7PX3HXqTdu2tRHwcZ8MUMqwQ2-npMve0hR1Kpm8=.3b639c80-f5fd-4445-a682-b1a656c8a278@github.com>
References: <wIuR7gaQWIRdb8DtEN1VXi9dNkUMuKn8zv3Myc4V2gc=.3356e893-5322-4bb4-aa37-731fb6e9a4b0@github.com>
 <KAD32In5r6VDU4e0LePqKTHv8bn7fc9xb9zAI1UBkHY=.acba81de-6332-4cf9-9a66-d6e0f488b61b@github.com>
 <xeIs7PX3HXqTdu2tRHwcZ8MUMqwQ2-npMve0hR1Kpm8=.3b639c80-f5fd-4445-a682-b1a656c8a278@github.com>
Message-ID: <X0JLWafyuyum8VPF25kVst69Dog-K7frF1aVyqkRVYo=.1b7a2858-c24a-4a6a-af2c-7aa387fbf76c@github.com>

On Tue, 5 Dec 2023 22:01:04 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Create RandomBigIntegers.java
>>   
>>   Create a benchmark to measure the performance of BigInteger(int, Random) constructor implementation.
>
> So, item 1 is a non-issue and item 2 is not likely a problem in practice. What, if anything, will be done about item 3?

@bplb Maybe an assertion at the end of `randomBits(int, Random)` method, or a test class.

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

PR Comment: https://git.openjdk.org/jdk/pull/16817#issuecomment-1843077150

From pminborg at openjdk.org  Wed Dec  6 15:21:47 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 6 Dec 2023 15:21:47 GMT
Subject: RFR: 8321387: SegmentAllocator:allocateFrom(AddressLayout,
 MemorySegment) does not throw stated UnsupportedOperationException [v2]
In-Reply-To: <f7av5DIVPpT40yTe3Lsk66GxhTQCLXCoCVe1TJH9hjg=.049eba24-4bf8-4ddc-a1a0-e8db117d72b8@github.com>
References: <f7av5DIVPpT40yTe3Lsk66GxhTQCLXCoCVe1TJH9hjg=.049eba24-4bf8-4ddc-a1a0-e8db117d72b8@github.com>
Message-ID: <SSX8dQXxv8-AAQZUSR6eeSKcxlMn5EAYywWABqiC5RA=.b6cf6364-497c-43c6-bed4-b6d4630a0233@github.com>

> This PR proposes to change the exception type for exceptions thrown for certain methods with a parameter of type `MemorySegment` when it is `MemorySegment::isReadOnly`. Previously an `UnsupportedOperationException` was specified but in some cases, in reality, an `IllegalArgumentException` was thrown. 
> 
> The principle used in this PR is that operations acting on an MS where the MS is `this` should throw an `UnsupportedOperationException` whereas in cases where the MS is a *parameter* an `IllegalArgumentException` should be thrown.
> 
> It should be noted that this PR retains the previous behavior for MS VarHandle access (even though the MS is a parameter to the accessor methods, the first parameter can be said to represent `this`).

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

  Update after comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16993/files
  - new: https://git.openjdk.org/jdk/pull/16993/files/ac7859ab..8ba6278c

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

  Stats: 75 lines in 6 files changed: 17 ins; 0 del; 58 mod
  Patch: https://git.openjdk.org/jdk/pull/16993.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16993/head:pull/16993

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

From rriggs at openjdk.org  Wed Dec  6 15:31:37 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 6 Dec 2023 15:31:37 GMT
Subject: RFR: 8321206: Make Locale related system properties static
 properties
In-Reply-To: <EKzdSEIjrFq0mXKLGOdRCePeu29DWWQnpAY5FDVAK40=.3bcd4037-e3e5-4cf1-948d-665355914106@github.com>
References: <EKzdSEIjrFq0mXKLGOdRCePeu29DWWQnpAY5FDVAK40=.3bcd4037-e3e5-4cf1-948d-665355914106@github.com>
Message-ID: <Q0s3jRna4fd61HAQ2vdOd935m3pKE849yQ1cgnkcE2c=.b0cf13d4-70f6-46c0-b71b-3f63e449ced5@github.com>

On Tue, 5 Dec 2023 23:04:55 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Currently, Locale-related system properties, such as `user.language` or `user.country`, are initialized when the `Locale` class is loaded. Making them static properties is safer than relying on the class initialization timing, which could potentially be changed depending on the implementation.

src/java.base/share/classes/java/util/Locale.java line 1061:

> 1059:         if (sm != null) {
> 1060:             sm.checkPropertiesAccess();
> 1061:         }

This SM check is no longer needed; the use of privilegedGetProperties made access unconditional.
The static properties are always accessible to the locale implementation.

src/java.base/share/classes/jdk/internal/util/StaticProperty.java line 113:

> 111:         USER_EXTENSIONS_DISPLAY = getProperty(props, "user.extensions.display", USER_EXTENSIONS);
> 112:         USER_EXTENSIONS_FORMAT = getProperty(props, "user.extensions.format", USER_EXTENSIONS);
> 113:         USER_REGION = getProperty(props, "user.region", "");

Computing the defaults for these properties should be in the Locale class, close to the initialization of the default locale. Splitting the responsibility across files makes it harder to follow what happens where/when.

src/java.base/share/classes/jdk/internal/util/StaticProperty.java line 415:

> 413:     public static String userRegion() {
> 414:         return USER_REGION;
> 415:     }

Using methods to retrieve these makes is more complicated.
The bleeding of the enum values outside of Locale is undesirable.
Since the property values are final strings, I suggest just making the fields public and keep the mapping local to the Locale class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16986#discussion_r1417495473
PR Review Comment: https://git.openjdk.org/jdk/pull/16986#discussion_r1417510556
PR Review Comment: https://git.openjdk.org/jdk/pull/16986#discussion_r1417485546

From pminborg at openjdk.org  Wed Dec  6 15:32:54 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 6 Dec 2023 15:32:54 GMT
Subject: RFR: 8321387: SegmentAllocator:allocateFrom(AddressLayout,
 MemorySegment) does not throw stated UnsupportedOperationException [v3]
In-Reply-To: <f7av5DIVPpT40yTe3Lsk66GxhTQCLXCoCVe1TJH9hjg=.049eba24-4bf8-4ddc-a1a0-e8db117d72b8@github.com>
References: <f7av5DIVPpT40yTe3Lsk66GxhTQCLXCoCVe1TJH9hjg=.049eba24-4bf8-4ddc-a1a0-e8db117d72b8@github.com>
Message-ID: <nVkeGoT3PfcoFWSwePvbl2t5-S5IEAj_JTobwWzetT0=.e9ea2b56-938d-4cb4-9266-e6300a22f76a@github.com>

> This PR proposes to change the exception type for exceptions thrown for certain methods with a parameter of type `MemorySegment` when it is `MemorySegment::isReadOnly`. Previously an `UnsupportedOperationException` was specified but in some cases, in reality, an `IllegalArgumentException` was thrown. 
> 
> The principle used in this PR is that operations acting on an MS where the MS is `this` should throw an `UnsupportedOperationException` whereas in cases where the MS is a *parameter* an `IllegalArgumentException` should be thrown.
> 
> It should be noted that this PR retains the previous behavior for MS VarHandle access (even though the MS is a parameter to the accessor methods, the first parameter can be said to represent `this`).

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

  Update throws docs fror SegmentAllocator

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16993/files
  - new: https://git.openjdk.org/jdk/pull/16993/files/8ba6278c..d7b08a40

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

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

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

From asotona at openjdk.org  Wed Dec  6 15:34:46 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Dec 2023 15:34:46 GMT
Subject: RFR: 8321248: ClassFile API ClassModel::verify is inconsistent
 with the rest of the API [v2]
In-Reply-To: <GiTWQ6BA8jSxOyLiVMbQJkr4lPdbDML2PbaQv2B6aus=.830242ed-5daf-4d09-85db-562cfee6e109@github.com>
References: <ydm5vaSl_9iTojm2PkI5Z4pu9OkV8L663DFFuKOgINM=.6e7bd095-fc4c-4884-af15-137ef3565e17@github.com>
 <GiTWQ6BA8jSxOyLiVMbQJkr4lPdbDML2PbaQv2B6aus=.830242ed-5daf-4d09-85db-562cfee6e109@github.com>
Message-ID: <iTeId2RAroI-8lgQimKhZluQXhzhtRN0Yv9unkkUWSY=.ff97dd23-3080-456e-8b70-8484c488fa4f@github.com>

On Wed, 6 Dec 2023 10:40:51 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ClassFile API `ClassModel::verify` accepts `ClassHierarchyResolver` as an optional argument and does not respect `ClassFile.ClassHierarchyResolverOption` of the actual context.
>> Parsing, building and transforming take options from the actual `ClassFile` context and verification should follow the same API pattern.
>> 
>> This patch removes `ClassModel::verify` methods and introduces new top level methods:
>> 
>> List<VerifyError> ClassFile::verify(ClassModel model);
>> List<VerifyError> ClassFile::verify(byte[] bytes);
>> List<VerifyError> ClassFile::verify(Path path);
>> 
>> 
>> Impact of the API change is minimal as the API has not been released yet.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted modified test

Thank you for the reviews.

Yes, next step is to improve verifier range and also cover it with negative tests (see https://github.com/openjdk/jdk/pull/16809/files#diff-a23859572e86e946a9ce66361e64e4b7e4473f134bb49a248fccd70d2ac96ea2)

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

PR Comment: https://git.openjdk.org/jdk/pull/16947#issuecomment-1843120837

From asotona at openjdk.org  Wed Dec  6 15:34:48 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Dec 2023 15:34:48 GMT
Subject: Integrated: 8321248: ClassFile API ClassModel::verify is inconsistent
 with the rest of the API
In-Reply-To: <ydm5vaSl_9iTojm2PkI5Z4pu9OkV8L663DFFuKOgINM=.6e7bd095-fc4c-4884-af15-137ef3565e17@github.com>
References: <ydm5vaSl_9iTojm2PkI5Z4pu9OkV8L663DFFuKOgINM=.6e7bd095-fc4c-4884-af15-137ef3565e17@github.com>
Message-ID: <9Sx8G-RVNRjecpYkIvTBIt4_Y7knwYVeOJeMUyJ9tyA=.bc0716de-0e84-4267-bacf-02eb6b597a14@github.com>

On Mon, 4 Dec 2023 11:12:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> ClassFile API `ClassModel::verify` accepts `ClassHierarchyResolver` as an optional argument and does not respect `ClassFile.ClassHierarchyResolverOption` of the actual context.
> Parsing, building and transforming take options from the actual `ClassFile` context and verification should follow the same API pattern.
> 
> This patch removes `ClassModel::verify` methods and introduces new top level methods:
> 
> List<VerifyError> ClassFile::verify(ClassModel model);
> List<VerifyError> ClassFile::verify(byte[] bytes);
> List<VerifyError> ClassFile::verify(Path path);
> 
> 
> Impact of the API change is minimal as the API has not been released yet.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 0217b5ac
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0217b5ac8b25db96fce026ac027b18024e25a329
Stats:     94 lines in 11 files changed: 44 ins; 32 del; 18 mod

8321248: ClassFile API ClassModel::verify is inconsistent with the rest of the API

Reviewed-by: jlahoda, mcimadamore

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

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

From mcimadamore at openjdk.org  Wed Dec  6 15:41:39 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 6 Dec 2023 15:41:39 GMT
Subject: RFR: 8321387: SegmentAllocator:allocateFrom(AddressLayout,
 MemorySegment) does not throw stated UnsupportedOperationException [v3]
In-Reply-To: <nVkeGoT3PfcoFWSwePvbl2t5-S5IEAj_JTobwWzetT0=.e9ea2b56-938d-4cb4-9266-e6300a22f76a@github.com>
References: <f7av5DIVPpT40yTe3Lsk66GxhTQCLXCoCVe1TJH9hjg=.049eba24-4bf8-4ddc-a1a0-e8db117d72b8@github.com>
 <nVkeGoT3PfcoFWSwePvbl2t5-S5IEAj_JTobwWzetT0=.e9ea2b56-938d-4cb4-9266-e6300a22f76a@github.com>
Message-ID: <wvBDzSgkI77yU9puqhZisitja6i30oYPm4scotWgY4g=.2f6985fc-0624-4496-9239-d6f2aecd0af7@github.com>

On Wed, 6 Dec 2023 15:32:54 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to change the exception type for exceptions thrown for certain methods with a parameter of type `MemorySegment` when it is `MemorySegment::isReadOnly`. Previously an `UnsupportedOperationException` was specified but in some cases, in reality, an `IllegalArgumentException` was thrown. 
>> 
>> The principle used in this PR is that operations acting on an MS where the MS is `this` should throw an `UnsupportedOperationException` whereas in cases where the MS is a *parameter* an `IllegalArgumentException` should be thrown.
>> 
>> It should be noted that this PR retains the previous behavior for MS VarHandle access (even though the MS is a parameter to the accessor methods, the first parameter can be said to represent `this`).
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update throws docs fror SegmentAllocator

src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 95:

> 93:      * @param str the Java string to be converted into a C string
> 94:      * @return a new native segment containing the converted C string
> 95:      * @throws IllegalArgumentException if the allocated segment is

I don't think the changes here are useful. What does it mean for an allocated segment to be read-only? I think all these conditions are tied to `prefixAllocator` blindly accepting read-only segments, which should NOT be the case. I suggest to revert all the chnages here and document (and throw) a new exception for when a prefix allocator is created from a read-only segment.

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 367:

> 365: 
> 366:     @ForceInline
> 367:     public void checkAccess(long offset, long length, AccessConstraint access) {

These changes should be reverted, I don't think we use the UOE mode anymore. Just revert the impl to what it was before (also true for VarHandle templates).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16993#discussion_r1417525637
PR Review Comment: https://git.openjdk.org/jdk/pull/16993#discussion_r1417528416

From mcimadamore at openjdk.org  Wed Dec  6 15:44:40 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 6 Dec 2023 15:44:40 GMT
Subject: RFR: 8321387: SegmentAllocator:allocateFrom(AddressLayout,
 MemorySegment) does not throw stated UnsupportedOperationException [v3]
In-Reply-To: <nVkeGoT3PfcoFWSwePvbl2t5-S5IEAj_JTobwWzetT0=.e9ea2b56-938d-4cb4-9266-e6300a22f76a@github.com>
References: <f7av5DIVPpT40yTe3Lsk66GxhTQCLXCoCVe1TJH9hjg=.049eba24-4bf8-4ddc-a1a0-e8db117d72b8@github.com>
 <nVkeGoT3PfcoFWSwePvbl2t5-S5IEAj_JTobwWzetT0=.e9ea2b56-938d-4cb4-9266-e6300a22f76a@github.com>
Message-ID: <P8fcF4dAeTVw_cMuY0RotcTB0VSAO7bRBbaQNsLsumg=.e308e083-71ce-4bae-9da1-969d62fc899f@github.com>

On Wed, 6 Dec 2023 15:32:54 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to change the exception type for exceptions thrown for certain methods with a parameter of type `MemorySegment` when it is `MemorySegment::isReadOnly`. Previously an `UnsupportedOperationException` was specified but in some cases, in reality, an `IllegalArgumentException` was thrown. 
>> 
>> The principle used in this PR is that operations acting on an MS where the MS is `this` should throw an `UnsupportedOperationException` whereas in cases where the MS is a *parameter* an `IllegalArgumentException` should be thrown.
>> 
>> It should be noted that this PR retains the previous behavior for MS VarHandle access (even though the MS is a parameter to the accessor methods, the first parameter can be said to represent `this`).
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update throws docs fror SegmentAllocator

There are still more changes than required, I think

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

PR Review: https://git.openjdk.org/jdk/pull/16993#pullrequestreview-1767913213

From dl at openjdk.org  Wed Dec  6 16:15:46 2023
From: dl at openjdk.org (Doug Lea)
Date: Wed, 6 Dec 2023 16:15:46 GMT
Subject: Integrated: JDK-8319662 ForkJoinPool trims worker threads too slowly
In-Reply-To: <EfYHyY5R-XjTMrOb7XJbe4Y0m9Zq7zYuI4BlS3T2k2w=.8682eec9-4cae-4004-85dc-923062ac1b5f@github.com>
References: <EfYHyY5R-XjTMrOb7XJbe4Y0m9Zq7zYuI4BlS3T2k2w=.8682eec9-4cae-4004-85dc-923062ac1b5f@github.com>
Message-ID: <n6JdcI0YgDoXVz00Bt56RCav0d-UnfmSJ1qzSn6f8y0=.f5a08a3d-bf1c-42c3-bf29-ec2a657d9b09@github.com>

On Sun, 19 Nov 2023 17:36:01 GMT, Doug Lea <dl at openjdk.org> wrote:

> This update cascades timeouts to trim subsequent workers after the first  keepAlive inactive period.

This pull request has now been integrated.

Changeset: cc25d8b1
Author:    Doug Lea <dl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cc25d8b12bbab9dde9ade7762927dcb8d27e23c5
Stats:     251 lines in 2 files changed: 79 ins; 45 del; 127 mod

8319662: ForkJoinPool trims worker threads too slowly
8319498: ForkJoinPool.invoke(ForkJoinTask) does not specify behavior when task throws checked exception

Reviewed-by: alanb

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

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

From hannesw at openjdk.org  Wed Dec  6 16:29:46 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 6 Dec 2023 16:29:46 GMT
Subject: RFR: JDK-8320538: Obsolete CSS styles in collection framework doc-file
Message-ID: <dm5VZgu4Xwl_uod_KHR4-Ld9VJs5a8VVMIlV0FuN5dA=.914e6b24-4367-44bc-806f-b43c1c682224@github.com>

Please review a simple change to remove a stray inline CSS element from the Collection Framework index doc file. The only thing the `a {font-weight: bold;}` rule did was to make all links in the header and footer bold as [can be seen here][1]; the three content links to the other doc files are still displayed in bold font because they are contained in `<b>` tags. The other CSS rules had no effect in the page. 

[1]: https://download.java.net/java/early_access/jdk22/docs/api/java.base/java/util/doc-files/coll-index.html

I also added the `<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">` meta tag which is present in all other pages (both doc-files and generated by JavaDoc).

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

Commit messages:
 - JDK-8320538: Obsolete CSS styles in collection framework doc-file

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

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

From bpb at openjdk.org  Wed Dec  6 16:44:40 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 6 Dec 2023 16:44:40 GMT
Subject: RFR: 8320759: Creation of random BigIntegers can be made faster
 [v3]
In-Reply-To: <xeIs7PX3HXqTdu2tRHwcZ8MUMqwQ2-npMve0hR1Kpm8=.3b639c80-f5fd-4445-a682-b1a656c8a278@github.com>
References: <wIuR7gaQWIRdb8DtEN1VXi9dNkUMuKn8zv3Myc4V2gc=.3356e893-5322-4bb4-aa37-731fb6e9a4b0@github.com>
 <KAD32In5r6VDU4e0LePqKTHv8bn7fc9xb9zAI1UBkHY=.acba81de-6332-4cf9-9a66-d6e0f488b61b@github.com>
 <xeIs7PX3HXqTdu2tRHwcZ8MUMqwQ2-npMve0hR1Kpm8=.3b639c80-f5fd-4445-a682-b1a656c8a278@github.com>
Message-ID: <xGMewjBAIuxGNCwsiH3LD94KT0YKE-zSlrGsyp3Layk=.e51b194b-8ec2-444c-b664-42300b762ad8@github.com>

On Tue, 5 Dec 2023 22:01:04 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Create RandomBigIntegers.java
>>   
>>   Create a benchmark to measure the performance of BigInteger(int, Random) constructor implementation.
>
> So, item 1 is a non-issue and item 2 is not likely a problem in practice. What, if anything, will be done about item 3?

> @bplb Maybe an assertion at the end of `randomBits(int, Random)` method, or a test class.

@fabioromano1 A test class would be better as then we would be able to catch any problems during routine testing. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/16817#issuecomment-1843266956

From mcimadamore at openjdk.org  Wed Dec  6 16:56:44 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 6 Dec 2023 16:56:44 GMT
Subject: RFR: 8321467: MemorySegment.setString(long, String,
 Charset) throws IAE(Misaligned access)
Message-ID: <BQJBLeTlmzWI3QiroA-zIql4DXSQFJVrFHxn4Nd0F-Q=.d72cf232-0efe-4284-8857-863cb991526b@github.com>

This PR fixes a couple of aligned accesses when reading/writing strings. Such aligned accesses crept in when we optimized string read/write operations to work in bulk. As a result, depending on the maximum alignment constraints supported by the heap segment, some string operations might fail.

I've added some tests to make sure that all operations work as expected with unaligned semantics.

Note: I've considered inferring an alignment constraint from the provided charset, and then use aligned operations (and document that behavior), but I found that to be unsatisfactory: memory operations typically accept a layout, which allow clients to opt out from alignment checks if needed. But if we always infer an alignment constraint from the provided charset, clients would find themselves w/o an escape hatch. For this reason, I think the best way to fix this is to use unaligned operations when reading/writing the string.

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

Commit messages:
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/16999/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16999&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321467
  Stats: 79 lines in 2 files changed: 69 ins; 6 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/16999.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16999/head:pull/16999

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

From mcimadamore at openjdk.org  Wed Dec  6 17:03:08 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 6 Dec 2023 17:03:08 GMT
Subject: RFR: 8321467: MemorySegment.setString(long, String,
 Charset) throws IAE(Misaligned access) [v2]
In-Reply-To: <BQJBLeTlmzWI3QiroA-zIql4DXSQFJVrFHxn4Nd0F-Q=.d72cf232-0efe-4284-8857-863cb991526b@github.com>
References: <BQJBLeTlmzWI3QiroA-zIql4DXSQFJVrFHxn4Nd0F-Q=.d72cf232-0efe-4284-8857-863cb991526b@github.com>
Message-ID: <jlIx8-O5dDz0dWmUF1p_DtGIfEiUEb-ud-FCMN8Qcjw=.27460ae1-e281-48ab-9192-08bc93781eea@github.com>

> This PR fixes a couple of aligned accesses when reading/writing strings. Such aligned accesses crept in when we optimized string read/write operations to work in bulk. As a result, depending on the maximum alignment constraints supported by the heap segment, some string operations might fail.
> 
> I've added some tests to make sure that all operations work as expected with unaligned semantics.
> 
> Note: I've considered inferring an alignment constraint from the provided charset, and then use aligned operations (and document that behavior), but I found that to be unsatisfactory: memory operations typically accept a layout, which allow clients to opt out from alignment checks if needed. But if we always infer an alignment constraint from the provided charset, clients would find themselves w/o an escape hatch. For this reason, I think the best way to fix this is to use unaligned operations when reading/writing the string.

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

 - Make test more robust
 - Simplify test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16999/files
  - new: https://git.openjdk.org/jdk/pull/16999/files/856d3e14..12cf9e3a

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

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

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

From duke at openjdk.org  Wed Dec  6 17:16:50 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 6 Dec 2023 17:16:50 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v8]
In-Reply-To: <gvK1FxA_Bm_0ZVahS1S7Gr9GMXVmDYeRejiv3T51jVE=.9506e127-d11c-4c56-a6de-bef6d61d3cc3@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <7ocsRxaWjoU2vxwPUSE7BrnLSL1bF_7Pp8vReacNJvE=.1c044b21-b27e-4e94-8db0-6ae888a1e8b9@github.com>
 <gvK1FxA_Bm_0ZVahS1S7Gr9GMXVmDYeRejiv3T51jVE=.9506e127-d11c-4c56-a6de-bef6d61d3cc3@github.com>
Message-ID: <U3bL-hzUArX9ZmXqR4LSenxEn2Q0ysD5aIoEaQejpKI=.ef6a5de4-52d6-461e-8be1-e6a67ab9b3ec@github.com>

On Tue, 5 Dec 2023 19:33:48 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Srinivas Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
>> 
>>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>>  - add GCC version guards
>>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>>  - Remove C++17 from C flags
>>  - add avoid masked stores operation
>>  - update the code to check for supported simd sort cpus
>>  - Disable AVX2 sort for 64-bit types
>>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>>  - fix jcheck failures due to windows encoding
>>  - fix carriage return and change insertion sort thresholds
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/d8b29378...bc590d9f
>
> src/java.base/linux/native/libsimdsort/avx512-32bit-qsort.hpp line 235:
> 
>> 233:         return avx512_double_compressstore<zmm_vector<type_t>>(
>> 234:             left_addr, right_addr, k, reg);
>> 235:     }
> 
> Can be removed.

This is needed for AVX512 sort...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1417690992

From duke at openjdk.org  Wed Dec  6 17:23:03 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 6 Dec 2023 17:23:03 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v9]
In-Reply-To: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
Message-ID: <IDxV7jNTnTc7pjv5xNTbk5LRT0D-mgcbdnkTq9TDQ7E=.6de40c65-26a0-4953-8ab3-b19bcb45e6f8@github.com>

> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX2 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
> 
> For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
> 
> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
> 
> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
> <link rel=File-List
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
> 
> 
> </head>
> 
> <body link="#0563C1" vlink="#954F72">
> 
> 
> 
> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
> -- | -- | -- | -- | --
> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
> 
> </body>
> 
> </html>
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/...

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  remove unused avx2 64 bit sort functions; add assertions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16534/files
  - new: https://git.openjdk.org/jdk/pull/16534/files/bc590d9f..c143e0b9

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

  Stats: 128 lines in 4 files changed: 12 ins; 116 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16534.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16534/head:pull/16534

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

From duke at openjdk.org  Wed Dec  6 17:23:04 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 6 Dec 2023 17:23:04 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v9]
In-Reply-To: <7_T6sM3wjbSzZ0ab9FsptbpPnlQ2J4NNctQNkdbDFdI=.b595a8cc-4b14-44c6-8319-00e68fea21c3@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <e5w5YZ0WD8S3UVFBYz6I0PdKZ6yOkD77BCq2arDd6i4=.7eecadcb-e627-4e9b-8f1e-3fc41c63243b@github.com>
 <bopxvLCquUtZQxt8kAJskzXBR2YE_I0PW13i3NBJNNY=.e65abf3d-0ff4-4450-875b-ca3717170485@github.com>
 <DeQgR1PaXlk2yzlxV15N3ViZY26wXtlgfVKxRY6vuWo=.6d38f729-0ca9-4f43-9e23-f5e73a01cc23@github.com>
 <b1Nv5Y7Klpvp5ACcHJTTblwGmnA64cyRg-3YzotaHvc=.0bd8a0f0-0844-44a9-a3bb-4af2e8514ee1@github.com>
 <t_23EA--aX8v2US9Lsib1ZF3bl4HQx_Z4RXqlgQo8LE=.6f1f2873-015c-4b69-ad47-b449e5b77a45@github.com>
 <pRcJlU1a4jG9gMaftLn5IerudMSDIrvr70KBefkpNSo=.f442f0d4-887f-4376-a66e-8254fa35927c@github.com>
 <OJ1ZK4a8c_bZik60v503VUtZoweFFv6VhhGg1sp4qSY=.e8852bf1-2d7f-4164-b952-d88b294ec1f7@github.com>
 <_gSNXk0qGAtpY-WJ5OCHk_3-nuGrwwSn-ffK9f2TEcs=.40f785ba-83dd-40fe-8075-a7a7872ea600@github.com>
 <v95kXnbADF5XriLfeg2v5yVYBo-BUzR-dhpcubuMDcI=.03d8e5a7-8b0c-4291-99df-2d3ec6cd356c@github.com>
 <D2AGAYSictxU124OSQMg3V5bpM1oKBdxKLd
 BS0X7ow8=.326a6f38-e9ab-4b24-a6d6-d8eebdb346f7@github.com>
 <wpFxnb5dr5v2UHZYPPdi4XsBUiLtFXGxRySgr6xCmJM=.74175d6e-0f30-464e-9c76-cc4e8bd6f36a@github.com>
 <7_T6sM3wjbSzZ0ab9FsptbpPnlQ2J4NNctQNkdbDFdI=.b595a8cc-4b14-44c6-8319-00e68fea21c3@github.com>
Message-ID: <M2KPFFgTiBmYcdxO7_wNRYYokECxNAHmgsvbt-s8_k0=.6320d2de-2710-4ca7-a6b4-d1954167ca01@github.com>

On Wed, 6 Dec 2023 11:59:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Hi Magnus (@magicus),
>>  
>>> Are you saying that when compiling with GCC 6, it will just silently ignore `-std=c++17`? I'd have assumed that it printed a warning or error about an unknown or invalid option, if C++17 is not supported.
>> 
>> The GCC complier for versions 6 (and even 5) silently ignores the flag `-std=c++17`. It does not print any warning or error. I tested it with a toy C++ program and also by building OpenJDK using GCC 6. 
>> 
>>> You can't check for if compiler options should be enabled or not inside source code files.
>> 
>>  what I meant was, there are #ifdef guards using predefined macros in the C++ source code to check for GCC version and make the simdsort code available for compilation or not based on the GCC version
>> 
>> 
>> // src/java.base/linux/native/libsimdsort/simdsort-support.hpp
>> #if defined(_LP64) && (defined(__GNUC__) && ((__GNUC__ > 7) || ((__GNUC__ == 7) && (__GNUC_MINOR__ >= 5))))
>>         #define __SIMDSORT_SUPPORTED_LINUX
>> #endif
>> 
>> 
>> 
>> //src/java.base/linux/native/libsimdsort/avx2-linux-qsort.cpp
>> #include "simdsort-support.hpp"
>> #ifdef __SIMDSORT_SUPPORTED_LINUX
>>             <simdsort functions>
>> #endif
>
> Okay, then I guess I am fine with this.

Thank you Magnus!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1417707661

From duke at openjdk.org  Wed Dec  6 17:23:13 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 6 Dec 2023 17:23:13 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v8]
In-Reply-To: <gvK1FxA_Bm_0ZVahS1S7Gr9GMXVmDYeRejiv3T51jVE=.9506e127-d11c-4c56-a6de-bef6d61d3cc3@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <7ocsRxaWjoU2vxwPUSE7BrnLSL1bF_7Pp8vReacNJvE=.1c044b21-b27e-4e94-8db0-6ae888a1e8b9@github.com>
 <gvK1FxA_Bm_0ZVahS1S7Gr9GMXVmDYeRejiv3T51jVE=.9506e127-d11c-4c56-a6de-bef6d61d3cc3@github.com>
Message-ID: <zipNAArwW5naESKzcUCV2POoD2KH8Lg3V5-Y-98g5-s=.3f22dfca-a421-4cab-b836-d8e36b51af62@github.com>

On Tue, 5 Dec 2023 19:37:34 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Srinivas Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
>> 
>>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>>  - add GCC version guards
>>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>>  - Remove C++17 from C flags
>>  - add avoid masked stores operation
>>  - update the code to check for supported simd sort cpus
>>  - Disable AVX2 sort for 64-bit types
>>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>>  - fix jcheck failures due to windows encoding
>>  - fix carriage return and change insertion sort thresholds
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/d4151e5b...bc590d9f
>
> src/java.base/linux/native/libsimdsort/avx2-emu-funcs.hpp line 64:
> 
>> 62:     }
>> 63:     return lut;
>> 64: }();
> 
> Lut64 is needed for compress64 emulation, can be removed.

Removed in the latest commit...

> src/java.base/linux/native/libsimdsort/avx2-emu-funcs.hpp line 234:
> 
>> 232: 
>> 233:     vtype::mask_storeu(leftStore, left, temp);
>> 234: }
> 
> Can be removed if not being used.

Removed in the latest commit...

> src/java.base/linux/native/libsimdsort/avx2-emu-funcs.hpp line 277:
> 
>> 275: 
>> 276:     return _mm_popcnt_u32(shortMask);
>> 277: }
> 
> Can be removed if not being used.

Removed in the latest commit...

> src/java.base/linux/native/libsimdsort/avx2-linux-qsort.cpp line 44:
> 
>> 42:                 break;
>> 43:             case JVM_T_FLOAT:
>> 44:                 avx2_fast_sort((float*)array, from_index, to_index, INSERTION_SORT_THRESHOLD_32BIT);
> 
> Assertions for unsupported types.

Added in the latest commit...

> src/java.base/linux/native/libsimdsort/avx2-linux-qsort.cpp line 56:
> 
>> 54:             case JVM_T_FLOAT:
>> 55:                 avx2_fast_partition((float*)array, from_index, to_index, pivot_indices, index_pivot1, index_pivot2);
>> 56:                 break;
> 
> Please add assertion for unsupported types.

Added in the latest commit...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1417701182
PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1417702999
PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1417702251
PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1417701469
PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1417701705

From duke at openjdk.org  Wed Dec  6 17:23:14 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 6 Dec 2023 17:23:14 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v9]
In-Reply-To: <bfQ06T6iTnowcGtYhxroMpFD7c9SIconr-AaWliY7Us=.c85c0dbb-0c57-4565-81ac-bf9ad4cbeb5e@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <7ocsRxaWjoU2vxwPUSE7BrnLSL1bF_7Pp8vReacNJvE=.1c044b21-b27e-4e94-8db0-6ae888a1e8b9@github.com>
 <bfQ06T6iTnowcGtYhxroMpFD7c9SIconr-AaWliY7Us=.c85c0dbb-0c57-4565-81ac-bf9ad4cbeb5e@github.com>
Message-ID: <Fo2CJITUDIymCcSYskZgCSwztX4oZ-SU5QioTuNYEX4=.a4fd82a3-3a4e-4560-8b23-f49752cbb437@github.com>

On Tue, 5 Dec 2023 19:19:23 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove unused avx2 64 bit sort functions; add assertions
>
> src/java.base/linux/native/libsimdsort/avx2-linux-qsort.cpp line 50:
> 
>> 48:             case JVM_T_DOUBLE:
>> 49:                 avx2_fast_sort((double*)array, from_index, to_index, INSERTION_SORT_THRESHOLD_64BIT);
>> 50:                 break;
> 
> Please add safe assertions for missing types.

This is from an older (but outdated) commit. The assertions have been added in other cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1417706670

From duke at openjdk.org  Wed Dec  6 17:23:41 2023
From: duke at openjdk.org (Brett Okken)
Date: Wed, 6 Dec 2023 17:23:41 GMT
Subject: RFR: 8321470: ThreadLocal.nextHashCode can be static final
Message-ID: <7g_sH5nIxOFlqEARD90RX5X6I_flcAt0VHUtzU0Fqyo=.1dd55021-9720-40a7-ad0b-d18e07963b50@github.com>

The static AtomicInteger used for the nextHashCode should be final.

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

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into threadlocal_final
 - make ThreadLocal.nextHashCode final

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

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

From shade at openjdk.org  Wed Dec  6 17:23:42 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 6 Dec 2023 17:23:42 GMT
Subject: RFR: 8321470: ThreadLocal.nextHashCode can be static final
In-Reply-To: <7g_sH5nIxOFlqEARD90RX5X6I_flcAt0VHUtzU0Fqyo=.1dd55021-9720-40a7-ad0b-d18e07963b50@github.com>
References: <7g_sH5nIxOFlqEARD90RX5X6I_flcAt0VHUtzU0Fqyo=.1dd55021-9720-40a7-ad0b-d18e07963b50@github.com>
Message-ID: <zzYKjLBcs294wQTj-eDQpuOTtpd3iSGW3KW1lAG0ZYg=.f533ce62-6789-4a94-88b8-d1f3fd0261de@github.com>

On Wed, 6 Dec 2023 00:52:48 GMT, Brett Okken <duke at openjdk.org> wrote:

> The static AtomicInteger used for the nextHashCode should be final.

Submitted: https://bugs.openjdk.org/browse/JDK-8321470

Please change this PR title to "8321470: ThreadLocal.nextHashCode can be static final", and bots would do the rest.

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

PR Comment: https://git.openjdk.org/jdk/pull/16987#issuecomment-1842976493

From shade at openjdk.org  Wed Dec  6 17:32:38 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 6 Dec 2023 17:32:38 GMT
Subject: RFR: 8321470: ThreadLocal.nextHashCode can be static final
In-Reply-To: <7g_sH5nIxOFlqEARD90RX5X6I_flcAt0VHUtzU0Fqyo=.1dd55021-9720-40a7-ad0b-d18e07963b50@github.com>
References: <7g_sH5nIxOFlqEARD90RX5X6I_flcAt0VHUtzU0Fqyo=.1dd55021-9720-40a7-ad0b-d18e07963b50@github.com>
Message-ID: <ehAQ4oBPp6zHX9mr7pdXKBSmWU20o_8uU_9f6RcfxSs=.1deef403-83e6-4b45-a51a-f589b42a5cd8@github.com>

On Wed, 6 Dec 2023 00:52:48 GMT, Brett Okken <duke at openjdk.org> wrote:

> The static AtomicInteger used for the nextHashCode should be final.

Looks okay to me!

Since this is new contribution, I would like someone else to take a look.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16987#pullrequestreview-1768229984

From duke at openjdk.org  Wed Dec  6 17:42:47 2023
From: duke at openjdk.org (Brett Okken)
Date: Wed, 6 Dec 2023 17:42:47 GMT
Subject: RFR: 8321470: ThreadLocal.nextHashCode can be static final [v2]
In-Reply-To: <7g_sH5nIxOFlqEARD90RX5X6I_flcAt0VHUtzU0Fqyo=.1dd55021-9720-40a7-ad0b-d18e07963b50@github.com>
References: <7g_sH5nIxOFlqEARD90RX5X6I_flcAt0VHUtzU0Fqyo=.1dd55021-9720-40a7-ad0b-d18e07963b50@github.com>
Message-ID: <mioVujKuoINmPzHE_cNt3Bm9IsCec0kE9XkwXLs9j-Q=.a8dfe582-b2f5-4561-92df-a4215e8e8577@github.com>

> The static AtomicInteger used for the nextHashCode should be final.

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

  Update full name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16987/files
  - new: https://git.openjdk.org/jdk/pull/16987/files/9e276138..d05272a3

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

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

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

From duke at openjdk.org  Wed Dec  6 17:48:04 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 6 Dec 2023 17:48:04 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v10]
In-Reply-To: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
Message-ID: <hbnJof4NG7vsMtA6Ze5xcZ_XqyGKE4kJJ5t4mWDpYtA=.c0dc9cba-007f-4164-843e-1d74dd894501@github.com>

> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX2 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
> 
> For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
> 
> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
> 
> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
> <link rel=File-List
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
> 
> 
> </head>
> 
> <body link="#0563C1" vlink="#954F72">
> 
> 
> 
> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
> -- | -- | -- | -- | --
> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
> 
> </body>
> 
> </html>
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/...

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  add missing header files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16534/files
  - new: https://git.openjdk.org/jdk/pull/16534/files/c143e0b9..7e124581

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

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

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

From jbhateja at openjdk.org  Wed Dec  6 17:48:05 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 6 Dec 2023 17:48:05 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v10]
In-Reply-To: <hbnJof4NG7vsMtA6Ze5xcZ_XqyGKE4kJJ5t4mWDpYtA=.c0dc9cba-007f-4164-843e-1d74dd894501@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <hbnJof4NG7vsMtA6Ze5xcZ_XqyGKE4kJJ5t4mWDpYtA=.c0dc9cba-007f-4164-843e-1d74dd894501@github.com>
Message-ID: <u8cnCqv4xmTnuYLURQdWGR_h4HNWmmuKM-zgdue3thg=.832ce475-9c89-48ae-88e2-6155c7235c41@github.com>

On Wed, 6 Dec 2023 17:44:25 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX2 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
>> 
>> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
>> 
>> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId content=Excel.Sheet>
>> <meta name=Generator content="Microsoft Excel 15">
>> <link id=Main-File rel=Main-File
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
>> <link rel=File-List
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
>> 
>> 
>> </head>
>> 
>> <body link="#0563C1" vlink="#954F72">
>> 
>> 
>> 
>> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
>> -- | -- | -- | -- | --
>> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
>> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
>> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
>> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
>> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
>> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
>> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
>> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
>> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
>> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
>> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
>> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
>> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
>> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
>> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
>> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
>> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
>> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
>> 
>> </body>
>> 
>> </html>
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId cont...
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add missing header files

LGTM, thanks!

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

Marked as reviewed by jbhateja (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16534#pullrequestreview-1768255412

From duke at openjdk.org  Wed Dec  6 17:48:06 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 6 Dec 2023 17:48:06 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v10]
In-Reply-To: <u8cnCqv4xmTnuYLURQdWGR_h4HNWmmuKM-zgdue3thg=.832ce475-9c89-48ae-88e2-6155c7235c41@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <hbnJof4NG7vsMtA6Ze5xcZ_XqyGKE4kJJ5t4mWDpYtA=.c0dc9cba-007f-4164-843e-1d74dd894501@github.com>
 <u8cnCqv4xmTnuYLURQdWGR_h4HNWmmuKM-zgdue3thg=.832ce475-9c89-48ae-88e2-6155c7235c41@github.com>
Message-ID: <Os9Qc0Q8N6tzPrwpww6omeOU4qKq4tqZCXS2MN1_vJc=.0fddcbb5-56e6-4c27-b839-12579f462115@github.com>

On Wed, 6 Dec 2023 17:42:39 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> LGTM, thanks!

Thanks Jatin!

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

PR Comment: https://git.openjdk.org/jdk/pull/16534#issuecomment-1843372385

From jlaskey at openjdk.org  Wed Dec  6 17:56:58 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 6 Dec 2023 17:56:58 GMT
Subject: RFR: JDK-8320570 NegativeArraySizeException decoding >1G UTF8
 bytes with non-ascii characters [v4]
In-Reply-To: <wK-u3PPhgDfuUAGIWQNgYs_gxKrDVjsNs8ImLonZObU=.49b3b03b-6deb-418a-9ab0-9c9fc563b33a@github.com>
References: <wK-u3PPhgDfuUAGIWQNgYs_gxKrDVjsNs8ImLonZObU=.49b3b03b-6deb-418a-9ab0-9c9fc563b33a@github.com>
Message-ID: <LduGyJoPxVvKdlW6vX8rmCNUHRX9OH1cYCIwLA8i6k4=.c12cb192-1852-4afb-95d6-59e41303cfdb@github.com>

> A regression is found in Java9+ creating String instance from UTF8 bytes, a side effect of string compactation https://openjdk.org/jeps/254 that changed the decoding logic. Specifically, when constructing a string from bytes: 
> 
> ``` 
> String str = new String(largeBytes, StandardCharsets.UTF_8); 
> ``` 
> 
> if the size of largeBytes is greater than 2^30 (>1 GB) but smaller than INT_MAX (2 GB), it fails on Java9+ (including 11, 17, 21, though the stack trace is slightly different, see below), regardless of jvm heap size. In Java8, it succeeded when jvm heap size is set to be sufficient.

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

 - Alternate 64 bit test
 - Exclude 32 bit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16974/files
  - new: https://git.openjdk.org/jdk/pull/16974/files/144b5161..9926adda

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

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

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

From rriggs at openjdk.org  Wed Dec  6 18:02:36 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 6 Dec 2023 18:02:36 GMT
Subject: RFR: JDK-8320570 NegativeArraySizeException decoding >1G UTF8
 bytes with non-ascii characters [v4]
In-Reply-To: <LduGyJoPxVvKdlW6vX8rmCNUHRX9OH1cYCIwLA8i6k4=.c12cb192-1852-4afb-95d6-59e41303cfdb@github.com>
References: <wK-u3PPhgDfuUAGIWQNgYs_gxKrDVjsNs8ImLonZObU=.49b3b03b-6deb-418a-9ab0-9c9fc563b33a@github.com>
 <LduGyJoPxVvKdlW6vX8rmCNUHRX9OH1cYCIwLA8i6k4=.c12cb192-1852-4afb-95d6-59e41303cfdb@github.com>
Message-ID: <Vj8d616nkMmRLkeBe0cqwegAPZ0P6YNWLUMyJc2R7lo=.3e394cc5-3de0-42dc-88b5-fcb36f84fc07@github.com>

On Wed, 6 Dec 2023 17:56:58 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> A regression is found in Java9+ creating String instance from UTF8 bytes, a side effect of string compactation https://openjdk.org/jeps/254 that changed the decoding logic. Specifically, when constructing a string from bytes: 
>> 
>> ``` 
>> String str = new String(largeBytes, StandardCharsets.UTF_8); 
>> ``` 
>> 
>> if the size of largeBytes is greater than 2^30 (>1 GB) but smaller than INT_MAX (2 GB), it fails on Java9+ (including 11, 17, 21, though the stack trace is slightly different, see below), regardless of jvm heap size. In Java8, it succeeded when jvm heap size is set to be sufficient.
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Alternate 64 bit test
>  - Exclude 32 bit

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16974#pullrequestreview-1768284373

From sviswanathan at openjdk.org  Wed Dec  6 18:07:45 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 6 Dec 2023 18:07:45 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v10]
In-Reply-To: <hbnJof4NG7vsMtA6Ze5xcZ_XqyGKE4kJJ5t4mWDpYtA=.c0dc9cba-007f-4164-843e-1d74dd894501@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <hbnJof4NG7vsMtA6Ze5xcZ_XqyGKE4kJJ5t4mWDpYtA=.c0dc9cba-007f-4164-843e-1d74dd894501@github.com>
Message-ID: <1H8N81T-C79IER_JFotgxYegmmZHI8-Efbe0vbmO5oU=.2150bacd-7a5a-4a66-8096-662a35cc893e@github.com>

On Wed, 6 Dec 2023 17:48:04 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX2 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
>> 
>> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
>> 
>> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId content=Excel.Sheet>
>> <meta name=Generator content="Microsoft Excel 15">
>> <link id=Main-File rel=Main-File
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
>> <link rel=File-List
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
>> 
>> 
>> </head>
>> 
>> <body link="#0563C1" vlink="#954F72">
>> 
>> 
>> 
>> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
>> -- | -- | -- | -- | --
>> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
>> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
>> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
>> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
>> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
>> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
>> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
>> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
>> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
>> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
>> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
>> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
>> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
>> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
>> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
>> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
>> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
>> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
>> 
>> </body>
>> 
>> </html>
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId cont...
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add missing header files

@TobiHartmann @vnkozlov Please advice if we can go head and integrate this PR today before the fork.

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

PR Comment: https://git.openjdk.org/jdk/pull/16534#issuecomment-1843407940

From naoto at openjdk.org  Wed Dec  6 18:08:35 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 6 Dec 2023 18:08:35 GMT
Subject: RFR: 8321206: Make Locale related system properties static
 properties
In-Reply-To: <84iT7QgD8wSQoFnFQrKSsYAuG9HLxHZQYfWKeINibiA=.ec2589e5-dd56-4ee5-b3ea-b08e01373ed2@github.com>
References: <EKzdSEIjrFq0mXKLGOdRCePeu29DWWQnpAY5FDVAK40=.3bcd4037-e3e5-4cf1-948d-665355914106@github.com>
 <84iT7QgD8wSQoFnFQrKSsYAuG9HLxHZQYfWKeINibiA=.ec2589e5-dd56-4ee5-b3ea-b08e01373ed2@github.com>
Message-ID: <l8nC92bziy0WWjyqyEOEKOU29WdERzFUvxQVntwj5e4=.c979c552-edf1-46db-87bd-ebe566d83b86@github.com>

On Wed, 6 Dec 2023 02:14:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I'm not following the changes to cdsHeapVerifier.cpp. You've marked the new entries as `C` but the definition is:
> 
> ```
> // [C] A non-final static string that is assigned a string literal during class
> // initialization; this string is never changed during -Xshare:dump.
> ```
> 
> and these are final static strings not non-final. ???

I simply followed the fix to https://bugs.openjdk.org/browse/JDK-8295295 where the last time I added a `StaticProperty`, it broke the CDS test. Since I am not familiar in this area, I am happy to have the reasoning corrected. I would appreciate suggestions.

> You also have a large number of test failures with this PR.

Are you referring to GHA tests? I am not sure they are relevant to this fix, as my run for mach5 did not cause any regression test failures.

> Can I also suggest that you change the bug and PR synopsis to say StaticProperty rather than static properties as I found it quite confusing to understand the issue.

Modified.

>> Making them static properties is safer than relying on the class initialization timing
> "class initialization" refers to the static initialization of a class. I assume that is not what you mean here but the creation of the instance of the class? Even StaticProperty still initializes these things during class initialization, so I'm unclear exactly what this is trying to say.

Modified it to specifically saying `Locale` class loading time.

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

PR Comment: https://git.openjdk.org/jdk/pull/16986#issuecomment-1843406352

From naoto at openjdk.org  Wed Dec  6 18:08:38 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 6 Dec 2023 18:08:38 GMT
Subject: RFR: 8321206: Make Locale related system properties static
 properties
In-Reply-To: <797rwHmV9jH9-73C5QISVPprqdl2245BQn0M5h8L5DE=.58daf90d-4828-488f-8bd9-acd100580bee@github.com>
References: <EKzdSEIjrFq0mXKLGOdRCePeu29DWWQnpAY5FDVAK40=.3bcd4037-e3e5-4cf1-948d-665355914106@github.com>
 <797rwHmV9jH9-73C5QISVPprqdl2245BQn0M5h8L5DE=.58daf90d-4828-488f-8bd9-acd100580bee@github.com>
Message-ID: <_K-8MSM-5das1rxMjw6xb73L3zg01yJg7GXXPothFec=.27d3af67-0b80-4506-80a7-bec4ce559648@github.com>

On Wed, 6 Dec 2023 08:14:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Currently, Locale-related system properties, such as `user.language` or `user.country`, are initialized when the `Locale` class is loaded. Making them static properties is safer than relying on the `Locale` class loading timing, which could potentially be changed depending on the implementation.
>
> src/java.base/share/classes/java/util/Locale.java line 1099:
> 
>> 1097:             StaticProperty.userCountry(category.ordinal() + 1),
>> 1098:             StaticProperty.userVariant(category.ordinal() + 1),
>> 1099:             getDefaultExtensions(StaticProperty.userExtensions(category.ordinal() + 1))
> 
> I suspect this would be more readable, and maintainable, if you add non-public languageKey/scriptKey/countryKey/variantKey methods to Locale.Category. That would change this to getInstance(category.languageKey(), ...) so no sight of the ordinal at the use-site.

Right. Will change it in the next iteration

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16986#discussion_r1417769586

From naoto at openjdk.org  Wed Dec  6 18:15:35 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 6 Dec 2023 18:15:35 GMT
Subject: RFR: 8321206: Make Locale related system properties
 `StaticProperty`
In-Reply-To: <Q0s3jRna4fd61HAQ2vdOd935m3pKE849yQ1cgnkcE2c=.b0cf13d4-70f6-46c0-b71b-3f63e449ced5@github.com>
References: <EKzdSEIjrFq0mXKLGOdRCePeu29DWWQnpAY5FDVAK40=.3bcd4037-e3e5-4cf1-948d-665355914106@github.com>
 <Q0s3jRna4fd61HAQ2vdOd935m3pKE849yQ1cgnkcE2c=.b0cf13d4-70f6-46c0-b71b-3f63e449ced5@github.com>
Message-ID: <ZnPuPk7VLYZ4_vqt5CwSSdpj772lq3cy0hml5yLBcnk=.feed0618-944f-4961-8c18-0f8689336a2a@github.com>

On Wed, 6 Dec 2023 15:27:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Currently, Locale-related system properties, such as `user.language` or `user.country`, are initialized when the `Locale` class is loaded. Making them static properties is safer than relying on the `Locale` class loading timing, which could potentially be changed depending on the implementation.
>
> src/java.base/share/classes/jdk/internal/util/StaticProperty.java line 113:
> 
>> 111:         USER_EXTENSIONS_DISPLAY = getProperty(props, "user.extensions.display", USER_EXTENSIONS);
>> 112:         USER_EXTENSIONS_FORMAT = getProperty(props, "user.extensions.format", USER_EXTENSIONS);
>> 113:         USER_REGION = getProperty(props, "user.region", "");
> 
> Computing the defaults for these properties should be in the Locale class, close to the initialization of the default locale. Splitting the responsibility across files makes it harder to follow what happens where/when.

If I am not mistaken, these assignments should stay here in `StaticProperty`, as that is the whole purpose of this change. Depending on `Locale` class loading time might be fragile, and this change guarantees the properties are initialized and frozen in `System.initPhase1()`

> src/java.base/share/classes/jdk/internal/util/StaticProperty.java line 415:
> 
>> 413:     public static String userRegion() {
>> 414:         return USER_REGION;
>> 415:     }
> 
> Using methods to retrieve these makes is more complicated.
> The bleeding of the enum values outside of Locale is undesirable.
> Since the property values are final strings, I suggest just making the fields public and keep the mapping local to the Locale class.

As Alan commented, I will not use `Locale.Category.ordinal()` but instead use the properties keys. Would that address your suggestion?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16986#discussion_r1417793505
PR Review Comment: https://git.openjdk.org/jdk/pull/16986#discussion_r1417785427

From naoto at openjdk.org  Wed Dec  6 18:18:36 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 6 Dec 2023 18:18:36 GMT
Subject: RFR: 8321206: Make Locale related system properties
 `StaticProperty`
In-Reply-To: <Q0s3jRna4fd61HAQ2vdOd935m3pKE849yQ1cgnkcE2c=.b0cf13d4-70f6-46c0-b71b-3f63e449ced5@github.com>
References: <EKzdSEIjrFq0mXKLGOdRCePeu29DWWQnpAY5FDVAK40=.3bcd4037-e3e5-4cf1-948d-665355914106@github.com>
 <Q0s3jRna4fd61HAQ2vdOd935m3pKE849yQ1cgnkcE2c=.b0cf13d4-70f6-46c0-b71b-3f63e449ced5@github.com>
Message-ID: <QA5zE2q2iyGWygzW4aXlQmLf_hFMNZoQQh7cKb5dU8k=.8a96034f-d987-47e9-bb70-f3da30e9023b@github.com>

On Wed, 6 Dec 2023 15:18:27 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Currently, Locale-related system properties, such as `user.language` or `user.country`, are initialized when the `Locale` class is loaded. Making them static properties is safer than relying on the `Locale` class loading timing, which could potentially be changed depending on the implementation.
>
> src/java.base/share/classes/java/util/Locale.java line 1061:
> 
>> 1059:         if (sm != null) {
>> 1060:             sm.checkPropertiesAccess();
>> 1061:         }
> 
> This SM check is no longer needed; the use of privilegedGetProperties made access unconditional.
> The static properties are always accessible to the locale implementation.

Was wondering so. Will remove them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16986#discussion_r1417796853

From kvn at openjdk.org  Wed Dec  6 18:29:41 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 6 Dec 2023 18:29:41 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v10]
In-Reply-To: <1H8N81T-C79IER_JFotgxYegmmZHI8-Efbe0vbmO5oU=.2150bacd-7a5a-4a66-8096-662a35cc893e@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <hbnJof4NG7vsMtA6Ze5xcZ_XqyGKE4kJJ5t4mWDpYtA=.c0dc9cba-007f-4164-843e-1d74dd894501@github.com>
 <1H8N81T-C79IER_JFotgxYegmmZHI8-Efbe0vbmO5oU=.2150bacd-7a5a-4a66-8096-662a35cc893e@github.com>
Message-ID: <AwRo0-HLJR6L8VbdZMsGrp25Rwku3yREefT0M-6N82k=.4cb8bf71-3dc3-432c-bdec-df03f0a4d74a@github.com>

On Wed, 6 Dec 2023 18:05:22 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> @TobiHartmann @vnkozlov Please advice if we can go head and integrate this PR today before the fork.

Too late. Changes looks fine to me (I am still on fence that we moving to C++ implementation of intrinsics and require latest C++ compiler version). I need to run testing for latest version of changes before approval. Lets not rush.

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

PR Comment: https://git.openjdk.org/jdk/pull/16534#issuecomment-1843446956

From sviswanathan at openjdk.org  Wed Dec  6 18:33:45 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 6 Dec 2023 18:33:45 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v10]
In-Reply-To: <AwRo0-HLJR6L8VbdZMsGrp25Rwku3yREefT0M-6N82k=.4cb8bf71-3dc3-432c-bdec-df03f0a4d74a@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <hbnJof4NG7vsMtA6Ze5xcZ_XqyGKE4kJJ5t4mWDpYtA=.c0dc9cba-007f-4164-843e-1d74dd894501@github.com>
 <1H8N81T-C79IER_JFotgxYegmmZHI8-Efbe0vbmO5oU=.2150bacd-7a5a-4a66-8096-662a35cc893e@github.com>
 <AwRo0-HLJR6L8VbdZMsGrp25Rwku3yREefT0M-6N82k=.4cb8bf71-3dc3-432c-bdec-df03f0a4d74a@github.com>
Message-ID: <oOCxQNLnxkRMKCABb6QeqLVL9MyhH7_Uwz8qn1d54gk=.e4e2e963-f622-4f16-af0b-dce3ac00474c@github.com>

On Wed, 6 Dec 2023 18:26:34 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> @TobiHartmann @vnkozlov Please advice if we can go head and integrate this PR today before the fork.
>
>> @TobiHartmann @vnkozlov Please advice if we can go head and integrate this PR today before the fork.
> 
> Too late. Changes looks fine to me (I am still on fence that we moving to C++ implementation of intrinsics and require latest C++ compiler version). I need to run testing for latest version of changes before approval. Lets not rush.

Thanks a lot @vnkozlov, we will wait for your approval.

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

PR Comment: https://git.openjdk.org/jdk/pull/16534#issuecomment-1843454162

From darcy at openjdk.org  Wed Dec  6 18:41:57 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 6 Dec 2023 18:41:57 GMT
Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v6]
In-Reply-To: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
Message-ID: <Mje8eoVfAhXc5K8LoU8YnhAga5PevtfNArYMUHXn6w8=.1cab743b-c1b8-460f-b492-80defdc48745@github.com>

> Time to start making preparations for JDK 23.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Regenerate JDK 22 symbol files.
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Add symbol files.
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Update symbol files to JDK 22 b26.
 - ... and 8 more: https://git.openjdk.org/jdk/compare/db5613af...efe849f6

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

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

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

From rgiulietti at openjdk.org  Wed Dec  6 18:44:41 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 6 Dec 2023 18:44:41 GMT
Subject: RFR: 8320759: Creation of random BigIntegers can be made faster
 [v3]
In-Reply-To: <X0JLWafyuyum8VPF25kVst69Dog-K7frF1aVyqkRVYo=.1b7a2858-c24a-4a6a-af2c-7aa387fbf76c@github.com>
References: <wIuR7gaQWIRdb8DtEN1VXi9dNkUMuKn8zv3Myc4V2gc=.3356e893-5322-4bb4-aa37-731fb6e9a4b0@github.com>
 <KAD32In5r6VDU4e0LePqKTHv8bn7fc9xb9zAI1UBkHY=.acba81de-6332-4cf9-9a66-d6e0f488b61b@github.com>
 <xeIs7PX3HXqTdu2tRHwcZ8MUMqwQ2-npMve0hR1Kpm8=.3b639c80-f5fd-4445-a682-b1a656c8a278@github.com>
 <X0JLWafyuyum8VPF25kVst69Dog-K7frF1aVyqkRVYo=.1b7a2858-c24a-4a6a-af2c-7aa387fbf76c@github.com>
Message-ID: <z30-UVP7Mmfy6bUIeYMeu_X6Xa8OD9R1q_wsU2BkqUc=.fd0d11df-419f-4940-a471-967dafd87a39@github.com>

On Wed, 6 Dec 2023 15:07:59 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> So, item 1 is a non-issue and item 2 is not likely a problem in practice. What, if anything, will be done about item 3?
>
> @bplb Maybe an assertion at the end of `randomBits(int, Random)` method, or a test class.

@fabioromano1 
As suggested earlier, you might want to take a look [here](https://github.com/openjdk/jdk/blob/master/test/jdk/java/math/BigInteger/ByteArrayConstructorTest.java) to see how the fields can be accessed from your test, preferably JUnit and preferably placing it into that same folder.

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

PR Comment: https://git.openjdk.org/jdk/pull/16817#issuecomment-1843479248

From kvn at openjdk.org  Wed Dec  6 18:44:47 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 6 Dec 2023 18:44:47 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v10]
In-Reply-To: <hbnJof4NG7vsMtA6Ze5xcZ_XqyGKE4kJJ5t4mWDpYtA=.c0dc9cba-007f-4164-843e-1d74dd894501@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <hbnJof4NG7vsMtA6Ze5xcZ_XqyGKE4kJJ5t4mWDpYtA=.c0dc9cba-007f-4164-843e-1d74dd894501@github.com>
Message-ID: <dSUNCdyZym0mjS3bSuYSqKFt8d5seRlDAiYfA2ixzOQ=.7d79c7da-4972-497b-bf61-096565ebb322@github.com>

On Wed, 6 Dec 2023 17:48:04 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX2 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
>> 
>> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
>> 
>> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId content=Excel.Sheet>
>> <meta name=Generator content="Microsoft Excel 15">
>> <link id=Main-File rel=Main-File
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
>> <link rel=File-List
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
>> 
>> 
>> </head>
>> 
>> <body link="#0563C1" vlink="#954F72">
>> 
>> 
>> 
>> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
>> -- | -- | -- | -- | --
>> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
>> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
>> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
>> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
>> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
>> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
>> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
>> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
>> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
>> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
>> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
>> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
>> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
>> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
>> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
>> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
>> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
>> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
>> 
>> </body>
>> 
>> </html>
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId cont...
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add missing header files

src/hotspot/share/opto/library_call.cpp line 5393:

> 5391:     if (!Matcher::supports_simd_sort(bt)) {
> 5392:       return false;
> 5393:     }

This check should be in `C2Compiler::is_intrinsic_supported()`

src/hotspot/share/opto/library_call.cpp line 5450:

> 5448:   if (!Matcher::supports_simd_sort(bt)) {
> 5449:     return false;
> 5450:   }

Same.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1417831171
PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1417832246

From jlaskey at openjdk.org  Wed Dec  6 20:14:06 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 6 Dec 2023 20:14:06 GMT
Subject: RFR: JDK-8320570 NegativeArraySizeException decoding >1G UTF8
 bytes with non-ascii characters [v5]
In-Reply-To: <wK-u3PPhgDfuUAGIWQNgYs_gxKrDVjsNs8ImLonZObU=.49b3b03b-6deb-418a-9ab0-9c9fc563b33a@github.com>
References: <wK-u3PPhgDfuUAGIWQNgYs_gxKrDVjsNs8ImLonZObU=.49b3b03b-6deb-418a-9ab0-9c9fc563b33a@github.com>
Message-ID: <sHJbXzGdKzUHqI-RHi8Z72TQjWmqBw0zb72biPadlb4=.4788c4f5-28d8-41ec-8951-ced0586a4e09@github.com>

> A regression is found in Java9+ creating String instance from UTF8 bytes, a side effect of string compactation https://openjdk.org/jeps/254 that changed the decoding logic. Specifically, when constructing a string from bytes: 
> 
> ``` 
> String str = new String(largeBytes, StandardCharsets.UTF_8); 
> ``` 
> 
> if the size of largeBytes is greater than 2^30 (>1 GB) but smaller than INT_MAX (2 GB), it fails on Java9+ (including 11, 17, 21, though the stack trace is slightly different, see below), regardless of jvm heap size. In Java8, it succeeded when jvm heap size is set to be sufficient.

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

 - Merge remote-tracking branch 'upstream/master' into 8320570
 - Alternate 64 bit test
 - Exclude 32 bit
 - Requested changes
 - Bump up memory
 - Cotrrect NegativeSize.java
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16974/files
  - new: https://git.openjdk.org/jdk/pull/16974/files/9926adda..8ae170dd

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

  Stats: 39190 lines in 426 files changed: 14144 ins; 23593 del; 1453 mod
  Patch: https://git.openjdk.org/jdk/pull/16974.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16974/head:pull/16974

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

From duke at openjdk.org  Wed Dec  6 20:36:04 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 6 Dec 2023 20:36:04 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v11]
In-Reply-To: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
Message-ID: <drQZwXdTKCD5FyyAYLAE0TDCSUSIaNEDdbspV3r7ahI=.07011779-006f-4a93-84c9-d1f997b130c9@github.com>

> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX2 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
> 
> For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
> 
> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
> 
> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
> <link rel=File-List
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
> 
> 
> </head>
> 
> <body link="#0563C1" vlink="#954F72">
> 
> 
> 
> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
> -- | -- | -- | -- | --
> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
> 
> </body>
> 
> </html>
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/...

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  Change supported intrinsic check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16534/files
  - new: https://git.openjdk.org/jdk/pull/16534/files/7e124581..9621eb04

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

  Stats: 28 lines in 4 files changed: 20 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/16534.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16534/head:pull/16534

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

From duke at openjdk.org  Wed Dec  6 20:36:09 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 6 Dec 2023 20:36:09 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v10]
In-Reply-To: <dSUNCdyZym0mjS3bSuYSqKFt8d5seRlDAiYfA2ixzOQ=.7d79c7da-4972-497b-bf61-096565ebb322@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <hbnJof4NG7vsMtA6Ze5xcZ_XqyGKE4kJJ5t4mWDpYtA=.c0dc9cba-007f-4164-843e-1d74dd894501@github.com>
 <dSUNCdyZym0mjS3bSuYSqKFt8d5seRlDAiYfA2ixzOQ=.7d79c7da-4972-497b-bf61-096565ebb322@github.com>
Message-ID: <Iatvjk9HYS1ka2u-FvwFQiuDKil3q2i0d48IPfEO6Dw=.67bfa7b6-c737-43b9-9a03-43dd09fa30e0@github.com>

On Wed, 6 Dec 2023 18:41:26 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add missing header files
>
> src/hotspot/share/opto/library_call.cpp line 5393:
> 
>> 5391:     if (!Matcher::supports_simd_sort(bt)) {
>> 5392:       return false;
>> 5393:     }
> 
> This check should be in `C2Compiler::is_intrinsic_supported()`

Hi Vladimir (@vnkozlov), please see the updated changes which use `C2Compiler::is_intrinsic_supported(id, bt)`

> src/hotspot/share/opto/library_call.cpp line 5450:
> 
>> 5448:   if (!Matcher::supports_simd_sort(bt)) {
>> 5449:     return false;
>> 5450:   }
> 
> Same.

Please see the updated changes which use C2Compiler::is_intrinsic_supported(id, bt)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1417946689
PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1417946968

From naoto at openjdk.org  Wed Dec  6 20:55:48 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 6 Dec 2023 20:55:48 GMT
Subject: RFR: 8321206: Make Locale related system properties
 `StaticProperty` [v2]
In-Reply-To: <EKzdSEIjrFq0mXKLGOdRCePeu29DWWQnpAY5FDVAK40=.3bcd4037-e3e5-4cf1-948d-665355914106@github.com>
References: <EKzdSEIjrFq0mXKLGOdRCePeu29DWWQnpAY5FDVAK40=.3bcd4037-e3e5-4cf1-948d-665355914106@github.com>
Message-ID: <CcKGxJp4T09SzhWQ3TBXPqH5TBPb9GbD6QRO0opn8Pg=.3054f472-f801-4846-bbfb-5f29cc8e8512@github.com>

> Currently, Locale-related system properties, such as `user.language` or `user.country`, are initialized when the `Locale` class is loaded. Making them static properties is safer than relying on the `Locale` class loading timing, which could potentially be changed depending on the implementation.

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

 - Reflects review comments
 - Merge branch 'master' into JDK-8321206-Locale-static-properties
 - Add exclusions in cdsHeapVerifier for new StaticProperties
 - initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16986/files
  - new: https://git.openjdk.org/jdk/pull/16986/files/929f339b..35396106

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

  Stats: 38933 lines in 413 files changed: 13835 ins; 23669 del; 1429 mod
  Patch: https://git.openjdk.org/jdk/pull/16986.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16986/head:pull/16986

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

From naoto at openjdk.org  Wed Dec  6 20:55:49 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 6 Dec 2023 20:55:49 GMT
Subject: RFR: 8321206: Make Locale related system properties
 `StaticProperty` [v2]
In-Reply-To: <ZnPuPk7VLYZ4_vqt5CwSSdpj772lq3cy0hml5yLBcnk=.feed0618-944f-4961-8c18-0f8689336a2a@github.com>
References: <EKzdSEIjrFq0mXKLGOdRCePeu29DWWQnpAY5FDVAK40=.3bcd4037-e3e5-4cf1-948d-665355914106@github.com>
 <Q0s3jRna4fd61HAQ2vdOd935m3pKE849yQ1cgnkcE2c=.b0cf13d4-70f6-46c0-b71b-3f63e449ced5@github.com>
 <ZnPuPk7VLYZ4_vqt5CwSSdpj772lq3cy0hml5yLBcnk=.feed0618-944f-4961-8c18-0f8689336a2a@github.com>
Message-ID: <8zTg5vwrz9SklpuzxRvP7-HtLiirju_mLFpRwIuN-V8=.d51e086d-74df-4183-a8ea-434897f3c374@github.com>

On Wed, 6 Dec 2023 18:10:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/StaticProperty.java line 415:
>> 
>>> 413:     public static String userRegion() {
>>> 414:         return USER_REGION;
>>> 415:     }
>> 
>> Using methods to retrieve these makes is more complicated.
>> The bleeding of the enum values outside of Locale is undesirable.
>> Since the property values are final strings, I suggest just making the fields public and keep the mapping local to the Locale class.
>
> As Alan commented, I will not use `Locale.Category.ordinal()` but instead use the properties keys. Would that address your suggestion?

Ended up replacing public methods with public fields

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16986#discussion_r1417964470

From naoto at openjdk.org  Wed Dec  6 21:18:45 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 6 Dec 2023 21:18:45 GMT
Subject: RFR: 8321409: Console read line with zero out should zero out
 underlying buffer in JLine (redux)
Message-ID: <W8wRAZIT88cFG4AhOlRGdwHo2bovYSNIe1bk9iDP39Q=.b0d9dc4a-afa0-4ac8-8c60-890d2f10b553@github.com>

This is an additional fix to JDK-8321131, where more clearing is required in JLine.

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

Commit messages:
 - initial commit

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

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

From jlaskey at openjdk.org  Wed Dec  6 21:57:48 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 6 Dec 2023 21:57:48 GMT
Subject: Integrated: JDK-8320570 NegativeArraySizeException decoding >1G UTF8
 bytes with non-ascii characters
In-Reply-To: <wK-u3PPhgDfuUAGIWQNgYs_gxKrDVjsNs8ImLonZObU=.49b3b03b-6deb-418a-9ab0-9c9fc563b33a@github.com>
References: <wK-u3PPhgDfuUAGIWQNgYs_gxKrDVjsNs8ImLonZObU=.49b3b03b-6deb-418a-9ab0-9c9fc563b33a@github.com>
Message-ID: <l1cw6PTFRuArA2eTdbfBBgfpcp65UnXfwKCmuICFDxs=.99ac6790-c4d8-4183-9a20-b92329c1925d@github.com>

On Tue, 5 Dec 2023 14:57:09 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> A regression is found in Java9+ creating String instance from UTF8 bytes, a side effect of string compactation https://openjdk.org/jeps/254 that changed the decoding logic. Specifically, when constructing a string from bytes: 
> 
> ``` 
> String str = new String(largeBytes, StandardCharsets.UTF_8); 
> ``` 
> 
> if the size of largeBytes is greater than 2^30 (>1 GB) but smaller than INT_MAX (2 GB), it fails on Java9+ (including 11, 17, 21, though the stack trace is slightly different, see below), regardless of jvm heap size. In Java8, it succeeded when jvm heap size is set to be sufficient.

This pull request has now been integrated.

Changeset: 82796bde
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/82796bdebbf56b98ec97a6d572ed68c2842f60c6
Stats:     82 lines in 2 files changed: 75 ins; 0 del; 7 mod

8320570: NegativeArraySizeException decoding >1G UTF8 bytes with non-ascii characters

Reviewed-by: rriggs

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

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

From rriggs at openjdk.org  Wed Dec  6 22:07:37 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 6 Dec 2023 22:07:37 GMT
Subject: RFR: 8321206: Make Locale related system properties
 `StaticProperty` [v2]
In-Reply-To: <CcKGxJp4T09SzhWQ3TBXPqH5TBPb9GbD6QRO0opn8Pg=.3054f472-f801-4846-bbfb-5f29cc8e8512@github.com>
References: <EKzdSEIjrFq0mXKLGOdRCePeu29DWWQnpAY5FDVAK40=.3bcd4037-e3e5-4cf1-948d-665355914106@github.com>
 <CcKGxJp4T09SzhWQ3TBXPqH5TBPb9GbD6QRO0opn8Pg=.3054f472-f801-4846-bbfb-5f29cc8e8512@github.com>
Message-ID: <BeZNSOs6JQ5rM1TNhDfGnQuoyjGWTZRTrhPLVM6Q9ck=.acbf6d25-7fb9-4681-8f5f-87e13126e632@github.com>

On Wed, 6 Dec 2023 20:55:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Currently, Locale-related system properties, such as `user.language` or `user.country`, are initialized when the `Locale` class is loaded. Making them static properties is safer than relying on the `Locale` class loading timing, which could potentially be changed depending on the implementation.
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Reflects review comments
>  - Merge branch 'master' into JDK-8321206-Locale-static-properties
>  - Add exclusions in cdsHeapVerifier for new StaticProperties
>  - initial commit

Looks good; simpler and more direct is an improvement.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16986#pullrequestreview-1768704534

From sgibbons at openjdk.org  Wed Dec  6 22:23:47 2023
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 6 Dec 2023 22:23:47 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v3]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <Mhrn-0x2O7V6BPYYphYXmvmBD3eaaIqxhXn06UBTpMc=.d7c6bb34-1d69-4a4a-aa43-31abc163da06@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

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

  Support UU IndexOf

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/e614b86f..5e03173e

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

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

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

From kvn at openjdk.org  Wed Dec  6 22:59:41 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 6 Dec 2023 22:59:41 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v10]
In-Reply-To: <Os9Qc0Q8N6tzPrwpww6omeOU4qKq4tqZCXS2MN1_vJc=.0fddcbb5-56e6-4c27-b839-12579f462115@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <hbnJof4NG7vsMtA6Ze5xcZ_XqyGKE4kJJ5t4mWDpYtA=.c0dc9cba-007f-4164-843e-1d74dd894501@github.com>
 <u8cnCqv4xmTnuYLURQdWGR_h4HNWmmuKM-zgdue3thg=.832ce475-9c89-48ae-88e2-6155c7235c41@github.com>
 <Os9Qc0Q8N6tzPrwpww6omeOU4qKq4tqZCXS2MN1_vJc=.0fddcbb5-56e6-4c27-b839-12579f462115@github.com>
Message-ID: <hu1-M6J5FHsos8it_WTyop4ezyUvTMLWU0I1eDL03A0=.fb5413a8-7fd5-4d35-aeb4-932efee2c93d@github.com>

On Wed, 6 Dec 2023 17:44:24 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> LGTM, thanks!
>
>> LGTM, thanks!
> 
> Thanks Jatin!

@vamsi-parasa, sorry, I was wrong. I missed that you need to check type `bt`. Latest change is more complicated than it was before. Please revert it back (undo last change). I will test previous version 09.

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

PR Comment: https://git.openjdk.org/jdk/pull/16534#issuecomment-1843822075

From duke at openjdk.org  Wed Dec  6 23:12:13 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 6 Dec 2023 23:12:13 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v12]
In-Reply-To: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
Message-ID: <_L--_bl81TgfP1_0bLld6-xzcNqsopfL3HX3bmlbqgE=.923709b1-2e65-4659-a9cd-db4a6ac375c0@github.com>

> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX2 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
> 
> For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
> 
> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
> 
> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
> <link rel=File-List
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
> 
> 
> </head>
> 
> <body link="#0563C1" vlink="#954F72">
> 
> 
> 
> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
> -- | -- | -- | -- | --
> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
> 
> </body>
> 
> </html>
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/...

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  Revert "Change supported intrinsic check"
  
  This reverts commit 9621eb045c2958582f81ec06b237789a07481ddd.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16534/files
  - new: https://git.openjdk.org/jdk/pull/16534/files/9621eb04..eadba369

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

  Stats: 28 lines in 4 files changed: 0 ins; 20 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/16534.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16534/head:pull/16534

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

From duke at openjdk.org  Wed Dec  6 23:12:14 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 6 Dec 2023 23:12:14 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v12]
In-Reply-To: <Os9Qc0Q8N6tzPrwpww6omeOU4qKq4tqZCXS2MN1_vJc=.0fddcbb5-56e6-4c27-b839-12579f462115@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <hbnJof4NG7vsMtA6Ze5xcZ_XqyGKE4kJJ5t4mWDpYtA=.c0dc9cba-007f-4164-843e-1d74dd894501@github.com>
 <u8cnCqv4xmTnuYLURQdWGR_h4HNWmmuKM-zgdue3thg=.832ce475-9c89-48ae-88e2-6155c7235c41@github.com>
 <Os9Qc0Q8N6tzPrwpww6omeOU4qKq4tqZCXS2MN1_vJc=.0fddcbb5-56e6-4c27-b839-12579f462115@github.com>
Message-ID: <fDxbLY4lMd-F3lJEjcX7Xu2Y86cZrOASmgfu41zFkVg=.434364bd-61eb-4bc1-a6a6-3e187cf10012@github.com>

On Wed, 6 Dec 2023 17:44:24 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> LGTM, thanks!
>
>> LGTM, thanks!
> 
> Thanks Jatin!

> @vamsi-parasa, sorry, I was wrong. I missed that you need to check type `bt`. Latest change is more complicated than it was before. Please revert it back (undo last change). I will test previous version 09.
@vnkozlov 
Vladimir, please see the commit reverted in the updated changes pushed now.

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

PR Comment: https://git.openjdk.org/jdk/pull/16534#issuecomment-1843834085

From kvn at openjdk.org  Wed Dec  6 23:17:42 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 6 Dec 2023 23:17:42 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v12]
In-Reply-To: <_L--_bl81TgfP1_0bLld6-xzcNqsopfL3HX3bmlbqgE=.923709b1-2e65-4659-a9cd-db4a6ac375c0@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <_L--_bl81TgfP1_0bLld6-xzcNqsopfL3HX3bmlbqgE=.923709b1-2e65-4659-a9cd-db4a6ac375c0@github.com>
Message-ID: <NBATWRQteo2cmkX8BodUzAeXshXOVYhItQbIsTznTQ8=.dc220a47-e276-4153-9884-4ff89e8527d5@github.com>

On Wed, 6 Dec 2023 23:12:13 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX2 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
>> 
>> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
>> 
>> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId content=Excel.Sheet>
>> <meta name=Generator content="Microsoft Excel 15">
>> <link id=Main-File rel=Main-File
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
>> <link rel=File-List
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
>> 
>> 
>> </head>
>> 
>> <body link="#0563C1" vlink="#954F72">
>> 
>> 
>> 
>> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
>> -- | -- | -- | -- | --
>> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
>> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
>> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
>> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
>> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
>> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
>> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
>> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
>> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
>> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
>> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
>> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
>> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
>> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
>> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
>> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
>> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
>> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
>> 
>> </body>
>> 
>> </html>
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId cont...
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Change supported intrinsic check"
>   
>   This reverts commit 9621eb045c2958582f81ec06b237789a07481ddd.

Good. I submitted testing.

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

PR Comment: https://git.openjdk.org/jdk/pull/16534#issuecomment-1843839669

From rriggs at openjdk.org  Wed Dec  6 23:37:44 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 6 Dec 2023 23:37:44 GMT
Subject: RFR: 8321180: Condition for non-latin1 string size too large exception
 is off by one
Message-ID: <a7-9Y_75hNj9RjvAAY12LLfQFwdQ0c-YOV2LfwHgVrQ=.0463c47f-c925-4800-bef7-50cbb715405d@github.com>

In the compact string implementation of non-latin1 (UTF16) strings the length is constrained by VM implementation limit on the size a byte array that can be allocated. To produce a useful exception the implementation checks the string size against the maximum byte array size. The exception message is correct

"UTF16 String size is " + len + ", should be less than or equal to " + MAX_LENGTH

The code should match the message, otherwise the exception thrown is: 

java.lang.OutOfMemoryError: Requested array size exceeds VM limit

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

Commit messages:
 - 8321180: Condition for non-latin1 string size too large is off by one

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

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

From kvn at openjdk.org  Thu Dec  7 00:34:48 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 7 Dec 2023 00:34:48 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v12]
In-Reply-To: <fDxbLY4lMd-F3lJEjcX7Xu2Y86cZrOASmgfu41zFkVg=.434364bd-61eb-4bc1-a6a6-3e187cf10012@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <hbnJof4NG7vsMtA6Ze5xcZ_XqyGKE4kJJ5t4mWDpYtA=.c0dc9cba-007f-4164-843e-1d74dd894501@github.com>
 <u8cnCqv4xmTnuYLURQdWGR_h4HNWmmuKM-zgdue3thg=.832ce475-9c89-48ae-88e2-6155c7235c41@github.com>
 <Os9Qc0Q8N6tzPrwpww6omeOU4qKq4tqZCXS2MN1_vJc=.0fddcbb5-56e6-4c27-b839-12579f462115@github.com>
 <fDxbLY4lMd-F3lJEjcX7Xu2Y86cZrOASmgfu41zFkVg=.434364bd-61eb-4bc1-a6a6-3e187cf10012@github.com>
Message-ID: <huS-3meCchpHYnberzOmVeE5Z43hSFGdl9E4FSBRt-c=.8f87b240-cb11-48ed-89d9-fa59b675b6ca@github.com>

On Wed, 6 Dec 2023 23:09:01 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>>> LGTM, thanks!
>> 
>> Thanks Jatin!
>
>> @vamsi-parasa, sorry, I was wrong. I missed that you need to check type `bt`. Latest change is more complicated than it was before. Please revert it back (undo last change). I will test previous version 09.
> @vnkozlov 
> Vladimir, please see the commit reverted in the updated changes pushed now.

@vamsi-parasa, please, remind me which tests check that code in `libsmdsort.so` is used?

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

PR Comment: https://git.openjdk.org/jdk/pull/16534#issuecomment-1843938518

From duke at openjdk.org  Thu Dec  7 01:03:47 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Thu, 7 Dec 2023 01:03:47 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v12]
In-Reply-To: <fDxbLY4lMd-F3lJEjcX7Xu2Y86cZrOASmgfu41zFkVg=.434364bd-61eb-4bc1-a6a6-3e187cf10012@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <hbnJof4NG7vsMtA6Ze5xcZ_XqyGKE4kJJ5t4mWDpYtA=.c0dc9cba-007f-4164-843e-1d74dd894501@github.com>
 <u8cnCqv4xmTnuYLURQdWGR_h4HNWmmuKM-zgdue3thg=.832ce475-9c89-48ae-88e2-6155c7235c41@github.com>
 <Os9Qc0Q8N6tzPrwpww6omeOU4qKq4tqZCXS2MN1_vJc=.0fddcbb5-56e6-4c27-b839-12579f462115@github.com>
 <fDxbLY4lMd-F3lJEjcX7Xu2Y86cZrOASmgfu41zFkVg=.434364bd-61eb-4bc1-a6a6-3e187cf10012@github.com>
Message-ID: <wV34H4ZTDiQHvrPvLcGAoAuhEzBnElswbSNrfQoMtEk=.9f455185-4618-4fc0-a37f-cf605d765636@github.com>

On Wed, 6 Dec 2023 23:09:01 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>>> LGTM, thanks!
>> 
>> Thanks Jatin!
>
>> @vamsi-parasa, sorry, I was wrong. I missed that you need to check type `bt`. Latest change is more complicated than it was before. Please revert it back (undo last change). I will test previous version 09.
> @vnkozlov 
> Vladimir, please see the commit reverted in the updated changes pushed now.

> @vamsi-parasa, please, remind me which tests check that code in `libsmdsort.so` is used?

@vnkozlov 
Please see the tests for simd sort code in `test/jdk/java/util/Arrays/Sorting.java`

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

PR Comment: https://git.openjdk.org/jdk/pull/16534#issuecomment-1843963054

From jpai at openjdk.org  Thu Dec  7 05:08:34 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 7 Dec 2023 05:08:34 GMT
Subject: RFR: 8321470: ThreadLocal.nextHashCode can be static final [v2]
In-Reply-To: <mioVujKuoINmPzHE_cNt3Bm9IsCec0kE9XkwXLs9j-Q=.a8dfe582-b2f5-4561-92df-a4215e8e8577@github.com>
References: <7g_sH5nIxOFlqEARD90RX5X6I_flcAt0VHUtzU0Fqyo=.1dd55021-9720-40a7-ad0b-d18e07963b50@github.com>
 <mioVujKuoINmPzHE_cNt3Bm9IsCec0kE9XkwXLs9j-Q=.a8dfe582-b2f5-4561-92df-a4215e8e8577@github.com>
Message-ID: <6XkY3VWRfOrSynfqeWt8XS-cYYPAmcuCFSesakNS1Zs=.30c587fa-6c22-4f27-b6bb-ac1023a5d3e5@github.com>

On Wed, 6 Dec 2023 17:42:47 GMT, Brett Okken <duke at openjdk.org> wrote:

>> The static AtomicInteger used for the nextHashCode should be final.
>
> Brett Okken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update full name

The change looks fine to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16987#pullrequestreview-1769179862

From jpai at openjdk.org  Thu Dec  7 05:21:33 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 7 Dec 2023 05:21:33 GMT
Subject: RFR: 8320198: some reference processing tests don't wait long
 enough for reference processing to complete
In-Reply-To: <8Gi1trYkUo7x5YiAURAeH3TdzpoJchvmrHyIm2WCHKk=.18df4d76-6ad9-40f9-a079-f271b5cd7272@github.com>
References: <8Gi1trYkUo7x5YiAURAeH3TdzpoJchvmrHyIm2WCHKk=.18df4d76-6ad9-40f9-a079-f271b5cd7272@github.com>
Message-ID: <9Ahw2gNobLhzgeopsKNhqifL8KjeSZci_DCqbkhbETU=.0825e799-6cd3-4946-9ca7-0a5ba9c37ee0@github.com>

On Mon, 4 Dec 2023 17:46:18 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> This slightly increases the wait for reference processing to complete to accommodate long Xcomp compile times.  Testing is underway.

test/jdk/java/lang/Object/FinalizationOption.java line 89:

> 87:     static boolean checkFinalizerCalled(boolean expected) {
> 88:         create();
> 89:         for (int i = 0; i < 100; i++) {

Hello Tom, I think this entire loop can be replaced by using the `jdk.test.lib.util.ForceGC` utility class available in the tests. That class has the necessary knowledge of using the jtreg timeout factor. I think you could replace this loop with something like (I haven't tried it):


 ForceGC.wait(() -> finalizerWasCalled);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16956#discussion_r1418373430

From alanb at openjdk.org  Thu Dec  7 06:32:37 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 7 Dec 2023 06:32:37 GMT
Subject: RFR: 8321409: Console read line with zero out should zero out
 underlying buffer in JLine (redux)
In-Reply-To: <W8wRAZIT88cFG4AhOlRGdwHo2bovYSNIe1bk9iDP39Q=.b0d9dc4a-afa0-4ac8-8c60-890d2f10b553@github.com>
References: <W8wRAZIT88cFG4AhOlRGdwHo2bovYSNIe1bk9iDP39Q=.b0d9dc4a-afa0-4ac8-8c60-890d2f10b553@github.com>
Message-ID: <PFJgKzV_c4Wu_VdOAIPsZv1DnjpYIYk9vGrmrZs3B-w=.99f7a560-13b0-4289-a217-9a502ae32e07@github.com>

On Wed, 6 Dec 2023 21:12:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is an additional fix to JDK-8321131, where more clearing is required in JLine.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17004#pullrequestreview-1769310866

From darcy at openjdk.org  Thu Dec  7 06:33:02 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 7 Dec 2023 06:33:02 GMT
Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v7]
In-Reply-To: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
Message-ID: <gP4NSm10UOuaPUJbDAASnybpKh4T1ds-zvkjHiZH2-U=.03c17fcb-c21c-49f4-8cdd-323db3e0d6a8@github.com>

> Time to start making preparations for JDK 23.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:

 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Regenerate JDK 22 symbol files.
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Add symbol files.
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - ... and 11 more: https://git.openjdk.org/jdk/compare/632a3c56...4a871372

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

Changes: https://git.openjdk.org/jdk/pull/16505/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16505&range=06
  Stats: 4866 lines in 98 files changed: 4828 ins; 0 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/16505.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16505/head:pull/16505

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

From darcy at openjdk.org  Thu Dec  7 06:41:09 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 7 Dec 2023 06:41:09 GMT
Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v8]
In-Reply-To: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
Message-ID: <GYRRAPm9pekioWkc3IaUOzWIYFMGAcc9a2Uvkk5Q-ds=.461d318d-ad9a-45cf-a2a7-6edc17d55302@github.com>

> Time to start making preparations for JDK 23.

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

  Update copyright year.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16505/files
  - new: https://git.openjdk.org/jdk/pull/16505/files/4a871372..a1aa187c

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

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

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

From xgong at openjdk.org  Thu Dec  7 06:41:16 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 7 Dec 2023 06:41:16 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v8]
In-Reply-To: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
Message-ID: <_hHpYHZtmwFRLVj4waIAI1iWq8AINtdwx2Wtp-ZztrM=.c7f07b96-914f-4f67-a2a7-761be6e36e92@github.com>

> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
> 
> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
> 
> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
> 
> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
> 
> [1] https://github.com/openjdk/jdk/pull/3638
> [2] https://sleef.org/
> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
> [4] https://packages.debian.org/bookworm/libsleef3
> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html

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

 - Remove -fvisibility in makefile and add the attribute in source code
 - Merge branch 'jdk:master' into JDK-8312425
 - Add "--with-libsleef-lib" and "--with-libsleef-include" options
 - Separate neon and sve functions into two source files
 - Merge branch 'jdk:master' into JDK-8312425
 - Rename vmath to sleef in configure
 - Address review comments in build system
 - Add a bundled native lib in jdk as a bridge to libsleef
 - Merge 'jdk:master' into JDK-8312425
 - Disable sleef by default
 - ... and 2 more: https://git.openjdk.org/jdk/compare/6feb6794...c55357b6

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16234/files
  - new: https://git.openjdk.org/jdk/pull/16234/files/f3ff0672..c55357b6

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

  Stats: 83778 lines in 1591 files changed: 38309 ins; 39305 del; 6164 mod
  Patch: https://git.openjdk.org/jdk/pull/16234.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16234/head:pull/16234

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

From sspitsyn at openjdk.org  Thu Dec  7 07:08:47 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 7 Dec 2023 07:08:47 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable
Message-ID: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>

This fix is for JDK 23 but the intention is to back port it to 22 in RDP-1 time frame.
It is fixing a deadlock issue between `VirtualThread` class critical sections with the `interruptLock` (in methods: `unpark()`, `interrupt()`, `getAndClearInterrupt()`, `threadState()`, `toString()`), `JvmtiVTMSTransitionDisabler` and JVMTI `Suspend/Resume` mechanisms.
The deadlocking scenario is well described by Patricio in a bug report comment.
In simple words, a virtual thread should not be suspended during 'interruptLock' critical sections.

The fix is to record that a virtual thread is in a critical section (`JavaThread`'s `_in_critical_section` bit) by notifying the VM/JVMTI about begin/end of critical section.
This bit is used in `HandshakeState::get_op_for_self()` to filter out any `HandshakeOperation` if a target `JavaThread` is in a critical section.

Some of new notifications with `notifyJvmtiSync()` method is on a performance critical path. It is why this method has been intrincified.

New test was developed by Patricio:
 `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
The test is very nice as it reliably in 100% reproduces the deadlock without the fix.
The test is never failing with this fix.

Testing:
 - tested with newly added test: `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
 - tested with mach5 tiers 1-6

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

Commit messages:
 - added @summary to new test SuspendWithInterruptLock.java
 - add new test SuspendWithInterruptLock.java
 - 8311218: fatal error: stuck in JvmtiVTMSTransitionDisabler::VTMS_transition_disable

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

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

From alanb at openjdk.org  Thu Dec  7 07:44:36 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 7 Dec 2023 07:44:36 GMT
Subject: RFR: JDK-8320538: Obsolete CSS styles in collection framework
 doc-file
In-Reply-To: <dm5VZgu4Xwl_uod_KHR4-Ld9VJs5a8VVMIlV0FuN5dA=.914e6b24-4367-44bc-806f-b43c1c682224@github.com>
References: <dm5VZgu4Xwl_uod_KHR4-Ld9VJs5a8VVMIlV0FuN5dA=.914e6b24-4367-44bc-806f-b43c1c682224@github.com>
Message-ID: <M36LTjk5kxJkFz-n6DYmEdVNVxLS7ikGDALQ3HHnEr8=.232a58f9-a96a-4a14-acb7-fc99c2c1f1e4@github.com>

On Wed, 6 Dec 2023 16:22:24 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a simple change to remove a stray inline CSS element from the Collection Framework index doc file. The only thing the `a {font-weight: bold;}` rule did was to make all links in the header and footer bold as [can be seen here][1]; the three content links to the other doc files are still displayed in bold font because they are contained in `<b>` tags. The other CSS rules had no effect in the page. 
> 
> [1]: https://download.java.net/java/early_access/jdk22/docs/api/java.base/java/util/doc-files/coll-index.html
> 
> Screenshot of the fixed page:
> <img width="1082" alt="coll-framework-index" src="https://github.com/openjdk/jdk/assets/15975/0bd3b613-e535-438c-bd4d-7c8817df5702">
> 
> I also added the `<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">` meta tag which is present in all other pages (both doc-files and generated by JavaDoc).

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16997#pullrequestreview-1769396161

From pminborg at openjdk.org  Thu Dec  7 07:48:34 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 7 Dec 2023 07:48:34 GMT
Subject: RFR: 8321467: MemorySegment.setString(long, String,
 Charset) throws IAE(Misaligned access) [v2]
In-Reply-To: <jlIx8-O5dDz0dWmUF1p_DtGIfEiUEb-ud-FCMN8Qcjw=.27460ae1-e281-48ab-9192-08bc93781eea@github.com>
References: <BQJBLeTlmzWI3QiroA-zIql4DXSQFJVrFHxn4Nd0F-Q=.d72cf232-0efe-4284-8857-863cb991526b@github.com>
 <jlIx8-O5dDz0dWmUF1p_DtGIfEiUEb-ud-FCMN8Qcjw=.27460ae1-e281-48ab-9192-08bc93781eea@github.com>
Message-ID: <pAblAATVLdcb6F5kfGmbs0AfqjoV0PKtGRKYmHykFos=.b8fb0e20-f870-4794-8b37-ed353849c7ea@github.com>

On Wed, 6 Dec 2023 17:03:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR fixes a couple of aligned accesses when reading/writing strings. Such aligned accesses crept in when we optimized string read/write operations to work in bulk. As a result, depending on the maximum alignment constraints supported by the heap segment, some string operations might fail.
>> 
>> I've added some tests to make sure that all operations work as expected with unaligned semantics.
>> 
>> Note: I've considered inferring an alignment constraint from the provided charset, and then use aligned operations (and document that behavior), but I found that to be unsatisfactory: memory operations typically accept a layout, which allow clients to opt out from alignment checks if needed. But if we always infer an alignment constraint from the provided charset, clients would find themselves w/o an escape hatch. For this reason, I think the best way to fix this is to use unaligned operations when reading/writing the string.
>
> Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Make test more robust
>  - Simplify test

LGTM. Testing looks solid.

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

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16999#pullrequestreview-1769404275

From asotona at openjdk.org  Thu Dec  7 07:53:58 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 7 Dec 2023 07:53:58 GMT
Subject: RFR: 8320360: ClassFile.parse: Some defect class files cause
 unexpected exceptions to be thrown [v2]
In-Reply-To: <jbASOjz9CTAwfu_m0H5z3XpWmcuMmuF2aPkyjyLE7PE=.fe0e8a24-50c0-4c20-9de3-34834c8fa8c3@github.com>
References: <jbASOjz9CTAwfu_m0H5z3XpWmcuMmuF2aPkyjyLE7PE=.fe0e8a24-50c0-4c20-9de3-34834c8fa8c3@github.com>
Message-ID: <71S-mvJz6ZUKrEESzAAWbiwfs5sd0JkSTqavQtkHdfo=.f75af6fd-fb6e-4fe2-9dc1-15ca245a73f9@github.com>

> ClassFile API throws `IndexOutOfBoundsException` when classfile structure is corrupted so the parser attempts to read beyond the classfile bounds.
> General contract is that only `IllegalArgumentException` or its subclasses is expected when parser fails.
> This patch wraps `IndexOutOfBoundsExceptions` thrown from all `ClassReaderImpl.buffer` manipulations into an  `IllegalArgumentException("Reading beyond classfile bounds", iOOBECause)`.
> Relevant tests are added.
> 
> Please review.
> 
> Thanks,
> 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 three commits:

 - Merge branch 'master' into JDK-8320360-bounds
   
   # Conflicts:
   #	test/jdk/jdk/classfile/LimitsTest.java
 - added bug # to the test
 - 8320360: ClassFile.parse: Some defect class files cause unexpected exceptions to be thrown

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

Changes: https://git.openjdk.org/jdk/pull/16762/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16762&range=01
  Stats: 69 lines in 2 files changed: 47 ins; 0 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/16762.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16762/head:pull/16762

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

From pminborg at openjdk.org  Thu Dec  7 08:15:01 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 7 Dec 2023 08:15:01 GMT
Subject: RFR: 8321387: SegmentAllocator:allocateFrom(AddressLayout,
 MemorySegment) does not throw stated UnsupportedOperationException [v4]
In-Reply-To: <f7av5DIVPpT40yTe3Lsk66GxhTQCLXCoCVe1TJH9hjg=.049eba24-4bf8-4ddc-a1a0-e8db117d72b8@github.com>
References: <f7av5DIVPpT40yTe3Lsk66GxhTQCLXCoCVe1TJH9hjg=.049eba24-4bf8-4ddc-a1a0-e8db117d72b8@github.com>
Message-ID: <PWe9VKqwio0wYdKAEjbyDEvPqaFjPHKfjHAc9yiaqVM=.38f2b23d-ab08-49d4-b9ab-9a782c82a40e@github.com>

> This PR proposes to change the exception type for exceptions thrown for certain methods with a parameter of type `MemorySegment` when it is `MemorySegment::isReadOnly`. Previously an `UnsupportedOperationException` was specified but in some cases, in reality, an `IllegalArgumentException` was thrown. 
> 
> The principle used in this PR is that operations acting on an MS where the MS is `this` should throw an `UnsupportedOperationException` whereas in cases where the MS is a *parameter* an `IllegalArgumentException` should be thrown.
> 
> It should be noted that this PR retains the previous behavior for MS VarHandle access (even though the MS is a parameter to the accessor methods, the first parameter can be said to represent `this`).

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

  Disallow read only segments for SA factories

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16993/files
  - new: https://git.openjdk.org/jdk/pull/16993/files/d7b08a40..491e71fc

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

  Stats: 68 lines in 2 files changed: 22 ins; 44 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16993.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16993/head:pull/16993

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

From pminborg at openjdk.org  Thu Dec  7 08:17:37 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 7 Dec 2023 08:17:37 GMT
Subject: RFR: 8321387: SegmentAllocator:allocateFrom(AddressLayout,
 MemorySegment) does not throw stated UnsupportedOperationException [v3]
In-Reply-To: <wvBDzSgkI77yU9puqhZisitja6i30oYPm4scotWgY4g=.2f6985fc-0624-4496-9239-d6f2aecd0af7@github.com>
References: <f7av5DIVPpT40yTe3Lsk66GxhTQCLXCoCVe1TJH9hjg=.049eba24-4bf8-4ddc-a1a0-e8db117d72b8@github.com>
 <nVkeGoT3PfcoFWSwePvbl2t5-S5IEAj_JTobwWzetT0=.e9ea2b56-938d-4cb4-9266-e6300a22f76a@github.com>
 <wvBDzSgkI77yU9puqhZisitja6i30oYPm4scotWgY4g=.2f6985fc-0624-4496-9239-d6f2aecd0af7@github.com>
Message-ID: <nGny8GceL4pgmKnc8w0fjRIiDO-GlxVXOi4sfjZSCJw=.f6a1099d-d813-4cc6-aea5-ed2401d4db6b@github.com>

On Wed, 6 Dec 2023 15:36:57 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update throws docs fror SegmentAllocator
>
> src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 95:
> 
>> 93:      * @param str the Java string to be converted into a C string
>> 94:      * @return a new native segment containing the converted C string
>> 95:      * @throws IllegalArgumentException if the allocated segment is
> 
> I don't think the changes here are useful. What does it mean for an allocated segment to be read-only? I think all these conditions are tied to `prefixAllocator` blindly accepting read-only segments, which should NOT be the case. I suggest to revert all the chnages here and document (and throw) a new exception for when a prefix allocator is created from a read-only segment.

I have updated the PR according to this. It should be noted that, theoretically, it is still possible to write a bespoke `SegmentAllocator` that returns read-only segments. I think then, the user made a deliberate choice and perhaps understands the consequences.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16993#discussion_r1418543624

From pminborg at openjdk.org  Thu Dec  7 09:00:46 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 7 Dec 2023 09:00:46 GMT
Subject: RFR: 8321387: SegmentAllocator:allocateFrom(AddressLayout,
 MemorySegment) does not throw stated UnsupportedOperationException [v5]
In-Reply-To: <f7av5DIVPpT40yTe3Lsk66GxhTQCLXCoCVe1TJH9hjg=.049eba24-4bf8-4ddc-a1a0-e8db117d72b8@github.com>
References: <f7av5DIVPpT40yTe3Lsk66GxhTQCLXCoCVe1TJH9hjg=.049eba24-4bf8-4ddc-a1a0-e8db117d72b8@github.com>
Message-ID: <BFA7sAh-f_BfiU58ds2O4v3Nrc8ssjAdWb2vwAS3RHs=.328834b7-2326-43f5-94a8-0a5615e3c84a@github.com>

> This PR proposes to change the exception type for exceptions thrown for certain methods with a parameter of type `MemorySegment` when it is `MemorySegment::isReadOnly`. Previously an `UnsupportedOperationException` was specified but in some cases, in reality, an `IllegalArgumentException` was thrown. 
> 
> The principle used in this PR is that operations acting on an MS where the MS is `this` should throw an `UnsupportedOperationException` whereas in cases where the MS is a *parameter* an `IllegalArgumentException` should be thrown.
> 
> It should be noted that this PR retains the previous behavior for MS VarHandle access (even though the MS is a parameter to the accessor methods, the first parameter can be said to represent `this`).

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

  Revert checkAccess parameter type

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16993/files
  - new: https://git.openjdk.org/jdk/pull/16993/files/491e71fc..f674b9c6

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

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

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

From hannesw at openjdk.org  Thu Dec  7 09:26:45 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 7 Dec 2023 09:26:45 GMT
Subject: Integrated: JDK-8320538: Obsolete CSS styles in collection framework
 doc-file
In-Reply-To: <dm5VZgu4Xwl_uod_KHR4-Ld9VJs5a8VVMIlV0FuN5dA=.914e6b24-4367-44bc-806f-b43c1c682224@github.com>
References: <dm5VZgu4Xwl_uod_KHR4-Ld9VJs5a8VVMIlV0FuN5dA=.914e6b24-4367-44bc-806f-b43c1c682224@github.com>
Message-ID: <RS5efMbUGhXyOcg9aBP9rkHL0ec5GjGMmLtGGaKzNgY=.a476c8ef-be3f-45fb-978c-49341bc92f10@github.com>

On Wed, 6 Dec 2023 16:22:24 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a simple change to remove a stray inline CSS element from the Collection Framework index doc file. The only thing the `a {font-weight: bold;}` rule did was to make all links in the header and footer bold as [can be seen here][1]; the three content links to the other doc files are still displayed in bold font because they are contained in `<b>` tags. The other CSS rules had no effect in the page. 
> 
> [1]: https://download.java.net/java/early_access/jdk22/docs/api/java.base/java/util/doc-files/coll-index.html
> 
> Screenshot of the fixed page:
> <img width="1082" alt="coll-framework-index" src="https://github.com/openjdk/jdk/assets/15975/0bd3b613-e535-438c-bd4d-7c8817df5702">
> 
> I also added the `<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">` meta tag which is present in all other pages (both doc-files and generated by JavaDoc).

This pull request has now been integrated.

Changeset: 9a87e52c
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9a87e52c0ca6754092845c8ebc9e324c58936c72
Stats:     10 lines in 1 file changed: 0 ins; 9 del; 1 mod

8320538: Obsolete CSS styles in collection framework doc-file

Reviewed-by: alanb

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

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

From xgong at openjdk.org  Thu Dec  7 09:30:01 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 7 Dec 2023 09:30:01 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v9]
In-Reply-To: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
Message-ID: <hd3QLWKom9VFSeX9AxaD6vzAN0goIoUn74UDH3cdumY=.e7c4a01c-620a-4686-be89-4ad82ba1f340@github.com>

> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
> 
> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
> 
> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
> 
> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
> 
> [1] https://github.com/openjdk/jdk/pull/3638
> [2] https://sleef.org/
> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
> [4] https://packages.debian.org/bookworm/libsleef3
> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html

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

  Fix potential attribute issue

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16234/files
  - new: https://git.openjdk.org/jdk/pull/16234/files/c55357b6..7a4be736

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

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

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

From xgong at openjdk.org  Thu Dec  7 09:30:05 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 7 Dec 2023 09:30:05 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v7]
In-Reply-To: <0ya82eFBzsE0U96QMoP7OKmd7PAvW7GFXYP_iD_HTqE=.f12ca572-4a4e-4fbd-947b-e11f0aad81a1@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <VaRAGqDPyx-9MRdtDUT1EwN2bEwJM0V3o0_AJpmNdBU=.0af098f2-aedf-43e2-a7b1-d127b02f14ba@github.com>
 <0ya82eFBzsE0U96QMoP7OKmd7PAvW7GFXYP_iD_HTqE=.f12ca572-4a4e-4fbd-947b-e11f0aad81a1@github.com>
Message-ID: <sbP1Ok5WY4IwPagSf38zMmDSs2oYs2O6uO9nC-oQVuk=.d20ad8ac-6cbb-47ae-aa88-29a4def8552f@github.com>

On Wed, 6 Dec 2023 11:46:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add "--with-libsleef-lib" and "--with-libsleef-include" options
>
> make/modules/jdk.incubator.vector/Lib.gmk line 45:
> 
>> 43:   $(eval $(call SetupJdkLibrary, BUILD_LIBVMATH, \
>> 44:       NAME := vmath, \
>> 45:       CFLAGS := $(CFLAGS_JDKLIB) $(LIBSLEEF_CFLAGS) -fvisibility=default, \
> 
> Why `-fvisibility=default`? (Sorry, only noticed this now)

Yeah. Considering all the symbols in this lib are global and need to be exported, I added this flag here instead of the source code. I'v removed this in latest commit, and added the attribute visibility in source code like other jdk code. Please help to review again. Thanks a lot!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1418458207

From ihse at openjdk.org  Thu Dec  7 09:42:45 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 7 Dec 2023 09:42:45 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v9]
In-Reply-To: <hd3QLWKom9VFSeX9AxaD6vzAN0goIoUn74UDH3cdumY=.e7c4a01c-620a-4686-be89-4ad82ba1f340@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <hd3QLWKom9VFSeX9AxaD6vzAN0goIoUn74UDH3cdumY=.e7c4a01c-620a-4686-be89-4ad82ba1f340@github.com>
Message-ID: <aZvKwyT8NMnJgFWlEbIrzO5ekyF9FRBYzHKmyEbMXQY=.de5cda35-5ac9-48fd-b733-68364cb2141b@github.com>

On Thu, 7 Dec 2023 09:30:01 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
>> 
>> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
>> 
>> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
>> 
>> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
>> 
>> [1] https://github.com/openjdk/jdk/pull/3638
>> [2] https://sleef.org/
>> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
>> [4] https://packages.debian.org/bookworm/libsleef3
>> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix potential attribute issue

Build changes finally look good. Great, actually! Thanks for persisting, despite the many rounds of review.

You will still need the 2 hotspot reviews for the hotspot part of the patch.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16234#pullrequestreview-1769660206

From shade at openjdk.org  Thu Dec  7 09:48:36 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 7 Dec 2023 09:48:36 GMT
Subject: RFR: 8321470: ThreadLocal.nextHashCode can be static final [v2]
In-Reply-To: <mioVujKuoINmPzHE_cNt3Bm9IsCec0kE9XkwXLs9j-Q=.a8dfe582-b2f5-4561-92df-a4215e8e8577@github.com>
References: <7g_sH5nIxOFlqEARD90RX5X6I_flcAt0VHUtzU0Fqyo=.1dd55021-9720-40a7-ad0b-d18e07963b50@github.com>
 <mioVujKuoINmPzHE_cNt3Bm9IsCec0kE9XkwXLs9j-Q=.a8dfe582-b2f5-4561-92df-a4215e8e8577@github.com>
Message-ID: <leb9xis9ZwFEIs-36ylBF-uRPGPdNBeDeLbPNeBa1eg=.af5749af-06ad-46d6-b47f-9758d9f12cc5@github.com>

On Wed, 6 Dec 2023 17:42:47 GMT, Brett Okken <duke at openjdk.org> wrote:

>> The static AtomicInteger used for the nextHashCode should be final.
>
> Brett Okken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update full name

@bokken, you are good to `/integrate`.

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

PR Comment: https://git.openjdk.org/jdk/pull/16987#issuecomment-1845016772

From redestad at openjdk.org  Thu Dec  7 10:59:41 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 7 Dec 2023 10:59:41 GMT
Subject: RFR: 8321468: Remove StringUTF16::equals
Message-ID: <CySSsfGkTiz_6q09rb7VCW_rGwin9V8NN-Ugh8Wltds=.9a4652c2-4b0a-4644-8a48-f9ee6dd5abc4@github.com>

https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of `StringUTF16::equals`. At the time I did some performance verification focused on x86 showing that simplifying and only using `StringLatin1::equals` was either neutral or a win. 

I repeated this experiment recently, adding some focused tests on aarch64 where the code generation actually tries to take advantage and generate slightly more efficient code for `StringUTF16::equals`: 
https://github.com/openjdk/jdk/pull/16933#discussion_r1414118658

The indication here is that disabling use of `StringUTF16::equals` was the right choice: any effect from the low-level optimization (one less branch at the tail end) was offset by the `isLatin1()` branch and added code generation (that all gets inlined).

In a `-XX:-CompactStrings` configuration the slightly improved code generation in `StringUTF16::equals` might help, since the `isLatin1()` test and subsequent call to `StringLatin1::equals` would be DCEd. To get the best of both worlds the code in `String::equals` _could_ be sharpened so that we statically pick the best implementation based on `CompactStrings` mode (see comment below). This shows a tiny win (up to -0.2ns/op per `String::equals` on M1; netural on x86). But is all this complexity worth it for a gain that will get lost in the noise on anything realistic?

This PR instead proposes removing `StringUTF16::equals` and simplifying the mechanisms to support the `StringLatin1/UTF16::equals` pair of intrinsics in hotspot.

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

Commit messages:
 - Fix and further cleanup RISC
 - Remove StringUTF16::equals

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

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

From redestad at openjdk.org  Thu Dec  7 10:59:42 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 7 Dec 2023 10:59:42 GMT
Subject: RFR: 8321468: Remove StringUTF16::equals
In-Reply-To: <CySSsfGkTiz_6q09rb7VCW_rGwin9V8NN-Ugh8Wltds=.9a4652c2-4b0a-4644-8a48-f9ee6dd5abc4@github.com>
References: <CySSsfGkTiz_6q09rb7VCW_rGwin9V8NN-Ugh8Wltds=.9a4652c2-4b0a-4644-8a48-f9ee6dd5abc4@github.com>
Message-ID: <gSwkx2TQNZQMrIwQWNrP_A-zbYyOv3U4VHVGT2BeI1I=.cfe304a4-43d3-4939-ba82-360aae006971@github.com>

On Wed, 6 Dec 2023 14:20:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of `StringUTF16::equals`. At the time I did some performance verification focused on x86 showing that simplifying and only using `StringLatin1::equals` was either neutral or a win. 
> 
> I repeated this experiment recently, adding some focused tests on aarch64 where the code generation actually tries to take advantage and generate slightly more efficient code for `StringUTF16::equals`: 
> https://github.com/openjdk/jdk/pull/16933#discussion_r1414118658
> 
> The indication here is that disabling use of `StringUTF16::equals` was the right choice: any effect from the low-level optimization (one less branch at the tail end) was offset by the `isLatin1()` branch and added code generation (that all gets inlined).
> 
> In a `-XX:-CompactStrings` configuration the slightly improved code generation in `StringUTF16::equals` might help, since the `isLatin1()` test and subsequent call to `StringLatin1::equals` would be DCEd. To get the best of both worlds the code in `String::equals` _could_ be sharpened so that we statically pick the best implementation based on `CompactStrings` mode (see comment below). This shows a tiny win (up to -0.2ns/op per `String::equals` on M1; netural on x86). But is all this complexity worth it for a gain that will get lost in the noise on anything realistic?
> 
> This PR instead proposes removing `StringUTF16::equals` and simplifying the mechanisms to support the `StringLatin1/UTF16::equals` pair of intrinsics in hotspot.

For reference these are the microbenchmarks used in the JDK-8215017 verification experiment:


diff --git a/test/micro/org/openjdk/bench/java/lang/StringEquals.java b/test/micro/org/openjdk/bench/java/lang/StringEquals.java
index b0db6a7037e..effe855c228 100644
--- a/test/micro/org/openjdk/bench/java/lang/StringEquals.java
+++ b/test/micro/org/openjdk/bench/java/lang/StringEquals.java
@@ -43,6 +43,9 @@ public class StringEquals {
     public String test5 = new String(test4); // equal to test4, but not same
     public String test6 = new String("0123456780");
     public String test7 = new String("0123\u01FE");
+    public String test8 = new String("12\u01FE");
+    public String test9 = new String("12\u01FF");
+    public String test10 = new String("12\u01FE");

     @Benchmark
     public boolean different() {
@@ -73,5 +76,15 @@ public boolean differentCoders() {
     public boolean equalsUTF16() {
         return test5.equals(test4);
     }
+
+    @Benchmark
+    public boolean equalsUTF16_3_NE() {
+        return test8.equals(test9);
+    }
+
+    @Benchmark
+    public boolean equalsUTF16_3_EQ() {
+        return test8.equals(test10);
+    }
 }


And this is the change to `String` to get it back to pre-JDK-8215017 state:


diff --git a/src/java.base/share/classes/java/lang/String.java b/src/java.base/share/classes/java/lang/String.java
index 5869e086191..18ad0e85d33 100644
--- a/src/java.base/share/classes/java/lang/String.java
+++ b/src/java.base/share/classes/java/lang/String.java
@@ -1900,9 +1900,13 @@ public boolean equals(Object anObject) {
         if (this == anObject) {
             return true;
         }
-        return (anObject instanceof String aString)
-                && (!COMPACT_STRINGS || this.coder == aString.coder)
-                && StringLatin1.equals(value, aString.value);
+        if (anObject instanceof String aString) {
+            if (coder() == aString.coder()) {
+                return isLatin1() ? StringLatin1.equals(value, aString.value)
+                        : StringUTF16.equals(value, aString.value);
+            }
+        }
+        return false;
     }

     /**

M1 experiment with `-XX:-CompactStrings` and a patch to choose the `StringUTF16::equals` if `COMPACT_STRINGS` is false[1]:

Name                          Cnt  Base   Error   Test   Error  Unit  Change
StringEquals.equalsUTF16_3_EQ   5 1,799 ? 0,008  1,585 ? 0,009 ns/op   1,14x (p = 0,000*)
StringEquals.equalsUTF16_3_NE   5 1,622 ? 0,007  1,541 ? 0,011 ns/op   1,05x (p = 0,000*)
  * = significant


[1] 

diff --git a/src/java.base/share/classes/java/lang/String.java b/src/java.base/share/classes/java/lang/String.java
index 5869e086191..10451bda83f 100644
--- a/src/java.base/share/classes/java/lang/String.java
+++ b/src/java.base/share/classes/java/lang/String.java
@@ -1900,9 +1900,14 @@ public boolean equals(Object anObject) {
         if (this == anObject) {
             return true;
         }
-        return (anObject instanceof String aString)
-                && (!COMPACT_STRINGS || this.coder == aString.coder)
-                && StringLatin1.equals(value, aString.value);
+        if (anObject instanceof String aString) {
+            if (COMPACT_STRINGS) {
+                return this.coder == aString.coder && StringLatin1.equals(value, aString.value);
+            } else {
+                return StringUTF16.equals(value, aString.value);
+            }
+        }
+        return false;
     }

     /**


As expected this shows a tiny but measurable win on non-x86 platforms for `-CompactString` when retaining `StringUTF16::equals` and selecting it statically. For `+CompactStrings` this is performance neutral with the baseline.

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

PR Comment: https://git.openjdk.org/jdk/pull/16995#issuecomment-1845096784
PR Comment: https://git.openjdk.org/jdk/pull/16995#issuecomment-1845110919

From alanb at openjdk.org  Thu Dec  7 11:44:46 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 7 Dec 2023 11:44:46 GMT
Subject: Integrated: 8321270: Virtual Thread.yield consumes parking permit
In-Reply-To: <lO0N190PTq5-xjJV0LlgHWm8srDw2K8aC_U0E5qf4gA=.057efa94-6e79-4c76-9273-32ca1449bf84@github.com>
References: <lO0N190PTq5-xjJV0LlgHWm8srDw2K8aC_U0E5qf4gA=.057efa94-6e79-4c76-9273-32ca1449bf84@github.com>
Message-ID: <T9spTgtB2xHU8XSIV5fPfc_AodBVss3ZjHgXSti41aA=.cf915a8c-2131-4003-9395-b6c89c8ba6fc@github.com>

On Mon, 4 Dec 2023 16:08:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> When a virtual thread continues after Thread.yield it currently consumes thread's parking permit. This is an oversight, the parking permit should only be consumed when continuing after park.
> 
> The changes are straight-forward. The internal "RUNNABLE" state is replaced with UNPARKED and YIELDED state, effectively encoding the previous state. So for the most part, it's just replacing the usages of RUNNABLE. The additional states require refactoring tryGetStackTrace, this is the method that is used for Thread::getStackTrace when the virtual thread is unmounted. It is also changed to not not swallow the REE if the reesubmit fails (tryStackTrace has to resubmit as the task for the thread may run, or the thread unparked, while "suspended" and sampling its stack trace). The changes are a subset of larger changes in the loom repo, future PRs will propose to bring in other changes to get main line up to date.
> 
> For testing the existing ThreadAPI has new test cases.
> 
> Testing: test1-5. This includes the JVMTI tests as it maps the thread states to JVMTI thread states.

This pull request has now been integrated.

Changeset: 29d7a223
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/29d7a22348e43cba253d0483c4c05922368f6b8a
Stats:     158 lines in 4 files changed: 79 ins; 19 del; 60 mod

8321270: Virtual Thread.yield consumes parking permit

Reviewed-by: sspitsyn

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

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

From mcimadamore at openjdk.org  Thu Dec  7 11:48:35 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 7 Dec 2023 11:48:35 GMT
Subject: RFR: 8321387: SegmentAllocator:allocateFrom(AddressLayout,
 MemorySegment) does not throw stated UnsupportedOperationException [v5]
In-Reply-To: <BFA7sAh-f_BfiU58ds2O4v3Nrc8ssjAdWb2vwAS3RHs=.328834b7-2326-43f5-94a8-0a5615e3c84a@github.com>
References: <f7av5DIVPpT40yTe3Lsk66GxhTQCLXCoCVe1TJH9hjg=.049eba24-4bf8-4ddc-a1a0-e8db117d72b8@github.com>
 <BFA7sAh-f_BfiU58ds2O4v3Nrc8ssjAdWb2vwAS3RHs=.328834b7-2326-43f5-94a8-0a5615e3c84a@github.com>
Message-ID: <f8IR1bVeiB5sx8u5X062v5iDHx1bk7cA6pm8spwd_Mg=.d7e2fcfc-b572-4b75-b2d0-9135e490dadc@github.com>

On Thu, 7 Dec 2023 09:00:46 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to change the exception type for exceptions thrown for certain methods with a parameter of type `MemorySegment` when it is `MemorySegment::isReadOnly`. Previously an `UnsupportedOperationException` was specified but in some cases, in reality, an `IllegalArgumentException` was thrown. 
>> 
>> The principle used in this PR is that operations acting on an MS where the MS is `this` should throw an `UnsupportedOperationException` whereas in cases where the MS is a *parameter* an `IllegalArgumentException` should be thrown.
>> 
>> It should be noted that this PR retains the previous behavior for MS VarHandle access (even though the MS is a parameter to the accessor methods, the first parameter can be said to represent `this`).
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert checkAccess parameter type

Looks good!

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16993#pullrequestreview-1769982170

From mcimadamore at openjdk.org  Thu Dec  7 12:54:41 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 7 Dec 2023 12:54:41 GMT
Subject: Integrated: 8321467: MemorySegment.setString(long, String,
 Charset) throws IAE(Misaligned access)
In-Reply-To: <BQJBLeTlmzWI3QiroA-zIql4DXSQFJVrFHxn4Nd0F-Q=.d72cf232-0efe-4284-8857-863cb991526b@github.com>
References: <BQJBLeTlmzWI3QiroA-zIql4DXSQFJVrFHxn4Nd0F-Q=.d72cf232-0efe-4284-8857-863cb991526b@github.com>
Message-ID: <O1Rj-2H2_5dqg1m9HSsoxj6wKjF0-ImTkAsYhI7aLuA=.0c5a9178-72d7-4182-bb77-a79c54dafeaf@github.com>

On Wed, 6 Dec 2023 16:49:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR fixes a couple of aligned accesses when reading/writing strings. Such aligned accesses crept in when we optimized string read/write operations to work in bulk. As a result, depending on the maximum alignment constraints supported by the heap segment, some string operations might fail.
> 
> I've added some tests to make sure that all operations work as expected with unaligned semantics.
> 
> Note: I've considered inferring an alignment constraint from the provided charset, and then use aligned operations (and document that behavior), but I found that to be unsatisfactory: memory operations typically accept a layout, which allow clients to opt out from alignment checks if needed. But if we always infer an alignment constraint from the provided charset, clients would find themselves w/o an escape hatch. For this reason, I think the best way to fix this is to use unaligned operations when reading/writing the string.

This pull request has now been integrated.

Changeset: 42bb8526
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/42bb8526967ce6d74b409c0f7aa6f8580af1aaa0
Stats:     56 lines in 2 files changed: 43 ins; 6 del; 7 mod

8321467: MemorySegment.setString(long, String, Charset) throws IAE(Misaligned access)

Reviewed-by: pminborg

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

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

From duke at openjdk.org  Thu Dec  7 13:05:45 2023
From: duke at openjdk.org (Brett Okken)
Date: Thu, 7 Dec 2023 13:05:45 GMT
Subject: Integrated: 8321470: ThreadLocal.nextHashCode can be static final
In-Reply-To: <7g_sH5nIxOFlqEARD90RX5X6I_flcAt0VHUtzU0Fqyo=.1dd55021-9720-40a7-ad0b-d18e07963b50@github.com>
References: <7g_sH5nIxOFlqEARD90RX5X6I_flcAt0VHUtzU0Fqyo=.1dd55021-9720-40a7-ad0b-d18e07963b50@github.com>
Message-ID: <HjfKlFFI71rX8ODMH7nuNfshXkqwcjyd-sbqU876kw4=.048216aa-df6a-4895-aa1f-1b6cc234d109@github.com>

On Wed, 6 Dec 2023 00:52:48 GMT, Brett Okken <duke at openjdk.org> wrote:

> The static AtomicInteger used for the nextHashCode should be final.

This pull request has now been integrated.

Changeset: c42535f1
Author:    Brett Okken <brett.okken at oracle.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c42535f1110d60d1472080ad4fcadb8acbeb4c4b
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8321470: ThreadLocal.nextHashCode can be static final

Reviewed-by: shade, jpai

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

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

From alanb at openjdk.org  Thu Dec  7 15:10:49 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 7 Dec 2023 15:10:49 GMT
Subject: Integrated: 8321223: Implementation of Scoped Values (Second Preview)
In-Reply-To: <GHxmDbYHCZyBofn9smONv0FSebHOfYuLEeHzc8cLsMc=.2ad135d9-1ab1-49e3-8bf1-e9e0c0fac310@github.com>
References: <GHxmDbYHCZyBofn9smONv0FSebHOfYuLEeHzc8cLsMc=.2ad135d9-1ab1-49e3-8bf1-e9e0c0fac310@github.com>
Message-ID: <CwAbdYTWYiJZpTWI5O1I0mzOq9lLnixwaH0ICDQzFYQ=.2c3adc87-fbad-4312-b341-fe6749c64f8f@github.com>

On Sun, 3 Dec 2023 08:46:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This API is sitting out JDK 22, meaning no API/implementation changes in this PR. Some small API changes are likely for JDK 23.
> 
> For now, we just need to bump JEP number/title that shows up in the preview section of the javadoc.

This pull request has now been integrated.

Changeset: 58530f40
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/58530f4098538f490cfea58f2382d0997841c171
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8321223: Implementation of Scoped Values (Second Preview)

Reviewed-by: psandoz, mcimadamore

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

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

From duke at openjdk.org  Thu Dec  7 17:04:17 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 7 Dec 2023 17:04:17 GMT
Subject: RFR: 8321396: Retire test/jdk/java/util/zip/NoExtensionSignature.java
Message-ID: <Uk5zGrQ9KCBjcxbpERQ8MmgQb9huvh6tbKyvVcoNrNQ=.52e08c3d-ea26-4329-bcaa-7982a73ab390@github.com>

Please review this PR which suggests we retire the ZIP test `NoExtensionSignature` along with its `test.jar` test vector. 

The concern of a missing data descriptor signature is covered by the recently updated  `DataDescriptorSignatureMissing` test. That test is more complete, includes more documentation and uses a programmatically generated test vector.

One might argue that 'more tests are always better', but in this case I think the 21 year old `NoExtensionSignature` test with its binary test vector is nebulous and requires extensive analysis to understand, more so to update. I think it does not carry its weight and should be retired.

Careful analysis of the deleted `test.jar` test vector revealed that it contains a local header with non-zero `compressed size` and `uncompressed size` fields for a streaming-mode entry. `APPNOTE.TXT` mandates that when bit 3 of the general purpose bit flag is set, then these fields and the `crc` field should all be set to zero. 

By injecting assertions into `ZipInputStream.readLOC` I was able to determine that `NoExtensionSignature` is the only test currently parsing a ZIP file with such non-zero fields in streaming mode. 

Because of this, and out of caution, this PR introduces a new test `DataDescriptorIgnoreCrcAndSizeFields` which  explicitly verifies that `ZipInputStream` does not read any non-zero `crc`, `compressed size` and `uncompressed size` field values from a local header when in streaming mode. `ZipInputStream` should ignore these values and it would be good to have a test which asserts that this invariant holds even when the fields are non-zero.

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

Commit messages:
 - Rename 'nameAndContent' parameter to 'expected'
 - Retire the test NoExtensionSignature in favor of DataDescriptorSignatureMissing. Introduce the new test DataDescriptorIgnoreCrcAndSizeFields covering unrelated aspects implicitly tested by NoExtensionSignature.

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

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

From darcy at openjdk.org  Thu Dec  7 17:04:41 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 7 Dec 2023 17:04:41 GMT
Subject: Integrated: JDK-8319413: Start of release updates for JDK 23
In-Reply-To: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
Message-ID: <zmVMgvlrXfVNIim6gb1ZSPp2jteSr8-AwHK01zktclc=.fa0c0145-9b1e-42c0-86ca-8b677f55f07b@github.com>

On Fri, 3 Nov 2023 23:42:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Time to start making preparations for JDK 23.

This pull request has now been integrated.

Changeset: 519ecd35
Author:    Joe Darcy <darcy at openjdk.org>
Committer: Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/519ecd352a66633589f160db7390647d90e36b99
Stats:     4872 lines in 98 files changed: 4828 ins; 0 del; 44 mod

8319413: Start of release updates for JDK 23
8319414: Add SourceVersion.RELEASE_23
8319416: Add source 23 and target 23 to javac

Reviewed-by: iris, erikj, alanb, vromero

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

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

From never at openjdk.org  Thu Dec  7 17:08:51 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Thu, 7 Dec 2023 17:08:51 GMT
Subject: RFR: 8320198: some reference processing tests don't wait long
 enough for reference processing to complete
In-Reply-To: <9Ahw2gNobLhzgeopsKNhqifL8KjeSZci_DCqbkhbETU=.0825e799-6cd3-4946-9ca7-0a5ba9c37ee0@github.com>
References: <8Gi1trYkUo7x5YiAURAeH3TdzpoJchvmrHyIm2WCHKk=.18df4d76-6ad9-40f9-a079-f271b5cd7272@github.com>
 <9Ahw2gNobLhzgeopsKNhqifL8KjeSZci_DCqbkhbETU=.0825e799-6cd3-4946-9ca7-0a5ba9c37ee0@github.com>
Message-ID: <imtnfJlYR_xQnsghP_I5lVLhNt6i9NL7KQIAHjmcDHo=.34a01a68-4e56-469f-b035-4be429ee83b9@github.com>

On Thu, 7 Dec 2023 05:18:26 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This slightly increases the wait for reference processing to complete to accommodate long Xcomp compile times.  Testing is underway.
>
> test/jdk/java/lang/Object/FinalizationOption.java line 89:
> 
>> 87:     static boolean checkFinalizerCalled(boolean expected) {
>> 88:         create();
>> 89:         for (int i = 0; i < 100; i++) {
> 
> Hello Tom, I think this entire loop can be replaced by using the `jdk.test.lib.util.ForceGC` utility class available in the tests. That class has the necessary knowledge of using the jtreg timeout factor. I think you could replace this loop with something like (I haven't tried it):
> 
> 
>  ForceGC.wait(() -> finalizerWasCalled);

Thanks for the tip.  I'll take a look at.  Even if there isn't something that's exactly right I think having a general waitForReferenceProcessing helper would be a good idea for any tests which do this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16956#discussion_r1419305640

From duke at openjdk.org  Thu Dec  7 17:28:54 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 7 Dec 2023 17:28:54 GMT
Subject: RFR: 8321396: Retire
 test/jdk/java/util/zip/NoExtensionSignature.java
In-Reply-To: <Uk5zGrQ9KCBjcxbpERQ8MmgQb9huvh6tbKyvVcoNrNQ=.52e08c3d-ea26-4329-bcaa-7982a73ab390@github.com>
References: <Uk5zGrQ9KCBjcxbpERQ8MmgQb9huvh6tbKyvVcoNrNQ=.52e08c3d-ea26-4329-bcaa-7982a73ab390@github.com>
Message-ID: <uaiWid1RZlx56cFBzNqHYkJBx8LJKocEL-f1cJWBNsQ=.ccf8916b-5f44-45c8-a0a7-6916bc960340@github.com>

On Tue, 5 Dec 2023 15:58:14 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Please review this PR which suggests we retire the ZIP test `NoExtensionSignature` along with its `test.jar` test vector. 
> 
> The concern of a missing data descriptor signature is covered by the recently updated  `DataDescriptorSignatureMissing` test. That test is more complete, includes more documentation and uses a programmatically generated test vector.
> 
> One might argue that 'more tests are always better', but in this case I think the 21 year old `NoExtensionSignature` test with its binary test vector is nebulous and requires extensive analysis to understand, more so to update. I think it does not carry its weight and should be retired.
> 
> Careful analysis of the deleted `test.jar` test vector revealed that it contains a local header with non-zero `compressed size` and `uncompressed size` fields for a streaming-mode entry. `APPNOTE.TXT` mandates that when bit 3 of the general purpose bit flag is set, then these fields and the `crc` field should all be set to zero. 
> 
> By injecting assertions into `ZipInputStream.readLOC` I was able to determine that `NoExtensionSignature` is the only test currently parsing a ZIP file with such non-zero fields in streaming mode. 
> 
> Because of this, and out of caution, this PR introduces a new test `DataDescriptorIgnoreCrcAndSizeFields` which  explicitly verifies that `ZipInputStream` does not read any non-zero `crc`, `compressed size` and `uncompressed size` field values from a local header when in streaming mode. `ZipInputStream` should ignore these values and it would be good to have a test which asserts that this invariant holds even when the fields are non-zero.

For completeness, here is a trace of the deleted `test.zip`:


------  Local File Header  ------
000000  signature          0x04034b50     
000004  version            20             
000006  flags              0x0008         
000008  method             8              Deflated
000010  time               0x9a45         19:18:10
000012  date               0x2c47         2002-02-07
000014  crc                0x00000000     
000018  csize              2              
000022  size               2              
000026  nlen               8              
000028  elen               0              
000030  name               8 bytes        'test.txt'

------  File Data  ------
000038  data               4 bytes        

------  Data Descriptor  ------
000042  crc                0xd8932aac     
000046  csize              4              
000050  size               2              

------  Central Directory File Header  ------
000054  signature          0x02014b50     
000058  made by version    788            
000060  extract version    20             
000062  flags              0x0008         
000064  method             8              Deflated
000066  time               0x9a45         19:18:10
000068  date               0x2c47         2002-02-07
000070  crc                0xd8932aac     
000074  csize              4              
000078  size               2              
000082  diskstart          0              
000084  nlen               8              
000086  elen               0              
000088  clen               0              
000090  iattr              0x00           
000092  eattr              0x81b60000     
000096  loc offset         0              
000100  name               8 bytes        'test.txt'

------  End of Central Directory  ------
000108  signature          0x06054b50     
000112  this disk          0              
000114  cen disk           0              
000116  entries disk       1              
000118  entries total      1              
000120  cen size           54             
000124  cen offset         54             
000128  clen               0

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

PR Comment: https://git.openjdk.org/jdk/pull/16975#issuecomment-1845780545

From lancea at openjdk.org  Thu Dec  7 18:17:40 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 7 Dec 2023 18:17:40 GMT
Subject: RFR: 8321396: Retire
 test/jdk/java/util/zip/NoExtensionSignature.java
In-Reply-To: <Uk5zGrQ9KCBjcxbpERQ8MmgQb9huvh6tbKyvVcoNrNQ=.52e08c3d-ea26-4329-bcaa-7982a73ab390@github.com>
References: <Uk5zGrQ9KCBjcxbpERQ8MmgQb9huvh6tbKyvVcoNrNQ=.52e08c3d-ea26-4329-bcaa-7982a73ab390@github.com>
Message-ID: <cTP_tF9IlNaExCz-O1g2i31Qhj8sqtZK1qMELFX_L6w=.966a4145-f416-45b8-92f1-d1eef0a25159@github.com>

On Tue, 5 Dec 2023 15:58:14 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Please review this PR which suggests we retire the ZIP test `NoExtensionSignature` along with its `test.jar` test vector.
> 
> The concern of a missing data descriptor signature is covered by the recently updated `DataDescriptorSignatureMissing` test. That test is more complete, includes more documentation and uses a programmatically generated test vector.


Eirik,  Could you add a reference to  [PR 12959](https://github.com/openjdk/jdk/pull/12959/) or to [JDK-8303920](https://bugs.openjdk.org/browse/JDK-8303920) in the above

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

PR Comment: https://git.openjdk.org/jdk/pull/16975#issuecomment-1845874650

From duke at openjdk.org  Thu Dec  7 18:22:03 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 7 Dec 2023 18:22:03 GMT
Subject: RFR: 8321396: Retire
 test/jdk/java/util/zip/NoExtensionSignature.java
In-Reply-To: <cTP_tF9IlNaExCz-O1g2i31Qhj8sqtZK1qMELFX_L6w=.966a4145-f416-45b8-92f1-d1eef0a25159@github.com>
References: <Uk5zGrQ9KCBjcxbpERQ8MmgQb9huvh6tbKyvVcoNrNQ=.52e08c3d-ea26-4329-bcaa-7982a73ab390@github.com>
 <cTP_tF9IlNaExCz-O1g2i31Qhj8sqtZK1qMELFX_L6w=.966a4145-f416-45b8-92f1-d1eef0a25159@github.com>
Message-ID: <IY_tGhfoAWwTgxWDIecB8Akw2azAM_nlDt2nOxZ_CUs=.ef2ceeec-d031-4f24-86a0-56cb2231febc@github.com>

On Thu, 7 Dec 2023 18:14:59 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Eirik, Could you add a reference to [PR 12959](https://github.com/openjdk/jdk/pull/12959/) or to [JDK-8303920](https://bugs.openjdk.org/browse/JDK-8303920) in the above

Thanks, that makes sense!

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

PR Comment: https://git.openjdk.org/jdk/pull/16975#issuecomment-1845880582

From naoto at openjdk.org  Thu Dec  7 19:48:50 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 7 Dec 2023 19:48:50 GMT
Subject: Integrated: 8321409: Console read line with zero out should zero out
 underlying buffer in JLine (redux)
In-Reply-To: <W8wRAZIT88cFG4AhOlRGdwHo2bovYSNIe1bk9iDP39Q=.b0d9dc4a-afa0-4ac8-8c60-890d2f10b553@github.com>
References: <W8wRAZIT88cFG4AhOlRGdwHo2bovYSNIe1bk9iDP39Q=.b0d9dc4a-afa0-4ac8-8c60-890d2f10b553@github.com>
Message-ID: <nBPK0uFYW279VbRgG5bFw82lgEEWonKwmodGsVjc83I=.a6e54a6f-6634-42e0-8faa-2d5ded95b97e@github.com>

On Wed, 6 Dec 2023 21:12:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is an additional fix to JDK-8321131, where more clearing is required in JLine.

This pull request has now been integrated.

Changeset: 4ed38f5a
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4ed38f5ad5f822ab948257ed39717ea919fd32ed
Stats:     12 lines in 3 files changed: 11 ins; 0 del; 1 mod

8321409: Console read line with zero out should zero out underlying buffer in JLine (redux)

Reviewed-by: alanb

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

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

From jlu at openjdk.org  Thu Dec  7 19:50:49 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 7 Dec 2023 19:50:49 GMT
Subject: RFR: 8321480: ISO 4217 Amendment 176 Update
Message-ID: <kLWpfbMrAiEskU8JqeFoGaEBzx1aTHI_vq5gxjjdoVw=.2b1af423-59c7-44e8-b4d4-deca303ec2a8@github.com>

Please review this PR which incorporates the ISO 4217 Amendment 176 Update. As the replacement of `ANG` to `XCG` won't occur until 2025, this change does not need to go into JDK22. `HR` was also updated to remove the past cutover dates.

An existing test in _ValidateISO4217.java_ checked that `Currency::getAvailableCurrencies` had all the expected currencies. This method returns all currencies, including ones to take place in the future (e.g. `XCG`). The expected currencies `Set` the method was test against had to be updated to also include future currencies as well.

Additionally, this change also converted a parameterized test to a normal JUnit test, due to output overflow.

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

Commit messages:
 - init

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

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

From duke at openjdk.org  Thu Dec  7 22:09:24 2023
From: duke at openjdk.org (Vladimir Yaroslavskiy)
Date: Thu, 7 Dec 2023 22:09:24 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v11]
In-Reply-To: <Gb1pFf-YBbIZdSO-XvQ54xqE5SvNezsl9WSHikEOEJA=.90ccd95f-4a79-4a3e-91a0-23eb83107937@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 <i1cu_VA2najjcZHepAbvkWGtVzuLMsdYFKssI5s-TFA=.be96a1ac-1eba-4b7f-bde9-1214082eb6c6@github.com>
 <Gb1pFf-YBbIZdSO-XvQ54xqE5SvNezsl9WSHikEOEJA=.90ccd95f-4a79-4a3e-91a0-23eb83107937@github.com>
Message-ID: <e8rv_97mAYHGXeRhI8dirZDJsn9ecO2gM91t1LCxnWI=.21859a35-93b8-449c-b4f8-d9dfc0912a7e@github.com>

On Tue, 28 Nov 2023 00:35:48 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add @SuppressWarnings (serial)
>
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
> <link rel=File-List
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
> 
> 
> 
> </head>
> 
> <body link="#0563C1" vlink="#954F72">
> 
> 
> Benchmark   (us/op) | Builder | (size) | Stock JDK     (+ AVX512 sort) | DPQS_r01     (+ AVX512 sort) | Speedup
> -- | -- | -- | -- | -- | --
> ArraysSort.Int.testSort | RANDOM | 600 | 2.256 | 1.713 | 1.32
> ArraysSort.Int.testSort | RANDOM | 9000 | 41.457 | 38.316 | 1.08
> ArraysSort.Int.testSort | RANDOM | 20000 | 98.448 | 86.376 | 1.14
> ArraysSort.Int.testSort | RANDOM | 400000 | 2820.939 | 2792.333 | 1.01
> ArraysSort.Int.testSort | RANDOM | 3000000 | 23426.411 | 23711.885 | 0.99
> ArraysSort.Int.testSort | REPEATED | 600 | 1.032 | 0.859 | 1.20
> ArraysSort.Int.testSort | REPEATED | 9000 | 5.114 | 5.014 | 1.02
> ArraysSort.Int.testSort | REPEATED | 20000 | 10.3 | 9.532 | 1.08
> ArraysSort.Int.testSort | REPEATED | 400000 | 210.742 | 235.281 | 0.90
> ArraysSort.Int.testSort | REPEATED | 3000000 | 1948.589 | 1955.258 | 1.00
> ArraysSort.Int.testSort | STAGGER | 600 | 2.125 | 2.157 | 0.99
> ArraysSort.Int.testSort | STAGGER | 9000 | 29.86 | 29.931 | 1.00
> ArraysSort.Int.testSort | STAGGER | 20000 | 67.096 | 66.543 | 1.01
> ArraysSort.Int.testSort | STAGGER | 400000 | 1247.53 | 1224.999 | 1.02
> ArraysSort.Int.testSort | STAGGER | 3000000 | 9435.404 | 9495.189 | 0.99
> ArraysSort.Int.testSort | SHUFFLE | 600 | 2.701 | 1.64 | 1.65
> ArraysSort.Int.testSort | SHUFFLE | 9000 | 38.976 | 34.201 | 1.14
> ArraysSort.Int.testSort | SHUFFLE | 20000 | 96.399 | 79.616 | 1.21
> ArraysSort.Int.testSort | SHUFFLE | 400000 | 2566.338 | 2436.271 | 1.05
> ArraysSort.Int.testSort | SHUFFLE | 3000000 | 20835.935 | 20071.12 | 1.04
> 
> 
> 
> </body>
> 
> </html>

Hello Vamsi (@vamsi-parasa),

Did you have a chance to run benchmarking?

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

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1846182446

From duke at openjdk.org  Thu Dec  7 22:14:24 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Thu, 7 Dec 2023 22:14:24 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v11]
In-Reply-To: <e8rv_97mAYHGXeRhI8dirZDJsn9ecO2gM91t1LCxnWI=.21859a35-93b8-449c-b4f8-d9dfc0912a7e@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 <i1cu_VA2najjcZHepAbvkWGtVzuLMsdYFKssI5s-TFA=.be96a1ac-1eba-4b7f-bde9-1214082eb6c6@github.com>
 <Gb1pFf-YBbIZdSO-XvQ54xqE5SvNezsl9WSHikEOEJA=.90ccd95f-4a79-4a3e-91a0-23eb83107937@github.com>
 <e8rv_97mAYHGXeRhI8dirZDJsn9ecO2gM91t1LCxnWI=.21859a35-93b8-449c-b4f8-d9dfc0912a7e@github.com>
Message-ID: <YWMLD2h61ydTBKL1XjSae71BbZyDGSZa7VxLWPlCZs0=.4978fb5b-f130-484f-9e2c-9b9f16286f9d@github.com>

On Thu, 7 Dec 2023 22:06:14 GMT, Vladimir Yaroslavskiy <duke at openjdk.org> wrote:

>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId content=Excel.Sheet>
>> <meta name=Generator content="Microsoft Excel 15">
>> <link id=Main-File rel=Main-File
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
>> <link rel=File-List
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
>> 
>> 
>> 
>> </head>
>> 
>> <body link="#0563C1" vlink="#954F72">
>> 
>> 
>> Benchmark   (us/op) | Builder | (size) | Stock JDK     (+ AVX512 sort) | DPQS_r01     (+ AVX512 sort) | Speedup
>> -- | -- | -- | -- | -- | --
>> ArraysSort.Int.testSort | RANDOM | 600 | 2.256 | 1.713 | 1.32
>> ArraysSort.Int.testSort | RANDOM | 9000 | 41.457 | 38.316 | 1.08
>> ArraysSort.Int.testSort | RANDOM | 20000 | 98.448 | 86.376 | 1.14
>> ArraysSort.Int.testSort | RANDOM | 400000 | 2820.939 | 2792.333 | 1.01
>> ArraysSort.Int.testSort | RANDOM | 3000000 | 23426.411 | 23711.885 | 0.99
>> ArraysSort.Int.testSort | REPEATED | 600 | 1.032 | 0.859 | 1.20
>> ArraysSort.Int.testSort | REPEATED | 9000 | 5.114 | 5.014 | 1.02
>> ArraysSort.Int.testSort | REPEATED | 20000 | 10.3 | 9.532 | 1.08
>> ArraysSort.Int.testSort | REPEATED | 400000 | 210.742 | 235.281 | 0.90
>> ArraysSort.Int.testSort | REPEATED | 3000000 | 1948.589 | 1955.258 | 1.00
>> ArraysSort.Int.testSort | STAGGER | 600 | 2.125 | 2.157 | 0.99
>> ArraysSort.Int.testSort | STAGGER | 9000 | 29.86 | 29.931 | 1.00
>> ArraysSort.Int.testSort | STAGGER | 20000 | 67.096 | 66.543 | 1.01
>> ArraysSort.Int.testSort | STAGGER | 400000 | 1247.53 | 1224.999 | 1.02
>> ArraysSort.Int.testSort | STAGGER | 3000000 | 9435.404 | 9495.189 | 0.99
>> ArraysSort.Int.testSort | SHUFFLE | 600 | 2.701 | 1.64 | 1.65
>> ArraysSort.Int.testSort | SHUFFLE | 9000 | 38.976 | 34.201 | 1.14
>> ArraysSort.Int.testSort | SHUFFLE | 20000 | 96.399 | 79.616 | 1.21
>> ArraysSort.Int.testSort | SHUFFLE | 400000 | 2566.338 | 2436.271 | 1.05
>> ArraysSort.Int.testSort | SHUFFLE | 3000000 | 20835.935 | 20071.12 | 1.04
>> 
>> 
>> 
>> </body>
>> 
>> </html>
>
> Hello Vamsi (@vamsi-parasa),
> 
> Did you have a chance to run benchmarking?

Hello Vladimir (@iaroslavski),

Will provide the data by EOD Friday (US Pacific time). 
Had to wrap up some important things at work as I'll be going on a winter vacation for 4 weeks starting from Monday.
Thanks for understanding!

Thanks,
Vamsi

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

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1846189152

From jlu at openjdk.org  Thu Dec  7 22:15:51 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 7 Dec 2023 22:15:51 GMT
Subject: RFR: 6230751: [Fmt-Ch] Recursive MessageFormats in ChoiceFormats
 ignore indicated subformats [v4]
In-Reply-To: <7wIjtUukVVmPac0CLynJTK8zIx7Difi9122zthoFj_w=.8e65ff5d-816b-4383-b833-0df272efaede@github.com>
References: <7wIjtUukVVmPac0CLynJTK8zIx7Difi9122zthoFj_w=.8e65ff5d-816b-4383-b833-0df272efaede@github.com>
Message-ID: <fwY-rbmc0jFTiLzxc299f8BqCI_9UzDs6IDaOSHth-A=.b5508d4f-04bb-47b1-84b4-819e906bb935@github.com>

> Please review this PR which updates an incorrect code example in _java/text/ChoiceFormat_.
> 
> ChoiceFormat (and MessageFormat) provide an example of how to produce a pattern that supports singular and plural forms. The ChoiceFormat example is incorrect, as recursive MessageFormats produced by a ChoiceFormat subformat only recognize subformats defined through the MessageFormat pattern syntax, not through the subformats contained within the top level MessageFormat. 
> 
> In the original example,
> `Format[] testFormats = {fileform, null, NumberFormat.getInstance()};` could have been replaced with 
> `Format[] testFormats = {fileform, null, new ChoiceFormat("0#BROKEN")};` and the original output would have been the same.
> 
> This PR replaces the example with the one used in MessageFormat, which is correct. 
> 
> This PR also includes a drive-by fix to remove leftover `<blockquote>`s from a previous `@snippet` conversion.

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

  shorten wording

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16891/files
  - new: https://git.openjdk.org/jdk/pull/16891/files/47e91b3d..3c9a6324

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

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

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

From naoto at openjdk.org  Thu Dec  7 22:31:16 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 7 Dec 2023 22:31:16 GMT
Subject: RFR: 8321480: ISO 4217 Amendment 176 Update
In-Reply-To: <kLWpfbMrAiEskU8JqeFoGaEBzx1aTHI_vq5gxjjdoVw=.2b1af423-59c7-44e8-b4d4-deca303ec2a8@github.com>
References: <kLWpfbMrAiEskU8JqeFoGaEBzx1aTHI_vq5gxjjdoVw=.2b1af423-59c7-44e8-b4d4-deca303ec2a8@github.com>
Message-ID: <YJ3f4NQyWkLM6xaR_zIU039s-AWMaDZhXC0HXZATN04=.bec227f8-9a88-4a92-b807-9e0fc720125d@github.com>

On Thu, 7 Dec 2023 19:43:14 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which incorporates the ISO 4217 Amendment 176 Update. As the replacement of `ANG` to `XCG` won't occur until 2025, this change does not need to go into JDK22. `HR` was also updated to remove the past cutover dates.
> 
> An existing test in _ValidateISO4217.java_ checked that `Currency::getAvailableCurrencies` had all the expected currencies. This method returns all currencies, including ones to take place in the future (e.g. `XCG`). The expected currencies `Set` the method was test against had to be updated to also include future currencies as well.
> 
> Additionally, this change also converted a parameterized test to a normal JUnit test, due to output overflow.

src/java.base/share/classes/sun/util/resources/CurrencyNames.properties line 497:

> 495: xbd=European Unit of Account (XBD)
> 496: xcd=East Caribbean Dollar
> 497: xcg=Caribbean Guilder

I think `XCG=XCG` is also needed for not throwing `MissingResourceException` for `getSymbol()`

test/jdk/java/util/Currency/ValidateISO4217.java line 181:

> 179:                     // without updating ISO4217Codes
> 180:                     String futureCurr = tokens.nextToken();
> 181:                     testCurrencies.add(Currency.getInstance(futureCurr));

I'd not add the future currency, and fix it in the code not to add future currency in available currencies.

test/jdk/java/util/Currency/ValidateISO4217.java line 289:

> 287:                 assertNull(Currency.getInstance(Locale.of("", country)),
> 288:                         "Error: Currency.getInstance() for this locale should return null: " + country);
> 289:             }

What is this change for?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17023#discussion_r1419721244
PR Review Comment: https://git.openjdk.org/jdk/pull/17023#discussion_r1419722063
PR Review Comment: https://git.openjdk.org/jdk/pull/17023#discussion_r1419722636

From kvn at openjdk.org  Fri Dec  8 00:36:21 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 8 Dec 2023 00:36:21 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v12]
In-Reply-To: <_L--_bl81TgfP1_0bLld6-xzcNqsopfL3HX3bmlbqgE=.923709b1-2e65-4659-a9cd-db4a6ac375c0@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <_L--_bl81TgfP1_0bLld6-xzcNqsopfL3HX3bmlbqgE=.923709b1-2e65-4659-a9cd-db4a6ac375c0@github.com>
Message-ID: <Y7s_Omtt8q8W9rzWEypxgjVtZn3MAHfISJZgeFApL2k=.f369a72e-50d3-4ffd-a616-3210ac823d8e@github.com>

On Wed, 6 Dec 2023 23:12:13 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX2 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
>> 
>> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
>> 
>> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId content=Excel.Sheet>
>> <meta name=Generator content="Microsoft Excel 15">
>> <link id=Main-File rel=Main-File
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
>> <link rel=File-List
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
>> 
>> 
>> </head>
>> 
>> <body link="#0563C1" vlink="#954F72">
>> 
>> 
>> 
>> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
>> -- | -- | -- | -- | --
>> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
>> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
>> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
>> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
>> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
>> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
>> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
>> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
>> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
>> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
>> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
>> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
>> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
>> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
>> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
>> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
>> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
>> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
>> 
>> </body>
>> 
>> </html>
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId cont...
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Change supported intrinsic check"
>   
>   This reverts commit 9621eb045c2958582f81ec06b237789a07481ddd.

Testing have only one failure in closed tests and I need to fix it before this can be pushed.

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

PR Comment: https://git.openjdk.org/jdk/pull/16534#issuecomment-1846315767

From duke at openjdk.org  Fri Dec  8 00:36:22 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 8 Dec 2023 00:36:22 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v12]
In-Reply-To: <Y7s_Omtt8q8W9rzWEypxgjVtZn3MAHfISJZgeFApL2k=.f369a72e-50d3-4ffd-a616-3210ac823d8e@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <_L--_bl81TgfP1_0bLld6-xzcNqsopfL3HX3bmlbqgE=.923709b1-2e65-4659-a9cd-db4a6ac375c0@github.com>
 <Y7s_Omtt8q8W9rzWEypxgjVtZn3MAHfISJZgeFApL2k=.f369a72e-50d3-4ffd-a616-3210ac823d8e@github.com>
Message-ID: <YcEQlYSi5wgr6gcw7Led1o415DIIHXu6kRYL4cGndqQ=.11796f39-7161-495e-acc1-cbdbfff2a818@github.com>

On Fri, 8 Dec 2023 00:31:26 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Testing have only one failure in closed tests and I need to fix it before this can be pushed.

Thanks Vladimir for the update. Is the test failure because of this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/16534#issuecomment-1846317507

From kvn at openjdk.org  Fri Dec  8 00:47:23 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 8 Dec 2023 00:47:23 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v12]
In-Reply-To: <YcEQlYSi5wgr6gcw7Led1o415DIIHXu6kRYL4cGndqQ=.11796f39-7161-495e-acc1-cbdbfff2a818@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <_L--_bl81TgfP1_0bLld6-xzcNqsopfL3HX3bmlbqgE=.923709b1-2e65-4659-a9cd-db4a6ac375c0@github.com>
 <Y7s_Omtt8q8W9rzWEypxgjVtZn3MAHfISJZgeFApL2k=.f369a72e-50d3-4ffd-a616-3210ac823d8e@github.com>
 <YcEQlYSi5wgr6gcw7Led1o415DIIHXu6kRYL4cGndqQ=.11796f39-7161-495e-acc1-cbdbfff2a818@github.com>
Message-ID: <PXjw2KihDJ5OZNkYQ12N7O6FyZIVaj1NG_wtGZhBrFo=.3e805224-5fc1-4580-9555-de70fbbc67cf@github.com>

On Fri, 8 Dec 2023 00:33:49 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

> > Testing have only one failure in closed tests and I need to fix it before this can be pushed.
> 
> Thanks Vladimir for the update. Is the test failure because of this PR?

Yes. One of our test, which checks integrity of built JDK, is confused by changes in libsimdsort.so.

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

PR Comment: https://git.openjdk.org/jdk/pull/16534#issuecomment-1846326542

From xgong at openjdk.org  Fri Dec  8 00:53:27 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 8 Dec 2023 00:53:27 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v9]
In-Reply-To: <hd3QLWKom9VFSeX9AxaD6vzAN0goIoUn74UDH3cdumY=.e7c4a01c-620a-4686-be89-4ad82ba1f340@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <hd3QLWKom9VFSeX9AxaD6vzAN0goIoUn74UDH3cdumY=.e7c4a01c-620a-4686-be89-4ad82ba1f340@github.com>
Message-ID: <b96RhEmwIImjWS3oyk9PxePfyguzdnMH99r5ehZymyM=.713daa09-855a-48e7-9aff-af671cc947c9@github.com>

On Thu, 7 Dec 2023 09:30:01 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
>> 
>> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
>> 
>> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
>> 
>> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
>> 
>> [1] https://github.com/openjdk/jdk/pull/3638
>> [2] https://sleef.org/
>> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
>> [4] https://packages.debian.org/bookworm/libsleef3
>> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix potential attribute issue

> Build changes finally look good. Great, actually! Thanks for persisting, despite the many rounds of review.
> 
> You will still need the 2 hotspot reviews for the hotspot part of the patch.
> 
> /reviewers 3

Thanks for the review and all the comments!

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1846330893

From sspitsyn at openjdk.org  Fri Dec  8 01:16:52 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 8 Dec 2023 01:16:52 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v2]
In-Reply-To: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
Message-ID: <rFV2kG_1cw-LDPZLlFeYZd6cwCQV_JSkmqSFMm9JSKE=.a4d911c2-75b6-44a6-bdff-e29121a879b6@github.com>

> This fix is for JDK 23 but the intention is to back port it to 22 in RDP-1 time frame.
> It is fixing a deadlock issue between `VirtualThread` class critical sections with the `interruptLock` (in methods: `unpark()`, `interrupt()`, `getAndClearInterrupt()`, `threadState()`, `toString()`), `JvmtiVTMSTransitionDisabler` and JVMTI `Suspend/Resume` mechanisms.
> The deadlocking scenario is well described by Patricio in a bug report comment.
> In simple words, a virtual thread should not be suspended during 'interruptLock' critical sections.
> 
> The fix is to record that a virtual thread is in a critical section (`JavaThread`'s `_in_critical_section` bit) by notifying the VM/JVMTI about begin/end of critical section.
> This bit is used in `HandshakeState::get_op_for_self()` to filter out any `HandshakeOperation` if a target `JavaThread` is in a critical section.
> 
> Some of new notifications with `notifyJvmtiSync()` method is on a performance critical path. It is why this method has been intrincified.
> 
> New test was developed by Patricio:
>  `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
> The test is very nice as it reliably in 100% reproduces the deadlock without the fix.
> The test is never failing with this fix.
> 
> Testing:
>  - tested with newly added test: `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
>  - tested with mach5 tiers 1-6

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

 - Resolved merge conflict in VirtualThread.java
 - added @summary to new test SuspendWithInterruptLock.java
 - add new test SuspendWithInterruptLock.java
 - 8311218: fatal error: stuck in JvmtiVTMSTransitionDisabler::VTMS_transition_disable

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

Changes: https://git.openjdk.org/jdk/pull/17011/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17011&range=01
  Stats: 183 lines in 15 files changed: 178 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/17011.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17011/head:pull/17011

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

From duke at openjdk.org  Fri Dec  8 01:31:28 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 8 Dec 2023 01:31:28 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v11]
In-Reply-To: <e8rv_97mAYHGXeRhI8dirZDJsn9ecO2gM91t1LCxnWI=.21859a35-93b8-449c-b4f8-d9dfc0912a7e@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 <i1cu_VA2najjcZHepAbvkWGtVzuLMsdYFKssI5s-TFA=.be96a1ac-1eba-4b7f-bde9-1214082eb6c6@github.com>
 <Gb1pFf-YBbIZdSO-XvQ54xqE5SvNezsl9WSHikEOEJA=.90ccd95f-4a79-4a3e-91a0-23eb83107937@github.com>
 <e8rv_97mAYHGXeRhI8dirZDJsn9ecO2gM91t1LCxnWI=.21859a35-93b8-449c-b4f8-d9dfc0912a7e@github.com>
Message-ID: <m_FlD1imWi57n0EqQXsrFue-FkO4D1hIbHUI2ph5d6o=.3fcdbf05-7147-4461-8d8e-6947f6f18d62@github.com>

On Thu, 7 Dec 2023 22:06:14 GMT, Vladimir Yaroslavskiy <duke at openjdk.org> wrote:

>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId content=Excel.Sheet>
>> <meta name=Generator content="Microsoft Excel 15">
>> <link id=Main-File rel=Main-File
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
>> <link rel=File-List
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
>> 
>> 
>> 
>> </head>
>> 
>> <body link="#0563C1" vlink="#954F72">
>> 
>> 
>> Benchmark   (us/op) | Builder | (size) | Stock JDK     (+ AVX512 sort) | DPQS_r01     (+ AVX512 sort) | Speedup
>> -- | -- | -- | -- | -- | --
>> ArraysSort.Int.testSort | RANDOM | 600 | 2.256 | 1.713 | 1.32
>> ArraysSort.Int.testSort | RANDOM | 9000 | 41.457 | 38.316 | 1.08
>> ArraysSort.Int.testSort | RANDOM | 20000 | 98.448 | 86.376 | 1.14
>> ArraysSort.Int.testSort | RANDOM | 400000 | 2820.939 | 2792.333 | 1.01
>> ArraysSort.Int.testSort | RANDOM | 3000000 | 23426.411 | 23711.885 | 0.99
>> ArraysSort.Int.testSort | REPEATED | 600 | 1.032 | 0.859 | 1.20
>> ArraysSort.Int.testSort | REPEATED | 9000 | 5.114 | 5.014 | 1.02
>> ArraysSort.Int.testSort | REPEATED | 20000 | 10.3 | 9.532 | 1.08
>> ArraysSort.Int.testSort | REPEATED | 400000 | 210.742 | 235.281 | 0.90
>> ArraysSort.Int.testSort | REPEATED | 3000000 | 1948.589 | 1955.258 | 1.00
>> ArraysSort.Int.testSort | STAGGER | 600 | 2.125 | 2.157 | 0.99
>> ArraysSort.Int.testSort | STAGGER | 9000 | 29.86 | 29.931 | 1.00
>> ArraysSort.Int.testSort | STAGGER | 20000 | 67.096 | 66.543 | 1.01
>> ArraysSort.Int.testSort | STAGGER | 400000 | 1247.53 | 1224.999 | 1.02
>> ArraysSort.Int.testSort | STAGGER | 3000000 | 9435.404 | 9495.189 | 0.99
>> ArraysSort.Int.testSort | SHUFFLE | 600 | 2.701 | 1.64 | 1.65
>> ArraysSort.Int.testSort | SHUFFLE | 9000 | 38.976 | 34.201 | 1.14
>> ArraysSort.Int.testSort | SHUFFLE | 20000 | 96.399 | 79.616 | 1.21
>> ArraysSort.Int.testSort | SHUFFLE | 400000 | 2566.338 | 2436.271 | 1.05
>> ArraysSort.Int.testSort | SHUFFLE | 3000000 | 20835.935 | 20071.12 | 1.04
>> 
>> 
>> 
>> </body>
>> 
>> </html>
>
> Hello Vamsi (@vamsi-parasa),
> 
> Did you have a chance to run benchmarking?

Hi Vladimir (@iaroslavski),

Please see the data below.

Thanks,
Vamsi

<html xmlns:v="urn:schemas-microsoft-com:vml"
xmlns:o="urn:schemas-microsoft-com:office:office"
xmlns:x="urn:schemas-microsoft-com:office:excel"
xmlns="http://www.w3.org/TR/REC-html40">

<head>

<meta name=ProgId content=Excel.Sheet>
<meta name=Generator content="Microsoft Excel 15">
<link id=Main-File rel=Main-File
href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
<link rel=File-List
href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">



</head>

<body link="#0563C1" vlink="#954F72">


Benchmark (us/op) | (builder) | (size) | Stock JDK | r_02 | r_03 | r_04 | r_05 | r_06 | r_07 | r_08 | r_98 | r_99
-- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
ArraysSort.Int.testSort | RANDOM | 600 | 2.256 | 1.634 | 1.651 | 1.659 | 1.671 | 1.646 | 1.611 | 1.661 | 1.642 | 1.671
ArraysSort.Int.testSort | RANDOM | 9000 | 41.457 | 37.697 | 38.075 | 37.927 | 39.693 | 38.989 | 37.86 | 38.163 | 39.222 | 38.835
ArraysSort.Int.testSort | RANDOM | 20000 | 98.448 | 91.494 | 89.683 | 87.971 | 90.231 | 90.141 | 90.515 | 90.415 | 89.571 | 90.308
ArraysSort.Int.testSort | RANDOM | 400000 | 2820.939 | 2816.5 | 2811.334 | 2833.15 | 2802.958 | 2813.012 | 2815.24 | 2825.526 | 2801.497 | 2816.25
ArraysSort.Int.testSort | RANDOM | 3000000 | 23426.411 | 23661.09 | 23778.15 | 23748.91 | 23802.62 | 23746.3 | 23778.16 | 23631.1 | 23651.78 | 23859.91
ArraysSort.Int.testSort | REPEATED | 600 | 1.032 | 0.929 | 0.955 | 0.944 | 0.927 | 0.928 | 0.953 | 0.918 | 0.934 | 0.93
ArraysSort.Int.testSort | REPEATED | 9000 | 5.114 | 5.059 | 4.832 | 5.162 | 4.965 | 4.973 | 5.518 | 5.003 | 5.435 | 4.971
ArraysSort.Int.testSort | REPEATED | 20000 | 10.3 | 12.238 | 12.474 | 12.482 | 12.351 | 12.338 | 12.372 | 12.394 | 12.688 | 13.477
ArraysSort.Int.testSort | REPEATED | 400000 | 210.742 | 261.709 | 264.572 | 263.203 | 260.822 | 260.475 | 262.03 | 260.356 | 265.976 | 264.273
ArraysSort.Int.testSort | REPEATED | 3000000 | 1948.589 | 2062.235 | 2079.128 | 2065.445 | 2053.24 | 2076.278 | 2049.799 | 2059.1 | 2073.191 | 2075.65
ArraysSort.Int.testSort | STAGGER | 600 | 2.125 | 2.001 | 2.023 | 2.021 | 2.001 | 2.018 | 2.011 | 2.017 | 2.005 | 2.011
ArraysSort.Int.testSort | STAGGER | 9000 | 29.86 | 26.169 | 26.093 | 25.562 | 26.385 | 26.109 | 26.485 | 26.375 | 26.412 | 25.712
ArraysSort.Int.testSort | STAGGER | 20000 | 67.096 | 77.157 | 63.636 | 64.479 | 58.697 | 59.728 | 58.913 | 59.482 | 58.633 | 76.904
ArraysSort.Int.testSort | STAGGER | 400000 | 1247.53 | 1271.293 | 1236.158 | 1240.29 | 1261.469 | 1233.526 | 1153.822 | 1255.238 | 1224.071 | 1235.624
ArraysSort.Int.testSort | STAGGER | 3000000 | 9435.404 | 9612.98 | 9597.262 | 9590.393 | 9592.343 | 9616.005 | 9591.057 | 9637.881 | 9596.932 | 9570.482
ArraysSort.Int.testSort | SHUFFLE | 600 | 2.701 | 1.678 | 1.66 | 1.676 | 1.694 | 1.704 | 1.693 | 1.686 | 1.675 | 1.699
ArraysSort.Int.testSort | SHUFFLE | 9000 | 38.976 | 35.146 | 34.879 | 34.723 | 35.093 | 35.904 | 35.672 | 35.124 | 34.626 | 35.553
ArraysSort.Int.testSort | SHUFFLE | 20000 | 96.399 | 81.651 | 83.113 | 81.186 | 80.802 | 82.464 | 81.473 | 83.511 | 82.289 | 81.794
ArraysSort.Int.testSort | SHUFFLE | 400000 | 2566.338 | 2446.738 | 2424.526 | 2433.211 | 2459.019 | 2446.518 | 2450.989 | 2447.125 | 2449.441 | 2444.414
ArraysSort.Int.testSort | SHUFFLE | 3000000 | 20835.935 | 20317.16 | 20215.73 | 20079.75 | 20233.43 | 19997.91 | 20151.79 | 20244.29 | 20080.24 | 19993.81



</body>

</html>

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

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1846413441

From darcy at openjdk.org  Fri Dec  8 06:11:14 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 8 Dec 2023 06:11:14 GMT
Subject: RFR: JDK-8316708: Augment WorstCaseTests with more cases
In-Reply-To: <aYFHc-tqZuKV3cSom8J_HcLXC0oejl0ntLhQEvEt0dg=.d849594a-74e2-4e02-9c24-a1f1e98b8d7a@github.com>
References: <aYFHc-tqZuKV3cSom8J_HcLXC0oejl0ntLhQEvEt0dg=.d849594a-74e2-4e02-9c24-a1f1e98b8d7a@github.com>
Message-ID: <iKUDsB3JuEB_q4vxAP2j2RB_W0rGC1JIn8mDis6jhy0=.90c7a5c3-9285-4d74-ba35-3755e6f2e2d8@github.com>

On Fri, 22 Sep 2023 05:36:02 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> A new paper
> 
>  "Accuracy of Mathematical Functions in Single, Double, Double Extended, and Quadruple Precision"
> by Brian Gladman, Vincenzo Innocente and Paul Zimmermann
> https://members.loria.fr/PZimmermann/papers/accuracy.pdf
> 
> details the inputs with generate the worst-case observed errors in different math library implementations. The FDLIBM-related worst cases should be added to the test suite.

Still keep alive.

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

PR Comment: https://git.openjdk.org/jdk/pull/15879#issuecomment-1846597255

From alanb at openjdk.org  Fri Dec  8 06:33:16 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Dec 2023 06:33:16 GMT
Subject: RFR: 8310994: Add JFR event for selection operations
In-Reply-To: <c6WoSzZK6rgiOJwmPYTwCQk1ZIJr31CKXhjP7oD2GI4=.0526ba79-a228-4d58-9911-06315892f713@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
 <c6WoSzZK6rgiOJwmPYTwCQk1ZIJr31CKXhjP7oD2GI4=.0526ba79-a228-4d58-9911-06315892f713@github.com>
Message-ID: <eFGT4ltuYb7Rs4hf5QcNaqf4klAl1ilxfjETsPv9A8w=.1618e4ff-51ab-499c-a653-7606f2825767@github.com>

On Wed, 22 Nov 2023 12:08:08 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> It could also be interesting to provide the `timeout` that was given to the selection operation.

I've tried to work through issues, esp. around selector spinning, and being able to distinguish select from selectNow is important for all of them, so yes, the timeout is needed or else no emit when the timeout == 0 as that's the case you have to filter out when troubleshooting.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1419979779

From alanb at openjdk.org  Fri Dec  8 06:39:59 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Dec 2023 06:39:59 GMT
Subject: RFR: 8320532: Remove Thread/ThreadGroup suspend/resume [v2]
In-Reply-To: <fo-bZ3xEWhzc_uVWKgz0xC6qhgOSmMV4q1oNJLBGAAE=.fabdd0ac-7db1-4c49-975b-f357a573b20c@github.com>
References: <fo-bZ3xEWhzc_uVWKgz0xC6qhgOSmMV4q1oNJLBGAAE=.fabdd0ac-7db1-4c49-975b-f357a573b20c@github.com>
Message-ID: <SI9bdn-OkYf1RLFZ55L4jUxUg99xiDg_LGSdmJcRu2E=.3a4f863d-267d-41bf-b2fb-2ed155b42b9c@github.com>

> The deadlock prone Thread/ThreadGroup suspend/resume were deprecated since JDK 1.2, deprecated for removal in Java 14, and re-specified/degraded to throw UnsupportedOperationException unconditionally in Java 19/20.  Early in Java 23 seems a fine time to finally remove these methods.
> 
> Corpus analysis of 176 million classes in 485k artifacts found no remaining usages of ThreadGroup.suspend/resume beyond the artifacts that include a copy of java.lang.ThreadGroup (!). It found 87 remaining uses of Thread.suspend and 86 remaining usages of Thread.resume, some of these are tests.
> 
> Thread.suspend/resume have always linked to the "Java Thread Primitive Deprecation" page. This originally explained the reasons why suspend/resume were deprecated. When these methods were degraded to throw UOE we changed the text to explain why the ability to suspend or resume a thread was removed. Now we must change it again. One choice is to re-word to explain why the Java APIs were removed or why the Java APIs don't define a way to suspend/resume threads, the other choice (which I prefer) is to remove the text.
> 
> The method description of java.lang.management.ThreadInfo.isSuspended is tweaked to link to JVMTI SuspendThread instead of Thread.suspend

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

 - Update copyright year
 - Merge
 - Clarify ThreadInfo.isSuspended
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16789/files
  - new: https://git.openjdk.org/jdk/pull/16789/files/cc17ea42..517de309

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

  Stats: 106040 lines in 2348 files changed: 55620 ins; 41750 del; 8670 mod
  Patch: https://git.openjdk.org/jdk/pull/16789.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16789/head:pull/16789

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

From jpai at openjdk.org  Fri Dec  8 06:50:21 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 8 Dec 2023 06:50:21 GMT
Subject: RFR: 8320532: Remove Thread/ThreadGroup suspend/resume [v2]
In-Reply-To: <SI9bdn-OkYf1RLFZ55L4jUxUg99xiDg_LGSdmJcRu2E=.3a4f863d-267d-41bf-b2fb-2ed155b42b9c@github.com>
References: <fo-bZ3xEWhzc_uVWKgz0xC6qhgOSmMV4q1oNJLBGAAE=.fabdd0ac-7db1-4c49-975b-f357a573b20c@github.com>
 <SI9bdn-OkYf1RLFZ55L4jUxUg99xiDg_LGSdmJcRu2E=.3a4f863d-267d-41bf-b2fb-2ed155b42b9c@github.com>
Message-ID: <hxHXVEFAMvmA4kMt5wPUMpQW4TVD5t65yjeckq_mUWw=.696a317a-72ec-4d23-85b1-caa7121e6ba1@github.com>

On Fri, 8 Dec 2023 06:39:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The deadlock prone Thread/ThreadGroup suspend/resume were deprecated since JDK 1.2, deprecated for removal in Java 14, and re-specified/degraded to throw UnsupportedOperationException unconditionally in Java 19/20.  Early in Java 23 seems a fine time to finally remove these methods.
>> 
>> Corpus analysis of 176 million classes in 485k artifacts found no remaining usages of ThreadGroup.suspend/resume beyond the artifacts that include a copy of java.lang.ThreadGroup (!). It found 87 remaining uses of Thread.suspend and 86 remaining usages of Thread.resume, some of these are tests.
>> 
>> Thread.suspend/resume have always linked to the "Java Thread Primitive Deprecation" page. This originally explained the reasons why suspend/resume were deprecated. When these methods were degraded to throw UOE we changed the text to explain why the ability to suspend or resume a thread was removed. Now we must change it again. One choice is to re-word to explain why the Java APIs were removed or why the Java APIs don't define a way to suspend/resume threads, the other choice (which I prefer) is to remove the text.
>> 
>> The method description of java.lang.management.ThreadInfo.isSuspended is tweaked to link to JVMTI SuspendThread instead of Thread.suspend
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Update copyright year
>  - Merge
>  - Clarify ThreadInfo.isSuspended
>  - Initial commit

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16789#pullrequestreview-1771631210

From alanb at openjdk.org  Fri Dec  8 07:13:29 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Dec 2023 07:13:29 GMT
Subject: Integrated: 8320532: Remove Thread/ThreadGroup suspend/resume
In-Reply-To: <fo-bZ3xEWhzc_uVWKgz0xC6qhgOSmMV4q1oNJLBGAAE=.fabdd0ac-7db1-4c49-975b-f357a573b20c@github.com>
References: <fo-bZ3xEWhzc_uVWKgz0xC6qhgOSmMV4q1oNJLBGAAE=.fabdd0ac-7db1-4c49-975b-f357a573b20c@github.com>
Message-ID: <-ghU_3TzyD_yGIvb5DVotvLawh17x9VcmtJDsOIp9HA=.2bab4e1f-9733-47e5-bf1a-dacd5eaec136@github.com>

On Thu, 23 Nov 2023 09:18:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The deadlock prone Thread/ThreadGroup suspend/resume were deprecated since JDK 1.2, deprecated for removal in Java 14, and re-specified/degraded to throw UnsupportedOperationException unconditionally in Java 19/20.  Early in Java 23 seems a fine time to finally remove these methods.
> 
> Corpus analysis of 176 million classes in 485k artifacts found no remaining usages of ThreadGroup.suspend/resume beyond the artifacts that include a copy of java.lang.ThreadGroup (!). It found 87 remaining uses of Thread.suspend and 86 remaining usages of Thread.resume, some of these are tests.
> 
> Thread.suspend/resume have always linked to the "Java Thread Primitive Deprecation" page. This originally explained the reasons why suspend/resume were deprecated. When these methods were degraded to throw UOE we changed the text to explain why the ability to suspend or resume a thread was removed. Now we must change it again. One choice is to re-word to explain why the Java APIs were removed or why the Java APIs don't define a way to suspend/resume threads, the other choice (which I prefer) is to remove the text.
> 
> The method description of java.lang.management.ThreadInfo.isSuspended is tweaked to link to JVMTI SuspendThread instead of Thread.suspend

This pull request has now been integrated.

Changeset: af5c4922
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/af5c49226c3416a9c3bdde06cac2076acf9de5c3
Stats:     553 lines in 9 files changed: 116 ins; 430 del; 7 mod

8320532: Remove Thread/ThreadGroup suspend/resume

Reviewed-by: dholmes, jpai, sspitsyn, smarks

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

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

From alanb at openjdk.org  Fri Dec  8 07:43:34 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Dec 2023 07:43:34 GMT
Subject: RFR: 8320786: Remove ThreadGroup.stop [v2]
In-Reply-To: <Dqdd03-L_LXO03xjfRisn4jAvKCAIjJ6FCOfrJegh9Y=.9cffbda7-2a48-4e91-866c-1ebfae6a8c6f@github.com>
References: <Dqdd03-L_LXO03xjfRisn4jAvKCAIjJ6FCOfrJegh9Y=.9cffbda7-2a48-4e91-866c-1ebfae6a8c6f@github.com>
Message-ID: <zrgIs1eEhh2lc-lOyiP6fc_kN8X5i2H0wj_aKgOGjq8=.b785a35d-3b62-4b2c-be99-e6bca19f6e66@github.com>

> ThreadGroup.stop was deprecated since JDK 1.2, deprecated for removal in Java 18, and re-specified/degraded to throw UnsupportedOperationException unconditionally in Java 20. Early in Java 23 seems a fine time to finally remove this method. Corpus analysis of 176 million classes in 485k artifacts found residual usages in 14 artifacts, so not many.
> 
> It would be nice if we could remove Thread.stop at the same time. Sadly there are still quite a few artifacts containing code (and in some cases tests) that reference this method. We will have to come back to this in some future release.

Alan Bateman 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
 - Initial commit

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

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

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

From alanb at openjdk.org  Fri Dec  8 08:07:25 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Dec 2023 08:07:25 GMT
Subject: Integrated: 8320786: Remove ThreadGroup.stop
In-Reply-To: <Dqdd03-L_LXO03xjfRisn4jAvKCAIjJ6FCOfrJegh9Y=.9cffbda7-2a48-4e91-866c-1ebfae6a8c6f@github.com>
References: <Dqdd03-L_LXO03xjfRisn4jAvKCAIjJ6FCOfrJegh9Y=.9cffbda7-2a48-4e91-866c-1ebfae6a8c6f@github.com>
Message-ID: <rFIdWNxx7tSQWJg5Ic4YTjkyXWIJUE1zD34APvRArA8=.398d30f8-865f-461a-9c57-97475a03fbf6@github.com>

On Mon, 27 Nov 2023 16:58:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> ThreadGroup.stop was deprecated since JDK 1.2, deprecated for removal in Java 18, and re-specified/degraded to throw UnsupportedOperationException unconditionally in Java 20. Early in Java 23 seems a fine time to finally remove this method. Corpus analysis of 176 million classes in 485k artifacts found residual usages in 14 artifacts, so not many.
> 
> It would be nice if we could remove Thread.stop at the same time. Sadly there are still quite a few artifacts containing code (and in some cases tests) that reference this method. We will have to come back to this in some future release.

This pull request has now been integrated.

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

8320786: Remove ThreadGroup.stop

Reviewed-by: rriggs, dholmes, jpai

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

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

From alanb at openjdk.org  Fri Dec  8 09:43:14 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Dec 2023 09:43:14 GMT
Subject: RFR: 8316141: Improve CEN header validation checking
In-Reply-To: <UPqU1snygN84AiDbn5nxQzfsxQrovnsRuSLHpROqAUc=.63d4c018-ac1f-466f-9842-94a84e6d09fa@github.com>
References: <UPqU1snygN84AiDbn5nxQzfsxQrovnsRuSLHpROqAUc=.63d4c018-ac1f-466f-9842-94a84e6d09fa@github.com>
Message-ID: <mA-B-Jq4ymAM1fUDjWgG-X-JVttQYJQ_PfA5RJBuZYM=.e7d2200c-9569-4a93-b778-d9e7613687c9@github.com>

On Wed, 8 Nov 2023 19:59:34 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Please review this  PR which enhances the existing CEN header validation checking to ensure that the
>  size of the CEN Header + name length + comment length + extra length do not exceed 65,535 bytes per the PKWare APP.NOTE 4.4.10, 4.4.11, & 4.4.12. Also check that current CEN header will not exceed the length of the CEN array.
> 
> Mach 5 tiers 1-3 are clean with this change.

I think the zip changes are okay. As per our discussion here, the compatibility impact can be evaluated later in JDK 23 to gauge whether there it is too strict.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16570#pullrequestreview-1771978971

From jpai at openjdk.org  Fri Dec  8 10:21:17 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 8 Dec 2023 10:21:17 GMT
Subject: RFR: JDK-8319626: Override toString() for ZipFile [v7]
In-Reply-To: <Iy4p9slUnyrWD5XUd6IER-MMmX0VgMyPdV6lYPWzLq4=.6e54f547-9bce-4469-8e37-3a2be9e02ac1@github.com>
References: <UEVJDXC8Cs_RSBUEsWgmq8SPvI-T4LSydbPKr8u29iA=.fdce7d47-87a8-42ba-9cd4-119bf9023ad9@github.com>
 <Iy4p9slUnyrWD5XUd6IER-MMmX0VgMyPdV6lYPWzLq4=.6e54f547-9bce-4469-8e37-3a2be9e02ac1@github.com>
Message-ID: <0TKNGz1hOQmuTyplP7UhHD_7qV5_P0sPq5acTMXJsv0=.399049d0-79bd-48d4-8a42-ef7fbe5835e2@github.com>

On Fri, 1 Dec 2023 21:32:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319982) which overrides and provides an implementation of `toString()` in _java.util.zip.ZipFile_ (and by extension, _java.util.jar.JarFile_).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   drop additional specification

src/java.base/share/classes/java/util/zip/ZipFile.java line 494:

> 492:     @Override
> 493:     public String toString() {
> 494:         return res.zsrc.key.file.getName()

Hello Justin, relying on `res.zsrc.key.file` to get to the file name can cause troubles. For example, consider this usage (which I ran in jshell) with this proposed change in this PR:


jshell> import java.util.zip.*

jshell> ZipFile zf = new ZipFile("/tmp/workdir.zip")
zf ==> workdir.zip at 34c45dca

jshell> zf.close()

jshell> zf.toString()
|  Exception java.lang.NullPointerException: Cannot read field "key" because "this.res.zsrc" is null
|        at ZipFile.toString (ZipFile.java:494)
|        at (#4:1)



What I do here is that I call `ZipFile.toString()` after I (intentionally) close the `ZipFile`. The `toString()` call leads to `NullPointerException` because on closing the `ZipFile` instance we clean up the resource it holds on to.

I think what we can do here is, something like (the following diff was generated on top of the current state of this PR):


diff --git a/src/java.base/share/classes/java/util/zip/ZipFile.java b/src/java.base/share/classes/java/util/zip/ZipFile.java
index 67a5e65089f..2b6996294e1 100644
--- a/src/java.base/share/classes/java/util/zip/ZipFile.java
+++ b/src/java.base/share/classes/java/util/zip/ZipFile.java
@@ -95,7 +95,8 @@
  */
 public class ZipFile implements ZipConstants, Closeable {
 
-    private final String name;     // zip file name
+    private final String filePath;     // zip file path
+    private final String fileName;     // name of the file
     private volatile boolean closeRequested;
 
     // The "resource" used by this zip file that needs to be
@@ -245,7 +246,8 @@ public ZipFile(File file, int mode, Charset charset) throws IOException
         }
         Objects.requireNonNull(charset, "charset");
 
-        this.name = name;
+        this.filePath = name;
+        this.fileName = file.getName();
         long t0 = System.nanoTime();
 
         this.res = new CleanableResource(this, ZipCoder.get(charset), file, mode);
@@ -483,7 +485,7 @@ public int available() throws IOException {
      * @return the path name of the ZIP file
      */
     public String getName() {
-        return name;
+        return filePath;
     }
 
     /**
@@ -491,7 +493,7 @@ public String getName() {
      */
     @Override
     public String toString() {
-        return res.zsrc.key.file.getName()
+        return this.fileName
                 + "@" + Integer.toHexString(System.identityHashCode(this));
     }
 



The above example usage now works even after I close the ZipFile. I haven't run other tests, but given that this doesn't change any APIs or their implementation, I think the tests would run fine too.

Do you see any issues with this?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16643#discussion_r1420232060

From sspitsyn at openjdk.org  Fri Dec  8 11:54:40 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 8 Dec 2023 11:54:40 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v3]
In-Reply-To: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
Message-ID: <-3HkgdDQk9480AnHQeIxaNsqK0nVzjaf6UZJ5E9LGHo=.bdff2ed6-db98-4a77-832f-6accad54245f@github.com>

> This fix is for JDK 23 but the intention is to back port it to 22 in RDP-1 time frame.
> It is fixing a deadlock issue between `VirtualThread` class critical sections with the `interruptLock` (in methods: `unpark()`, `interrupt()`, `getAndClearInterrupt()`, `threadState()`, `toString()`), `JvmtiVTMSTransitionDisabler` and JVMTI `Suspend/Resume` mechanisms.
> The deadlocking scenario is well described by Patricio in a bug report comment.
> In simple words, a virtual thread should not be suspended during 'interruptLock' critical sections.
> 
> The fix is to record that a virtual thread is in a critical section (`JavaThread`'s `_in_critical_section` bit) by notifying the VM/JVMTI about begin/end of critical section.
> This bit is used in `HandshakeState::get_op_for_self()` to filter out any `HandshakeOperation` if a target `JavaThread` is in a critical section.
> 
> Some of new notifications with `notifyJvmtiSync()` method is on a performance critical path. It is why this method has been intrincified.
> 
> New test was developed by Patricio:
>  `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
> The test is very nice as it reliably in 100% reproduces the deadlock without the fix.
> The test is never failing with this fix.
> 
> Testing:
>  - tested with newly added test: `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
>  - tested with mach5 tiers 1-6

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

  review: (1) rename notifyJvmti method; (2) add try-final statements to VirtualThread methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17011/files
  - new: https://git.openjdk.org/jdk/pull/17011/files/ccba940d..18f1752e

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

  Stats: 80 lines in 9 files changed: 25 ins; 7 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/17011.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17011/head:pull/17011

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

From alanb at openjdk.org  Fri Dec  8 12:09:15 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Dec 2023 12:09:15 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v3]
In-Reply-To: <-3HkgdDQk9480AnHQeIxaNsqK0nVzjaf6UZJ5E9LGHo=.bdff2ed6-db98-4a77-832f-6accad54245f@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
 <-3HkgdDQk9480AnHQeIxaNsqK0nVzjaf6UZJ5E9LGHo=.bdff2ed6-db98-4a77-832f-6accad54245f@github.com>
Message-ID: <pS1TWVzQt5czKRifws8S2UgvBEQRtbxt6inw4L__KAs=.3b671378-e651-4a10-99a0-e317254a5a32@github.com>

On Fri, 8 Dec 2023 11:54:40 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fix is for JDK 23 but the intention is to back port it to 22 in RDP-1 time frame.
>> It is fixing a deadlock issue between `VirtualThread` class critical sections with the `interruptLock` (in methods: `unpark()`, `interrupt()`, `getAndClearInterrupt()`, `threadState()`, `toString()`), `JvmtiVTMSTransitionDisabler` and JVMTI `Suspend/Resume` mechanisms.
>> The deadlocking scenario is well described by Patricio in a bug report comment.
>> In simple words, a virtual thread should not be suspended during 'interruptLock' critical sections.
>> 
>> The fix is to record that a virtual thread is in a critical section (`JavaThread`'s `_in_critical_section` bit) by notifying the VM/JVMTI about begin/end of critical section.
>> This bit is used in `HandshakeState::get_op_for_self()` to filter out any `HandshakeOperation` if a target `JavaThread` is in a critical section.
>> 
>> Some of new notifications with `notifyJvmtiSync()` method is on a performance critical path. It is why this method has been intrincified.
>> 
>> New test was developed by Patricio:
>>  `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
>> The test is very nice as it reliably in 100% reproduces the deadlock without the fix.
>> The test is never failing with this fix.
>> 
>> Testing:
>>  - tested with newly added test: `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: (1) rename notifyJvmti method; (2) add try-final statements to VirtualThread methods

I chatted briefly with @sspitsyn about this. A couple of points:
- It shouldn't be necessary to touch mount/unmount as the thread identity is the carrier, not the virtual thread, when executing the "critical code".
- toggle_is_in_critical_section needs to detect reentrancy, it is otherwise too early to refactor the Java code, e.g. call threadState while holding the interrupt lock.
- All the use-sides will need to use try-finally to more reliably revert the critical section flag when rewinding.
- The naming is very problematic, we'll need to replace with methods that are clearly named enter and exit critical section. Ongoing work in this area to support monitors has to introduce some temporary pinning so there will be enter/exitCriticalSection methods, that's a better place for the JVMTI hooks.

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

PR Comment: https://git.openjdk.org/jdk/pull/17011#issuecomment-1847063362

From duke at openjdk.org  Fri Dec  8 13:23:14 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 8 Dec 2023 13:23:14 GMT
Subject: RFR: 8321396: Retire
 test/jdk/java/util/zip/NoExtensionSignature.java
In-Reply-To: <Uk5zGrQ9KCBjcxbpERQ8MmgQb9huvh6tbKyvVcoNrNQ=.52e08c3d-ea26-4329-bcaa-7982a73ab390@github.com>
References: <Uk5zGrQ9KCBjcxbpERQ8MmgQb9huvh6tbKyvVcoNrNQ=.52e08c3d-ea26-4329-bcaa-7982a73ab390@github.com>
Message-ID: <Li9WK-4MmflnLcKLSM3vsZbuQCFQOh4K-r_q-5Xb9b0=.57bbd56f-ebc8-430b-a64a-576f7a336f29@github.com>

On Tue, 5 Dec 2023 15:58:14 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Please review this PR which suggests we retire the ZIP test `NoExtensionSignature` along with its `test.jar` test vector. 
> 
> The concern of a missing data descriptor signature is covered by the recently updated  `DataDescriptorSignatureMissing` test, see #12959. That test is more complete, includes more documentation and uses a programmatically generated test vector.
> 
> One might argue that 'more tests are always better', but in this case I think the 21 year old `NoExtensionSignature` test with its binary test vector is nebulous and requires extensive analysis to understand, more so to update. I think it does not carry its weight and should be retired.
> 
> Careful analysis of the deleted `test.jar` test vector revealed that it contains a local header with non-zero `compressed size` and `uncompressed size` fields for a streaming-mode entry. `APPNOTE.TXT` mandates that when bit 3 of the general purpose bit flag is set, then these fields and the `crc` field should all be set to zero. 
> 
> By injecting assertions into `ZipInputStream.readLOC` I was able to determine that `NoExtensionSignature` is the only test currently parsing a ZIP file with such non-zero fields in streaming mode. 
> 
> Because of this, and out of caution, this PR introduces a new test `DataDescriptorIgnoreCrcAndSizeFields` which  explicitly verifies that `ZipInputStream` does not read any non-zero `crc`, `compressed size` or `uncompressed size` field values from a local header when in streaming mode. `ZipInputStream` should ignore these values and it would be good to have a test which asserts that this invariant holds even when the fields are non-zero.

Here's the relevant section from `APPNOTE.TXT`:


4.4.4 general purpose bit flag: (2 bytes)
[..]
Bit 3: If this bit is set, the fields crc-32, compressed 
       size and uncompressed size are set to zero in the 
       local header. The correct values are put in the 
       data descriptor immediately following the compressed
       data.

One could argue we should validate and throw a `ZipException` for such entries, but that is perhaps a question for another PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/16975#issuecomment-1847156258

From stsypanov at openjdk.org  Fri Dec  8 15:12:38 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 8 Dec 2023 15:12:38 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v4]
In-Reply-To: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
Message-ID: <4Q5aB_WUBnrhpke3Slf6MU-gvmcJShp63fSNBknEdIg=.d42734b0-e0aa-411d-a091-c1c3ccf7e3fa@github.com>

> It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`.
> 
> See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612

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

 - Merge branch 'master' into 8320971
 - 8320971: Add test
 - 8320971: Trust any OutputStream from java.*
 - 8320971: Use BufferedInputStream.class.getPackageName()
 - 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16879/files
  - new: https://git.openjdk.org/jdk/pull/16879/files/a77208e0..b68eeba3

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

  Stats: 92426 lines in 1894 files changed: 46037 ins; 39554 del; 6835 mod
  Patch: https://git.openjdk.org/jdk/pull/16879.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16879/head:pull/16879

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

From eastigeevich at openjdk.org  Fri Dec  8 15:19:44 2023
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Fri, 8 Dec 2023 15:19:44 GMT
Subject: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512
 [v8]
In-Reply-To: <yBk1E0UvGMs1SkRvJ4Ffw5EVjAoIISDDYtoX4bNUZqE=.54dca99d-e0c0-4ae5-bc60-6519ba695d37@github.com>
References: <XbiGOUrvZoi-2JNIMmUGYXGN9iv2jD7o3cuBrtgvyj4=.3656f9cc-7e66-45be-a5ef-35ba481129e0@github.com>
 <yBk1E0UvGMs1SkRvJ4Ffw5EVjAoIISDDYtoX4bNUZqE=.54dca99d-e0c0-4ae5-bc60-6519ba695d37@github.com>
Message-ID: <YKqmmlqFC2cU_5ngtDNOaB4zS7zxdAJTZOe6xjInCAE=.38d7f892-b1e5-4ee7-85dc-d5fa7a41d627@github.com>

On Thu, 24 Jun 2021 17:02:03 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration. Also allows for performance improvement for non-AVX-512 enabled platforms. Due to the nature of MIME-encoded inputs, modify the intrinsic signature to accept an additional parameter (isMIME) for fast-path MIME decoding.
>> 
>> A change was made to the signature of DecodeBlock in Base64.java to provide the intrinsic information as to whether MIME decoding was being done.  This allows for the intrinsic to bypass the expensive setup of zmm registers from AVX tables, knowing there may be invalid Base64 characters every 76 characters or so.  A change was also made here removing the restriction that the intrinsic must return an even multiple of 3 bytes decoded.  This implementation handles the pad characters at the end of the string and will return the actual number of characters decoded.
>> 
>> The AVX portion of this code will decode in blocks of 256 bytes per loop iteration, then in chunks of 64 bytes, followed by end fixup decoding.  The non-AVX code is an assembly-optimized version of the java DecodeBlock and behaves identically.
>> 
>> Running the Base64Decode benchmark, this change increases decode performance by an average of 2.6x with a maximum 19.7x for buffers > ~20k.  The numbers are given in the table below.
>> 
>> **Base Score** is without intrinsic support, **Optimized Score** is using this intrinsic, and **Gain** is **Base** / **Optimized**.
>> 
>> 
>> Benchmark Name | Base Score | Optimized Score | Gain
>> -- | -- | -- | --
>> testBase64Decode size 1 | 15.36 | 15.32 | 1.00
>> testBase64Decode size 3 | 17.00 | 16.72 | 1.02
>> testBase64Decode size 7 | 20.60 | 18.82 | 1.09
>> testBase64Decode size 32 | 34.21 | 26.77 | 1.28
>> testBase64Decode size 64 | 54.43 | 38.35 | 1.42
>> testBase64Decode size 80 | 66.40 | 48.34 | 1.37
>> testBase64Decode size 96 | 73.16 | 52.90 | 1.38
>> testBase64Decode size 112 | 84.93 | 51.82 | 1.64
>> testBase64Decode size 512 | 288.81 | 32.04 | 9.01
>> testBase64Decode size 1000 | 560.48 | 40.79 | 13.74
>> testBase64Decode size 20000 | 9530.28 | 483.37 | 19.72
>> testBase64Decode size 50000 | 24552.24 | 1735.07 | 14.15
>> testBase64MIMEDecode size 1 | 22.87 | 21.36 | 1.07
>> testBase64MIMEDecode size 3 | 27.79 | 25.32 | 1.10
>> testBase64MIMEDecode size 7 | 44.74 | 43.81 | 1.02
>> testBase64MIMEDecode size 32 | 142.69 | 129.56 | 1.10
>> testBase64MIMEDecode size 64 | 256.90 | 243.80 | 1.05
>> testBase64MIMEDecode size 80 | 311.60 | 310.80 | 1.00
>> testBase64MIMEDecode size...
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed Windows register stomping.

We found this optimization causes https://bugs.openjdk.org/browse/JDK-8321599

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

PR Comment: https://git.openjdk.org/jdk/pull/4368#issuecomment-1847357495

From stsypanov at openjdk.org  Fri Dec  8 15:46:31 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 8 Dec 2023 15:46:31 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v5]
In-Reply-To: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
Message-ID: <PIxhz5YwwhYz47aGphHQU7vB2wrjvLQ2ZDZAxh1zgqg=.1b7b2e40-7280-4146-8825-5f28b50704ee@github.com>

> It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`.
> 
> See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612

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

  8320971: Use same approach as BAOS

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16879/files
  - new: https://git.openjdk.org/jdk/pull/16879/files/b68eeba3..69fb33f6

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

  Stats: 18 lines in 3 files changed: 11 ins; 4 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/16879.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16879/head:pull/16879

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

From alanb at openjdk.org  Fri Dec  8 15:47:28 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Dec 2023 15:47:28 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v12]
In-Reply-To: <iHvfP1CJRkBYTMEyCGUHvsyWxPHdVp36g49nxbxZfXU=.db86d493-f32e-4faf-a3e5-cf414ac9abbb@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <iHvfP1CJRkBYTMEyCGUHvsyWxPHdVp36g49nxbxZfXU=.db86d493-f32e-4faf-a3e5-cf414ac9abbb@github.com>
Message-ID: <SgsGUJfHNA8VUNYOMq84os1Z6fd65JmoL8LzCWuZ6lo=.9f170e6b-9cd6-4311-b541-32877614d325@github.com>

On Tue, 5 Dec 2023 19:15:53 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:
> 
>  - Add @enablePreview for JImageValidator that uses classfile API
>  - Fix SystemModulesPlugin after merge
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Don't show the verbose hint when already verbose
>  - Use '_files' over '_resources' as the suffix for listing resources
>  - Remove the hidden option hint.
>    
>    Also adjust the messages being printed when performing
>    a run-time image link.
>  - Localize messages, switch expression
>  - Rename RunImageArchive => JRTArchive and RunImageLinkException => RuntimeImageLinkException
>    
>    Also moved the stamp file to jdk.jlink module. The resources files per
>    module now get unconditionally created (empty if no resources not in the
>    jimage).
>  - First round of addressing review feedback.
>    
>    - Share resource names (JlinkTask and JlinkResourcesListPlugin)
>    - Exclude resources in JlinkResourcesListPlugin the same way
>      as done for other plugins.
>  - Rename AddRunImageResourcesPlugin => JlinkResourcesListPlugin
>  - ... and 36 more: https://git.openjdk.org/jdk/compare/87516e29...a797ea69

I tried out the latest commit (a797ea69).

The output "The default module path, '$java.home/jmods' not present. Use --verbose to show the full list of plugin options applied" is bit confusing as it looks like jlink failed but it actually succeeded. Blowing away the generated image and retrying with --verbose tripped this assert

java.lang.AssertionError: handling of scratch options failed
	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.logPackagedModuleEquivalent(JlinkTask.java:675)
	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImageProvider(JlinkTask.java:581)
	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:430)
	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:302)
	at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
	at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34)
Caused by: jdk.tools.jlink.internal.TaskHelper$BadArgs: (...my-original-jdk-directory..)/build/linux-x64/images/jdk/jmods already exists
	at jdk.jlink/jdk.tools.jlink.internal.TaskHelper.newBadArgs(TaskHelper.java:730)
	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.lambda$static$12(JlinkTask.java:183)
	at jdk.jlink/jdk.tools.jlink.internal.TaskHelper$Option.process(TaskHelper.java:177)
	at jdk.jlink/jdk.tools.jlink.internal.TaskHelper$OptionsHelper.handleOptions(TaskHelper.java:600)
	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.logPackagedModuleEquivalent(JlinkTask.java:672)
	... 5 more

I haven't dug into this yet but I'm puzzled that the file path to where the original build was created is in the exception messages, is that recorded?

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

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1847408088

From duke at openjdk.org  Fri Dec  8 16:32:16 2023
From: duke at openjdk.org (ExE Boss)
Date: Fri, 8 Dec 2023 16:32:16 GMT
Subject: RFR: 8321180: Condition for non-latin1 string size too large
 exception is off by one
In-Reply-To: <a7-9Y_75hNj9RjvAAY12LLfQFwdQ0c-YOV2LfwHgVrQ=.0463c47f-c925-4800-bef7-50cbb715405d@github.com>
References: <a7-9Y_75hNj9RjvAAY12LLfQFwdQ0c-YOV2LfwHgVrQ=.0463c47f-c925-4800-bef7-50cbb715405d@github.com>
Message-ID: <zr32wTTsQ_sQ9FMPM99bJreabSZZYH73ImjV2LbC0I4=.8761db23-b906-4429-b897-d3b06697d6bf@github.com>

On Wed, 6 Dec 2023 23:31:26 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> In the compact string implementation of non-latin1 (UTF16) strings the length is constrained by VM implementation limit on the size a byte array that can be allocated. To produce a useful exception the implementation checks the string size against the maximum byte array size. The exception message is correct
> 
> "UTF16 String size is " + len + ", should be less than or equal to " + MAX_LENGTH
> 
> The code should match the message, otherwise the exception thrown is: 
> 
> java.lang.OutOfMemoryError: Requested array size exceeds VM limit

src/java.base/share/classes/java/lang/StringUTF16.java line 59:

> 57:         if (len >= MAX_LENGTH) {
> 58:             throw new OutOfMemoryError("UTF16 String size is " + len +
> 59:                                        ", should be less than or equal to " + MAX_LENGTH);

Suggestion:

                                       ", should be less than " + MAX_LENGTH);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17008#discussion_r1420747765

From lancea at openjdk.org  Fri Dec  8 16:40:27 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 8 Dec 2023 16:40:27 GMT
Subject: Integrated: 8316141: Improve CEN header validation checking
In-Reply-To: <UPqU1snygN84AiDbn5nxQzfsxQrovnsRuSLHpROqAUc=.63d4c018-ac1f-466f-9842-94a84e6d09fa@github.com>
References: <UPqU1snygN84AiDbn5nxQzfsxQrovnsRuSLHpROqAUc=.63d4c018-ac1f-466f-9842-94a84e6d09fa@github.com>
Message-ID: <kJ5xy2JB4C7Y7wRpVe0oj1Nv5s2qOVRbkhWg_idLIMo=.3f0375ee-4a37-4f45-94f8-efaca48d0ee9@github.com>

On Wed, 8 Nov 2023 19:59:34 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Please review this  PR which enhances the existing CEN header validation checking to ensure that the
>  size of the CEN Header + name length + comment length + extra length do not exceed 65,535 bytes per the PKWare APP.NOTE 4.4.10, 4.4.11, & 4.4.12. Also check that current CEN header will not exceed the length of the CEN array.
> 
> Mach 5 tiers 1-3 are clean with this change.

This pull request has now been integrated.

Changeset: 0eb299af
Author:    Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0eb299af792f95d66797e2274c359190bfd5560c
Stats:     335 lines in 4 files changed: 322 ins; 4 del; 9 mod

8316141: Improve CEN header validation checking

Reviewed-by: alanb

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

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

From duke at openjdk.org  Fri Dec  8 17:26:17 2023
From: duke at openjdk.org (Markus KARG)
Date: Fri, 8 Dec 2023 17:26:17 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v5]
In-Reply-To: <PIxhz5YwwhYz47aGphHQU7vB2wrjvLQ2ZDZAxh1zgqg=.1b7b2e40-7280-4146-8825-5f28b50704ee@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <PIxhz5YwwhYz47aGphHQU7vB2wrjvLQ2ZDZAxh1zgqg=.1b7b2e40-7280-4146-8825-5f28b50704ee@github.com>
Message-ID: <HINMdsgBdHRT1i50Ugt5NH33BHDzFfVcM3HakpKuNlQ=.5e998744-1ae7-44c3-a5f0-1e95e3348316@github.com>

On Fri, 8 Dec 2023 15:46:31 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`.
>> 
>> See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8320971: Use same approach as BAOS

src/java.base/share/classes/java/io/OutputStream.java line 212:

> 210:      * @return true if the argument of {@link #write(byte[])}} and {@link #write(byte[], int, int)}} needn't be copied
> 211:      */
> 212:     boolean trusted() {

This is a strange construction. Any subclass could simply implement this as `return true;`. Where is the guard against this, and why not doing it that way?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1420812353

From vsitnikov at openjdk.org  Fri Dec  8 17:57:17 2023
From: vsitnikov at openjdk.org (Vladimir Sitnikov)
Date: Fri, 8 Dec 2023 17:57:17 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v5]
In-Reply-To: <HINMdsgBdHRT1i50Ugt5NH33BHDzFfVcM3HakpKuNlQ=.5e998744-1ae7-44c3-a5f0-1e95e3348316@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <PIxhz5YwwhYz47aGphHQU7vB2wrjvLQ2ZDZAxh1zgqg=.1b7b2e40-7280-4146-8825-5f28b50704ee@github.com>
 <HINMdsgBdHRT1i50Ugt5NH33BHDzFfVcM3HakpKuNlQ=.5e998744-1ae7-44c3-a5f0-1e95e3348316@github.com>
Message-ID: <KVHJovfrp7aU1w9DQV5aM8sjH0RfX4ya2rg11u47Gu0=.825bbfd5-6b95-4046-bba3-15d5fa95aa5a@github.com>

On Fri, 8 Dec 2023 17:23:59 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8320971: Use same approach as BAOS
>
> src/java.base/share/classes/java/io/OutputStream.java line 212:
> 
>> 210:      * @return true if the argument of {@link #write(byte[])}} and {@link #write(byte[], int, int)}} needn't be copied
>> 211:      */
>> 212:     boolean trusted() {
> 
> This is a strange construction. Any subclass could simply implement this as `return true;`. Where is the guard against this, and why not doing it that way?

Technically speaking, `OutputStream` is an `abstract class`, so this declaration of `boolean trusted()` is a package-protected method that will be visible and overridable only within JDK itself.
However, I agree it looks suspicious.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1420846454

From alanb at openjdk.org  Fri Dec  8 18:12:16 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Dec 2023 18:12:16 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v5]
In-Reply-To: <KVHJovfrp7aU1w9DQV5aM8sjH0RfX4ya2rg11u47Gu0=.825bbfd5-6b95-4046-bba3-15d5fa95aa5a@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <PIxhz5YwwhYz47aGphHQU7vB2wrjvLQ2ZDZAxh1zgqg=.1b7b2e40-7280-4146-8825-5f28b50704ee@github.com>
 <HINMdsgBdHRT1i50Ugt5NH33BHDzFfVcM3HakpKuNlQ=.5e998744-1ae7-44c3-a5f0-1e95e3348316@github.com>
 <KVHJovfrp7aU1w9DQV5aM8sjH0RfX4ya2rg11u47Gu0=.825bbfd5-6b95-4046-bba3-15d5fa95aa5a@github.com>
Message-ID: <-PGXOsciYCdrE8FYfhCNfMqhs9sKXuk0RPU-yEM8rDM=.830dc3cd-5c96-4f61-b6d4-d12467d83cd2@github.com>

On Fri, 8 Dec 2023 17:54:21 GMT, Vladimir Sitnikov <vsitnikov at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/OutputStream.java line 212:
>> 
>>> 210:      * @return true if the argument of {@link #write(byte[])}} and {@link #write(byte[], int, int)}} needn't be copied
>>> 211:      */
>>> 212:     boolean trusted() {
>> 
>> This is a strange construction. Any subclass could simply implement this as `return true;`. Where is the guard against this, and why not doing it that way?
>
> Technically speaking, `OutputStream` is an `abstract class`, so this declaration of `boolean trusted()` is a package-protected method that will be visible and overridable only within JDK itself.
> However, I agree it looks suspicious.

The comment on this method doesn't look right. The issue for BAIS is that its lifetime may be different to the byte[] that it wraps, think about use after the BAIS has been discarded. You don't want a sink keeping a reference to the byte[] even if it doesn't scribble on it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1420861805

From duke at openjdk.org  Fri Dec  8 18:22:19 2023
From: duke at openjdk.org (Vladimir Yaroslavskiy)
Date: Fri, 8 Dec 2023 18:22:19 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v11]
In-Reply-To: <m_FlD1imWi57n0EqQXsrFue-FkO4D1hIbHUI2ph5d6o=.3fcdbf05-7147-4461-8d8e-6947f6f18d62@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 <i1cu_VA2najjcZHepAbvkWGtVzuLMsdYFKssI5s-TFA=.be96a1ac-1eba-4b7f-bde9-1214082eb6c6@github.com>
 <Gb1pFf-YBbIZdSO-XvQ54xqE5SvNezsl9WSHikEOEJA=.90ccd95f-4a79-4a3e-91a0-23eb83107937@github.com>
 <e8rv_97mAYHGXeRhI8dirZDJsn9ecO2gM91t1LCxnWI=.21859a35-93b8-449c-b4f8-d9dfc0912a7e@github.com>
 <m_FlD1imWi57n0EqQXsrFue-FkO4D1hIbHUI2ph5d6o=.3fcdbf05-7147-4461-8d8e-6947f6f18d62@github.com>
Message-ID: <fUwGlvkPYT4oiYmQOOLTr6GwrO2UYwazCAaGqNV7OnU=.19628dd7-e8cf-4dd2-ac56-3a2a560eec29@github.com>

On Fri, 8 Dec 2023 01:27:35 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> Hello Vamsi (@vamsi-parasa),
>> 
>> Did you have a chance to run benchmarking?
>
> Hi Vladimir (@iaroslavski),
> 
> Please see the data below.
> 
> Thanks,
> Vamsi
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
> <link rel=File-List
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
> 
> 
> 
> </head>
> 
> <body link="#0563C1" vlink="#954F72">
> 
> 
> Benchmark (us/op) | (builder) | (size) | Stock JDK | r_02 | r_03 | r_04 | r_05 | r_06 | r_07 | r_08 | r_98 | r_99
> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
> ArraysSort.Int.testSort | RANDOM | 600 | 2.256 | 1.634 | 1.651 | 1.659 | 1.671 | 1.646 | 1.611 | 1.661 | 1.642 | 1.671
> ArraysSort.Int.testSort | RANDOM | 9000 | 41.457 | 37.697 | 38.075 | 37.927 | 39.693 | 38.989 | 37.86 | 38.163 | 39.222 | 38.835
> ArraysSort.Int.testSort | RANDOM | 20000 | 98.448 | 91.494 | 89.683 | 87.971 | 90.231 | 90.141 | 90.515 | 90.415 | 89.571 | 90.308
> ArraysSort.Int.testSort | RANDOM | 400000 | 2820.939 | 2816.5 | 2811.334 | 2833.15 | 2802.958 | 2813.012 | 2815.24 | 2825.526 | 2801.497 | 2816.25
> ArraysSort.Int.testSort | RANDOM | 3000000 | 23426.411 | 23661.09 | 23778.15 | 23748.91 | 23802.62 | 23746.3 | 23778.16 | 23631.1 | 23651.78 | 23859.91
> ArraysSort.Int.testSort | REPEATED | 600 | 1.032 | 0.929 | 0.955 | 0.944 | 0.927 | 0.928 | 0.953 | 0.918 | 0.934 | 0.93
> ArraysSort.Int.testSort | REPEATED | 9000 | 5.114 | 5.059 | 4.832 | 5.162 | 4.965 | 4.973 | 5.518 | 5.003 | 5.435 | 4.971
> ArraysSort.Int.testSort | REPEATED | 20000 | 10.3 | 12.238 | 12.474 | 12.482 | 12.351 | 12.338 | 12.372 | 12.394 | 12.688 | 13.477
> ArraysSort.Int.testSort | REPEATED | 400000 | 210.742 | 261.709 | 264.572 | 263.203 | 260.822 | 260.475 | 262.03 | 260.356 | 265.976 | 264.273
> ArraysSort.Int.testSort | REPEATED | 3000000 | 1948.589 | 2062.235 | 2079.128 | 2065.445 | 2053.24 | 2076.278 | 2049.799 | 2059.1 | 2073.191 | 2075.65
> ArraysSort.Int.testSort | STAGGER | 600 | 2.125 | 2.001 | 2.023 | 2.021 | 2.001 | 2.018 | 2.011 | 2.017 | 2.005 | 2.011
> ArraysSort.Int.testSort | STAGGER | 9000 | 29.86 | 26.169 | 26.093 | 25.562 | 26.385 | 26.109 | 26.485 | 26.375 | 26.412 | 25.712
> ArraysSort.Int.testSort | STAGGER | 20000 | 67.096 | 77.157 | 63.636 | 64.479 | 58.697 | 59.728 | 58.91...

Thank you, Vamsi (@vamsi-parasa)
I will analyze the result

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

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1847631177

From naoto at openjdk.org  Fri Dec  8 18:50:28 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 8 Dec 2023 18:50:28 GMT
Subject: RFR: 8321206: Make Locale related system properties
 `StaticProperty` [v2]
In-Reply-To: <CcKGxJp4T09SzhWQ3TBXPqH5TBPb9GbD6QRO0opn8Pg=.3054f472-f801-4846-bbfb-5f29cc8e8512@github.com>
References: <EKzdSEIjrFq0mXKLGOdRCePeu29DWWQnpAY5FDVAK40=.3bcd4037-e3e5-4cf1-948d-665355914106@github.com>
 <CcKGxJp4T09SzhWQ3TBXPqH5TBPb9GbD6QRO0opn8Pg=.3054f472-f801-4846-bbfb-5f29cc8e8512@github.com>
Message-ID: <AuT8osz5OTTgUPjKj3dNoZY0FrleITpg0t0ANBddHn4=.bec34b03-9c0c-4c6c-8d41-f4c40165736c@github.com>

On Wed, 6 Dec 2023 20:55:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Currently, Locale-related system properties, such as `user.language` or `user.country`, are initialized when the `Locale` class is loaded. Making them static properties is safer than relying on the `Locale` class loading timing, which could potentially be changed depending on the implementation.
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Reflects review comments
>  - Merge branch 'master' into JDK-8321206-Locale-static-properties
>  - Add exclusions in cdsHeapVerifier for new StaticProperties
>  - initial commit

Thanks for the reviews. I will ask hotspot folks to rectify the reasonings in `cdsHeapVerifier.cpp` if necessary.

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

PR Comment: https://git.openjdk.org/jdk/pull/16986#issuecomment-1847661347

From naoto at openjdk.org  Fri Dec  8 18:50:29 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 8 Dec 2023 18:50:29 GMT
Subject: Integrated: 8321206: Make Locale related system properties
 `StaticProperty`
In-Reply-To: <EKzdSEIjrFq0mXKLGOdRCePeu29DWWQnpAY5FDVAK40=.3bcd4037-e3e5-4cf1-948d-665355914106@github.com>
References: <EKzdSEIjrFq0mXKLGOdRCePeu29DWWQnpAY5FDVAK40=.3bcd4037-e3e5-4cf1-948d-665355914106@github.com>
Message-ID: <0N_HoY6mfXkYgkDIqPeazGM-Pq7XEv-rB2UpdFq1JTU=.cd357314-0825-44a4-96a8-8e0cc840120e@github.com>

On Tue, 5 Dec 2023 23:04:55 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Currently, Locale-related system properties, such as `user.language` or `user.country`, are initialized when the `Locale` class is loaded. Making them static properties is safer than relying on the `Locale` class loading timing, which could potentially be changed depending on the implementation.

This pull request has now been integrated.

Changeset: 0c178beb
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0c178beb69c4c5fc3e92621340748e42d017d458
Stats:     69 lines in 3 files changed: 49 ins; 7 del; 13 mod

8321206: Make Locale related system properties `StaticProperty`

Reviewed-by: rriggs

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

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

From rgiulietti at openjdk.org  Fri Dec  8 19:35:15 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 8 Dec 2023 19:35:15 GMT
Subject: RFR: 8321180: Condition for non-latin1 string size too large
 exception is off by one
In-Reply-To: <zr32wTTsQ_sQ9FMPM99bJreabSZZYH73ImjV2LbC0I4=.8761db23-b906-4429-b897-d3b06697d6bf@github.com>
References: <a7-9Y_75hNj9RjvAAY12LLfQFwdQ0c-YOV2LfwHgVrQ=.0463c47f-c925-4800-bef7-50cbb715405d@github.com>
 <zr32wTTsQ_sQ9FMPM99bJreabSZZYH73ImjV2LbC0I4=.8761db23-b906-4429-b897-d3b06697d6bf@github.com>
Message-ID: <kZSNl0cyDPRbHVejEd_cvgg1DHnClam64o3zbBB2I18=.8e248b35-e10e-497f-9581-6fc9c82137e5@github.com>

On Fri, 8 Dec 2023 16:28:21 GMT, ExE Boss <duke at openjdk.org> wrote:

>> In the compact string implementation of non-latin1 (UTF16) strings the length is constrained by VM implementation limit on the size a byte array that can be allocated. To produce a useful exception the implementation checks the string size against the maximum byte array size. The exception message is correct
>> 
>> "UTF16 String size is " + len + ", should be less than or equal to " + MAX_LENGTH
>> 
>> The code should match the message, otherwise the exception thrown is: 
>> 
>> java.lang.OutOfMemoryError: Requested array size exceeds VM limit
>
> src/java.base/share/classes/java/lang/StringUTF16.java line 59:
> 
>> 57:         if (len >= MAX_LENGTH) {
>> 58:             throw new OutOfMemoryError("UTF16 String size is " + len +
>> 59:                                        ", should be less than or equal to " + MAX_LENGTH);
> 
> Suggestion:
> 
>                                        ", should be less than " + MAX_LENGTH);

I second @ExE-Boss's comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17008#discussion_r1420935417

From rriggs at openjdk.org  Fri Dec  8 19:50:30 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 8 Dec 2023 19:50:30 GMT
Subject: RFR: 8321180: Condition for non-latin1 string size too large
 exception is off by one [v2]
In-Reply-To: <a7-9Y_75hNj9RjvAAY12LLfQFwdQ0c-YOV2LfwHgVrQ=.0463c47f-c925-4800-bef7-50cbb715405d@github.com>
References: <a7-9Y_75hNj9RjvAAY12LLfQFwdQ0c-YOV2LfwHgVrQ=.0463c47f-c925-4800-bef7-50cbb715405d@github.com>
Message-ID: <5Xbl04FacFfIghtTPEwfYjOFJBAS1mN-NOh5L4Rap_s=.6bc99f66-4bd9-464e-a3b5-4cfcefcad52d@github.com>

> In the compact string implementation of non-latin1 (UTF16) strings the length is constrained by VM implementation limit on the size a byte array that can be allocated. To produce a useful exception the implementation checks the string size against the maximum byte array size. The exception message is correct
> 
> "UTF16 String size is " + len + ", should be less than or equal to " + MAX_LENGTH
> 
> The code should match the message, otherwise the exception thrown is: 
> 
> java.lang.OutOfMemoryError: Requested array size exceeds VM limit

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

  As suggested by reviewers
  Correct exception message text
  Removed unused imports

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17008/files
  - new: https://git.openjdk.org/jdk/pull/17008/files/f2de15ac..2f03e1f2

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

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

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

From rriggs at openjdk.org  Fri Dec  8 19:50:32 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 8 Dec 2023 19:50:32 GMT
Subject: RFR: 8321180: Condition for non-latin1 string size too large
 exception is off by one [v2]
In-Reply-To: <kZSNl0cyDPRbHVejEd_cvgg1DHnClam64o3zbBB2I18=.8e248b35-e10e-497f-9581-6fc9c82137e5@github.com>
References: <a7-9Y_75hNj9RjvAAY12LLfQFwdQ0c-YOV2LfwHgVrQ=.0463c47f-c925-4800-bef7-50cbb715405d@github.com>
 <zr32wTTsQ_sQ9FMPM99bJreabSZZYH73ImjV2LbC0I4=.8761db23-b906-4429-b897-d3b06697d6bf@github.com>
 <kZSNl0cyDPRbHVejEd_cvgg1DHnClam64o3zbBB2I18=.8e248b35-e10e-497f-9581-6fc9c82137e5@github.com>
Message-ID: <EpP7BX_ETxx1o0b39TaEODOoU0AXRrWW1j0ZBj3NvMU=.c756fa89-159e-459b-aba4-bacb7a9c7640@github.com>

On Fri, 8 Dec 2023 19:32:02 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/StringUTF16.java line 59:
>> 
>>> 57:         if (len >= MAX_LENGTH) {
>>> 58:             throw new OutOfMemoryError("UTF16 String size is " + len +
>>> 59:                                        ", should be less than or equal to " + MAX_LENGTH);
>> 
>> Suggestion:
>> 
>>                                        ", should be less than " + MAX_LENGTH);
>
> I second @ExE-Boss's comment.

Need to recheck.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17008#discussion_r1420965152

From duke at openjdk.org  Fri Dec  8 19:59:26 2023
From: duke at openjdk.org (Bernd)
Date: Fri, 8 Dec 2023 19:59:26 GMT
Subject: RFR: 8321206: Make Locale related system properties
 `StaticProperty` [v2]
In-Reply-To: <CcKGxJp4T09SzhWQ3TBXPqH5TBPb9GbD6QRO0opn8Pg=.3054f472-f801-4846-bbfb-5f29cc8e8512@github.com>
References: <EKzdSEIjrFq0mXKLGOdRCePeu29DWWQnpAY5FDVAK40=.3bcd4037-e3e5-4cf1-948d-665355914106@github.com>
 <CcKGxJp4T09SzhWQ3TBXPqH5TBPb9GbD6QRO0opn8Pg=.3054f472-f801-4846-bbfb-5f29cc8e8512@github.com>
Message-ID: <X-7VTYPXMTHc1QUmldwOviIJvwPIQqV5X45mJ6ydkWs=.4ec5883e-3e93-44de-9abe-f8f90304d45a@github.com>

On Wed, 6 Dec 2023 20:55:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Currently, Locale-related system properties, such as `user.language` or `user.country`, are initialized when the `Locale` class is loaded. Making them static properties is safer than relying on the `Locale` class loading timing, which could potentially be changed depending on the implementation.
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Reflects review comments
>  - Merge branch 'master' into JDK-8321206-Locale-static-properties
>  - Add exclusions in cdsHeapVerifier for new StaticProperties
>  - initial commit

This should probably get a release note, i think I remember I saw and even used setProperty in main to set a language locale.

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

PR Comment: https://git.openjdk.org/jdk/pull/16986#issuecomment-1847767973

From duke at openjdk.org  Fri Dec  8 20:11:21 2023
From: duke at openjdk.org (Vladimir Yaroslavskiy)
Date: Fri, 8 Dec 2023 20:11:21 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v11]
In-Reply-To: <m_FlD1imWi57n0EqQXsrFue-FkO4D1hIbHUI2ph5d6o=.3fcdbf05-7147-4461-8d8e-6947f6f18d62@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 <i1cu_VA2najjcZHepAbvkWGtVzuLMsdYFKssI5s-TFA=.be96a1ac-1eba-4b7f-bde9-1214082eb6c6@github.com>
 <Gb1pFf-YBbIZdSO-XvQ54xqE5SvNezsl9WSHikEOEJA=.90ccd95f-4a79-4a3e-91a0-23eb83107937@github.com>
 <e8rv_97mAYHGXeRhI8dirZDJsn9ecO2gM91t1LCxnWI=.21859a35-93b8-449c-b4f8-d9dfc0912a7e@github.com>
 <m_FlD1imWi57n0EqQXsrFue-FkO4D1hIbHUI2ph5d6o=.3fcdbf05-7147-4461-8d8e-6947f6f18d62@github.com>
Message-ID: <C9cdmmBTW6uphtzkL9BdV4DboIuwNF6M-UMnC3xM8vg=.2aa0c11c-cb22-445f-86f6-281c6ab6368c@github.com>

On Fri, 8 Dec 2023 01:27:35 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> Hello Vamsi (@vamsi-parasa),
>> 
>> Did you have a chance to run benchmarking?
>
> Hi Vladimir (@iaroslavski),
> 
> Please see the data below.
> 
> Thanks,
> Vamsi
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
> <link rel=File-List
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
> 
> 
> 
> </head>
> 
> <body link="#0563C1" vlink="#954F72">
> 
> 
> Benchmark (us/op) | (builder) | (size) | Stock JDK | r_02 | r_03 | r_04 | r_05 | r_06 | r_07 | r_08 | r_98 | r_99
> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
> ArraysSort.Int.testSort | RANDOM | 600 | 2.256 | 1.634 | 1.651 | 1.659 | 1.671 | 1.646 | 1.611 | 1.661 | 1.642 | 1.671
> ArraysSort.Int.testSort | RANDOM | 9000 | 41.457 | 37.697 | 38.075 | 37.927 | 39.693 | 38.989 | 37.86 | 38.163 | 39.222 | 38.835
> ArraysSort.Int.testSort | RANDOM | 20000 | 98.448 | 91.494 | 89.683 | 87.971 | 90.231 | 90.141 | 90.515 | 90.415 | 89.571 | 90.308
> ArraysSort.Int.testSort | RANDOM | 400000 | 2820.939 | 2816.5 | 2811.334 | 2833.15 | 2802.958 | 2813.012 | 2815.24 | 2825.526 | 2801.497 | 2816.25
> ArraysSort.Int.testSort | RANDOM | 3000000 | 23426.411 | 23661.09 | 23778.15 | 23748.91 | 23802.62 | 23746.3 | 23778.16 | 23631.1 | 23651.78 | 23859.91
> ArraysSort.Int.testSort | REPEATED | 600 | 1.032 | 0.929 | 0.955 | 0.944 | 0.927 | 0.928 | 0.953 | 0.918 | 0.934 | 0.93
> ArraysSort.Int.testSort | REPEATED | 9000 | 5.114 | 5.059 | 4.832 | 5.162 | 4.965 | 4.973 | 5.518 | 5.003 | 5.435 | 4.971
> ArraysSort.Int.testSort | REPEATED | 20000 | 10.3 | 12.238 | 12.474 | 12.482 | 12.351 | 12.338 | 12.372 | 12.394 | 12.688 | 13.477
> ArraysSort.Int.testSort | REPEATED | 400000 | 210.742 | 261.709 | 264.572 | 263.203 | 260.822 | 260.475 | 262.03 | 260.356 | 265.976 | 264.273
> ArraysSort.Int.testSort | REPEATED | 3000000 | 1948.589 | 2062.235 | 2079.128 | 2065.445 | 2053.24 | 2076.278 | 2049.799 | 2059.1 | 2073.191 | 2075.65
> ArraysSort.Int.testSort | STAGGER | 600 | 2.125 | 2.001 | 2.023 | 2.021 | 2.001 | 2.018 | 2.011 | 2.017 | 2.005 | 2.011
> ArraysSort.Int.testSort | STAGGER | 9000 | 29.86 | 26.169 | 26.093 | 25.562 | 26.385 | 26.109 | 26.485 | 26.375 | 26.412 | 25.712
> ArraysSort.Int.testSort | STAGGER | 20000 | 67.096 | 77.157 | 63.636 | 64.479 | 58.697 | 59.728 | 58.91...

Hello Vamsi (@vamsi-parasa),

I made the process simpler: added all variants to be compared into ArraysSort class
(set the same package org.openjdk.bench.java.util). It will run all sorts incl. sort from jdk
in the same environment. It should provide more accurate results, otherwise we see some anomalies.

Could you please find time to run the benchmarking?
Take all classes below and put them in the package org.openjdk.bench.java.util.
https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSort.java

https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_a10.java
https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r14.java
https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r17.java
https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r18.java

Many thanks,
Vladimir

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

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1847781758

From stsypanov at openjdk.org  Fri Dec  8 20:19:16 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 8 Dec 2023 20:19:16 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v5]
In-Reply-To: <HINMdsgBdHRT1i50Ugt5NH33BHDzFfVcM3HakpKuNlQ=.5e998744-1ae7-44c3-a5f0-1e95e3348316@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <PIxhz5YwwhYz47aGphHQU7vB2wrjvLQ2ZDZAxh1zgqg=.1b7b2e40-7280-4146-8825-5f28b50704ee@github.com>
 <HINMdsgBdHRT1i50Ugt5NH33BHDzFfVcM3HakpKuNlQ=.5e998744-1ae7-44c3-a5f0-1e95e3348316@github.com>
Message-ID: <yP1juLY3ncoxnaLMN8UCVh21CCpigou9PVKkyNyNcqw=.5304bd17-b6fa-4e2e-8689-382d2576aeaa@github.com>

On Fri, 8 Dec 2023 17:23:59 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8320971: Use same approach as BAOS
>
> src/java.base/share/classes/java/io/OutputStream.java line 212:
> 
>> 210:      * @return true if the argument of {@link #write(byte[])}} and {@link #write(byte[], int, int)}} needn't be copied
>> 211:      */
>> 212:     boolean trusted() {
> 
> This is a strange construction. Any subclass could simply implement this as `return true;`. Where is the guard against this, and why not doing it that way?

@mkarg I guess the method can only be implemented by subclasses residing in the same package with `OutputStream`, right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1420990889

From rgiulietti at openjdk.org  Fri Dec  8 20:26:17 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 8 Dec 2023 20:26:17 GMT
Subject: RFR: 8321180: Condition for non-latin1 string size too large
 exception is off by one [v2]
In-Reply-To: <5Xbl04FacFfIghtTPEwfYjOFJBAS1mN-NOh5L4Rap_s=.6bc99f66-4bd9-464e-a3b5-4cfcefcad52d@github.com>
References: <a7-9Y_75hNj9RjvAAY12LLfQFwdQ0c-YOV2LfwHgVrQ=.0463c47f-c925-4800-bef7-50cbb715405d@github.com>
 <5Xbl04FacFfIghtTPEwfYjOFJBAS1mN-NOh5L4Rap_s=.6bc99f66-4bd9-464e-a3b5-4cfcefcad52d@github.com>
Message-ID: <u0Gm5vpYzz89t9oY24Sry_axZakWTK5zl_DwrT-uyeA=.191811b1-1eee-43b8-9c53-fb913173c442@github.com>

On Fri, 8 Dec 2023 19:50:30 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> In the compact string implementation of non-latin1 (UTF16) strings the length is constrained by VM implementation limit on the size a byte array that can be allocated. To produce a useful exception the implementation checks the string size against the maximum byte array size. The exception message is correct
>> 
>> "UTF16 String size is " + len + ", should be less than or equal to " + MAX_LENGTH
>> 
>> The code should match the message, otherwise the exception thrown is: 
>> 
>> java.lang.OutOfMemoryError: Requested array size exceeds VM limit
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   As suggested by reviewers
>   Correct exception message text
>   Removed unused imports

test/jdk/java/lang/String/CompactString/MaxSizeUTF16String.java line 53:

> 51:         int nonAsciiSize = nonAscii.length;
> 52:         int asciisize = byteSize - nonAsciiSize;
> 53:         byte[] arr = new byte[asciisize + nonAsciiSize];

Suggestion:

        byte[] arr = new byte[byteSize];

Note that `asciisize + nonAsciiSize` = `byteSize - nonAsciiSize + nonAsciiSize` = `byteSize`, even in the presence of overflows. Then `asciisize` becomes useless.

test/jdk/java/lang/String/CompactString/MaxSizeUTF16String.java line 54:

> 52:         int asciisize = byteSize - nonAsciiSize;
> 53:         byte[] arr = new byte[asciisize + nonAsciiSize];
> 54:         Arrays.fill(arr, (byte)'x');      // fill with latin1

`(byte) 0` is a valid UTF-8 sequence after all, so there is no need to fill the array with `'x'`.

test/jdk/java/lang/String/CompactString/MaxSizeUTF16String.java line 64:

> 62:         int nonAsciiSize = nonAscii.length;
> 63:         int asciisize = size - nonAsciiSize;
> 64:         char[] arr = new char[asciisize + nonAsciiSize];

Same as above

test/jdk/java/lang/String/CompactString/MaxSizeUTF16String.java line 65:

> 63:         int asciisize = size - nonAsciiSize;
> 64:         char[] arr = new char[asciisize + nonAsciiSize];
> 65:         Arrays.fill(arr, 'x');      // fill with latin1

Same as above

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17008#discussion_r1420993528
PR Review Comment: https://git.openjdk.org/jdk/pull/17008#discussion_r1420993636
PR Review Comment: https://git.openjdk.org/jdk/pull/17008#discussion_r1420993740
PR Review Comment: https://git.openjdk.org/jdk/pull/17008#discussion_r1420993780

From stsypanov at openjdk.org  Fri Dec  8 20:36:38 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 8 Dec 2023 20:36:38 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v6]
In-Reply-To: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
Message-ID: <0vI6OEY10pbF9ta59phTD1LPIJ69C5dmsrDGJIfvb0A=.533d98c5-3de1-4bb8-a404-9e0e4f4cb230@github.com>

> It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`.
> 
> See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612

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

  8320971: Rewrite comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16879/files
  - new: https://git.openjdk.org/jdk/pull/16879/files/69fb33f6..9bf4e22d

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

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

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

From naoto at openjdk.org  Fri Dec  8 21:14:23 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 8 Dec 2023 21:14:23 GMT
Subject: RFR: 8321206: Make Locale related system properties
 `StaticProperty` [v2]
In-Reply-To: <CcKGxJp4T09SzhWQ3TBXPqH5TBPb9GbD6QRO0opn8Pg=.3054f472-f801-4846-bbfb-5f29cc8e8512@github.com>
References: <EKzdSEIjrFq0mXKLGOdRCePeu29DWWQnpAY5FDVAK40=.3bcd4037-e3e5-4cf1-948d-665355914106@github.com>
 <CcKGxJp4T09SzhWQ3TBXPqH5TBPb9GbD6QRO0opn8Pg=.3054f472-f801-4846-bbfb-5f29cc8e8512@github.com>
Message-ID: <L_5WHDPcCvCWRCZOuDFgxsYDPOJ17FDZjIbjWhrkU1E=.061ced6c-08d5-431c-9ca2-e222a0f13cd7@github.com>

On Wed, 6 Dec 2023 20:55:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Currently, Locale-related system properties, such as `user.language` or `user.country`, are initialized when the `Locale` class is loaded. Making them static properties is safer than relying on the `Locale` class loading timing, which could potentially be changed depending on the implementation.
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Reflects review comments
>  - Merge branch 'master' into JDK-8321206-Locale-static-properties
>  - Add exclusions in cdsHeapVerifier for new StaticProperties
>  - initial commit

Can you elaborate on it more?  I don't think it is possible to change the default locale by modifying those system properties via the `setProperty()` call  in recent JDK releases.

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

PR Comment: https://git.openjdk.org/jdk/pull/16986#issuecomment-1847848415

From stsypanov at openjdk.org  Fri Dec  8 21:27:39 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 8 Dec 2023 21:27:39 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v7]
In-Reply-To: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
Message-ID: <eWDKiHWn3nzH-QE2wSqoPyTZ1-l3W-zp0sWzollSdjM=.564449dc-a755-4c7f-ab0f-53ce53e882fd@github.com>

> It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`.
> 
> See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612

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

  8320971: Rearrange code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16879/files
  - new: https://git.openjdk.org/jdk/pull/16879/files/9bf4e22d..6abc46d4

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

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

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

From rriggs at openjdk.org  Fri Dec  8 22:35:30 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 8 Dec 2023 22:35:30 GMT
Subject: RFR: 8321180: Condition for non-latin1 string size too large
 exception is off by one [v3]
In-Reply-To: <a7-9Y_75hNj9RjvAAY12LLfQFwdQ0c-YOV2LfwHgVrQ=.0463c47f-c925-4800-bef7-50cbb715405d@github.com>
References: <a7-9Y_75hNj9RjvAAY12LLfQFwdQ0c-YOV2LfwHgVrQ=.0463c47f-c925-4800-bef7-50cbb715405d@github.com>
Message-ID: <H8HJy9ZIDiDeagJpoJwT4CompGKeJYSo_JMz_PQQPuQ=.95c348aa-a120-4fac-8922-eea8ea08ed38@github.com>

> In the compact string implementation of non-latin1 (UTF16) strings the length is constrained by VM implementation limit on the size a byte array that can be allocated. To produce a useful exception the implementation checks the string size against the maximum byte array size. The exception message is correct
> 
> "UTF16 String size is " + len + ", should be less than or equal to " + MAX_LENGTH
> 
> The code should match the message, otherwise the exception thrown is: 
> 
> java.lang.OutOfMemoryError: Requested array size exceeds VM limit

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

  Simplify and clarify test data array creation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17008/files
  - new: https://git.openjdk.org/jdk/pull/17008/files/2f03e1f2..24b7696f

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

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

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

From kvn at openjdk.org  Fri Dec  8 22:40:21 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 8 Dec 2023 22:40:21 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v12]
In-Reply-To: <_L--_bl81TgfP1_0bLld6-xzcNqsopfL3HX3bmlbqgE=.923709b1-2e65-4659-a9cd-db4a6ac375c0@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <_L--_bl81TgfP1_0bLld6-xzcNqsopfL3HX3bmlbqgE=.923709b1-2e65-4659-a9cd-db4a6ac375c0@github.com>
Message-ID: <ztyQOqmAdklsQ8TjD3OA7MSWKd3ZzF-cvJnXuhCv2M0=.0eee671d-24e1-444d-bd01-1544962500f6@github.com>

On Wed, 6 Dec 2023 23:12:13 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX2 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
>> 
>> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
>> 
>> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId content=Excel.Sheet>
>> <meta name=Generator content="Microsoft Excel 15">
>> <link id=Main-File rel=Main-File
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
>> <link rel=File-List
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
>> 
>> 
>> </head>
>> 
>> <body link="#0563C1" vlink="#954F72">
>> 
>> 
>> 
>> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
>> -- | -- | -- | -- | --
>> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
>> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
>> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
>> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
>> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
>> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
>> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
>> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
>> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
>> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
>> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
>> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
>> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
>> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
>> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
>> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
>> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
>> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
>> 
>> </body>
>> 
>> </html>
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId cont...
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Change supported intrinsic check"
>   
>   This reverts commit 9621eb045c2958582f81ec06b237789a07481ddd.

I pushed closed changes.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16534#pullrequestreview-1773255608

From duke at openjdk.org  Fri Dec  8 22:43:34 2023
From: duke at openjdk.org (Glavo)
Date: Fri, 8 Dec 2023 22:43:34 GMT
Subject: RFR: 8321620: Optimize JImage decompressors
Message-ID: <xEJ1oQi1sGdIrtBsagVnqeYg5XoHAvfKfgeZWy_cgeA=.e9969e47-b82d-4858-8904-049d8d088a2e@github.com>

This PR significantly speeds up decompressing resources in Jimage while significantly reducing temporary memory allocations in the process.

This will improve startup speed for runtime images generated using `jlink --compress 1` and `jlink --compress 2` .

I generated a runtime image containing javac using `jlink --compress 1 --add-modules jdk.compiler` and tested the time it took to compile a simple HelloWorld program 20 times using `perf stat -r20 javac /dev/shm/HelloWorld.java`, this PR reduces the total time taken from 17830ms to 13598ms (31.12% faster).

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

Commit messages:
 - getStringMUTF8
 - Small optimization
 - use Byte.toUnsignedInt
 - opt decompressFlow
 - Delete CompressIndexes.readInt(DataInputStream)
 - opt StringSharingDecompressor
 - opt ZipDecompressor

Changes: https://git.openjdk.org/jdk/pull/16556/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16556&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321620
  Stats: 210 lines in 7 files changed: 70 ins; 60 del; 80 mod
  Patch: https://git.openjdk.org/jdk/pull/16556.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16556/head:pull/16556

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

From duke at openjdk.org  Fri Dec  8 22:43:34 2023
From: duke at openjdk.org (Glavo)
Date: Fri, 8 Dec 2023 22:43:34 GMT
Subject: RFR: 8321620: Optimize JImage decompressors
In-Reply-To: <xEJ1oQi1sGdIrtBsagVnqeYg5XoHAvfKfgeZWy_cgeA=.e9969e47-b82d-4858-8904-049d8d088a2e@github.com>
References: <xEJ1oQi1sGdIrtBsagVnqeYg5XoHAvfKfgeZWy_cgeA=.e9969e47-b82d-4858-8904-049d8d088a2e@github.com>
Message-ID: <Sj839pWrpFu6T-goUr3QXvrtHxKETEmH9-2jZ1kYKZc=.b75e06cc-5655-416a-9413-9f545d900e4a@github.com>

On Wed, 8 Nov 2023 11:55:22 GMT, Glavo <duke at openjdk.org> wrote:

> This PR significantly speeds up decompressing resources in Jimage while significantly reducing temporary memory allocations in the process.
> 
> This will improve startup speed for runtime images generated using `jlink --compress 1` and `jlink --compress 2` .
> 
> I generated a runtime image containing javac using `jlink --compress 1 --add-modules jdk.compiler` and tested the time it took to compile a simple HelloWorld program 20 times using `perf stat -r20 javac /dev/shm/HelloWorld.java`, this PR reduces the total time taken from 17830ms to 13598ms (31.12% faster).

I generated runtime images using `jlink --compress (1|2) --add-modules java.se,jdk.unsupported,jdk.management` and then ran the following JMH benchmark:


@Warmup(iterations = 10, time = 2)
@Measurement(iterations = 5, time = 3)
@Fork(value = 1, jvmArgsAppend = {"-XX:+UseG1GC", "-Xms8g", "-Xmx8g", "--add-exports=java.base/jdk.internal.jimage=ALL-UNNAMED"})
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@State(Scope.Benchmark)
public class Decompress {

    private static final ImageReader READER = ImageReaderFactory.getImageReader();
    private static final ImageLocation LOC = READER.findLocation("java.base", "java/lang/String.class");

    @Benchmark
    public ByteBuffer test() {
        return READER.getResourceBuffer(LOC);
    }

}



This is the result:


String Share
                                                            (Baseline)                        (Current)
Benchmark                           Mode  Cnt       Score       Error   Units        Score       Error   Units
Decompress.test                     avgt    5  184243.403 ? 3643.983   ns/op     35176.514 ?   507.618   ns/op   (-80.91%)
Decompress.test:gc.alloc.rate       avgt    5    3263.730 ?   64.431  MB/sec      3143.058 ?    45.330  MB/sec
Decompress.test:gc.alloc.rate.norm  avgt    5  630544.422 ?    0.008    B/op    115936.081 ?     0.001    B/op   (-81.61%)
Decompress.test:gc.count            avgt    5      10.000             counts         9.000              counts
Decompress.test:gc.time             avgt    5      14.000                 ms        13.000                  ms


Zip

Benchmark                           Mode  Cnt       Score       Error   Units        Score       Error   Units
Decompress.test                     avgt    5  194237.534 ?  1026.180   ns/op   152855.728 ? 16058.780   ns/op   (-21.30%)
Decompress.test:gc.alloc.rate       avgt    5    1197.700 ?     6.306  MB/sec      464.278 ?    47.465  MB/sec
Decompress.test:gc.alloc.rate.norm  avgt    5  243953.338 ?     5.810    B/op    74376.291 ?     2.175    B/op   (-69.51%)
Decompress.test:gc.count            avgt    5       2.000              counts        1.000              counts
Decompress.test:gc.time             avgt    5       4.000                  ms        3.000                  ms


The results show that memory allocation is reduced by more than 70% while decompression speed is significantly improved.

I ran the tier1 and tier2 tests and there were no new errors.

I generated a runtime image containing javac using `jlink --compress (0|1) --add-modules jdk.compiler` and tested the time it took to compile a simple HelloWorld program 20 times using `perf stat -r20 javac /dev/shm/HelloWorld.java`. This is the result:

Baseline, No Compress: 10829ms

String Share:

* Baseline: 17830ms
* This PR: 13598ms

Zip:

* Baseline: 12350ms
* This PR: 12279ms

You can see that in this test, this PR made the runtime image compressed using string share 30% faster.

Does anyone want to take a look at this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/16556#issuecomment-1801743767
PR Comment: https://git.openjdk.org/jdk/pull/16556#issuecomment-1802425032
PR Comment: https://git.openjdk.org/jdk/pull/16556#issuecomment-1804817957
PR Comment: https://git.openjdk.org/jdk/pull/16556#issuecomment-1847870676

From redestad at openjdk.org  Fri Dec  8 22:43:35 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 8 Dec 2023 22:43:35 GMT
Subject: RFR: 8321620: Optimize JImage decompressors
In-Reply-To: <xEJ1oQi1sGdIrtBsagVnqeYg5XoHAvfKfgeZWy_cgeA=.e9969e47-b82d-4858-8904-049d8d088a2e@github.com>
References: <xEJ1oQi1sGdIrtBsagVnqeYg5XoHAvfKfgeZWy_cgeA=.e9969e47-b82d-4858-8904-049d8d088a2e@github.com>
Message-ID: <WAO1b3skDQzpLAVAeM4aRswRtaQlH6m9mwnaJfEbosc=.4be552db-0e98-4486-a1f8-b8df7ed26f9d@github.com>

On Wed, 8 Nov 2023 11:55:22 GMT, Glavo <duke at openjdk.org> wrote:

> This PR significantly speeds up decompressing resources in Jimage while significantly reducing temporary memory allocations in the process.
> 
> This will improve startup speed for runtime images generated using `jlink --compress 1` and `jlink --compress 2` .
> 
> I generated a runtime image containing javac using `jlink --compress 1 --add-modules jdk.compiler` and tested the time it took to compile a simple HelloWorld program 20 times using `perf stat -r20 javac /dev/shm/HelloWorld.java`, this PR reduces the total time taken from 17830ms to 13598ms (31.12% faster).

I'll need some time to review this thoroughly but skimming through it it seems like a very nice enhancement, making `--compress` more appealing - great work! 

One gotcha in this area is that `jlink` by default does not recreate the CDS archive. Startup might gain from generating out the default CDS archive (`java -Xshare:dump`), but not doing so is a reasonable thing to do if you're aiming for minimal static footprint. But to make comparisons fair you need to take care to compare apples to apples: is the uncompressed baseline a similar jlink image generated without `--compress`? Or the default JDK image (uncompressed, with CDS)?

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

PR Comment: https://git.openjdk.org/jdk/pull/16556#issuecomment-1819976620

From duke at openjdk.org  Fri Dec  8 22:43:36 2023
From: duke at openjdk.org (Glavo)
Date: Fri, 8 Dec 2023 22:43:36 GMT
Subject: RFR: 8321620: Optimize JImage decompressors
In-Reply-To: <WAO1b3skDQzpLAVAeM4aRswRtaQlH6m9mwnaJfEbosc=.4be552db-0e98-4486-a1f8-b8df7ed26f9d@github.com>
References: <xEJ1oQi1sGdIrtBsagVnqeYg5XoHAvfKfgeZWy_cgeA=.e9969e47-b82d-4858-8904-049d8d088a2e@github.com>
 <WAO1b3skDQzpLAVAeM4aRswRtaQlH6m9mwnaJfEbosc=.4be552db-0e98-4486-a1f8-b8df7ed26f9d@github.com>
Message-ID: <MCrY0_SiauNhwM4i4MPDS4qhEE9SAeiHpIRDQnC0DRo=.a7e67aa5-e1f6-4987-9441-e0c9e9e477c9@github.com>

On Mon, 20 Nov 2023 23:36:51 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> But to make comparisons fair you need to take care to compare apples to apples: is the uncompressed baseline a similar jlink image generated without --compress? Or the default JDK image (uncompressed, with CDS)?

The uncompressed runtime image used for comparison was also generated using jlink, without using CDS, so the comparison should be fair.

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

PR Comment: https://git.openjdk.org/jdk/pull/16556#issuecomment-1824029266

From redestad at openjdk.org  Fri Dec  8 22:43:38 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 8 Dec 2023 22:43:38 GMT
Subject: RFR: 8321620: Optimize JImage decompressors
In-Reply-To: <Sj839pWrpFu6T-goUr3QXvrtHxKETEmH9-2jZ1kYKZc=.b75e06cc-5655-416a-9413-9f545d900e4a@github.com>
References: <xEJ1oQi1sGdIrtBsagVnqeYg5XoHAvfKfgeZWy_cgeA=.e9969e47-b82d-4858-8904-049d8d088a2e@github.com>
 <Sj839pWrpFu6T-goUr3QXvrtHxKETEmH9-2jZ1kYKZc=.b75e06cc-5655-416a-9413-9f545d900e4a@github.com>
Message-ID: <D5jQLveRWW7ftPVTkLTeMa9bvbwx8dHWmuQvZ-0FkCE=.cd26f683-8981-43d3-9e76-3d27693528c1@github.com>

On Fri, 8 Dec 2023 21:35:34 GMT, Glavo <duke at openjdk.org> wrote:

> Does anyone want to take a look at this PR?

RFE: https://bugs.openjdk.org/browse/JDK-8321620 - update the bug ID and this should PR should reach a wider audience. I'll have some time next week to help review.

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

PR Comment: https://git.openjdk.org/jdk/pull/16556#issuecomment-1847928881

From pminborg at openjdk.org  Fri Dec  8 22:43:40 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 8 Dec 2023 22:43:40 GMT
Subject: RFR: 8321620: Optimize JImage decompressors
In-Reply-To: <xEJ1oQi1sGdIrtBsagVnqeYg5XoHAvfKfgeZWy_cgeA=.e9969e47-b82d-4858-8904-049d8d088a2e@github.com>
References: <xEJ1oQi1sGdIrtBsagVnqeYg5XoHAvfKfgeZWy_cgeA=.e9969e47-b82d-4858-8904-049d8d088a2e@github.com>
Message-ID: <Nv6UBLqiWTfWF6x6Ku_v8gP4x0auFB1Kd25qvJ0i618=.b1dc87ac-eb3c-4a49-a6f7-afef04158cc3@github.com>

On Wed, 8 Nov 2023 11:55:22 GMT, Glavo <duke at openjdk.org> wrote:

> This PR significantly speeds up decompressing resources in Jimage while significantly reducing temporary memory allocations in the process.
> 
> This will improve startup speed for runtime images generated using `jlink --compress 1` and `jlink --compress 2` .
> 
> I generated a runtime image containing javac using `jlink --compress 1 --add-modules jdk.compiler` and tested the time it took to compile a simple HelloWorld program 20 times using `perf stat -r20 javac /dev/shm/HelloWorld.java`, this PR reduces the total time taken from 17830ms to 13598ms (31.12% faster).

src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java line 349:

> 347: 
> 348:     int getStringMUTF8(int offset, byte[] bytesOut, int bytesOutOffset) {
> 349:         if (offset < 0 || offset >= strings.limit()) {

Can we use `Objects::checkIndex` here instead?

src/java.base/share/classes/jdk/internal/jimage/decompressor/StringSharingDecompressor.java line 94:

> 92:                                    int offset, long originalSize) throws IOException {
> 93:         if (originalSize > Integer.MAX_VALUE) {
> 94:             throw new OutOfMemoryError("Required array size too large");

Is this the correct exception type?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16556#discussion_r1399517646
PR Review Comment: https://git.openjdk.org/jdk/pull/16556#discussion_r1399518707

From duke at openjdk.org  Fri Dec  8 22:43:41 2023
From: duke at openjdk.org (Glavo)
Date: Fri, 8 Dec 2023 22:43:41 GMT
Subject: RFR: 8321620: Optimize JImage decompressors
In-Reply-To: <Nv6UBLqiWTfWF6x6Ku_v8gP4x0auFB1Kd25qvJ0i618=.b1dc87ac-eb3c-4a49-a6f7-afef04158cc3@github.com>
References: <xEJ1oQi1sGdIrtBsagVnqeYg5XoHAvfKfgeZWy_cgeA=.e9969e47-b82d-4858-8904-049d8d088a2e@github.com>
 <Nv6UBLqiWTfWF6x6Ku_v8gP4x0auFB1Kd25qvJ0i618=.b1dc87ac-eb3c-4a49-a6f7-afef04158cc3@github.com>
Message-ID: <wJFDNODLEwmoS3bCxIes3u2qXgPeRwv8UxIHKE_JNY0=.af048d61-5088-4096-9271-c883a5acf364@github.com>

On Mon, 20 Nov 2023 17:18:11 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Can we use `Objects::checkIndex` here instead?

No, because these classes need to be compiled with `--release 8`.

Javadoc:


/**
 * @implNote This class needs to maintain JDK 8 source compatibility.
 *
 * It is used internally in the JDK to implement jimage/jrtfs access,
 * but also compiled and delivered as part of the jrtfs.jar to support access
 * to the jimage file provided by the shipped JDK by tools running on JDK 8.
 */

> Is this the correct exception type?

I'm not sure, but I think it shouldn't matter, since the exception is never really thrown here for a valid jimage file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16556#discussion_r1399536065
PR Review Comment: https://git.openjdk.org/jdk/pull/16556#discussion_r1399538948

From redestad at openjdk.org  Fri Dec  8 22:43:41 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 8 Dec 2023 22:43:41 GMT
Subject: RFR: 8321620: Optimize JImage decompressors
In-Reply-To: <wJFDNODLEwmoS3bCxIes3u2qXgPeRwv8UxIHKE_JNY0=.af048d61-5088-4096-9271-c883a5acf364@github.com>
References: <xEJ1oQi1sGdIrtBsagVnqeYg5XoHAvfKfgeZWy_cgeA=.e9969e47-b82d-4858-8904-049d8d088a2e@github.com>
 <Nv6UBLqiWTfWF6x6Ku_v8gP4x0auFB1Kd25qvJ0i618=.b1dc87ac-eb3c-4a49-a6f7-afef04158cc3@github.com>
 <wJFDNODLEwmoS3bCxIes3u2qXgPeRwv8UxIHKE_JNY0=.af048d61-5088-4096-9271-c883a5acf364@github.com>
Message-ID: <oBuApuRLhm-v3r8Vv3WEqFhNdgir1KkrsJGYrgoCRNA=.1ea040da-153d-4b59-aa17-baf5bb837923@github.com>

On Mon, 20 Nov 2023 17:39:19 GMT, Glavo <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/jimage/decompressor/StringSharingDecompressor.java line 94:
>> 
>>> 92:                                    int offset, long originalSize) throws IOException {
>>> 93:         if (originalSize > Integer.MAX_VALUE) {
>>> 94:             throw new OutOfMemoryError("Required array size too large");
>> 
>> Is this the correct exception type?
>
>> Is this the correct exception type?
> 
> I'm not sure, but I think it shouldn't matter, since the exception is never really thrown here for a valid jimage file.

It's common to throw `OutOfMemoryError` when a requested array size would be too large, either due overflow or because some other limitation (see `StringUTF16::newBytesFor` or `String::replace` for some examples).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16556#discussion_r1399840037

From liach at openjdk.org  Fri Dec  8 22:43:43 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 8 Dec 2023 22:43:43 GMT
Subject: RFR: 8321620: Optimize JImage decompressors
In-Reply-To: <xEJ1oQi1sGdIrtBsagVnqeYg5XoHAvfKfgeZWy_cgeA=.e9969e47-b82d-4858-8904-049d8d088a2e@github.com>
References: <xEJ1oQi1sGdIrtBsagVnqeYg5XoHAvfKfgeZWy_cgeA=.e9969e47-b82d-4858-8904-049d8d088a2e@github.com>
Message-ID: <crO3iMFQYwOmY50MmcF-crAutKNz3SlSrk9JTJ6jdac=.7744faa8-b281-4cd7-8bc2-5bda7dc6bbdd@github.com>

On Wed, 8 Nov 2023 11:55:22 GMT, Glavo <duke at openjdk.org> wrote:

> This PR significantly speeds up decompressing resources in Jimage while significantly reducing temporary memory allocations in the process.
> 
> This will improve startup speed for runtime images generated using `jlink --compress 1` and `jlink --compress 2` .
> 
> I generated a runtime image containing javac using `jlink --compress 1 --add-modules jdk.compiler` and tested the time it took to compile a simple HelloWorld program 20 times using `perf stat -r20 javac /dev/shm/HelloWorld.java`, this PR reduces the total time taken from 17830ms to 13598ms (31.12% faster).

src/java.base/share/classes/jdk/internal/jimage/decompressor/StringSharingDecompressor.java line 111:

> 109:         int count = Short.toUnsignedInt(bytesIn.getShort());
> 110:         bytesOut[bytesOutOffset++] = (byte) ((count >> 8) & 0xff);
> 111:         bytesOut[bytesOutOffset++] = (byte) (count & 0xff);

Probably use `ByteArray.setUnsignedShort`:
Suggestion:

        ByteArray.setUnsignedShort(bytesOut, bytesOutOffset, count);
        bytesOutOffset += 2;

Same remark elsewhere.

src/java.base/share/classes/jdk/internal/jimage/decompressor/StringSharingDecompressor.java line 113:

> 111:         bytesOut[bytesOutOffset++] = (byte) (count & 0xff);
> 112:         for (int i = 1; i < count; i++) {
> 113:             int tag = bytesIn.get() & 0xff;

Suggestion:

            int tag = Byte.toUnsignedInt(bytesIn.get());

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16556#discussion_r1387400142
PR Review Comment: https://git.openjdk.org/jdk/pull/16556#discussion_r1387397234

From duke at openjdk.org  Fri Dec  8 22:43:43 2023
From: duke at openjdk.org (Glavo)
Date: Fri, 8 Dec 2023 22:43:43 GMT
Subject: RFR: 8321620: Optimize JImage decompressors
In-Reply-To: <crO3iMFQYwOmY50MmcF-crAutKNz3SlSrk9JTJ6jdac=.7744faa8-b281-4cd7-8bc2-5bda7dc6bbdd@github.com>
References: <xEJ1oQi1sGdIrtBsagVnqeYg5XoHAvfKfgeZWy_cgeA=.e9969e47-b82d-4858-8904-049d8d088a2e@github.com>
 <crO3iMFQYwOmY50MmcF-crAutKNz3SlSrk9JTJ6jdac=.7744faa8-b281-4cd7-8bc2-5bda7dc6bbdd@github.com>
Message-ID: <N5gnVorty3NHUojRfd53cpocAGufz62of_yrEAtpjHo=.eeaae6d0-3b08-4272-bcb3-a8e4e3146b28@github.com>

On Thu, 9 Nov 2023 02:07:57 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This PR significantly speeds up decompressing resources in Jimage while significantly reducing temporary memory allocations in the process.
>> 
>> This will improve startup speed for runtime images generated using `jlink --compress 1` and `jlink --compress 2` .
>> 
>> I generated a runtime image containing javac using `jlink --compress 1 --add-modules jdk.compiler` and tested the time it took to compile a simple HelloWorld program 20 times using `perf stat -r20 javac /dev/shm/HelloWorld.java`, this PR reduces the total time taken from 17830ms to 13598ms (31.12% faster).
>
> src/java.base/share/classes/jdk/internal/jimage/decompressor/StringSharingDecompressor.java line 111:
> 
>> 109:         int count = Short.toUnsignedInt(bytesIn.getShort());
>> 110:         bytesOut[bytesOutOffset++] = (byte) ((count >> 8) & 0xff);
>> 111:         bytesOut[bytesOutOffset++] = (byte) (count & 0xff);
> 
> Probably use `ByteArray.setUnsignedShort`:
> Suggestion:
> 
>         ByteArray.setUnsignedShort(bytesOut, bytesOutOffset, count);
>         bytesOutOffset += 2;
> 
> Same remark elsewhere.

These classes need to be compiled with `--release 8`, so I can't use the `ByteArray`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16556#discussion_r1387837310

From stsypanov at openjdk.org  Fri Dec  8 22:43:44 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 8 Dec 2023 22:43:44 GMT
Subject: RFR: 8321620: Optimize JImage decompressors
In-Reply-To: <xEJ1oQi1sGdIrtBsagVnqeYg5XoHAvfKfgeZWy_cgeA=.e9969e47-b82d-4858-8904-049d8d088a2e@github.com>
References: <xEJ1oQi1sGdIrtBsagVnqeYg5XoHAvfKfgeZWy_cgeA=.e9969e47-b82d-4858-8904-049d8d088a2e@github.com>
Message-ID: <gi5BuCb-8JKbYU8fCm02DGvXAETZfpaq5R-WdfTlFlo=.41e966d3-a28a-4a29-92df-728f0b61de17@github.com>

On Wed, 8 Nov 2023 11:55:22 GMT, Glavo <duke at openjdk.org> wrote:

> This PR significantly speeds up decompressing resources in Jimage while significantly reducing temporary memory allocations in the process.
> 
> This will improve startup speed for runtime images generated using `jlink --compress 1` and `jlink --compress 2` .
> 
> I generated a runtime image containing javac using `jlink --compress 1 --add-modules jdk.compiler` and tested the time it took to compile a simple HelloWorld program 20 times using `perf stat -r20 javac /dev/shm/HelloWorld.java`, this PR reduces the total time taken from 17830ms to 13598ms (31.12% faster).

test/jdk/tools/jlink/plugins/CompressIndexesTest.java line 100:

> 98: 
> 99:     private void check(byte[] flow, List<byte[]> arrays) {
> 100:         List<Integer> d = Arrays.stream(CompressIndexes.decompressFlow(flow)).boxed().toList();

Can we rewrite this as

int[] d = CompressIndexes.decompressFlow(flow);
int[] dd = new int[arrays.length];
for (int j = 0; j < arrays.length; j++) {
  byte[] b = arrays[j];
  dd[j] = CompressIndexes.decompress(b, 0);
}
if (!Arrays.equals(d, dd) {
//...
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16556#discussion_r1400744398

From duke at openjdk.org  Fri Dec  8 22:51:21 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 8 Dec 2023 22:51:21 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v12]
In-Reply-To: <ztyQOqmAdklsQ8TjD3OA7MSWKd3ZzF-cvJnXuhCv2M0=.0eee671d-24e1-444d-bd01-1544962500f6@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <_L--_bl81TgfP1_0bLld6-xzcNqsopfL3HX3bmlbqgE=.923709b1-2e65-4659-a9cd-db4a6ac375c0@github.com>
 <ztyQOqmAdklsQ8TjD3OA7MSWKd3ZzF-cvJnXuhCv2M0=.0eee671d-24e1-444d-bd01-1544962500f6@github.com>
Message-ID: <e_rkNep7m7NvH5BOGu-d66ZlJrLhMe5_rOA1pDS-cW8=.bed5ea58-ab94-4048-a4e4-7ebbbcbe1dae@github.com>

On Fri, 8 Dec 2023 22:37:26 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> I pushed closed changes.

Thanks Vladimir!

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

PR Comment: https://git.openjdk.org/jdk/pull/16534#issuecomment-1847939767

From duke at openjdk.org  Fri Dec  8 22:55:37 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 8 Dec 2023 22:55:37 GMT
Subject: Integrated: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods
 (int, float arrays)
In-Reply-To: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
Message-ID: <EHNbplJ2r5tEm1rxhEkQc96CxUFfZdXGymefYbon_J0=.5594b84c-c768-42f1-aece-78121d9171b8@github.com>

On Tue, 7 Nov 2023 00:12:41 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX2 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
> 
> For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
> 
> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
> 
> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
> <link rel=File-List
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
> 
> 
> </head>
> 
> <body link="#0563C1" vlink="#954F72">
> 
> 
> 
> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
> -- | -- | -- | -- | --
> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
> 
> </body>
> 
> </html>
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/...

This pull request has now been integrated.

Changeset: ce108446
Author:    vamsi-parasa <srinivas.vamsi.parasa at intel.com>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ce108446ca1fe604ecc24bbefb0bf1c6318271c7
Stats:     4026 lines in 24 files changed: 2311 ins; 1560 del; 155 mod

8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays)

Reviewed-by: sviswanathan, ihse, jbhateja, kvn

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

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

From duke at openjdk.org  Fri Dec  8 23:11:20 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 8 Dec 2023 23:11:20 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v11]
In-Reply-To: <C9cdmmBTW6uphtzkL9BdV4DboIuwNF6M-UMnC3xM8vg=.2aa0c11c-cb22-445f-86f6-281c6ab6368c@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 <i1cu_VA2najjcZHepAbvkWGtVzuLMsdYFKssI5s-TFA=.be96a1ac-1eba-4b7f-bde9-1214082eb6c6@github.com>
 <Gb1pFf-YBbIZdSO-XvQ54xqE5SvNezsl9WSHikEOEJA=.90ccd95f-4a79-4a3e-91a0-23eb83107937@github.com>
 <e8rv_97mAYHGXeRhI8dirZDJsn9ecO2gM91t1LCxnWI=.21859a35-93b8-449c-b4f8-d9dfc0912a7e@github.com>
 <m_FlD1imWi57n0EqQXsrFue-FkO4D1hIbHUI2ph5d6o=.3fcdbf05-7147-4461-8d8e-6947f6f18d62@github.com>
 <C9cdmmBTW6uphtzkL9BdV4DboIuwNF6M-UMnC3xM8vg=.2aa0c11c-cb22-445f-86f6-281c6ab6368c@github.com>
Message-ID: <ilIMEyMisn4iBP_aHMHO0LABXIyBOnhaTSs2cEjb7Gs=.7abf6321-1dde-4b54-b227-f66fe2a18aa4@github.com>

On Fri, 8 Dec 2023 20:08:22 GMT, Vladimir Yaroslavskiy <duke at openjdk.org> wrote:

>> Hi Vladimir (@iaroslavski),
>> 
>> Please see the data below.
>> 
>> Thanks,
>> Vamsi
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId content=Excel.Sheet>
>> <meta name=Generator content="Microsoft Excel 15">
>> <link id=Main-File rel=Main-File
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
>> <link rel=File-List
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
>> 
>> 
>> 
>> </head>
>> 
>> <body link="#0563C1" vlink="#954F72">
>> 
>> 
>> Benchmark (us/op) | (builder) | (size) | Stock JDK | r_02 | r_03 | r_04 | r_05 | r_06 | r_07 | r_08 | r_98 | r_99
>> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
>> ArraysSort.Int.testSort | RANDOM | 600 | 2.256 | 1.634 | 1.651 | 1.659 | 1.671 | 1.646 | 1.611 | 1.661 | 1.642 | 1.671
>> ArraysSort.Int.testSort | RANDOM | 9000 | 41.457 | 37.697 | 38.075 | 37.927 | 39.693 | 38.989 | 37.86 | 38.163 | 39.222 | 38.835
>> ArraysSort.Int.testSort | RANDOM | 20000 | 98.448 | 91.494 | 89.683 | 87.971 | 90.231 | 90.141 | 90.515 | 90.415 | 89.571 | 90.308
>> ArraysSort.Int.testSort | RANDOM | 400000 | 2820.939 | 2816.5 | 2811.334 | 2833.15 | 2802.958 | 2813.012 | 2815.24 | 2825.526 | 2801.497 | 2816.25
>> ArraysSort.Int.testSort | RANDOM | 3000000 | 23426.411 | 23661.09 | 23778.15 | 23748.91 | 23802.62 | 23746.3 | 23778.16 | 23631.1 | 23651.78 | 23859.91
>> ArraysSort.Int.testSort | REPEATED | 600 | 1.032 | 0.929 | 0.955 | 0.944 | 0.927 | 0.928 | 0.953 | 0.918 | 0.934 | 0.93
>> ArraysSort.Int.testSort | REPEATED | 9000 | 5.114 | 5.059 | 4.832 | 5.162 | 4.965 | 4.973 | 5.518 | 5.003 | 5.435 | 4.971
>> ArraysSort.Int.testSort | REPEATED | 20000 | 10.3 | 12.238 | 12.474 | 12.482 | 12.351 | 12.338 | 12.372 | 12.394 | 12.688 | 13.477
>> ArraysSort.Int.testSort | REPEATED | 400000 | 210.742 | 261.709 | 264.572 | 263.203 | 260.822 | 260.475 | 262.03 | 260.356 | 265.976 | 264.273
>> ArraysSort.Int.testSort | REPEATED | 3000000 | 1948.589 | 2062.235 | 2079.128 | 2065.445 | 2053.24 | 2076.278 | 2049.799 | 2059.1 | 2073.191 | 2075.65
>> ArraysSort.Int.testSort | STAGGER | 600 | 2.125 | 2.001 | 2.023 | 2.021 | 2.001 | 2.018 | 2.011 | 2.017 | 2.005 | 2.011
>> ArraysSort.Int.testSort | STAGGER | 9000 | 29.86 | 26.169 | 26.093 | 25.562 | 26.385 | 26.109 | 26.485 | 26.375 | 26.412 | 25.712
>> ArraysSort.Int.te...
>
> Hello Vamsi (@vamsi-parasa),
> 
> I made the process simpler: added all variants to be compared into ArraysSort class
> (set the same package org.openjdk.bench.java.util). It will run all sorts incl. sort from jdk
> in the same environment. It should provide more accurate results, otherwise we see some anomalies.
> 
> Could you please find time to run the benchmarking?
> Take all classes below and put them in the package org.openjdk.bench.java.util.
> https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSort.java
> 
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_a10.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r14.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r17.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r18.java
> 
> Many thanks,
> Vladimir

Sure Vladimir (@iaroslavski),

Will run the tests. 

Also, the baseline stock JDK has changed as a new PR which improves AVX512 sort by up to 35% has been integrated. The PR implements AVX2 sort (https://github.com/openjdk/jdk/pull/16534) but it also improves the performance of AVX512 sort.

Will use the new stock JDK for these measurements and provide the results by EOD Sunday (US pacific time).

Thanks,
Vamsi

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

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1847956297

From duke at openjdk.org  Sat Dec  9 12:12:15 2023
From: duke at openjdk.org (Markus KARG)
Date: Sat, 9 Dec 2023 12:12:15 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v5]
In-Reply-To: <yP1juLY3ncoxnaLMN8UCVh21CCpigou9PVKkyNyNcqw=.5304bd17-b6fa-4e2e-8689-382d2576aeaa@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <PIxhz5YwwhYz47aGphHQU7vB2wrjvLQ2ZDZAxh1zgqg=.1b7b2e40-7280-4146-8825-5f28b50704ee@github.com>
 <HINMdsgBdHRT1i50Ugt5NH33BHDzFfVcM3HakpKuNlQ=.5e998744-1ae7-44c3-a5f0-1e95e3348316@github.com>
 <yP1juLY3ncoxnaLMN8UCVh21CCpigou9PVKkyNyNcqw=.5304bd17-b6fa-4e2e-8689-382d2576aeaa@github.com>
Message-ID: <0tawstjswd8iXsm9Fyb5Bgts1C77lbCbtx23icId6GM=.0097b842-66cc-45c6-962c-b240d4214d6a@github.com>

On Fri, 8 Dec 2023 20:16:43 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/OutputStream.java line 212:
>> 
>>> 210:      * @return true if the argument of {@link #write(byte[])}} and {@link #write(byte[], int, int)}} needn't be copied
>>> 211:      */
>>> 212:     boolean trusted() {
>> 
>> This is a strange construction. Any subclass could simply implement this as `return true;`. Where is the guard against this, and why not doing it that way?
>
> @mkarg I guess the method can only be implemented by subclasses residing in the same package with `OutputStream`, right?
> 
> @AlanBateman fixed

@stsypanov Yes but still it is just weird to ask any output stream if *it* is trusted. I mean, it feels just unsecure to ask: "Do *you* pretend to be trusted?" instead of "Do *we* trust you?". I could sleep better if this method would not be part of each OutputStream subclass. We should either move it back to the place where needed, or into some static utility like `OutputStreams::isTrusted(OutputStream)` (mind the plural!), or it should at least be `final`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1421410216

From duke at openjdk.org  Sat Dec  9 12:17:13 2023
From: duke at openjdk.org (Bernd)
Date: Sat, 9 Dec 2023 12:17:13 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v5]
In-Reply-To: <0tawstjswd8iXsm9Fyb5Bgts1C77lbCbtx23icId6GM=.0097b842-66cc-45c6-962c-b240d4214d6a@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <PIxhz5YwwhYz47aGphHQU7vB2wrjvLQ2ZDZAxh1zgqg=.1b7b2e40-7280-4146-8825-5f28b50704ee@github.com>
 <HINMdsgBdHRT1i50Ugt5NH33BHDzFfVcM3HakpKuNlQ=.5e998744-1ae7-44c3-a5f0-1e95e3348316@github.com>
 <yP1juLY3ncoxnaLMN8UCVh21CCpigou9PVKkyNyNcqw=.5304bd17-b6fa-4e2e-8689-382d2576aeaa@github.com>
 <0tawstjswd8iXsm9Fyb5Bgts1C77lbCbtx23icId6GM=.0097b842-66cc-45c6-962c-b240d4214d6a@github.com>
Message-ID: <0LSpc-7YoxARC_x8eTqadZeEJzMEoomMtgeQIuVFCtA=.20778da7-792d-4ff6-8f71-93c65a62bec8@github.com>

On Sat, 9 Dec 2023 12:09:37 GMT, Markus KARG <duke at openjdk.org> wrote:

>> @mkarg I guess the method can only be implemented by subclasses residing in the same package with `OutputStream`, right?
>> 
>> @AlanBateman fixed
>
> @stsypanov Yes but still it is just weird to ask any output stream if *it* is trusted. I mean, it feels just unsecure to ask: "Do *you* pretend to be trusted?" instead of "Do *we* trust you?". I could sleep better if this method would not be part of each OutputStream subclass. We should either move it back to the place where needed, or into some static utility like `OutputStreams::isTrusted(OutputStream)` (mind the plural!), or it should at least be `final`.

And it should not only talk about modifying the buffer. As it?s also about leaking the reference.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1421410743

From rgiulietti at openjdk.org  Sat Dec  9 16:42:16 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Sat, 9 Dec 2023 16:42:16 GMT
Subject: RFR: 8321180: Condition for non-latin1 string size too large
 exception is off by one [v3]
In-Reply-To: <H8HJy9ZIDiDeagJpoJwT4CompGKeJYSo_JMz_PQQPuQ=.95c348aa-a120-4fac-8922-eea8ea08ed38@github.com>
References: <a7-9Y_75hNj9RjvAAY12LLfQFwdQ0c-YOV2LfwHgVrQ=.0463c47f-c925-4800-bef7-50cbb715405d@github.com>
 <H8HJy9ZIDiDeagJpoJwT4CompGKeJYSo_JMz_PQQPuQ=.95c348aa-a120-4fac-8922-eea8ea08ed38@github.com>
Message-ID: <iuUhvKqeACpaCcHS2tbIg2IGI-r7Xw4NGAi1su0q_Bk=.0262f994-10f0-4be6-be1e-8dc47b6cce2a@github.com>

On Fri, 8 Dec 2023 22:35:30 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> In the compact string implementation of non-latin1 (UTF16) strings the length is constrained by VM implementation limit on the size a byte array that can be allocated. To produce a useful exception the implementation checks the string size against the maximum byte array size. The exception message is correct
>> 
>> "UTF16 String size is " + len + ", should be less than or equal to " + MAX_LENGTH
>> 
>> The code should match the message, otherwise the exception thrown is: 
>> 
>> java.lang.OutOfMemoryError: Requested array size exceeds VM limit
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify and clarify test data array creation

Marked as reviewed by rgiulietti (Reviewer).

LGTM

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

PR Review: https://git.openjdk.org/jdk/pull/17008#pullrequestreview-1773751297
PR Comment: https://git.openjdk.org/jdk/pull/17008#issuecomment-1848549411

From jjiang at openjdk.org  Sat Dec  9 23:25:27 2023
From: jjiang at openjdk.org (John Jiang)
Date: Sat, 9 Dec 2023 23:25:27 GMT
Subject: RFR: 8321637: Simplify if statement in ArraysSupport::hugeLength
Message-ID: <oMBdVUIKUu5OL4z0RHVOiogWAejQ6Ef7wfsTgKGI6wM=.a7b472b2-7b0a-4066-adfe-bdb00bc91d34@github.com>

It looks the `else-if` and `else` clauses in method `ArraysSupport::hugeLength` could be simplified by `Math::max`.

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

Commit messages:
 - 8321637: Simplify if statement in ArraysSupport::hugeLength

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

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

From duke at openjdk.org  Sat Dec  9 23:27:20 2023
From: duke at openjdk.org (Bernd)
Date: Sat, 9 Dec 2023 23:27:20 GMT
Subject: RFR: 8321206: Make Locale related system properties
 `StaticProperty` [v2]
In-Reply-To: <L_5WHDPcCvCWRCZOuDFgxsYDPOJ17FDZjIbjWhrkU1E=.061ced6c-08d5-431c-9ca2-e222a0f13cd7@github.com>
References: <EKzdSEIjrFq0mXKLGOdRCePeu29DWWQnpAY5FDVAK40=.3bcd4037-e3e5-4cf1-948d-665355914106@github.com>
 <CcKGxJp4T09SzhWQ3TBXPqH5TBPb9GbD6QRO0opn8Pg=.3054f472-f801-4846-bbfb-5f29cc8e8512@github.com>
 <L_5WHDPcCvCWRCZOuDFgxsYDPOJ17FDZjIbjWhrkU1E=.061ced6c-08d5-431c-9ca2-e222a0f13cd7@github.com>
Message-ID: <nBu5sF-lrxl3EqC_CJ27mu_1L9nr9X8HrX3jXPWyW8I=.d95dca80-1df4-4612-b946-06748087d950@github.com>

On Fri, 8 Dec 2023 21:11:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> in recent JDK releases.

ok, could be that this has changed before. It does make sense to not allow it if the sequence of initialisation can?t be guaranteed.

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

PR Comment: https://git.openjdk.org/jdk/pull/16986#issuecomment-1848779128

From duke at openjdk.org  Sat Dec  9 23:40:13 2023
From: duke at openjdk.org (jmehrens)
Date: Sat, 9 Dec 2023 23:40:13 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v5]
In-Reply-To: <0LSpc-7YoxARC_x8eTqadZeEJzMEoomMtgeQIuVFCtA=.20778da7-792d-4ff6-8f71-93c65a62bec8@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <PIxhz5YwwhYz47aGphHQU7vB2wrjvLQ2ZDZAxh1zgqg=.1b7b2e40-7280-4146-8825-5f28b50704ee@github.com>
 <HINMdsgBdHRT1i50Ugt5NH33BHDzFfVcM3HakpKuNlQ=.5e998744-1ae7-44c3-a5f0-1e95e3348316@github.com>
 <yP1juLY3ncoxnaLMN8UCVh21CCpigou9PVKkyNyNcqw=.5304bd17-b6fa-4e2e-8689-382d2576aeaa@github.com>
 <0tawstjswd8iXsm9Fyb5Bgts1C77lbCbtx23icId6GM=.0097b842-66cc-45c6-962c-b240d4214d6a@github.com>
 <0LSpc-7YoxARC_x8eTqadZeEJzMEoomMtgeQIuVFCtA=.20778da7-792d-4ff6-8f71-93c65a62bec8@github.com>
Message-ID: <UFLG482RqM9eZvv8qHg7EJf1b0ARIRGoNe36OCVGf9M=.f2ff1eee-424c-4900-be1e-836a8264a026@github.com>

On Sat, 9 Dec 2023 12:14:35 GMT, Bernd <duke at openjdk.org> wrote:

>> @stsypanov Yes but still it is just weird to ask any output stream if *it* is trusted. I mean, it feels just unsecure to ask: "Do *you* pretend to be trusted?" instead of "Do *we* trust you?". I could sleep better if this method would not be part of each OutputStream subclass. We should either move it back to the place where needed, or into some static utility like `OutputStreams::isTrusted(OutputStream)` (mind the plural!), or it should at least be `final`.
>
> (Deleted) the new version doesn?t have the issue (albeit now it?s rather complicated formulated) ?If stream can be used by JCL callers without extra copies of the byte[] argument to write(). This is not over writeable by user code.?

Unlike BAIS, the BufferedInputStream can wrap an untrusted InputStream.  BIS.buf is passed directly to wrapped InputStream so I would assume that we would want to avoid exposing BIS.buf to the `out` parameter of transferTo.  This way we know the input stream is not able to poison the output stream when a write is in progress.  

I assume that the current small list of trusted classes are also immune to poison so I imagine this patch is safe.  However, for any FilterInputStream we should either always use Arrays.copyOfRange because the input side can poison the output side or it needs a mirroring allow list for the target input stream to insure that the wrapped input stream is not poisoning the out parameter.

For instance, java.util.zip.CheckedOutputStream in theory could be added as trusted class as it doesn't leak or poison but, looking at the code it would appear that it is not immune to poison.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1421607704

From jiefu at openjdk.org  Sun Dec 10 03:59:17 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Sun, 10 Dec 2023 03:59:17 GMT
Subject: RFR: 8321637: Simplify if statement in ArraysSupport::hugeLength
In-Reply-To: <oMBdVUIKUu5OL4z0RHVOiogWAejQ6Ef7wfsTgKGI6wM=.a7b472b2-7b0a-4066-adfe-bdb00bc91d34@github.com>
References: <oMBdVUIKUu5OL4z0RHVOiogWAejQ6Ef7wfsTgKGI6wM=.a7b472b2-7b0a-4066-adfe-bdb00bc91d34@github.com>
Message-ID: <mXd4p_5IqL_CaRmGlvK1kes6UoHyi8lX4XXPsOzqgR0=.4589ca2c-02c7-475d-a66f-eb0ce126ce6f@github.com>

On Sat, 9 Dec 2023 23:19:52 GMT, John Jiang <jjiang at openjdk.org> wrote:

> It looks the `else-if` and `else` clauses in method `ArraysSupport::hugeLength` could be simplified by `Math::max`.

The JBS should be an enhancement, not a bug, right?

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

PR Comment: https://git.openjdk.org/jdk/pull/17043#issuecomment-1848849957

From jjiang at openjdk.org  Sun Dec 10 14:15:14 2023
From: jjiang at openjdk.org (John Jiang)
Date: Sun, 10 Dec 2023 14:15:14 GMT
Subject: RFR: 8321637: Simplify if statement in ArraysSupport::hugeLength
In-Reply-To: <mXd4p_5IqL_CaRmGlvK1kes6UoHyi8lX4XXPsOzqgR0=.4589ca2c-02c7-475d-a66f-eb0ce126ce6f@github.com>
References: <oMBdVUIKUu5OL4z0RHVOiogWAejQ6Ef7wfsTgKGI6wM=.a7b472b2-7b0a-4066-adfe-bdb00bc91d34@github.com>
 <mXd4p_5IqL_CaRmGlvK1kes6UoHyi8lX4XXPsOzqgR0=.4589ca2c-02c7-475d-a66f-eb0ce126ce6f@github.com>
Message-ID: <1CPp1WOBO96xKN6Zx366mvaKmf2MU-6gozznS-QLArg=.121c436f-0d10-491f-98ec-7003e57c4a4c@github.com>

On Sun, 10 Dec 2023 03:57:00 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> It looks the `else-if` and `else` clauses in method `ArraysSupport::hugeLength` could be simplified by `Math::max`.
>
> The JBS should be an enhancement, not a bug, right?

@DamonFool 
> The JBS should be an enhancement, not a bug, right?

Yes, it should be an enhancement rather than a bug.

Thanks @AlanBateman for changing this JBS type.

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

PR Comment: https://git.openjdk.org/jdk/pull/17043#issuecomment-1848976812

From stsypanov at openjdk.org  Sun Dec 10 19:36:36 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Sun, 10 Dec 2023 19:36:36 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v8]
In-Reply-To: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
Message-ID: <l4Tgk13a25Cs0YSvRzfTiziYcz2JvDKMCwe7LTYjaFs=.f20fe45c-e1b1-4558-a44f-9838fa87e200@github.com>

> It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`.
> 
> See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612

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

  8320971: Extract utility class

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16879/files
  - new: https://git.openjdk.org/jdk/pull/16879/files/6abc46d4..f5cf1346

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

  Stats: 73 lines in 4 files changed: 53 ins; 17 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/16879.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16879/head:pull/16879

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

From jlu at openjdk.org  Mon Dec 11 03:03:44 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 11 Dec 2023 03:03:44 GMT
Subject: RFR: 8321480: ISO 4217 Amendment 176 Update [v2]
In-Reply-To: <kLWpfbMrAiEskU8JqeFoGaEBzx1aTHI_vq5gxjjdoVw=.2b1af423-59c7-44e8-b4d4-deca303ec2a8@github.com>
References: <kLWpfbMrAiEskU8JqeFoGaEBzx1aTHI_vq5gxjjdoVw=.2b1af423-59c7-44e8-b4d4-deca303ec2a8@github.com>
Message-ID: <qbVDj_d2TOhj5-mHcBLKpc8lN6zTnhCP2UYi_h70Kxg=.b2ddfb6f-3cb2-4c15-93a3-6ff90c516501@github.com>

> Please review this PR which incorporates the ISO 4217 Amendment 176 Update. As the replacement of `ANG` to `XCG` won't occur until 2025, this change does not need to go into JDK22. `HR` was also updated to remove the past cutover dates.
> 
> An existing test in _ValidateISO4217.java_ checked that `Currency::getAvailableCurrencies` had all the expected currencies. This method returns all currencies, including ones to take place in the future (e.g. `XCG`). The expected currencies `Set` the method was test against had to be updated to also include future currencies as well.
> 
> Additionally, this change also converted a parameterized test to a normal JUnit test, due to output overflow.

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

 - Merge branch 'master' into 8321480-ISO4217-176
 - add comment
 - reflect review comments
 - add xcg to CurrencyNames
 - init

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17023/files
  - new: https://git.openjdk.org/jdk/pull/17023/files/249fbc7a..94f5870c

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

  Stats: 21626 lines in 351 files changed: 17767 ins; 3052 del; 807 mod
  Patch: https://git.openjdk.org/jdk/pull/17023.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17023/head:pull/17023

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

From jlu at openjdk.org  Mon Dec 11 03:03:45 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 11 Dec 2023 03:03:45 GMT
Subject: RFR: 8321480: ISO 4217 Amendment 176 Update [v2]
In-Reply-To: <YJ3f4NQyWkLM6xaR_zIU039s-AWMaDZhXC0HXZATN04=.bec227f8-9a88-4a92-b807-9e0fc720125d@github.com>
References: <kLWpfbMrAiEskU8JqeFoGaEBzx1aTHI_vq5gxjjdoVw=.2b1af423-59c7-44e8-b4d4-deca303ec2a8@github.com>
 <YJ3f4NQyWkLM6xaR_zIU039s-AWMaDZhXC0HXZATN04=.bec227f8-9a88-4a92-b807-9e0fc720125d@github.com>
Message-ID: <xLAOF_anhwmtVxg80QM2Kg9NdzcEMBM8GznHEUnMn9w=.153ddf67-ae74-4948-a1fc-f2f1697a3b3f@github.com>

On Thu, 7 Dec 2023 22:20:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8321480-ISO4217-176
>>  - add comment
>>  - reflect review comments
>>  - add xcg to CurrencyNames
>>  - init
>
> src/java.base/share/classes/sun/util/resources/CurrencyNames.properties line 497:
> 
>> 495: xbd=European Unit of Account (XBD)
>> 496: xcd=East Caribbean Dollar
>> 497: xcg=Caribbean Guilder
> 
> I think `XCG=XCG` is also needed for not throwing `MissingResourceException` for `getSymbol()`

Thanks for the correction, added in.

> test/jdk/java/util/Currency/ValidateISO4217.java line 181:
> 
>> 179:                     // without updating ISO4217Codes
>> 180:                     String futureCurr = tokens.nextToken();
>> 181:                     testCurrencies.add(Currency.getInstance(futureCurr));
> 
> I'd not add the future currency, and fix it in the code not to add future currency in available currencies.

Updated the Currency build process to disallow any Currencies that are future Currencies. This prevents the future currency, "XCG" from leaking out into `Currency.getAvailableCurrencies()`. (This was only exposed now, since the previous future Currencies were already ones expected to be found in `Currency.getAvailableCurrencies()`. E.g. Amendment 174 where HRK was replaced by EUR.

> test/jdk/java/util/Currency/ValidateISO4217.java line 289:
> 
>> 287:                 assertNull(Currency.getInstance(Locale.of("", country)),
>> 288:                         "Error: Currency.getInstance() for this locale should return null: " + country);
>> 289:             }
> 
> What is this change for?

The previous output was overflowing due to the method being a `@ParameterizedTest` since it was testing against 26*26 inputs. Changing to `@Test` makes diagnostics easier, as there is no more overflow.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17023#discussion_r1421898797
PR Review Comment: https://git.openjdk.org/jdk/pull/17023#discussion_r1421898780
PR Review Comment: https://git.openjdk.org/jdk/pull/17023#discussion_r1421898803

From gli at openjdk.org  Mon Dec 11 03:19:24 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 11 Dec 2023 03:19:24 GMT
Subject: RFR: 8321688: Build on linux with GCC 7.5.0 fails after 8319577
Message-ID: <vIByQ06ftSU9o1Rb4YOWXPrry1LkYSj-vJqLXaMXQ5g=.d5a0ea33-f57a-4549-addf-b7a9c5eaa67d@github.com>

Hi all,

This patch fixes the building failure introduced by [JDK-8319577](https://bugs.openjdk.org/browse/JDK-8319577) in old GCC version (linux & GCC 7.5.0 locally).

Thanks for the review.

 Best Regards,
-- Guoxiong

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

Commit messages:
 - JDK-8321688

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

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

From duke at openjdk.org  Mon Dec 11 03:45:26 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 11 Dec 2023 03:45:26 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v11]
In-Reply-To: <C9cdmmBTW6uphtzkL9BdV4DboIuwNF6M-UMnC3xM8vg=.2aa0c11c-cb22-445f-86f6-281c6ab6368c@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 <i1cu_VA2najjcZHepAbvkWGtVzuLMsdYFKssI5s-TFA=.be96a1ac-1eba-4b7f-bde9-1214082eb6c6@github.com>
 <Gb1pFf-YBbIZdSO-XvQ54xqE5SvNezsl9WSHikEOEJA=.90ccd95f-4a79-4a3e-91a0-23eb83107937@github.com>
 <e8rv_97mAYHGXeRhI8dirZDJsn9ecO2gM91t1LCxnWI=.21859a35-93b8-449c-b4f8-d9dfc0912a7e@github.com>
 <m_FlD1imWi57n0EqQXsrFue-FkO4D1hIbHUI2ph5d6o=.3fcdbf05-7147-4461-8d8e-6947f6f18d62@github.com>
 <C9cdmmBTW6uphtzkL9BdV4DboIuwNF6M-UMnC3xM8vg=.2aa0c11c-cb22-445f-86f6-281c6ab6368c@github.com>
Message-ID: <-bYhysKjQVb_ZS0I0YutJZ7umfYwbs74rtK6-d2qL9U=.f9981e59-f0c4-48f3-ad7e-5627aad00919@github.com>

On Fri, 8 Dec 2023 20:08:22 GMT, Vladimir Yaroslavskiy <duke at openjdk.org> wrote:

>> Hi Vladimir (@iaroslavski),
>> 
>> Please see the data below.
>> 
>> Thanks,
>> Vamsi
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId content=Excel.Sheet>
>> <meta name=Generator content="Microsoft Excel 15">
>> <link id=Main-File rel=Main-File
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
>> <link rel=File-List
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
>> 
>> 
>> 
>> </head>
>> 
>> <body link="#0563C1" vlink="#954F72">
>> 
>> 
>> Benchmark (us/op) | (builder) | (size) | Stock JDK | r_02 | r_03 | r_04 | r_05 | r_06 | r_07 | r_08 | r_98 | r_99
>> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
>> ArraysSort.Int.testSort | RANDOM | 600 | 2.256 | 1.634 | 1.651 | 1.659 | 1.671 | 1.646 | 1.611 | 1.661 | 1.642 | 1.671
>> ArraysSort.Int.testSort | RANDOM | 9000 | 41.457 | 37.697 | 38.075 | 37.927 | 39.693 | 38.989 | 37.86 | 38.163 | 39.222 | 38.835
>> ArraysSort.Int.testSort | RANDOM | 20000 | 98.448 | 91.494 | 89.683 | 87.971 | 90.231 | 90.141 | 90.515 | 90.415 | 89.571 | 90.308
>> ArraysSort.Int.testSort | RANDOM | 400000 | 2820.939 | 2816.5 | 2811.334 | 2833.15 | 2802.958 | 2813.012 | 2815.24 | 2825.526 | 2801.497 | 2816.25
>> ArraysSort.Int.testSort | RANDOM | 3000000 | 23426.411 | 23661.09 | 23778.15 | 23748.91 | 23802.62 | 23746.3 | 23778.16 | 23631.1 | 23651.78 | 23859.91
>> ArraysSort.Int.testSort | REPEATED | 600 | 1.032 | 0.929 | 0.955 | 0.944 | 0.927 | 0.928 | 0.953 | 0.918 | 0.934 | 0.93
>> ArraysSort.Int.testSort | REPEATED | 9000 | 5.114 | 5.059 | 4.832 | 5.162 | 4.965 | 4.973 | 5.518 | 5.003 | 5.435 | 4.971
>> ArraysSort.Int.testSort | REPEATED | 20000 | 10.3 | 12.238 | 12.474 | 12.482 | 12.351 | 12.338 | 12.372 | 12.394 | 12.688 | 13.477
>> ArraysSort.Int.testSort | REPEATED | 400000 | 210.742 | 261.709 | 264.572 | 263.203 | 260.822 | 260.475 | 262.03 | 260.356 | 265.976 | 264.273
>> ArraysSort.Int.testSort | REPEATED | 3000000 | 1948.589 | 2062.235 | 2079.128 | 2065.445 | 2053.24 | 2076.278 | 2049.799 | 2059.1 | 2073.191 | 2075.65
>> ArraysSort.Int.testSort | STAGGER | 600 | 2.125 | 2.001 | 2.023 | 2.021 | 2.001 | 2.018 | 2.011 | 2.017 | 2.005 | 2.011
>> ArraysSort.Int.testSort | STAGGER | 9000 | 29.86 | 26.169 | 26.093 | 25.562 | 26.385 | 26.109 | 26.485 | 26.375 | 26.412 | 25.712
>> ArraysSort.Int.te...
>
> Hello Vamsi (@vamsi-parasa),
> 
> I made the process simpler: added all variants to be compared into ArraysSort class
> (set the same package org.openjdk.bench.java.util). It will run all sorts incl. sort from jdk
> in the same environment. It should provide more accurate results, otherwise we see some anomalies.
> 
> Could you please find time to run the benchmarking?
> Take all classes below and put them in the package org.openjdk.bench.java.util.
> https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSort.java
> 
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_a10.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r14.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r17.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r18.java
> 
> Many thanks,
> Vladimir

Hi Vladimir (@iaroslavski)

Please see the data below using the latest version of AVX512 sort that got integrated into OpenJDK.

<html xmlns:v="urn:schemas-microsoft-com:vml"
xmlns:o="urn:schemas-microsoft-com:office:office"
xmlns:x="urn:schemas-microsoft-com:office:excel"
xmlns="http://www.w3.org/TR/REC-html40">

<head>

<meta name=ProgId content=Excel.Sheet>
<meta name=Generator content="Microsoft Excel 15">
<link id=Main-File rel=Main-File
href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
<link rel=File-List
href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">



</head>

<body link="#0563C1" vlink="#954F72">


Benchmark   (us/op) | (builder) | Stock JDK | a10 | r14 | r17 | r18
-- | -- | -- | -- | -- | -- | --
ArraysSort.Int.testSort | RANDOM | 2.202 | 2.226 | 1.535 | 1.556 | 1.546
ArraysSort.Int.testSort | RANDOM | 35.128 | 34.804 | 30.808 | 30.914 | 31.284
ArraysSort.Int.testSort | RANDOM | 78.571 | 77.224 | 72.567 | 73.098 | 73.337
ArraysSort.Int.testSort | RANDOM | 2466.487 | 2470.66 | 2504.654 | 2494.051 | 2499.746
ArraysSort.Int.testSort | RANDOM | 20704.14 | 20668.19 | 21377.73 | 21362.63 | 21278.94
ArraysSort.Int.testSort | REPEATED | 0.877 | 0.892 | 0.74 | 0.724 | 0.718
ArraysSort.Int.testSort | REPEATED | 4.789 | 4.788 | 4.92 | 4.721 | 4.891
ArraysSort.Int.testSort | REPEATED | 11.172 | 11.778 | 11.53 | 11.467 | 11.406
ArraysSort.Int.testSort | REPEATED | 207.212 | 207.292 | 255.46 | 258.832 | 254.44
ArraysSort.Int.testSort | REPEATED | 1862.544 | 1876.759 | 1952.646 | 1957.978 | 1981.906
ArraysSort.Int.testSort | STAGGER | 2.092 | 2.137 | 1.999 | 2.031 | 2.015
ArraysSort.Int.testSort | STAGGER | 29.891 | 30.321 | 25.626 | 26.318 | 26.396
ArraysSort.Int.testSort | STAGGER | 60.979 | 83.439 | 57.864 | 57.213 | 79.762
ArraysSort.Int.testSort | STAGGER | 1227.933 | 1224.495 | 1236.133 | 1229.773 | 1228.877
ArraysSort.Int.testSort | STAGGER | 9514.873 | 9565.599 | 9491.509 | 9481.147 | 9481.905
ArraysSort.Int.testSort | SHUFFLE | 1.608 | 1.595 | 1.419 | 1.442 | 1.491
ArraysSort.Int.testSort | SHUFFLE | 31.566 | 32.789 | 28.718 | 28.768 | 28.671
ArraysSort.Int.testSort | SHUFFLE | 82.157 | 83.741 | 70.889 | 69.951 | 71.196
ArraysSort.Int.testSort | SHUFFLE | 2251.219 | 2248.496 | 2184.459 | 2163.969 | 2156.239
ArraysSort.Int.testSort | SHUFFLE | 18211.05 | 18223.24 | 17987.4 | 18114.26 | 17994.98



</body>

</html>

Thanks,
Vamsi

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

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1849275855

From dholmes at openjdk.org  Mon Dec 11 05:06:28 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 11 Dec 2023 05:06:28 GMT
Subject: RFR: 8321206: Make Locale related system properties
 `StaticProperty` [v2]
In-Reply-To: <L_5WHDPcCvCWRCZOuDFgxsYDPOJ17FDZjIbjWhrkU1E=.061ced6c-08d5-431c-9ca2-e222a0f13cd7@github.com>
References: <EKzdSEIjrFq0mXKLGOdRCePeu29DWWQnpAY5FDVAK40=.3bcd4037-e3e5-4cf1-948d-665355914106@github.com>
 <CcKGxJp4T09SzhWQ3TBXPqH5TBPb9GbD6QRO0opn8Pg=.3054f472-f801-4846-bbfb-5f29cc8e8512@github.com>
 <L_5WHDPcCvCWRCZOuDFgxsYDPOJ17FDZjIbjWhrkU1E=.061ced6c-08d5-431c-9ca2-e222a0f13cd7@github.com>
Message-ID: <mn0uomeWi792xhtJ2u2hz6hdwEYhg4vU82d09XXLb7A=.5a14862f-9b5d-4875-8e85-c413ed7ddee3@github.com>

On Fri, 8 Dec 2023 21:11:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Reflects review comments
>>  - Merge branch 'master' into JDK-8321206-Locale-static-properties
>>  - Add exclusions in cdsHeapVerifier for new StaticProperties
>>  - initial commit
>
> Can you elaborate on it more?  I don't think it is possible to change the default locale by modifying those system properties via the `setProperty()` call  in recent JDK releases.

@naotoj  the hotspot changes were not approved by any Hotspot engineer. Unless trivial, all hotspot code changes require two reviews by hotspot developers.

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

PR Comment: https://git.openjdk.org/jdk/pull/16986#issuecomment-1849333218

From jlu at openjdk.org  Mon Dec 11 05:47:33 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 11 Dec 2023 05:47:33 GMT
Subject: RFR: JDK-8319626: Override toString() for ZipFile [v8]
In-Reply-To: <UEVJDXC8Cs_RSBUEsWgmq8SPvI-T4LSydbPKr8u29iA=.fdce7d47-87a8-42ba-9cd4-119bf9023ad9@github.com>
References: <UEVJDXC8Cs_RSBUEsWgmq8SPvI-T4LSydbPKr8u29iA=.fdce7d47-87a8-42ba-9cd4-119bf9023ad9@github.com>
Message-ID: <EEHjubpyde8VF6w4shuUjROZWwIabcGCI9DYMva_gy8=.afba4e81-0f88-4530-8e32-23ca7f949157@github.com>

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319982) which overrides and provides an implementation of `toString()` in _java.util.zip.ZipFile_ (and by extension, _java.util.jar.JarFile_).

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

 - Merge branch 'master' into JDK-8319626
 - break line
 - reflect review: change impl to store field name
 - drop additional specification
 - drop 2nd paragraph
 - return base name, not full path
 - shorten wording
 - reflect review: use separator, clarify spec
 - reflect review: change string value and drop spec
 - init

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16643/files
  - new: https://git.openjdk.org/jdk/pull/16643/files/159c4c8f..4ba2bd47

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16643&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16643&range=06-07

  Stats: 170989 lines in 3102 files changed: 94020 ins; 63689 del; 13280 mod
  Patch: https://git.openjdk.org/jdk/pull/16643.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16643/head:pull/16643

PR: https://git.openjdk.org/jdk/pull/16643

From jlu at openjdk.org  Mon Dec 11 05:47:37 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 11 Dec 2023 05:47:37 GMT
Subject: RFR: JDK-8319626: Override toString() for ZipFile [v7]
In-Reply-To: <0TKNGz1hOQmuTyplP7UhHD_7qV5_P0sPq5acTMXJsv0=.399049d0-79bd-48d4-8a42-ef7fbe5835e2@github.com>
References: <UEVJDXC8Cs_RSBUEsWgmq8SPvI-T4LSydbPKr8u29iA=.fdce7d47-87a8-42ba-9cd4-119bf9023ad9@github.com>
 <Iy4p9slUnyrWD5XUd6IER-MMmX0VgMyPdV6lYPWzLq4=.6e54f547-9bce-4469-8e37-3a2be9e02ac1@github.com>
 <0TKNGz1hOQmuTyplP7UhHD_7qV5_P0sPq5acTMXJsv0=.399049d0-79bd-48d4-8a42-ef7fbe5835e2@github.com>
Message-ID: <sm6nW4R1ivI_7o60aQ3gNEcEDefA1YWiZOlkqnZ7sOU=.1a7cd4c0-805f-4c1a-aadb-f88c91d393cc@github.com>

On Fri, 8 Dec 2023 10:18:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   drop additional specification
>
> src/java.base/share/classes/java/util/zip/ZipFile.java line 494:
> 
>> 492:     @Override
>> 493:     public String toString() {
>> 494:         return res.zsrc.key.file.getName()
> 
> Hello Justin, relying on `res.zsrc.key.file` to get to the file name can cause troubles. For example, consider this usage (which I ran in jshell) with this proposed change in this PR:
> 
> 
> jshell> import java.util.zip.*
> 
> jshell> ZipFile zf = new ZipFile("/tmp/workdir.zip")
> zf ==> workdir.zip at 34c45dca
> 
> jshell> zf.close()
> 
> jshell> zf.toString()
> |  Exception java.lang.NullPointerException: Cannot read field "key" because "this.res.zsrc" is null
> |        at ZipFile.toString (ZipFile.java:494)
> |        at (#4:1)
> 
> 
> 
> What I do here is that I call `ZipFile.toString()` after I (intentionally) close the `ZipFile`. The `toString()` call leads to `NullPointerException` because on closing the `ZipFile` instance we clean up the resource it holds on to.
> 
> I think what we can do here is, something like (the following diff was generated on top of the current state of this PR):
> 
> 
> diff --git a/src/java.base/share/classes/java/util/zip/ZipFile.java b/src/java.base/share/classes/java/util/zip/ZipFile.java
> index 67a5e65089f..2b6996294e1 100644
> --- a/src/java.base/share/classes/java/util/zip/ZipFile.java
> +++ b/src/java.base/share/classes/java/util/zip/ZipFile.java
> @@ -95,7 +95,8 @@
>   */
>  public class ZipFile implements ZipConstants, Closeable {
>  
> -    private final String name;     // zip file name
> +    private final String filePath;     // zip file path
> +    private final String fileName;     // name of the file
>      private volatile boolean closeRequested;
>  
>      // The "resource" used by this zip file that needs to be
> @@ -245,7 +246,8 @@ public ZipFile(File file, int mode, Charset charset) throws IOException
>          }
>          Objects.requireNonNull(charset, "charset");
>  
> -        this.name = name;
> +        this.filePath = name;
> +        this.fileName = file.getName();
>          long t0 = System.nanoTime();
>  
>          this.res = new CleanableResource(this, ZipCoder.get(charset), file, mode);
> @@ -483,7 +485,7 @@ public int available() throws IOException {
>       * @return the path name of the ZIP file
>       */
>      public String getName() {
> -        return name;
> +        return filePath;
>      }
>  
>      /**
> @@ -491,7 +493,7 @@ public String getName() {
>       */
>      @Override
>      public String toString() {
> -        return res.zsrc.key.file.getName()
> +        return this.fileName
>                  + "@" + Intege...

Hi Jai,

Thank you for the detailed response and suggested alternative.

My intentions were to get the file name by leveraging the existing code without introducing an additional field if possible, but I did not realize the `NPE` it would cause when closing the ZipFile as you demonstrated.

I appreciate your guidance, updated the PR to reflect your suggestions. I don't see how this would cause any issues with tests as you stated, but checked tiers 1-3 and all is good there.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16643#discussion_r1421964393

From pminborg at openjdk.org  Mon Dec 11 07:55:21 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 11 Dec 2023 07:55:21 GMT
Subject: Integrated: 8321387: SegmentAllocator:allocateFrom(AddressLayout,
 MemorySegment) does not throw stated UnsupportedOperationException
In-Reply-To: <f7av5DIVPpT40yTe3Lsk66GxhTQCLXCoCVe1TJH9hjg=.049eba24-4bf8-4ddc-a1a0-e8db117d72b8@github.com>
References: <f7av5DIVPpT40yTe3Lsk66GxhTQCLXCoCVe1TJH9hjg=.049eba24-4bf8-4ddc-a1a0-e8db117d72b8@github.com>
Message-ID: <N0PSX2-8Ep5MnPM1cliBwLg7DSdQgm9b8faegSLy0xs=.8d99be7b-75b9-46df-aa67-e7bed58e3e51@github.com>

On Wed, 6 Dec 2023 13:52:37 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to change the exception type for exceptions thrown for certain methods with a parameter of type `MemorySegment` when it is `MemorySegment::isReadOnly`. Previously an `UnsupportedOperationException` was specified but in some cases, in reality, an `IllegalArgumentException` was thrown. 
> 
> The principle used in this PR is that operations acting on an MS where the MS is `this` should throw an `UnsupportedOperationException` whereas in cases where the MS is a *parameter* an `IllegalArgumentException` should be thrown.
> 
> It should be noted that this PR retains the previous behavior for MS VarHandle access (even though the MS is a parameter to the accessor methods, the first parameter can be said to represent `this`).

This pull request has now been integrated.

Changeset: d13302f8
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d13302f8b06f65319426a25a9368abaf72f3c247
Stats:     103 lines in 10 files changed: 67 ins; 4 del; 32 mod

8321387: SegmentAllocator:allocateFrom(AddressLayout, MemorySegment) does not throw stated UnsupportedOperationException

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/16993

From stefank at openjdk.org  Mon Dec 11 09:21:21 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 11 Dec 2023 09:21:21 GMT
Subject: RFR: 8321713: Harmonize executeTestJvm with
 create[Limited]TestJavaProcessBuilder
Message-ID: <fIIn7OfSFIv_Or1dUx5NasB9s0qgov89khLMR73wFQs=.b026b011-764d-48cc-a728-baf350e1a30a@github.com>

[JDK-8315097](https://bugs.openjdk.org/browse/JDK-8315097): 'Rename createJavaProcessBuilder' changed the name of the ProcessTools helper functions used to create `ProcessBuilder`s used to spawn new java test processes.

We now have `createTestJavaProcessBuilder` and `createLimitedTestJavaProcess`. The former prepends jvm options from jtreg, while the latter doesn't.

With these functions it is common to see the following pattern in tests:

ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...);
OutputAnalyzer output = executeProcess(pb);


We have a couple of thin wrapper in `ProcessTools` that does exactly this, so that the code can be written as a one-liner:

OutputAnalyzer output = ProcessTools.executeTestJvm();


I propose that we name this functions using the same naming scheme we used for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`. That is, we change `executeTestJvm` to `executeTestJava` and add a new `executeLimitedTestJava` function.

-------------

Commit messages:
 - 8321713: Harmonize executeTestJvm with create[Limited]TestJavaProcessBuilder

Changes: https://git.openjdk.org/jdk/pull/17049/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17049&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321713
  Stats: 217 lines in 88 files changed: 28 ins; 1 del; 188 mod
  Patch: https://git.openjdk.org/jdk/pull/17049.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17049/head:pull/17049

PR: https://git.openjdk.org/jdk/pull/17049

From sgehwolf at openjdk.org  Mon Dec 11 09:59:24 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 11 Dec 2023 09:59:24 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v12]
In-Reply-To: <iHvfP1CJRkBYTMEyCGUHvsyWxPHdVp36g49nxbxZfXU=.db86d493-f32e-4faf-a3e5-cf414ac9abbb@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <iHvfP1CJRkBYTMEyCGUHvsyWxPHdVp36g49nxbxZfXU=.db86d493-f32e-4faf-a3e5-cf414ac9abbb@github.com>
Message-ID: <b1mV5ytPzsO0L_eS2FnVO_9Mmaz9fW-y56lK6tKJMjI=.ee24acee-701f-46f3-99f9-79787e21897a@github.com>

On Tue, 5 Dec 2023 19:15:53 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:
> 
>  - Add @enablePreview for JImageValidator that uses classfile API
>  - Fix SystemModulesPlugin after merge
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Don't show the verbose hint when already verbose
>  - Use '_files' over '_resources' as the suffix for listing resources
>  - Remove the hidden option hint.
>    
>    Also adjust the messages being printed when performing
>    a run-time image link.
>  - Localize messages, switch expression
>  - Rename RunImageArchive => JRTArchive and RunImageLinkException => RuntimeImageLinkException
>    
>    Also moved the stamp file to jdk.jlink module. The resources files per
>    module now get unconditionally created (empty if no resources not in the
>    jimage).
>  - First round of addressing review feedback.
>    
>    - Share resource names (JlinkTask and JlinkResourcesListPlugin)
>    - Exclude resources in JlinkResourcesListPlugin the same way
>      as done for other plugins.
>  - Rename AddRunImageResourcesPlugin => JlinkResourcesListPlugin
>  - ... and 36 more: https://git.openjdk.org/jdk/compare/87516e29...a797ea69

> I tried out the latest commit ([a797ea6](https://github.com/openjdk/jdk/commit/a797ea69bc2852a843f2c8cc4d4fcd18f1468682)).

Thanks for trying.
 
> The output "The default module path, '$java.home/jmods' not present. Use --verbose to show the full list of plugin options applied" is bit confusing as it looks like jlink failed but it actually succeeded.

I've changed the message printed for run-time image based links based on [review feedback](https://github.com/openjdk/jdk/pull/14787#issuecomment-1830528390). Happy to change that to whatever seems most amenable.

> Blowing away the generated image and retrying with --verbose tripped this assert
> 
> ```
> java.lang.AssertionError: handling of scratch options failed
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.logPackagedModuleEquivalent(JlinkTask.java:675)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImageProvider(JlinkTask.java:581)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:430)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:302)
> 	at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
> 	at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34)
> Caused by: jdk.tools.jlink.internal.TaskHelper$BadArgs: (...my-original-jdk-directory..)/build/linux-x64/images/jdk/jmods already exists
> 	at jdk.jlink/jdk.tools.jlink.internal.TaskHelper.newBadArgs(TaskHelper.java:730)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.lambda$static$12(JlinkTask.java:183)
> 	at jdk.jlink/jdk.tools.jlink.internal.TaskHelper$Option.process(TaskHelper.java:177)
> 	at jdk.jlink/jdk.tools.jlink.internal.TaskHelper$OptionsHelper.handleOptions(TaskHelper.java:600)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.logPackagedModuleEquivalent(JlinkTask.java:672)
> 	... 5 more
> ```

Could you please provide steps to reproduce this?

> I haven't dug into this yet but I'm puzzled that the file path to where the original build was created is in the exception messages, is that recorded?

Yes, in order to determine the plugin options that are being applied that is needed. I.e. a link using packaged modules - step 1 - will create a `jdk/tools/jlink/internal/cli_cmd.txt` file in the jimage, with the cli options that were used. Those options are then merged with a potential run-time image link - step 2 - after (if `jdk.jlink` was part of the original link) in order to figure out the plug-in options which were used in the packaged modules link step. The goal was to show the equivalent `jlink` command to use when only using packaged modules.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1849709413

From asotona at openjdk.org  Mon Dec 11 10:06:22 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 11 Dec 2023 10:06:22 GMT
Subject: RFR: 8321641: ClassFile
 ModuleAttribute.ModuleAttributeBuilder::moduleVersion spec contains a
 copy-paste error
Message-ID: <Kze5E6kz1NNCDhZY4HHBbYTkrxxFoJrNVDDu1JBzy_0=.d0a55866-f507-4538-bdaa-5477fe10e4f8@github.com>

This is a fix of ClassFile ModuleAttribute.ModuleAttributeBuilder::moduleVersion javadoc copy-paste error.

Please review.

Thanks,
Adam

-------------

Commit messages:
 - 8321641: ClassFile ModuleAttribute.ModuleAttributeBuilder::moduleVersion spec contains a copy-paste error

Changes: https://git.openjdk.org/jdk/pull/17051/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17051&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321641
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17051.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17051/head:pull/17051

PR: https://git.openjdk.org/jdk/pull/17051

From alanb at openjdk.org  Mon Dec 11 10:11:22 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 11 Dec 2023 10:11:22 GMT
Subject: RFR: 8321641: ClassFile
 ModuleAttribute.ModuleAttributeBuilder::moduleVersion spec contains a
 copy-paste error
In-Reply-To: <Kze5E6kz1NNCDhZY4HHBbYTkrxxFoJrNVDDu1JBzy_0=.d0a55866-f507-4538-bdaa-5477fe10e4f8@github.com>
References: <Kze5E6kz1NNCDhZY4HHBbYTkrxxFoJrNVDDu1JBzy_0=.d0a55866-f507-4538-bdaa-5477fe10e4f8@github.com>
Message-ID: <ks0HnmDcaZXft3noFyuRkE0VarJEYU5v6jBLmsgKjbA=.9c818d06-5862-4566-a820-ad2e3a0231c6@github.com>

On Mon, 11 Dec 2023 10:00:45 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This is a fix of ClassFile ModuleAttribute.ModuleAttributeBuilder::moduleVersion javadoc copy-paste error.
> 
> Please review.
> 
> Thanks,
> Adam

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17051#pullrequestreview-1774751827

From asotona at openjdk.org  Mon Dec 11 10:11:23 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 11 Dec 2023 10:11:23 GMT
Subject: Integrated: 8321641: ClassFile
 ModuleAttribute.ModuleAttributeBuilder::moduleVersion spec contains a
 copy-paste error
In-Reply-To: <Kze5E6kz1NNCDhZY4HHBbYTkrxxFoJrNVDDu1JBzy_0=.d0a55866-f507-4538-bdaa-5477fe10e4f8@github.com>
References: <Kze5E6kz1NNCDhZY4HHBbYTkrxxFoJrNVDDu1JBzy_0=.d0a55866-f507-4538-bdaa-5477fe10e4f8@github.com>
Message-ID: <lDwbwkCkm2a_BXfC9GX4TKMnVS8BnuLnA2K-clU8jz8=.73d92df7-1783-44b4-ab1c-68e3dd9ef3db@github.com>

On Mon, 11 Dec 2023 10:00:45 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This is a fix of ClassFile ModuleAttribute.ModuleAttributeBuilder::moduleVersion javadoc copy-paste error.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 3c6459e1
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3c6459e1de9e75898a1b32a95acf684050fbe1af
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8321641: ClassFile ModuleAttribute.ModuleAttributeBuilder::moduleVersion spec contains a copy-paste error

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/17051

From asotona at openjdk.org  Mon Dec 11 10:27:31 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 11 Dec 2023 10:27:31 GMT
Subject: [jdk22] RFR: 8321641: ClassFile
 ModuleAttribute.ModuleAttributeBuilder::moduleVersion spec contains a
 copy-paste error
Message-ID: <yCvzV4jYn8vlfL8yCFOyRbPmRdrgfDmgZLC18pNnx5k=.359a9f6a-77dd-41a6-9d76-3be2e3f4b643@github.com>

8321641: ClassFile ModuleAttribute.ModuleAttributeBuilder::moduleVersion spec contains a copy-paste error

-------------

Commit messages:
 - Backport 3c6459e1de9e75898a1b32a95acf684050fbe1af

Changes: https://git.openjdk.org/jdk22/pull/5/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=5&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321641
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk22/pull/5.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/5/head:pull/5

PR: https://git.openjdk.org/jdk22/pull/5

From stefank at openjdk.org  Mon Dec 11 12:28:40 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 11 Dec 2023 12:28:40 GMT
Subject: RFR: 8321718: ProcessTools.executeProcess calls waitFor before logging
Message-ID: <fK27CacDG-QccKV-QpUT3z9p8eppW4wbw0ALbNCJn5w=.a1b6a824-5a8d-4a99-83ad-147fcd773dbd@github.com>

There is some logging printed when tests spawns processes. This logging is triggered from calls to `OutputAnalyzer`, when it delegates calls to `LazyOutputBuffer`.

If we write code like this:

ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...);
OutputAnalyzer output = new OutputAnalyzer(pb.start());
int exitValue = output.getExitValue();


We get the following logging:

[timestamp0] "Gathering output for process <pid>
[timestamp1] Waiting for completion for process <pid>
[timestamp2] Waiting for completion finished for process <pid>


The first line comes from the `OutputAnalyzer` constructor and the two other lines comes from the `getExitValue` call, which calls logs the above messages around the call to `waitFor`.

If instead write the code above as:

ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...);
OutputAnalyzer output = ProcessTools.executeProcess(pb);
int exitValue = output.getExitValue();


We get the same logging, but timestamp1 and timestamp2 are almost the same. This happens because there's an extra call to `waitFor` inside `executeProcess`, but that `waitFor` does not have the "wait for" logging. So, instead we get the logging for the no-op `waitFor` inside `getExitValue`.

I would like to propose a small workaround to solve this. The workaround is that `executeProcess` delegates the `waitFor` call to the `LazyOutputBuffer` via `OutputAnalyzer`.  This is a small, limited workaround for this issue. Ideally I would like to extract the entire Process handling code out of LazyOutputBuffer and OutputAnalyzer, but the prototype for that rewrites all usages of `new OutputAnalyzer(pb.start())` and stretches far and wide in the test directories, so I'm starting out with this suggestion.

We can see of this patch by looking at the timestamps generated from the included test. Without the proposed workaround:

Without

testExecuteProcessExit
[2023-12-11T11:05:41.854579260Z] Gathering output for process 2547719
[2023-12-11T11:05:44.018335073Z] Waiting for completion for process 2547719
[2023-12-11T11:05:44.018851972Z] Waiting for completion finished for process 2547719

testExecuteProcessStdout
[2023-12-11T11:05:44.049509860Z] Gathering output for process 2547741
[2023-12-11T11:05:46.227768897Z] Waiting for completion for process 2547741
[2023-12-11T11:05:46.228021173Z] Waiting for completion finished for process 2547741


testNewOutputAnalyzerExit
[2023-12-11T11:05:46.231475003Z] Gathering output for process 2547782
[2023-12-11T11:05:46.231972095Z] Waiting for completion for process 2547782
[2023-12-11T11:05:48.421324123Z] Waiting for completion finished for process 2547782

testNewOutputAnalyzerStdout
[2023-12-11T11:05:48.424801269Z] Gathering output for process 2547929


With the proposed workaround:

testExecuteProcessExit
[2023-12-11T11:06:12.203633363Z] Gathering output for process 2550961
[2023-12-11T11:06:12.285826294Z] Waiting for completion for process 2550961
[2023-12-11T11:06:14.361912745Z] Waiting for completion finished for process 2550961

testExecuteProcessStdout
[2023-12-11T11:06:14.398685794Z] Gathering output for process 2550982
[2023-12-11T11:06:14.399518617Z] Waiting for completion for process 2550982
[2023-12-11T11:06:16.595986889Z] Waiting for completion finished for process 2550982

testNewOutputAnalyzerExit
[2023-12-11T11:06:16.602218373Z] Gathering output for process 2551067
[2023-12-11T11:06:16.603176801Z] Waiting for completion for process 2551067
[2023-12-11T11:06:18.793886942Z] Waiting for completion finished for process 2551067

testNewOutputAnalyzerStdout
[2023-12-11T11:06:18.796332176Z] Gathering output for process 2551172


See how the timestamp for "Waiting for completion for process" becomes "earlier" in the "executeProcess" cases.

-------------

Commit messages:
 - Whitespace cleanups
 - 8321718: ProcessTools.executeProcess calls waitFor before logging

Changes: https://git.openjdk.org/jdk/pull/17052/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17052&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321718
  Stats: 159 lines in 4 files changed: 145 ins; 11 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17052.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17052/head:pull/17052

PR: https://git.openjdk.org/jdk/pull/17052

From jvernee at openjdk.org  Mon Dec 11 13:47:30 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 11 Dec 2023 13:47:30 GMT
Subject: RFR: 8321400: java/foreign/TestStubAllocFailure.java fails with code
 cache exhaustion
Message-ID: <GzvkhIYT0Bz6jHuS5o-q_DvNTRCKfj5hqDRHPvN2MxY=.8ce04894-a4e6-4339-9dfb-26a1933d3e59@github.com>

Improve the test by being more lenient to related code cache exhaustion errors. The important thing is that we don't terminate with a fatal error, which the new code now checks for explicitly. The check for that is based on what is done by `./test/hotspot/jtreg/runtime/ErrorHandling/HsErrFileUtils.java` .

The existing `UpcallTestHelper.Output` class that was previously used to assert on stdout/stderr contents did not have the capability to look for patterns in the output. So, I've taken the opportunity to replace it with the more canonical `OutputAnalyzer` which comes from the test library.

Finally, I've also added back the test for downcall stub allocation failure which was removed as part of the initial patch because it was too inconsistent [1]. With the now approach, it should pass reliably as well.

Testing: `jdk_foreign`  suite (which contains all the affected tests)

[1]: https://github.com/openjdk/jdk/pull/16311/commits/9a1360598a91871ce6ec48330849c0e4e0279c64

-------------

Commit messages:
 - use match
 - Improve stub alloc test

Changes: https://git.openjdk.org/jdk/pull/17056/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17056&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321400
  Stats: 106 lines in 7 files changed: 47 ins; 42 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/17056.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17056/head:pull/17056

PR: https://git.openjdk.org/jdk/pull/17056

From jvernee at openjdk.org  Mon Dec 11 13:47:32 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 11 Dec 2023 13:47:32 GMT
Subject: RFR: 8321400: java/foreign/TestStubAllocFailure.java fails with
 code cache exhaustion
In-Reply-To: <GzvkhIYT0Bz6jHuS5o-q_DvNTRCKfj5hqDRHPvN2MxY=.8ce04894-a4e6-4339-9dfb-26a1933d3e59@github.com>
References: <GzvkhIYT0Bz6jHuS5o-q_DvNTRCKfj5hqDRHPvN2MxY=.8ce04894-a4e6-4339-9dfb-26a1933d3e59@github.com>
Message-ID: <UaSTBjDOiNIBjd_o0DwjEx0QVSwuDwy2cFnG-98L7gM=.c925ead4-2319-4c88-98fa-5a9e86356c2f@github.com>

On Mon, 11 Dec 2023 13:01:25 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Improve the test by being more lenient to related code cache exhaustion errors. The important thing is that we don't terminate with a fatal error, which the new code now checks for explicitly. The check for that is based on what is done by `./test/hotspot/jtreg/runtime/ErrorHandling/HsErrFileUtils.java` .
> 
> The existing `UpcallTestHelper.Output` class that was previously used to assert on stdout/stderr contents did not have the capability to look for patterns in the output. So, I've taken the opportunity to replace it with the more canonical `OutputAnalyzer` which comes from the test library.
> 
> Finally, I've also added back the test for downcall stub allocation failure which was removed as part of the initial patch because it was too inconsistent [1]. With the now approach, it should pass reliably as well.
> 
> Testing: `jdk_foreign`  suite (which contains all the affected tests)
> 
> [1]: https://github.com/openjdk/jdk/pull/16311/commits/9a1360598a91871ce6ec48330849c0e4e0279c64

test/jdk/java/foreign/TestStubAllocFailure.java line 64:

> 62:         public static void main(String[] args) throws Throwable {
> 63:             FunctionDescriptor descriptor = FunctionDescriptor.ofVoid();
> 64:             MethodHandle target = MethodHandles.lookup().findStatic(UpcallRunner.class, "target", descriptor.toMethodType());

Here I'm extracting the method handle lookup from the loop to make it more likely that we hit the code path that we are interested in, and don't get another VirtualMachineError due to this method handle lookup.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17056#discussion_r1422479110

From stsypanov at openjdk.org  Mon Dec 11 13:56:50 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 11 Dec 2023 13:56:50 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v9]
In-Reply-To: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
Message-ID: <t_HBR4K_uT5fZ4Njc_2HDTNaISnakvNfJMwwe2h0aF0=.3998926d-88ae-4e4f-9494-c4a8f2dae233@github.com>

> It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`.
> 
> See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612

Sergey Tsypanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:

 - Merge branch 'master' into 8320971
 - 8320971: Rename method
 - 8320971: Extract utility class
 - 8320971: Rearrange code
 - 8320971: Rewrite comment
 - 8320971: Use same approach as BAOS
 - Merge branch 'master' into 8320971
 - 8320971: Add test
 - 8320971: Trust any OutputStream from java.*
 - 8320971: Use BufferedInputStream.class.getPackageName()
 - ... and 1 more: https://git.openjdk.org/jdk/compare/e1615914...2df52c72

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16879/files
  - new: https://git.openjdk.org/jdk/pull/16879/files/f5cf1346..2df52c72

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16879&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16879&range=07-08

  Stats: 11404 lines in 80 files changed: 9535 ins; 1609 del; 260 mod
  Patch: https://git.openjdk.org/jdk/pull/16879.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16879/head:pull/16879

PR: https://git.openjdk.org/jdk/pull/16879

From stefank at openjdk.org  Mon Dec 11 14:03:36 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 11 Dec 2023 14:03:36 GMT
Subject: RFR: 8321713: Harmonize executeTestJvm with
 create[Limited]TestJavaProcessBuilder [v2]
In-Reply-To: <fIIn7OfSFIv_Or1dUx5NasB9s0qgov89khLMR73wFQs=.b026b011-764d-48cc-a728-baf350e1a30a@github.com>
References: <fIIn7OfSFIv_Or1dUx5NasB9s0qgov89khLMR73wFQs=.b026b011-764d-48cc-a728-baf350e1a30a@github.com>
Message-ID: <IZpxVFuHcDUgqatuwHUvYJ9TnqAWSJcztdNhoMrymnM=.b85b4311-14c9-49ce-ad60-29c7427e6410@github.com>

> [JDK-8315097](https://bugs.openjdk.org/browse/JDK-8315097): 'Rename createJavaProcessBuilder' changed the name of the ProcessTools helper functions used to create `ProcessBuilder`s used to spawn new java test processes.
> 
> We now have `createTestJavaProcessBuilder` and `createLimitedTestJavaProcess`. The former prepends jvm options from jtreg, while the latter doesn't.
> 
> With these functions it is common to see the following pattern in tests:
> 
> ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...);
> OutputAnalyzer output = executeProcess(pb);
> 
> 
> We have a couple of thin wrapper in `ProcessTools` that does exactly this, so that the code can be written as a one-liner:
> 
> OutputAnalyzer output = ProcessTools.executeTestJvm();
> 
> 
> I propose that we name this functions using the same naming scheme we used for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`. That is, we change `executeTestJvm` to `executeTestJava` and add a new `executeLimitedTestJava` function.

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Fix impl and add test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17049/files
  - new: https://git.openjdk.org/jdk/pull/17049/files/080caef5..ad072e06

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17049&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17049&range=00-01

  Stats: 54 lines in 2 files changed: 52 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17049.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17049/head:pull/17049

PR: https://git.openjdk.org/jdk/pull/17049

From stefank at openjdk.org  Mon Dec 11 14:06:43 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 11 Dec 2023 14:06:43 GMT
Subject: RFR: 8321713: Harmonize executeTestJvm with
 create[Limited]TestJavaProcessBuilder [v3]
In-Reply-To: <fIIn7OfSFIv_Or1dUx5NasB9s0qgov89khLMR73wFQs=.b026b011-764d-48cc-a728-baf350e1a30a@github.com>
References: <fIIn7OfSFIv_Or1dUx5NasB9s0qgov89khLMR73wFQs=.b026b011-764d-48cc-a728-baf350e1a30a@github.com>
Message-ID: <rOdHN6_YCb1J7nbJbJ3uAZ0_octri-wWhlPPrC04HYQ=.a13d7a73-71f2-403b-8efa-6aa614a0c11e@github.com>

> [JDK-8315097](https://bugs.openjdk.org/browse/JDK-8315097): 'Rename createJavaProcessBuilder' changed the name of the ProcessTools helper functions used to create `ProcessBuilder`s used to spawn new java test processes.
> 
> We now have `createTestJavaProcessBuilder` and `createLimitedTestJavaProcess`. The former prepends jvm options from jtreg, while the latter doesn't.
> 
> With these functions it is common to see the following pattern in tests:
> 
> ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...);
> OutputAnalyzer output = executeProcess(pb);
> 
> 
> We have a couple of thin wrapper in `ProcessTools` that does exactly this, so that the code can be written as a one-liner:
> 
> OutputAnalyzer output = ProcessTools.executeTestJvm();
> 
> 
> I propose that we name this functions using the same naming scheme we used for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`. That is, we change `executeTestJvm` to `executeTestJava` and add a new `executeLimitedTestJava` function.

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Test cleanup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17049/files
  - new: https://git.openjdk.org/jdk/pull/17049/files/ad072e06..5d488f42

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17049&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17049&range=01-02

  Stats: 10 lines in 1 file changed: 1 ins; 8 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17049.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17049/head:pull/17049

PR: https://git.openjdk.org/jdk/pull/17049

From ihse at openjdk.org  Mon Dec 11 14:23:19 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Dec 2023 14:23:19 GMT
Subject: RFR: 8321688: Build on linux with GCC 7.5.0 fails after 8319577
In-Reply-To: <vIByQ06ftSU9o1Rb4YOWXPrry1LkYSj-vJqLXaMXQ5g=.d5a0ea33-f57a-4549-addf-b7a9c5eaa67d@github.com>
References: <vIByQ06ftSU9o1Rb4YOWXPrry1LkYSj-vJqLXaMXQ5g=.d5a0ea33-f57a-4549-addf-b7a9c5eaa67d@github.com>
Message-ID: <-4G8wS-P5WhUxnXC4vTeDDLAnSmofRTzKWuBP79ZXA8=.7b63e694-1076-4a93-bce2-be88c6d2c415@github.com>

On Mon, 11 Dec 2023 02:36:30 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch fixes the building failure introduced by [JDK-8319577](https://bugs.openjdk.org/browse/JDK-8319577) in old GCC version (linux & GCC 7.5.0 locally).
> 
> Thanks for the review.
> 
>  Best Regards,
> -- Guoxiong

Just because a code change cause a compilation error, it does not mean that it is relevant for the build group.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17047#issuecomment-1850175802

From lkorinth at openjdk.org  Mon Dec 11 14:23:19 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 11 Dec 2023 14:23:19 GMT
Subject: RFR: 8321713: Harmonize executeTestJvm with
 create[Limited]TestJavaProcessBuilder [v3]
In-Reply-To: <rOdHN6_YCb1J7nbJbJ3uAZ0_octri-wWhlPPrC04HYQ=.a13d7a73-71f2-403b-8efa-6aa614a0c11e@github.com>
References: <fIIn7OfSFIv_Or1dUx5NasB9s0qgov89khLMR73wFQs=.b026b011-764d-48cc-a728-baf350e1a30a@github.com>
 <rOdHN6_YCb1J7nbJbJ3uAZ0_octri-wWhlPPrC04HYQ=.a13d7a73-71f2-403b-8efa-6aa614a0c11e@github.com>
Message-ID: <AmhDKzZkTwtkN4Wel_dJKdyeaKro8OPEKytNE5zszxw=.356b5728-8b2d-4371-b47d-15386a0ee252@github.com>

On Mon, 11 Dec 2023 14:06:43 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> [JDK-8315097](https://bugs.openjdk.org/browse/JDK-8315097): 'Rename createJavaProcessBuilder' changed the name of the ProcessTools helper functions used to create `ProcessBuilder`s used to spawn new java test processes.
>> 
>> We now have `createTestJavaProcessBuilder` and `createLimitedTestJavaProcess`. The former prepends jvm options from jtreg, while the latter doesn't.
>> 
>> With these functions it is common to see the following pattern in tests:
>> 
>> ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...);
>> OutputAnalyzer output = executeProcess(pb);
>> 
>> 
>> We have a couple of thin wrapper in `ProcessTools` that does exactly this, so that the code can be written as a one-liner:
>> 
>> OutputAnalyzer output = ProcessTools.executeTestJvm();
>> 
>> 
>> I propose that we name this functions using the same naming scheme we used for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`. That is, we change `executeTestJvm` to `executeTestJava` and add a new `executeLimitedTestJava` function.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test cleanup

Looks good to me.

-------------

Marked as reviewed by lkorinth (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17049#pullrequestreview-1775250269

From sgehwolf at openjdk.org  Mon Dec 11 15:04:30 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 11 Dec 2023 15:04:30 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v12]
In-Reply-To: <b1mV5ytPzsO0L_eS2FnVO_9Mmaz9fW-y56lK6tKJMjI=.ee24acee-701f-46f3-99f9-79787e21897a@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <iHvfP1CJRkBYTMEyCGUHvsyWxPHdVp36g49nxbxZfXU=.db86d493-f32e-4faf-a3e5-cf414ac9abbb@github.com>
 <b1mV5ytPzsO0L_eS2FnVO_9Mmaz9fW-y56lK6tKJMjI=.ee24acee-701f-46f3-99f9-79787e21897a@github.com>
Message-ID: <louKvHXu4d4DEWQkCmUN4qrsmAf68lNte7GDoCuFJOg=.333063aa-a3b0-48e8-b05d-e93187ac645e@github.com>

On Mon, 11 Dec 2023 09:56:49 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> > Blowing away the generated image and retrying with --verbose tripped this assert
> > ```
> > java.lang.AssertionError: handling of scratch options failed
> > 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.logPackagedModuleEquivalent(JlinkTask.java:675)
> > 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImageProvider(JlinkTask.java:581)
> > 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:430)
> > 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:302)
> > 	at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
> > 	at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34)
> > Caused by: jdk.tools.jlink.internal.TaskHelper$BadArgs: (...my-original-jdk-directory..)/build/linux-x64/images/jdk/jmods already exists
> > 	at jdk.jlink/jdk.tools.jlink.internal.TaskHelper.newBadArgs(TaskHelper.java:730)
> > 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.lambda$static$12(JlinkTask.java:183)
> > 	at jdk.jlink/jdk.tools.jlink.internal.TaskHelper$Option.process(TaskHelper.java:177)
> > 	at jdk.jlink/jdk.tools.jlink.internal.TaskHelper$OptionsHelper.handleOptions(TaskHelper.java:600)
> > 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.logPackagedModuleEquivalent(JlinkTask.java:672)
> > 	... 5 more
> > ```
> 
> Could you please provide steps to reproduce this?

NVM. Reproduced it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1850253784

From duke at openjdk.org  Mon Dec 11 15:04:31 2023
From: duke at openjdk.org (Markus KARG)
Date: Mon, 11 Dec 2023 15:04:31 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v9]
In-Reply-To: <t_HBR4K_uT5fZ4Njc_2HDTNaISnakvNfJMwwe2h0aF0=.3998926d-88ae-4e4f-9494-c4a8f2dae233@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <t_HBR4K_uT5fZ4Njc_2HDTNaISnakvNfJMwwe2h0aF0=.3998926d-88ae-4e4f-9494-c4a8f2dae233@github.com>
Message-ID: <WyZs0JKvA7aIG-HYMC4Mx1b28PqMBat6k7nLD8MED28=.dfe48d68-4593-48c3-9938-1689321b35de@github.com>

On Mon, 11 Dec 2023 13:56:50 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`.
>> 
>> See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612
>
> Sergey Tsypanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8320971
>  - 8320971: Rename method
>  - 8320971: Extract utility class
>  - 8320971: Rearrange code
>  - 8320971: Rewrite comment
>  - 8320971: Use same approach as BAOS
>  - Merge branch 'master' into 8320971
>  - 8320971: Add test
>  - 8320971: Trust any OutputStream from java.*
>  - 8320971: Use BufferedInputStream.class.getPackageName()
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/c3f8beba...2df52c72

With small changes I am +1 ! :-)

src/java.base/share/classes/java/io/ByteArrayInputStream.java line 212:

> 210:             // 'tmpbuf' is null if and only if 'out' is trusted
> 211:             byte[] tmpbuf;
> 212:             if (IOStreams.isTrusted(out))

IMHO we should use `IOStreams.isTrusted(out)` in BAIS, too.

src/java.base/share/classes/java/io/IOStreams.java line 1:

> 1: /*

Please fix Whitespace errors. Thanks. :-)

src/java.base/share/classes/java/io/IOStreams.java line 26:

> 24:  */
> 25: 
> 26: package java.io;

As this class is implementation-specific to OpenJDK, we should move it into the `com.sun` namespace.

src/java.base/share/classes/java/io/IOStreams.java line 39:

> 37:      * <pre>
> 38:      * - the reference to {@code byte[]} is not kept within the class
> 39:      * - the argument of {@link OutputStream#write(byte[])}} and {@link OutputStream#write(byte[], int, int)}} is not modified within the methods

`- the byte[] is not read outside of the given bounds`

-------------

Marked as reviewed by mkarg at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/16879#pullrequestreview-1775343572
PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1422602610
PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1422596506
PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1422601767
PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1422598809

From avoitylov at openjdk.org  Mon Dec 11 15:08:28 2023
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Mon, 11 Dec 2023 15:08:28 GMT
Subject: RFR: 8321514: UTF16 string gets constructed incorrectly from
 codepoints if CompactStrings is not enabled
Message-ID: <1azLdWceEALX1v_hfgt03ncVu_wtZyk3_lZ0B0J_cto=.a59aff49-50a9-498e-bc78-fd5468d87cd6@github.com>

Since JDK-8311906, if CompactStrings is not enabled, index is not considered when calling extractCodepoints from StringUTF16.toBytes(). Because of that the last elements of the source codepoints array are stripped from the resulting UTF16 string, which fires in other places (e.g. during RegEx processing).
 
The fix replaces len in extractCodepoints parameters with end that is index + len.

-------------

Commit messages:
 - whitespace
 - JDK-8321514 implementation

Changes: https://git.openjdk.org/jdk/pull/17057/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17057&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321514
  Stats: 46 lines in 2 files changed: 45 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17057.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17057/head:pull/17057

PR: https://git.openjdk.org/jdk/pull/17057

From duke at openjdk.org  Mon Dec 11 15:13:39 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 11 Dec 2023 15:13:39 GMT
Subject: RFR: 8321616: Convert the ReadZip test to JUnit
Message-ID: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>

Please review this PR which suggests we rewrite the `../zip/ZipFile/ReadZip.java` test to JUnit. 

The current test is a single main method with a sequence of fairly unrelated scenarios. It would benefit from a rewrite to multiple JUnit test methods and some general modernization and simplification of the code.

-------------

Commit messages:
 - Update copyright year
 - Convert ReadZip to JUnit

Changes: https://git.openjdk.org/jdk/pull/17038/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17038&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321616
  Stats: 222 lines in 1 file changed: 80 ins; 48 del; 94 mod
  Patch: https://git.openjdk.org/jdk/pull/17038.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17038/head:pull/17038

PR: https://git.openjdk.org/jdk/pull/17038

From asotona at openjdk.org  Mon Dec 11 15:23:20 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 11 Dec 2023 15:23:20 GMT
Subject: RFR: 8321540: ClassSignature.parseFrom() throws
 StringIndexOutOfBoundsException for invalid signatures
Message-ID: <t_7SgYfeuUPXZZC847NRMi90LGYdU0iBG6qCRrUkwmo=.2a2be1af-55a5-42d1-b883-66df0f974ac4@github.com>

ClassFile API models and parses signatures, however parsing of the signatures mostly throws IIOBE when it fails.
This patch improves SignaturesImpl parsing methods implementation and errors handling and adds relevant negative tests.
The parser is not an ultimate signatures validator yet, however this is a step forward to it.

Please review.

Thanks,
Adam

-------------

Commit messages:
 - 8321540: ClassSignature.parseFrom() throws StringIndexOutOfBoundsException for invalid signatures

Changes: https://git.openjdk.org/jdk/pull/17058/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17058&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321540
  Stats: 134 lines in 2 files changed: 103 ins; 5 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/17058.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17058/head:pull/17058

PR: https://git.openjdk.org/jdk/pull/17058

From abimpoudis at openjdk.org  Mon Dec 11 16:08:53 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 11 Dec 2023 16:08:53 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v34]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <5d4KAKHRi3RXoFSlZ6FtQx6OKetrSwnBU8XP1AbAhhY=.e1f9236c-e039-4bc4-838a-38a43caff265@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

Aggelos Biboudis has updated the pull request incrementally with 11 additional commits since the last revision:

 - Merge branch 'primitive-patterns-and-generating-dispatch' into primitive-patterns
 - Fixed switch in the cases of unboxing and widening
 - Merge branch 'JDK-8319220' into primitive-patterns
 - Merge branch 'master' into JDK-8319220
 - reflecting review comment: fixing letter case.
 - Reflecting review feedback.
 - Some more get->orElseThrow
 - Reflecting review feedback.
 - Avoiding generating dead code - review feedback.
 - Cleanup.
 - ... and 1 more: https://git.openjdk.org/jdk/compare/2b2405cc...fac9ca98

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/2b2405cc..fac9ca98

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=33
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=32-33

  Stats: 689 lines in 5 files changed: 423 ins; 222 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From abimpoudis at openjdk.org  Mon Dec 11 16:16:45 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 11 Dec 2023 16:16:45 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v35]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <YzWv2vncQQYO1qA4ALZd9x-uEVpkgRdAzoKiP9dvSqo=.b750b800-7fd4-4b0e-86bc-eab1813cd571@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Remove trailing spaces

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/fac9ca98..4fbdd708

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=34
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=33-34

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From pminborg at openjdk.org  Mon Dec 11 16:33:34 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 11 Dec 2023 16:33:34 GMT
Subject: [jdk22] RFR: 8321387: SegmentAllocator:allocateFrom(AddressLayout,
 MemorySegment) does not throw stated UnsupportedOperationException
Message-ID: <a1ASpXA5RU1dwhyWRjuwaLt5wx9Aou-ufUwtYYEB_ec=.31a145b6-d0a0-405e-a849-6b72e343b479@github.com>

This PR is a backport of https://github.com/openjdk/jdk/pull/16993

-------------

Commit messages:
 - Backport d13302f8b06f65319426a25a9368abaf72f3c247

Changes: https://git.openjdk.org/jdk22/pull/7/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=7&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321387
  Stats: 103 lines in 10 files changed: 67 ins; 4 del; 32 mod
  Patch: https://git.openjdk.org/jdk22/pull/7.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/7/head:pull/7

PR: https://git.openjdk.org/jdk22/pull/7

From sgehwolf at openjdk.org  Mon Dec 11 16:37:38 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 11 Dec 2023 16:37:38 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v13]
In-Reply-To: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
Message-ID: <1VoNUv8RTXkFcv411pVhC0E3AEZfsp_8EZNXn4IyP5M=.09425f9b-a6b4-4ed0-b659-09cf7aa4adba@github.com>

> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app b
 eing modularized).
> 
> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
> 
> Basic usage example:
> 
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
> $ ls ../linux-x86_64-server-release/images/jdk/jmods
> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.internal.vm.compiler.manage...

Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:

 - Disallow packaged modules and run-time image link
 - Only check for existing path when not a scratch task
   
   When using a run-time image link and the initial build was produced with
   the --keep-packaged-modules option, we don't need to check existing
   paths to the location where packaged modules need to be copied. This
   breaks the --verbose output validation.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14787/files
  - new: https://git.openjdk.org/jdk/pull/14787/files/a797ea69..821857ab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=11-12

  Stats: 17 lines in 2 files changed: 15 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787

PR: https://git.openjdk.org/jdk/pull/14787

From pminborg at openjdk.org  Mon Dec 11 16:46:20 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 11 Dec 2023 16:46:20 GMT
Subject: [jdk22] Integrated: 8321387:
 SegmentAllocator:allocateFrom(AddressLayout,
 MemorySegment) does not throw stated UnsupportedOperationException
In-Reply-To: <a1ASpXA5RU1dwhyWRjuwaLt5wx9Aou-ufUwtYYEB_ec=.31a145b6-d0a0-405e-a849-6b72e343b479@github.com>
References: <a1ASpXA5RU1dwhyWRjuwaLt5wx9Aou-ufUwtYYEB_ec=.31a145b6-d0a0-405e-a849-6b72e343b479@github.com>
Message-ID: <sQlzvRo-PXov8TRJa83BSJFuWqEH6anDtFoAP49V0Mg=.8e91a62e-1cd2-427a-9a2d-9140e5ec0c5a@github.com>

On Mon, 11 Dec 2023 16:26:52 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR is a backport of https://github.com/openjdk/jdk/pull/16993

This pull request has now been integrated.

Changeset: e88a0220
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/e88a02207240b848de5aaa6aae2c64b732fded48
Stats:     103 lines in 10 files changed: 67 ins; 4 del; 32 mod

8321387: SegmentAllocator:allocateFrom(AddressLayout, MemorySegment) does not throw stated UnsupportedOperationException

Reviewed-by: mcimadamore
Backport-of: d13302f8b06f65319426a25a9368abaf72f3c247

-------------

PR: https://git.openjdk.org/jdk22/pull/7

From mcimadamore at openjdk.org  Mon Dec 11 16:46:19 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 11 Dec 2023 16:46:19 GMT
Subject: [jdk22] RFR: 8321387: SegmentAllocator:allocateFrom(AddressLayout, 
 MemorySegment) does not throw stated UnsupportedOperationException
In-Reply-To: <a1ASpXA5RU1dwhyWRjuwaLt5wx9Aou-ufUwtYYEB_ec=.31a145b6-d0a0-405e-a849-6b72e343b479@github.com>
References: <a1ASpXA5RU1dwhyWRjuwaLt5wx9Aou-ufUwtYYEB_ec=.31a145b6-d0a0-405e-a849-6b72e343b479@github.com>
Message-ID: <UvYEqxM0aeq7ecoXghXot9FwNAW5fveGIs0flwfNTfA=.a415aa75-b40e-4e62-9337-b596e1c28ff1@github.com>

On Mon, 11 Dec 2023 16:26:52 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR is a backport of https://github.com/openjdk/jdk/pull/16993

Looks good (already approved in master)

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk22/pull/7#pullrequestreview-1775633794

From lancea at openjdk.org  Mon Dec 11 16:54:20 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 11 Dec 2023 16:54:20 GMT
Subject: RFR: 8321616: Convert the ReadZip test to JUnit
In-Reply-To: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
References: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
Message-ID: <nqc8WRQ-VshH7FVKGgZL7Ub7ZQalJ5Is7_3xrUPxB4M=.5fe2d329-6084-426e-979d-45bf322541b2@github.com>

On Fri, 8 Dec 2023 20:28:20 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Please review this PR which suggests we rewrite the `../zip/ZipFile/ReadZip.java` test to JUnit. 
> 
> The current test is a single main method with a sequence of fairly unrelated scenarios. It would benefit from a rewrite to multiple JUnit test methods and some general modernization and simplification of the code.

Thank you for tacking the conversion of this test to junit

One quick comment, if we are updating this test, we should look to get rid of input.zip which means we should also address as part of the change:

open/test/jdk/java/util/zip/ZipFile/EnumAfterClose.java
open/test/jdk/java/util/zip/ZipFile/FinalizeInflater.java
open/test/jdk/java/util/zip/ZipFile/StreamZipEntriesTest.java

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17038#issuecomment-1850472569

From sgehwolf at openjdk.org  Mon Dec 11 16:54:27 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 11 Dec 2023 16:54:27 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v12]
In-Reply-To: <louKvHXu4d4DEWQkCmUN4qrsmAf68lNte7GDoCuFJOg=.333063aa-a3b0-48e8-b05d-e93187ac645e@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <iHvfP1CJRkBYTMEyCGUHvsyWxPHdVp36g49nxbxZfXU=.db86d493-f32e-4faf-a3e5-cf414ac9abbb@github.com>
 <b1mV5ytPzsO0L_eS2FnVO_9Mmaz9fW-y56lK6tKJMjI=.ee24acee-701f-46f3-99f9-79787e21897a@github.com>
 <louKvHXu4d4DEWQkCmUN4qrsmAf68lNte7GDoCuFJOg=.333063aa-a3b0-48e8-b05d-e93187ac645e@github.com>
Message-ID: <inEVX9xQQ4X5SW7izVTo6gN_8mxOmaIb0R1RChOVUTA=.846696a7-c3ea-4f68-8712-4e3ab508e998@github.com>

On Mon, 11 Dec 2023 15:01:06 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> NVM. Reproduced it.

... and fixed with [b21585b](https://github.com/openjdk/jdk/pull/14787/commits/b21585bac17cdfe46ac3f2f6587b8a6b43a1cd56)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1850473199

From abimpoudis at openjdk.org  Mon Dec 11 17:14:02 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 11 Dec 2023 17:14:02 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v36]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <OCO29M0KzQHiTs60MP_uLMtH_w9rbPe0QhVt4R7BNMM=.ba3ae0f4-3c80-45b6-9240-63cc37e6ead6@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 52 commits:

 - Merge branch 'master' into primitive-patterns
 - Remove trailing spaces
 - Merge branch 'primitive-patterns-and-generating-dispatch' into primitive-patterns
 - Fixed switch in the cases of unboxing and widening
 - Merge branch 'JDK-8319220' into primitive-patterns
 - Merge branch 'master' into JDK-8319220
 - reflecting review comment: fixing letter case.
 - Reflecting review feedback.
 - Some more get->orElseThrow
 - Reflecting review feedback.
 - ... and 42 more: https://git.openjdk.org/jdk/compare/b270f30d...65457894

-------------

Changes: https://git.openjdk.org/jdk/pull/15638/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=35
  Stats: 3258 lines in 41 files changed: 2995 ins; 109 del; 154 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From duke at openjdk.org  Mon Dec 11 17:26:41 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 11 Dec 2023 17:26:41 GMT
Subject: RFR: 8321616: Convert the ReadZip test to JUnit
In-Reply-To: <nqc8WRQ-VshH7FVKGgZL7Ub7ZQalJ5Is7_3xrUPxB4M=.5fe2d329-6084-426e-979d-45bf322541b2@github.com>
References: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
 <nqc8WRQ-VshH7FVKGgZL7Ub7ZQalJ5Is7_3xrUPxB4M=.5fe2d329-6084-426e-979d-45bf322541b2@github.com>
Message-ID: <hRfJwrmX3Kxh3SFSSulpJlBSOvMulF_Ni40-g-FPBLg=.a725bbd9-c53e-4e1f-b360-4c08fea4a9c7@github.com>

On Mon, 11 Dec 2023 16:51:28 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> One quick comment, if we are updating this test, we should look to get rid of input.zip 

I started going down that road, but felt uneasy about the amount of unrelated changes in a single PR. I'd like to make efficient use of reviewer time, so my preference was to focus on the JUnit conversion, without too many other changes.

If you prefer that we get rid of input.zip and also convert the affected tests to JUnit in the same PR, then I'm happy to switch strategy.

Note that `StreamZipEntriesTest` also uses `input.jar`, this is also read by `Available`, `CopyJar`, `GetDirEntry`, `ReleaseInflater`. Should we get rid of `input.jar` as well, or perhaps defer that to a follow-up?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17038#issuecomment-1850524996

From lancea at openjdk.org  Mon Dec 11 17:43:32 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 11 Dec 2023 17:43:32 GMT
Subject: RFR: 8321616: Convert the ReadZip test to JUnit
In-Reply-To: <hRfJwrmX3Kxh3SFSSulpJlBSOvMulF_Ni40-g-FPBLg=.a725bbd9-c53e-4e1f-b360-4c08fea4a9c7@github.com>
References: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
 <nqc8WRQ-VshH7FVKGgZL7Ub7ZQalJ5Is7_3xrUPxB4M=.5fe2d329-6084-426e-979d-45bf322541b2@github.com>
 <hRfJwrmX3Kxh3SFSSulpJlBSOvMulF_Ni40-g-FPBLg=.a725bbd9-c53e-4e1f-b360-4c08fea4a9c7@github.com>
Message-ID: <YwLtHDhz_pWtO1B_wlJfnE0vJOjjPKZdkXuhtSEu9b0=.521c0e50-8f5d-4673-a037-88cb4a17ef92@github.com>

On Mon, 11 Dec 2023 17:22:14 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> > One quick comment, if we are updating this test, we should look to get rid of input.zip
> 
> I started going down that road, but felt uneasy about the amount of unrelated changes in a single PR. I'd like to make efficient use of reviewer time, so my preference was to focus on the JUnit conversion, without too many other changes.
> 
> If you prefer that we get rid of input.zip and also convert the affected tests to JUnit in the same PR, then I'm happy to switch strategy.
> 
> Note that `StreamZipEntriesTest` also uses `input.jar`, this is also read by `Available`, `CopyJar`, `GetDirEntry`, `ReleaseInflater`. Should we get rid of `input.jar` as well, or perhaps defer that to a follow-up?

input.zip and input.jar are pretty trivial:
>  jar tvf  test/jdk/java/util/zip/ZipFile/input.zip
>    506 Fri May 28 16:32:31 EDT 1999 ReadZip.java
>  jar tvf  test/jdk/java/util/zip/ZipFile/input.jar 
>      0 Tue Mar 23 13:09:08 EST 1999 META-INF/
>     86 Tue Mar 23 13:09:08 EST 1999 META-INF/MANIFEST.MF
>    728 Tue Mar 23 13:08:30 EST 1999 ReleaseInflater.java

So you could have the tests create the zip files on the fly or store the contents in an array within the tests.

If the tests create the zip file/jar on the fly, then we just need to make sure that we create it in the same fashion as the test needs.

I just think that we should take this opportunity as part of re-writing the tests to remove the need for the binary files in the workspace.

I don't have a preference whether we deal with input.jar separately, but these tests are not that complex so I do not see a risk if they are all converted at once, or done piece meal

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17038#issuecomment-1850559536

From duke at openjdk.org  Mon Dec 11 17:48:25 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 11 Dec 2023 17:48:25 GMT
Subject: RFR: 8321616: Convert the ReadZip test to JUnit
In-Reply-To: <YwLtHDhz_pWtO1B_wlJfnE0vJOjjPKZdkXuhtSEu9b0=.521c0e50-8f5d-4673-a037-88cb4a17ef92@github.com>
References: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
 <nqc8WRQ-VshH7FVKGgZL7Ub7ZQalJ5Is7_3xrUPxB4M=.5fe2d329-6084-426e-979d-45bf322541b2@github.com>
 <hRfJwrmX3Kxh3SFSSulpJlBSOvMulF_Ni40-g-FPBLg=.a725bbd9-c53e-4e1f-b360-4c08fea4a9c7@github.com>
 <YwLtHDhz_pWtO1B_wlJfnE0vJOjjPKZdkXuhtSEu9b0=.521c0e50-8f5d-4673-a037-88cb4a17ef92@github.com>
Message-ID: <MXWKJNJ3xfYnadDSR_UgwzGIjHmxxUJjf5jHc_DT0Tc=.cd854d10-e75e-4c22-a9ce-0ed1d2367fd0@github.com>

On Mon, 11 Dec 2023 17:40:24 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> I don't have a preference whether we deal with input.jar separately, but these tests are not that complex so I do not see a risk if they are all converted at once, or done piece meal

Thanks, I'll extend the goal of this PR to remove `input.jar`, `input.zip` and convert affected tests to JUnit along the way.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17038#issuecomment-1850570227

From naoto at openjdk.org  Mon Dec 11 17:58:45 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 11 Dec 2023 17:58:45 GMT
Subject: RFR: 8321206: Make Locale related system properties
 `StaticProperty` [v2]
In-Reply-To: <CcKGxJp4T09SzhWQ3TBXPqH5TBPb9GbD6QRO0opn8Pg=.3054f472-f801-4846-bbfb-5f29cc8e8512@github.com>
References: <EKzdSEIjrFq0mXKLGOdRCePeu29DWWQnpAY5FDVAK40=.3bcd4037-e3e5-4cf1-948d-665355914106@github.com>
 <CcKGxJp4T09SzhWQ3TBXPqH5TBPb9GbD6QRO0opn8Pg=.3054f472-f801-4846-bbfb-5f29cc8e8512@github.com>
Message-ID: <JEyQB0otOZ2W1aisHOayzgUdJKrZPP61khnYSWYl_AU=.ca49be72-0b8a-4801-b21d-0d0bca878319@github.com>

On Wed, 6 Dec 2023 20:55:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Currently, Locale-related system properties, such as `user.language` or `user.country`, are initialized when the `Locale` class is loaded. Making them static properties is safer than relying on the `Locale` class loading timing, which could potentially be changed depending on the implementation.
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Reflects review comments
>  - Merge branch 'master' into JDK-8321206-Locale-static-properties
>  - Add exclusions in cdsHeapVerifier for new StaticProperties
>  - initial commit

Sorry. I forgot the required reviewers' number differs in the hotspot. Let me know if a JBS issue is needed for further modifying the exclusion reasoning.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16986#issuecomment-1850588085

From luhenry at openjdk.org  Mon Dec 11 18:28:44 2023
From: luhenry at openjdk.org (Ludovic Henry)
Date: Mon, 11 Dec 2023 18:28:44 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v6]
In-Reply-To: <AnHvp-NR-sLPEha8BivPv-pBAmquGjSge4TIludLVHM=.e2866a94-78bb-40d7-8506-9807c5a3d786@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
 <3cK9QjVQNIgZoWWhrWKEb3XxfbLjprjRMBbStWegH7M=.6df92651-b97d-445a-aa42-302ea791bbea@github.com>
 <lQJoZ_hXjfLO-MRGDLar9L0yD6xAXF1QAu2AIAjwnKk=.390b6b58-3e5d-42af-90e6-2dd76b29172f@github.com>
 <AnHvp-NR-sLPEha8BivPv-pBAmquGjSge4TIludLVHM=.e2866a94-78bb-40d7-8506-9807c5a3d786@github.com>
Message-ID: <l5WD1cEIW8M7NHd72gK16F1_2cglU3Leeie4zdyCdR4=.6bb73168-2f49-4091-960c-e332694586fa@github.com>

On Mon, 4 Dec 2023 11:58:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I can't say anything for sure, but I picked up some positive vibes from our internal chat. I think the idea was that libsleef could potentially cover up vector math for all platforms that the current Intel lib solution is missing (basically, everything but linux+windows x64). So I this can be seen as a bit of a trial balloon if it is worth a more complete integration of libsleef in the JDK.

I can add that we are interested to use that for Linux + RISC-V support given the RISC-V support was recently merged into sleef upstream. https://github.com/shibatch/sleef/pull/477

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1850636984

From naoto at openjdk.org  Mon Dec 11 19:02:01 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 11 Dec 2023 19:02:01 GMT
Subject: RFR: 8320919: Clarify Locale related system properties
Message-ID: <IruGxIK9DXnXFDANt1y4sCMJEGZh1PTOKhOWZZxJEdc=.77092e02-fb4f-4c9e-8d53-0fa0cf3bae7d@github.com>

This is a doc change to clarify what the `Default Locale` is, and how it is established during the system startup using the system properties. Those locale-related system properties have existed since the early days of Java, but have never been publicly documented before. It is also the intention of this PR to clarify those system properties and how they are overridden. A corresponding CSR has been drafted.

-------------

Commit messages:
 - 6th draft
 - 5th draft
 - 4th draft
 - 3rd draft
 - 2nd draft
 - initial commt

Changes: https://git.openjdk.org/jdk/pull/17065/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17065&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8320919
  Stats: 81 lines in 1 file changed: 71 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/17065.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17065/head:pull/17065

PR: https://git.openjdk.org/jdk/pull/17065

From rriggs at openjdk.org  Mon Dec 11 19:30:23 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 11 Dec 2023 19:30:23 GMT
Subject: RFR: 8321514: UTF16 string gets constructed incorrectly from
 codepoints if CompactStrings is not enabled
In-Reply-To: <1azLdWceEALX1v_hfgt03ncVu_wtZyk3_lZ0B0J_cto=.a59aff49-50a9-498e-bc78-fd5468d87cd6@github.com>
References: <1azLdWceEALX1v_hfgt03ncVu_wtZyk3_lZ0B0J_cto=.a59aff49-50a9-498e-bc78-fd5468d87cd6@github.com>
Message-ID: <1NqqLhE0JjA-tXXDJ3Hxuz9ilDJCVCpVXzKy6vcrp6o=.71ca3d7c-05ae-466c-b15c-0dd070b04f3c@github.com>

On Mon, 11 Dec 2023 13:48:18 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

> Since JDK-8311906, if CompactStrings is not enabled, index is not considered when calling extractCodepoints from StringUTF16.toBytes(). Because of that the last elements of the source codepoints array are stripped from the resulting UTF16 string, which fires in other places (e.g. during RegEx processing).
>  
> The fix replaces len in extractCodepoints parameters with end that is index + len.

Thanks for tracking down this issue, it exposes a gap in the testing.
The fix looks fine.
The test is very specific to a particular use case.
I suggest adding a new test in PR#17066.
If it is suitable, pull it into the PR.

-------------

PR Review: https://git.openjdk.org/jdk/pull/17057#pullrequestreview-1776011326

From abimpoudis at openjdk.org  Mon Dec 11 19:44:01 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 11 Dec 2023 19:44:01 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v37]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <9ldTg1DpAuh8op3uQxpkt_9nXPHbvC8q-re-55L_lsU=.6b4019f2-b5ef-46da-bc9d-dde8308d2f3d@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/65457894..7a71ffa9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=36
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=35-36

  Stats: 12 lines in 1 file changed: 0 ins; 11 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From naoto at openjdk.org  Mon Dec 11 19:45:36 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 11 Dec 2023 19:45:36 GMT
Subject: RFR: 8321480: ISO 4217 Amendment 176 Update [v2]
In-Reply-To: <qbVDj_d2TOhj5-mHcBLKpc8lN6zTnhCP2UYi_h70Kxg=.b2ddfb6f-3cb2-4c15-93a3-6ff90c516501@github.com>
References: <kLWpfbMrAiEskU8JqeFoGaEBzx1aTHI_vq5gxjjdoVw=.2b1af423-59c7-44e8-b4d4-deca303ec2a8@github.com>
 <qbVDj_d2TOhj5-mHcBLKpc8lN6zTnhCP2UYi_h70Kxg=.b2ddfb6f-3cb2-4c15-93a3-6ff90c516501@github.com>
Message-ID: <cROvCurRl8Y1VrlwwovzSqkHowlQBc91xb3W6Qfm77M=.b84ba5f4-e2a1-4043-b890-09bccb81dab6@github.com>

On Mon, 11 Dec 2023 03:03:44 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which incorporates the ISO 4217 Amendment 176 Update. As the replacement of `ANG` to `XCG` won't occur until 2025, this change does not need to go into JDK22. `HR` was also updated to remove the past cutover dates.
>> 
>> An existing test in _ValidateISO4217.java_ checked that `Currency::getAvailableCurrencies` had all the expected currencies. This method returns all currencies, including ones to take place in the future (e.g. `XCG`). The expected currencies `Set` the method was test against had to be updated to also include future currencies as well.
>> 
>> Additionally, this change also converted a parameterized test to a normal JUnit test, due to output overflow.
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into 8321480-ISO4217-176
>  - add comment
>  - reflect review comments
>  - add xcg to CurrencyNames
>  - init

make/jdk/src/classes/build/tools/generatecurrencydata/GenerateCurrencyData.java line 347:

> 345:             // otherwise it will leak out into Currency:getAvailableCurrencies
> 346:             boolean notFutureCurrency = !Arrays.asList(specialCaseNewCurrencies).contains(currencyCode);
> 347:             boolean notSimpleCurrency = tableEntry == INVALID_COUNTRY_ENTRY

I'd rather not bundle up those conditions into `notSimpleCurrency`, as it obscures the other two cases. Simply OR-ing those conditions and `notFutureCurrency` ( or `!futureCurrency` may be more readable) would be sufficient IMO.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17023#discussion_r1423036797

From naoto at openjdk.org  Mon Dec 11 19:45:40 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 11 Dec 2023 19:45:40 GMT
Subject: RFR: 8321480: ISO 4217 Amendment 176 Update [v2]
In-Reply-To: <xLAOF_anhwmtVxg80QM2Kg9NdzcEMBM8GznHEUnMn9w=.153ddf67-ae74-4948-a1fc-f2f1697a3b3f@github.com>
References: <kLWpfbMrAiEskU8JqeFoGaEBzx1aTHI_vq5gxjjdoVw=.2b1af423-59c7-44e8-b4d4-deca303ec2a8@github.com>
 <YJ3f4NQyWkLM6xaR_zIU039s-AWMaDZhXC0HXZATN04=.bec227f8-9a88-4a92-b807-9e0fc720125d@github.com>
 <xLAOF_anhwmtVxg80QM2Kg9NdzcEMBM8GznHEUnMn9w=.153ddf67-ae74-4948-a1fc-f2f1697a3b3f@github.com>
Message-ID: <nkZM6gEJoCsBHcQcdx2hPMTbr2rnWZXzpZjbazd1qfM=.aad5365c-9597-418f-986e-a070f77b8a42@github.com>

On Mon, 11 Dec 2023 02:59:02 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> test/jdk/java/util/Currency/ValidateISO4217.java line 181:
>> 
>>> 179:                     // without updating ISO4217Codes
>>> 180:                     String futureCurr = tokens.nextToken();
>>> 181:                     testCurrencies.add(Currency.getInstance(futureCurr));
>> 
>> I'd not add the future currency, and fix it in the code not to add future currency in available currencies.
>
> Updated the Currency build process to disallow any Currencies that are future Currencies. This prevents the future currency, "XCG" from leaking out into `Currency.getAvailableCurrencies()`. (This was only exposed now, since the previous future Currencies were already ones expected to be found in `Currency.getAvailableCurrencies()`. For example, Amendment 174 where HRK was replaced by EUR.
> 
> (Tiers 1-5 clean with this change)

IIUC, this should have happened before, as a currency update like "XXA" -> "XXB" on a future date is pretty usual. I think this issue was simply not discovered by any users till now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17023#discussion_r1423040892

From stsypanov at openjdk.org  Mon Dec 11 19:58:27 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 11 Dec 2023 19:58:27 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v9]
In-Reply-To: <WyZs0JKvA7aIG-HYMC4Mx1b28PqMBat6k7nLD8MED28=.dfe48d68-4593-48c3-9938-1689321b35de@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <t_HBR4K_uT5fZ4Njc_2HDTNaISnakvNfJMwwe2h0aF0=.3998926d-88ae-4e4f-9494-c4a8f2dae233@github.com>
 <WyZs0JKvA7aIG-HYMC4Mx1b28PqMBat6k7nLD8MED28=.dfe48d68-4593-48c3-9938-1689321b35de@github.com>
Message-ID: <0ate3u4LIF3vjOJsRw5TLNQn4qIRNNNT_VUTGu1g6hI=.f41de4d9-c0ae-4179-941a-d7f55c184067@github.com>

On Mon, 11 Dec 2023 14:54:37 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8320971
>>  - 8320971: Rename method
>>  - 8320971: Extract utility class
>>  - 8320971: Rearrange code
>>  - 8320971: Rewrite comment
>>  - 8320971: Use same approach as BAOS
>>  - Merge branch 'master' into 8320971
>>  - 8320971: Add test
>>  - 8320971: Trust any OutputStream from java.*
>>  - 8320971: Use BufferedInputStream.class.getPackageName()
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/2ac25f70...2df52c72
>
> src/java.base/share/classes/java/io/IOStreams.java line 1:
> 
>> 1: /*
> 
> Please fix Whitespace errors. Thanks. :-)

I've just copy-pasted the header from another class. How should I fix it?

> src/java.base/share/classes/java/io/IOStreams.java line 39:
> 
>> 37:      * <pre>
>> 38:      * - the reference to {@code byte[]} is not kept within the class
>> 39:      * - the argument of {@link OutputStream#write(byte[])}} and {@link OutputStream#write(byte[], int, int)}} is not modified within the methods
> 
> `- the byte[] is not read outside of the given bounds`

Added

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1423051206
PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1423052717

From stsypanov at openjdk.org  Mon Dec 11 20:13:00 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 11 Dec 2023 20:13:00 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v10]
In-Reply-To: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
Message-ID: <gC0rXkYEqqDcSQztxNFC66RC09m6jXpT33xlr0Reae0=.caa756e0-cd7b-45c2-8a82-fe0aa3ab7976@github.com>

> It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`.
> 
> See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  8320971: Move IOStreams to com.sun.io

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16879/files
  - new: https://git.openjdk.org/jdk/pull/16879/files/2df52c72..3576a172

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16879&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16879&range=08-09

  Stats: 113 lines in 4 files changed: 60 ins; 53 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16879.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16879/head:pull/16879

PR: https://git.openjdk.org/jdk/pull/16879

From stsypanov at openjdk.org  Mon Dec 11 20:13:04 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 11 Dec 2023 20:13:04 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v9]
In-Reply-To: <WyZs0JKvA7aIG-HYMC4Mx1b28PqMBat6k7nLD8MED28=.dfe48d68-4593-48c3-9938-1689321b35de@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <t_HBR4K_uT5fZ4Njc_2HDTNaISnakvNfJMwwe2h0aF0=.3998926d-88ae-4e4f-9494-c4a8f2dae233@github.com>
 <WyZs0JKvA7aIG-HYMC4Mx1b28PqMBat6k7nLD8MED28=.dfe48d68-4593-48c3-9938-1689321b35de@github.com>
Message-ID: <xf8uLxck-PHXDF1_hCv-ia7uGE5Ns8Srlu8T4q-QYG8=.3e07c338-ba6f-44a7-979b-3295c7167052@github.com>

On Mon, 11 Dec 2023 14:58:57 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8320971
>>  - 8320971: Rename method
>>  - 8320971: Extract utility class
>>  - 8320971: Rearrange code
>>  - 8320971: Rewrite comment
>>  - 8320971: Use same approach as BAOS
>>  - Merge branch 'master' into 8320971
>>  - 8320971: Add test
>>  - 8320971: Trust any OutputStream from java.*
>>  - 8320971: Use BufferedInputStream.class.getPackageName()
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/eacded64...2df52c72
>
> src/java.base/share/classes/java/io/ByteArrayInputStream.java line 212:
> 
>> 210:             // 'tmpbuf' is null if and only if 'out' is trusted
>> 211:             byte[] tmpbuf;
>> 212:             if (IOStreams.isTrusted(out))
> 
> IMHO we should use `IOStreams.isTrusted(out)` in BAIS, too.

BAIS - ByteArrayInputStream? It's already there

> src/java.base/share/classes/java/io/IOStreams.java line 26:
> 
>> 24:  */
>> 25: 
>> 26: package java.io;
> 
> As this class is implementation-specific to OpenJDK, we should move it into the `com.sun` namespace.

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1423065992
PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1423064118

From stsypanov at openjdk.org  Mon Dec 11 20:34:29 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 11 Dec 2023 20:34:29 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v11]
In-Reply-To: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
Message-ID: <sy0uY02jl7CKM_34Fc4zOMuK9sIKfrHmMouUY4MdPrM=.1017646d-778b-4b14-8eba-615dfb57480f@github.com>

> It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`.
> 
> See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  8320971: Fix build

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16879/files
  - new: https://git.openjdk.org/jdk/pull/16879/files/3576a172..50e4e4e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16879&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16879&range=09-10

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16879.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16879/head:pull/16879

PR: https://git.openjdk.org/jdk/pull/16879

From duke at openjdk.org  Mon Dec 11 21:19:41 2023
From: duke at openjdk.org (Vladimir Yaroslavskiy)
Date: Mon, 11 Dec 2023 21:19:41 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v11]
In-Reply-To: <-bYhysKjQVb_ZS0I0YutJZ7umfYwbs74rtK6-d2qL9U=.f9981e59-f0c4-48f3-ad7e-5627aad00919@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 <i1cu_VA2najjcZHepAbvkWGtVzuLMsdYFKssI5s-TFA=.be96a1ac-1eba-4b7f-bde9-1214082eb6c6@github.com>
 <Gb1pFf-YBbIZdSO-XvQ54xqE5SvNezsl9WSHikEOEJA=.90ccd95f-4a79-4a3e-91a0-23eb83107937@github.com>
 <e8rv_97mAYHGXeRhI8dirZDJsn9ecO2gM91t1LCxnWI=.21859a35-93b8-449c-b4f8-d9dfc0912a7e@github.com>
 <m_FlD1imWi57n0EqQXsrFue-FkO4D1hIbHUI2ph5d6o=.3fcdbf05-7147-4461-8d8e-6947f6f18d62@github.com>
 <C9cdmmBTW6uphtzkL9BdV4DboIuwNF6M-UMnC3xM8vg=.2aa0c11c-cb22-445f-86f6-281c6ab6368c@github.com>
 <-bYhysKjQVb_ZS0I0YutJZ7umfYwbs74rtK6-d2qL9U=.f9981e59-f0c4-48f3-ad7e-5627aad00919@github.com>
Message-ID: <sm0g1pjycIAoH1aVqFQDPxD_6w_kEy3gdVKhbVpOh14=.793fb6e4-c523-4ebc-b22e-a3b929139e16@github.com>

On Mon, 11 Dec 2023 03:42:51 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> Hello Vamsi (@vamsi-parasa),
>> 
>> I made the process simpler: added all variants to be compared into ArraysSort class
>> (set the same package org.openjdk.bench.java.util). It will run all sorts incl. sort from jdk
>> in the same environment. It should provide more accurate results, otherwise we see some anomalies.
>> 
>> Could you please find time to run the benchmarking?
>> Take all classes below and put them in the package org.openjdk.bench.java.util.
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSort.java
>> 
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_a10.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r14.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r17.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r18.java
>> 
>> Many thanks,
>> Vladimir
>
> Hi Vladimir (@iaroslavski)
> 
> Please see the data below using the latest version of AVX512 sort that got integrated into OpenJDK.
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
> <link rel=File-List
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
> 
> 
> 
> </head>
> 
> <body link="#0563C1" vlink="#954F72">
> 
> 
> Benchmark   (us/op) | (builder) | Stock JDK | a10 | r14 | r17 | r18
> -- | -- | -- | -- | -- | -- | --
> ArraysSort.Int.testSort | RANDOM | 2.202 | 2.226 | 1.535 | 1.556 | 1.546
> ArraysSort.Int.testSort | RANDOM | 35.128 | 34.804 | 30.808 | 30.914 | 31.284
> ArraysSort.Int.testSort | RANDOM | 78.571 | 77.224 | 72.567 | 73.098 | 73.337
> ArraysSort.Int.testSort | RANDOM | 2466.487 | 2470.66 | 2504.654 | 2494.051 | 2499.746
> ArraysSort.Int.testSort | RANDOM | 20704.14 | 20668.19 | 21377.73 | 21362.63 | 21278.94
> ArraysSort.Int.testSort | REPEATED | 0.877 | 0.892 | 0.74 | 0.724 | 0.718
> ArraysSort.Int.testSort | REPEATED | 4.789 | 4.788 | 4.92 | 4.721 | 4.891
> ArraysSort.Int.testSort | REPEATED | 11.172 | 11.778 | 11.53 | 11.467 | 11.406
> ArraysSort.Int.testSort | REPEATED | 207.212 | 207.292 | 255.46 | 258.832 | 254.44
> ArraysSort.Int.testSort | REPEATED | 1862.544 | 1876.759 | 1952.646 | 1957.978 | 1981.906
> ArraysSort.Int.testSort | STAGGER | 2.092 | 2.137 | 1.999 | 2.031 | 2.015
> ArraysSort.Int.testSort | STAGGER | 29.891 | 30.321 | 25.626 | 26.318 | 26.396
> ArraysSort.Int.testSort | STAGGER | 60.979 | 83.439 | 57.864 | 57.213 | 79.762
> ArraysSort.Int.testSort | STAGGER | 1227.933 | 1224.495 | 1236.133 | 1229.773 | 1228.877
> ArraysSort.Int.testSort | STAGGER | 9514.873 | 9565.599 | 9491.509 | 9481.147 | 9481.905
> ArraysSort.Int.testSort | SHUFFLE | 1.608 | 1.595 | 1.419 | 1.442 | 1.491
> ArraysSort.Int.testSort | SHUFFLE | 31.566 | 32.789 | 28.718 | 28.768 | 28.671
> ArraysSort.Int.testSort | SHUFFLE | 82.157 | 83.741 | 70.889 | 69.951 | 71.196
> ArraysSort.Int.testSort | SHUFFLE | 2251.219 | 2248.496 | 2184.459 | 2163.969 | 2156.239
> ArraysSort.Int.testSort | SHUFFLE | 18211.05 | 18223.24 | 17987.4 | 18114.26 | 17994.98
> 
> 
> 
> </body>
> 
> </html>
> 
> Thanks,
> Vamsi

Many thanks, Vamsi (@vamsi-parasa)
I will analyze this result.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1850900504

From jlu at openjdk.org  Mon Dec 11 22:15:42 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 11 Dec 2023 22:15:42 GMT
Subject: RFR: 8321480: ISO 4217 Amendment 176 Update [v3]
In-Reply-To: <kLWpfbMrAiEskU8JqeFoGaEBzx1aTHI_vq5gxjjdoVw=.2b1af423-59c7-44e8-b4d4-deca303ec2a8@github.com>
References: <kLWpfbMrAiEskU8JqeFoGaEBzx1aTHI_vq5gxjjdoVw=.2b1af423-59c7-44e8-b4d4-deca303ec2a8@github.com>
Message-ID: <_Mb_yvfsGFhcLdQ3REh5R5CNbXpZ15Gi50JyqRs2fyg=.c6289fab-f0bf-419b-9506-f27b8e16a37c@github.com>

> Please review this PR which incorporates the ISO 4217 Amendment 176 Update. As the replacement of `ANG` to `XCG` won't occur until 2025, this change does not need to go into JDK22. `HR` was also updated to remove the past cutover dates.
> 
> An existing test in _ValidateISO4217.java_ checked that `Currency::getAvailableCurrencies` had all the expected currencies. This method returns all currencies, including ones to take place in the future (e.g. `XCG`). The expected currencies `Set` the method was test against had to be updated to also include future currencies as well.
> 
> Additionally, this change also converted a parameterized test to a normal JUnit test, due to output overflow.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  remove redundant conditionals

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17023/files
  - new: https://git.openjdk.org/jdk/pull/17023/files/94f5870c..85f389dd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17023&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17023&range=01-02

  Stats: 7 lines in 1 file changed: 2 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17023.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17023/head:pull/17023

PR: https://git.openjdk.org/jdk/pull/17023

From jlu at openjdk.org  Mon Dec 11 22:15:46 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 11 Dec 2023 22:15:46 GMT
Subject: RFR: 8321480: ISO 4217 Amendment 176 Update [v2]
In-Reply-To: <cROvCurRl8Y1VrlwwovzSqkHowlQBc91xb3W6Qfm77M=.b84ba5f4-e2a1-4043-b890-09bccb81dab6@github.com>
References: <kLWpfbMrAiEskU8JqeFoGaEBzx1aTHI_vq5gxjjdoVw=.2b1af423-59c7-44e8-b4d4-deca303ec2a8@github.com>
 <qbVDj_d2TOhj5-mHcBLKpc8lN6zTnhCP2UYi_h70Kxg=.b2ddfb6f-3cb2-4c15-93a3-6ff90c516501@github.com>
 <cROvCurRl8Y1VrlwwovzSqkHowlQBc91xb3W6Qfm77M=.b84ba5f4-e2a1-4043-b890-09bccb81dab6@github.com>
Message-ID: <9IE8FVl1QvHZmyyYk3EoBAyMmgxsjfuxjPeASptg_e8=.fdd151ed-f287-4a2a-96fd-97737b314775@github.com>

On Mon, 11 Dec 2023 19:38:38 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8321480-ISO4217-176
>>  - add comment
>>  - reflect review comments
>>  - add xcg to CurrencyNames
>>  - init
>
> make/jdk/src/classes/build/tools/generatecurrencydata/GenerateCurrencyData.java line 347:
> 
>> 345:             // otherwise it will leak out into Currency:getAvailableCurrencies
>> 346:             boolean notFutureCurrency = !Arrays.asList(specialCaseNewCurrencies).contains(currencyCode);
>> 347:             boolean notSimpleCurrency = tableEntry == INVALID_COUNTRY_ENTRY
> 
> I'd rather not bundle up those conditions into `notSimpleCurrency`, as it obscures the other two cases. Simply OR-ing those conditions and `notFutureCurrency` ( or `!futureCurrency` may be more readable) would be sufficient IMO.

Well, at first I had intended for the `notSimpleCurrency` to encapsulate all 3 cases. But upon further investigation, I think the current code is redundant.

The third conditional, `(tableEntry & SIMPLE_CASE_COUNTRY_FINAL_CHAR_MASK) != (currencyCode.charAt(2) - 'A')` checks if the currency's first two chars match the country code (which also implies the current currency is simple). It returns false if they match. When this is false, the other first two conditions are always false. If a currencyCode is simple, the countryCode is always defined, and the currencyCode itself is not special. Checking the first two AND the third seems redundant when the first two are always false if the third is false.

For example, take the currency `ADP` which will search for the table entry of the country `AD`. Since `AD=EUR`, the third conditional returns true. We now know that we do not have a simple currency, which is more than enough to make a decision whether to add the current currency to the otherCurrency List. But the existing code now checks that `AD` is a defined country and whether `EUR` is special or not (since `AD`'s tableEntry value is associated with `EUR`). I'm not sure why we would check that `EUR` is a special currency, when we are deciding to add `ADP` as an otherCurrency. It is hard to infer without any existing comments as well.

With commit [85f389d](https://github.com/openjdk/jdk/pull/17023/commits/85f389dd81893f9a58f25a663cf2a18b653bced7), the same exact values are added to the otherCurrency list. However, If we would prefer not to update such old code for the sake of safety, then I would at least like to add comments that warn which conditionals may be irrelevant. Wondering what your thoughts are regarding this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17023#discussion_r1423176706

From jlu at openjdk.org  Mon Dec 11 22:15:47 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 11 Dec 2023 22:15:47 GMT
Subject: RFR: 8321480: ISO 4217 Amendment 176 Update [v3]
In-Reply-To: <nkZM6gEJoCsBHcQcdx2hPMTbr2rnWZXzpZjbazd1qfM=.aad5365c-9597-418f-986e-a070f77b8a42@github.com>
References: <kLWpfbMrAiEskU8JqeFoGaEBzx1aTHI_vq5gxjjdoVw=.2b1af423-59c7-44e8-b4d4-deca303ec2a8@github.com>
 <YJ3f4NQyWkLM6xaR_zIU039s-AWMaDZhXC0HXZATN04=.bec227f8-9a88-4a92-b807-9e0fc720125d@github.com>
 <xLAOF_anhwmtVxg80QM2Kg9NdzcEMBM8GznHEUnMn9w=.153ddf67-ae74-4948-a1fc-f2f1697a3b3f@github.com>
 <nkZM6gEJoCsBHcQcdx2hPMTbr2rnWZXzpZjbazd1qfM=.aad5365c-9597-418f-986e-a070f77b8a42@github.com>
Message-ID: <mMjU9fWohEzJBdnJ-J2KtGb2KWf7tQc0wOO5UU5VgdU=.69e2dfb4-77d2-4cd5-9c87-3d01749aa20d@github.com>

On Mon, 11 Dec 2023 19:42:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Updated the Currency build process to disallow any Currencies that are future Currencies. This prevents the future currency, "XCG" from leaking out into `Currency.getAvailableCurrencies()`. (This was only exposed now, since the previous future Currencies were already ones expected to be found in `Currency.getAvailableCurrencies()`. For example, Amendment 174 where HRK was replaced by EUR.
>> 
>> (Tiers 1-5 clean with this change)
>
> IIUC, this should have happened before, as a currency update like "XXA" -> "XXB" on a future date is pretty usual. I think this issue was simply not discovered by any users till now.

I think this wasn't discovered/hasn't failed the test before because the amendments with future date changes most of the time were implemented after the date already occurred, so there was no cut-over, simply a new currency directly replacing the old (For example, ISO 171 SLE replacing SLL was direct). In the case where the cut-over hadn't happened, like 174 where EUR replaced HRK, EUR is already expected to be returned by `Currency.getAvailableCurrencies()` so there was no issue.

I claimed that this particular amendment exposed it, because if this case had happened before with an amendment update, it would have caused validateISO4217.java to fail (as it does with this case). Since that test checks if the set returned by the method does not contain any future currencies.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17023#discussion_r1423178773

From jlu at openjdk.org  Mon Dec 11 22:54:19 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 11 Dec 2023 22:54:19 GMT
Subject: RFR: 8320919: Clarify Locale related system properties
In-Reply-To: <IruGxIK9DXnXFDANt1y4sCMJEGZh1PTOKhOWZZxJEdc=.77092e02-fb4f-4c9e-8d53-0fa0cf3bae7d@github.com>
References: <IruGxIK9DXnXFDANt1y4sCMJEGZh1PTOKhOWZZxJEdc=.77092e02-fb4f-4c9e-8d53-0fa0cf3bae7d@github.com>
Message-ID: <T6amp0e6d8fH2bV2UYXHkXphSgU567xIt1dZWFZq26I=.d1e2cc6b-3094-4100-91d9-b105ac8351ee@github.com>

On Mon, 11 Dec 2023 18:54:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a doc change to clarify what the `Default Locale` is, and how it is established during the system startup using the system properties. Those locale-related system properties have existed since the early days of Java, but have never been publicly documented before. It is also the intention of this PR to clarify those system properties and how they are overridden. A corresponding CSR has been drafted.

LGTM; left some minor wording comments.

src/java.base/share/classes/java/util/Locale.java line 264:

> 262:  * <h3><a id="default_locale">Default Locale</a></h3>
> 263:  *
> 264:  * <p>The default Locale is provided mainly for the locale-sensitive methods if no

Suggestion:

 * <p>The default Locale is mainly provided for any locale-sensitive methods if no

src/java.base/share/classes/java/util/Locale.java line 270:

> 268:  * <ol>
> 269:  * <li>The locale-related system properties listed below are established from the
> 270:  * host environment. Some system properties (except for {@code user.language}) may

IIUC, should it be _all_ system properties, not _some_ if we are defining the single exception?

src/java.base/share/classes/java/util/Locale.java line 301:

> 299:  * is unparsable, it is ignored. The overriding values of other properties are not
> 300:  * checked for syntax or validity and are used directly in the default Locale.
> 301:  * (Typically, system property values can be provided using the {@code -D} command-line

Do these last two sentences need to be enclosed in a parentheses? It seems pretty important as it is the main way to override the properties via command-line.

src/java.base/share/classes/java/util/Locale.java line 307:

> 305:  * "foobarbaz".)
> 306:  * </li>
> 307:  * <li>The default {@code Locale} instance is constructed from these system

Might read better as "... is constructed from the values of these system properties."

src/java.base/share/classes/java/util/Locale.java line 317:

> 315:  * If the default Locale is changed with {@link #setDefault(Locale)}, the corresponding
> 316:  * system properties are not altered. It is not recommended that applications read
> 317:  * those system properties and parse/interpret them as their values may be out of sync.

Suggestion:

 * these system properties and parse/interpret them as their values may be out of sync.

src/java.base/share/classes/java/util/Locale.java line 321:

> 319:  * <p>There are finer-grained default Locales specific for each {@link Locale.Category}.
> 320:  * These category specific default Locales can be queried by {@link #getDefault(Category)},
> 321:  * and set by {@link #setDefault(Category, Locale)}. Constructions of these category

Suggestion:

 * and set by {@link #setDefault(Category, Locale)}. Construction of these category

src/java.base/share/classes/java/util/Locale.java line 327:

> 325:  * the value of the {@code user.language.display} system property will be used in the
> 326:  * {@code language} part of the default Locale for {@link Locale.Category#DISPLAY}
> 327:  * category. In the absence of category specific system properties the "category-less"

Suggestion:

 * category. In the absence of category specific system properties, the "category-less"

-------------

PR Review: https://git.openjdk.org/jdk/pull/17065#pullrequestreview-1776299148
PR Review Comment: https://git.openjdk.org/jdk/pull/17065#discussion_r1423205213
PR Review Comment: https://git.openjdk.org/jdk/pull/17065#discussion_r1423205166
PR Review Comment: https://git.openjdk.org/jdk/pull/17065#discussion_r1423206857
PR Review Comment: https://git.openjdk.org/jdk/pull/17065#discussion_r1423209519
PR Review Comment: https://git.openjdk.org/jdk/pull/17065#discussion_r1423205137
PR Review Comment: https://git.openjdk.org/jdk/pull/17065#discussion_r1423205118
PR Review Comment: https://git.openjdk.org/jdk/pull/17065#discussion_r1423205082

From naoto at openjdk.org  Mon Dec 11 23:05:45 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 11 Dec 2023 23:05:45 GMT
Subject: RFR: 8320919: Clarify Locale related system properties [v2]
In-Reply-To: <IruGxIK9DXnXFDANt1y4sCMJEGZh1PTOKhOWZZxJEdc=.77092e02-fb4f-4c9e-8d53-0fa0cf3bae7d@github.com>
References: <IruGxIK9DXnXFDANt1y4sCMJEGZh1PTOKhOWZZxJEdc=.77092e02-fb4f-4c9e-8d53-0fa0cf3bae7d@github.com>
Message-ID: <0NalGBQyBc5nfMnzpk_9dgKQcQABc-XvO_98fR1pwSQ=.cfb2e6e7-b5ea-4cd0-86a9-30b163d64795@github.com>

> This is a doc change to clarify what the `Default Locale` is, and how it is established during the system startup using the system properties. Those locale-related system properties have existed since the early days of Java, but have never been publicly documented before. It is also the intention of this PR to clarify those system properties and how they are overridden. A corresponding CSR has been drafted.

Naoto Sato has updated the pull request incrementally with four additional commits since the last revision:

 - Update src/java.base/share/classes/java/util/Locale.java
   
   Co-authored-by: Justin Lu <Justin.lu at oracle.com>
 - Update src/java.base/share/classes/java/util/Locale.java
   
   Co-authored-by: Justin Lu <Justin.lu at oracle.com>
 - Update src/java.base/share/classes/java/util/Locale.java
   
   Co-authored-by: Justin Lu <Justin.lu at oracle.com>
 - Update src/java.base/share/classes/java/util/Locale.java
   
   Co-authored-by: Justin Lu <Justin.lu at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17065/files
  - new: https://git.openjdk.org/jdk/pull/17065/files/b2614b17..4f5980bc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17065&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17065&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/17065.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17065/head:pull/17065

PR: https://git.openjdk.org/jdk/pull/17065

From naoto at openjdk.org  Mon Dec 11 23:20:25 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 11 Dec 2023 23:20:25 GMT
Subject: RFR: 8320919: Clarify Locale related system properties [v3]
In-Reply-To: <IruGxIK9DXnXFDANt1y4sCMJEGZh1PTOKhOWZZxJEdc=.77092e02-fb4f-4c9e-8d53-0fa0cf3bae7d@github.com>
References: <IruGxIK9DXnXFDANt1y4sCMJEGZh1PTOKhOWZZxJEdc=.77092e02-fb4f-4c9e-8d53-0fa0cf3bae7d@github.com>
Message-ID: <wty1T1zBJzvCBz9c2z1nPeD7316D_p9kU4CbQCeuUZs=.156e712d-b269-4bdf-b87d-f07a7057e2a2@github.com>

> This is a doc change to clarify what the `Default Locale` is, and how it is established during the system startup using the system properties. Those locale-related system properties have existed since the early days of Java, but have never been publicly documented before. It is also the intention of this PR to clarify those system properties and how they are overridden. A corresponding CSR has been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17065/files
  - new: https://git.openjdk.org/jdk/pull/17065/files/4f5980bc..8baa56a9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17065&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17065&range=01-02

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17065.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17065/head:pull/17065

PR: https://git.openjdk.org/jdk/pull/17065

From naoto at openjdk.org  Mon Dec 11 23:20:29 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 11 Dec 2023 23:20:29 GMT
Subject: RFR: 8320919: Clarify Locale related system properties [v3]
In-Reply-To: <T6amp0e6d8fH2bV2UYXHkXphSgU567xIt1dZWFZq26I=.d1e2cc6b-3094-4100-91d9-b105ac8351ee@github.com>
References: <IruGxIK9DXnXFDANt1y4sCMJEGZh1PTOKhOWZZxJEdc=.77092e02-fb4f-4c9e-8d53-0fa0cf3bae7d@github.com>
 <T6amp0e6d8fH2bV2UYXHkXphSgU567xIt1dZWFZq26I=.d1e2cc6b-3094-4100-91d9-b105ac8351ee@github.com>
Message-ID: <jscui0aN2Uv1aaFWxSp01sut1zKf7OLiS7EcboXEUYU=.790a7407-f595-415d-9dc9-561801a6e7db@github.com>

On Mon, 11 Dec 2023 22:42:56 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments
>
> src/java.base/share/classes/java/util/Locale.java line 270:
> 
>> 268:  * <ol>
>> 269:  * <li>The locale-related system properties listed below are established from the
>> 270:  * host environment. Some system properties (except for {@code user.language}) may
> 
> IIUC, should it be _all_ system properties, not _some_ if we are defining the single exception?

The host-dependent part of the code always generates at least the language, thus it was excluded.

> src/java.base/share/classes/java/util/Locale.java line 301:
> 
>> 299:  * is unparsable, it is ignored. The overriding values of other properties are not
>> 300:  * checked for syntax or validity and are used directly in the default Locale.
>> 301:  * (Typically, system property values can be provided using the {@code -D} command-line
> 
> Do these last two sentences need to be enclosed in a parentheses? It seems pretty important as it is the main way to override the properties via command-line.

The `-D` command-line option is not a part of the Java SE specification but an allowed behavior, so it may not be a normative description here.

> src/java.base/share/classes/java/util/Locale.java line 307:
> 
>> 305:  * "foobarbaz".)
>> 306:  * </li>
>> 307:  * <li>The default {@code Locale} instance is constructed from these system
> 
> Might read better as "... is constructed from the values of these system properties."

Thanks. modified

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17065#discussion_r1423228012
PR Review Comment: https://git.openjdk.org/jdk/pull/17065#discussion_r1423228059
PR Review Comment: https://git.openjdk.org/jdk/pull/17065#discussion_r1423228078

From vromero at openjdk.org  Mon Dec 11 23:39:40 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 11 Dec 2023 23:39:40 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
Message-ID: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>

Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.

TIA

-------------

Commit messages:
 - 8320575: generic type information lost on mandated parameters

Changes: https://git.openjdk.org/jdk/pull/17070/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8320575
  Stats: 45 lines in 2 files changed: 28 ins; 3 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/17070.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17070/head:pull/17070

PR: https://git.openjdk.org/jdk/pull/17070

From naoto at openjdk.org  Tue Dec 12 00:02:33 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 12 Dec 2023 00:02:33 GMT
Subject: RFR: 8321480: ISO 4217 Amendment 176 Update [v2]
In-Reply-To: <9IE8FVl1QvHZmyyYk3EoBAyMmgxsjfuxjPeASptg_e8=.fdd151ed-f287-4a2a-96fd-97737b314775@github.com>
References: <kLWpfbMrAiEskU8JqeFoGaEBzx1aTHI_vq5gxjjdoVw=.2b1af423-59c7-44e8-b4d4-deca303ec2a8@github.com>
 <qbVDj_d2TOhj5-mHcBLKpc8lN6zTnhCP2UYi_h70Kxg=.b2ddfb6f-3cb2-4c15-93a3-6ff90c516501@github.com>
 <cROvCurRl8Y1VrlwwovzSqkHowlQBc91xb3W6Qfm77M=.b84ba5f4-e2a1-4043-b890-09bccb81dab6@github.com>
 <9IE8FVl1QvHZmyyYk3EoBAyMmgxsjfuxjPeASptg_e8=.fdd151ed-f287-4a2a-96fd-97737b314775@github.com>
Message-ID: <2KltdehHRXOss4kdqkUm_hWg07xaY3mo9lxOgJmMD5o=.4bde98f5-7835-475f-9536-68af8d101ec8@github.com>

On Mon, 11 Dec 2023 22:04:23 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> make/jdk/src/classes/build/tools/generatecurrencydata/GenerateCurrencyData.java line 347:
>> 
>>> 345:             // otherwise it will leak out into Currency:getAvailableCurrencies
>>> 346:             boolean notFutureCurrency = !Arrays.asList(specialCaseNewCurrencies).contains(currencyCode);
>>> 347:             boolean notSimpleCurrency = tableEntry == INVALID_COUNTRY_ENTRY
>> 
>> I'd rather not bundle up those conditions into `notSimpleCurrency`, as it obscures the other two cases. Simply OR-ing those conditions and `notFutureCurrency` ( or `!futureCurrency` may be more readable) would be sufficient IMO.
>
> Well, at first I had intended for the `notSimpleCurrency` to encapsulate all 3 cases. But upon further investigation, I think the current code is redundant.
> 
> The third conditional, `(tableEntry & SIMPLE_CASE_COUNTRY_FINAL_CHAR_MASK) != (currencyCode.charAt(2) - 'A')` checks if the currency's first two chars match the country code (which also implies the current currency is simple). It returns false if they match. When this is false, the other first two conditions are always false. If a currencyCode is simple, the countryCode is always defined, and the currencyCode itself is not special. Checking the first two AND the third seems redundant when the first two are always false if the third is false.
> 
> For example, take the currency `ADP` which will search for the table entry of the country `AD`. Since `AD=EUR`, the third conditional returns true. We now know that we do not have a simple currency, which is more than enough to make a decision whether to add the current currency to the otherCurrency List. But the existing code now checks that `AD` is a defined country and whether `EUR` is special or not (since `AD`'s tableEntry value is associated with `EUR`). I'm not sure why we would check that `EUR` is a special currency, when we are deciding to add `ADP` as an otherCurrency. It is hard to infer without any existing comments as well.
> 
> With commit [85f389d](https://github.com/openjdk/jdk/pull/17023/commits/85f389dd81893f9a58f25a663cf2a18b653bced7), the same exact values are added to the otherCurrency list. However, If we would prefer not to update such old code for the sake of safety, then I would at least like to add comments that warn which conditionals may be irrelevant. Wondering what your thoughts are regarding this.

Can you compare the built binary `currency.data` before and after your change? If they are identical, I think we can go ahead and remove the redundancy in the tool.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17023#discussion_r1423251717

From naoto at openjdk.org  Tue Dec 12 00:02:34 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 12 Dec 2023 00:02:34 GMT
Subject: RFR: 8321480: ISO 4217 Amendment 176 Update [v3]
In-Reply-To: <mMjU9fWohEzJBdnJ-J2KtGb2KWf7tQc0wOO5UU5VgdU=.69e2dfb4-77d2-4cd5-9c87-3d01749aa20d@github.com>
References: <kLWpfbMrAiEskU8JqeFoGaEBzx1aTHI_vq5gxjjdoVw=.2b1af423-59c7-44e8-b4d4-deca303ec2a8@github.com>
 <YJ3f4NQyWkLM6xaR_zIU039s-AWMaDZhXC0HXZATN04=.bec227f8-9a88-4a92-b807-9e0fc720125d@github.com>
 <xLAOF_anhwmtVxg80QM2Kg9NdzcEMBM8GznHEUnMn9w=.153ddf67-ae74-4948-a1fc-f2f1697a3b3f@github.com>
 <nkZM6gEJoCsBHcQcdx2hPMTbr2rnWZXzpZjbazd1qfM=.aad5365c-9597-418f-986e-a070f77b8a42@github.com>
 <mMjU9fWohEzJBdnJ-J2KtGb2KWf7tQc0wOO5UU5VgdU=.69e2dfb4-77d2-4cd5-9c87-3d01749aa20d@github.com>
Message-ID: <CCMnaa7FR6dF8bREpG263pSu98FCfwOYl9jRDF3OCUc=.3d5f1555-e122-4239-bc60-d84b5010e6ff@github.com>

On Mon, 11 Dec 2023 22:06:58 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> IIUC, this should have happened before, as a currency update like "XXA" -> "XXB" on a future date is pretty usual. I think this issue was simply not discovered by any users till now.
>
> I think this wasn't discovered/hasn't failed the test before because the amendments with future date changes most of the time were implemented after the date already occurred, so there was no cut-over, simply a new currency directly replacing the old (For example, ISO 171 SLE replacing SLL was direct). In the case where the cut-over hadn't happened, like 174 where EUR replaced HRK, EUR is already expected to be returned by `Currency.getAvailableCurrencies()` so there was no issue.
> 
> I claimed that this particular amendment exposed it, because if this case had happened before with an amendment update, it would have caused validateISO4217.java to fail (as it does with this case). Since that test checks if the set returned by the method does not contain any future currencies.

Yes, it is rare but happened before. The test had failed with the cut-over date in the past. Possibly at that time, getAvailableCurrencies test may not have been there so it wasn't obvious when the modification was made.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17023#discussion_r1423251685

From vromero at openjdk.org  Tue Dec 12 00:04:43 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 12 Dec 2023 00:04:43 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 [v2]
In-Reply-To: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
Message-ID: <wpvpFd7AuoqXSfbAdQGF0sN4qqV-qbLt3Mb8fuKFlJ8=.82602746-ac1d-49a0-ba85-92f48229aeb7@github.com>

> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  javadoc adjustments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17070/files
  - new: https://git.openjdk.org/jdk/pull/17070/files/3894e79f..0cc1bc5a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/17070.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17070/head:pull/17070

PR: https://git.openjdk.org/jdk/pull/17070

From jlu at openjdk.org  Tue Dec 12 00:06:22 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 12 Dec 2023 00:06:22 GMT
Subject: RFR: 8321480: ISO 4217 Amendment 176 Update [v2]
In-Reply-To: <2KltdehHRXOss4kdqkUm_hWg07xaY3mo9lxOgJmMD5o=.4bde98f5-7835-475f-9536-68af8d101ec8@github.com>
References: <kLWpfbMrAiEskU8JqeFoGaEBzx1aTHI_vq5gxjjdoVw=.2b1af423-59c7-44e8-b4d4-deca303ec2a8@github.com>
 <qbVDj_d2TOhj5-mHcBLKpc8lN6zTnhCP2UYi_h70Kxg=.b2ddfb6f-3cb2-4c15-93a3-6ff90c516501@github.com>
 <cROvCurRl8Y1VrlwwovzSqkHowlQBc91xb3W6Qfm77M=.b84ba5f4-e2a1-4043-b890-09bccb81dab6@github.com>
 <9IE8FVl1QvHZmyyYk3EoBAyMmgxsjfuxjPeASptg_e8=.fdd151ed-f287-4a2a-96fd-97737b314775@github.com>
 <2KltdehHRXOss4kdqkUm_hWg07xaY3mo9lxOgJmMD5o=.4bde98f5-7835-475f-9536-68af8d101ec8@github.com>
Message-ID: <-2NhZj5YuxubGdJGfdoxK4vGu-ikXYyWPqXWtYh2eVc=.8882884b-eaf3-4cda-9d6f-2118073034fa@github.com>

On Mon, 11 Dec 2023 23:59:24 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Well, at first I had intended for the `notSimpleCurrency` to encapsulate all 3 cases. But upon further investigation, I think the current code is redundant.
>> 
>> The third conditional, `(tableEntry & SIMPLE_CASE_COUNTRY_FINAL_CHAR_MASK) != (currencyCode.charAt(2) - 'A')` checks if the currency's first two chars match the country code (which also implies the current currency is simple). It returns false if they match. When this is false, the other first two conditions are always false. If a currencyCode is simple, the countryCode is always defined, and the currencyCode itself is not special. Checking the first two AND the third seems redundant when the first two are always false if the third is false.
>> 
>> For example, take the currency `ADP` which will search for the table entry of the country `AD`. Since `AD=EUR`, the third conditional returns true. We now know that we do not have a simple currency, which is more than enough to make a decision whether to add the current currency to the otherCurrency List. But the existing code now checks that `AD` is a defined country and whether `EUR` is special or not (since `AD`'s tableEntry value is associated with `EUR`). I'm not sure why we would check that `EUR` is a special currency, when we are deciding to add `ADP` as an otherCurrency. It is hard to infer without any existing comments as well.
>> 
>> With commit [85f389d](https://github.com/openjdk/jdk/pull/17023/commits/85f389dd81893f9a58f25a663cf2a18b653bced7), the same exact values are added to the otherCurrency list. However, If we would prefer not to update such old code for the sake of safety, then I would at least like to add comments that warn which conditionals may be irrelevant. Wondering what your thoughts are regarding this.
>
> Can you compare the built binary `currency.data` before and after your change? If they are identical, I think we can go ahead and remove the redundancy in the tool.

Yes, I will go ahead and compare, as well as do a few more sanity checks

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17023#discussion_r1423253808

From naoto at openjdk.org  Tue Dec 12 00:36:32 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 12 Dec 2023 00:36:32 GMT
Subject: RFR: 6230751: [Fmt-Ch] Recursive MessageFormats in ChoiceFormats
 ignore indicated subformats [v4]
In-Reply-To: <fwY-rbmc0jFTiLzxc299f8BqCI_9UzDs6IDaOSHth-A=.b5508d4f-04bb-47b1-84b4-819e906bb935@github.com>
References: <7wIjtUukVVmPac0CLynJTK8zIx7Difi9122zthoFj_w=.8e65ff5d-816b-4383-b833-0df272efaede@github.com>
 <fwY-rbmc0jFTiLzxc299f8BqCI_9UzDs6IDaOSHth-A=.b5508d4f-04bb-47b1-84b4-819e906bb935@github.com>
Message-ID: <MJvXElRbAr0YLhS_CBIC_0YcJ7Tutpd6Ao8aW6kGM2M=.1d869ab5-ee9a-40b0-8c34-046fe34798aa@github.com>

On Thu, 7 Dec 2023 22:15:51 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates an incorrect code example in _java/text/ChoiceFormat_.
>> 
>> ChoiceFormat (and MessageFormat) provide an example of how to produce a pattern that supports singular and plural forms. The ChoiceFormat example is incorrect, as recursive MessageFormats produced by a ChoiceFormat subformat only recognize subformats defined through the MessageFormat pattern syntax, not through the subformats contained within the top level MessageFormat. 
>> 
>> In the original example,
>> `Format[] testFormats = {fileform, null, NumberFormat.getInstance()};` could have been replaced with 
>> `Format[] testFormats = {fileform, null, new ChoiceFormat("0#BROKEN")};` and the original output would have been the same.
>> 
>> This PR replaces the example with the one used in MessageFormat, which is correct. 
>> 
>> This PR also includes a drive-by fix to remove leftover `<blockquote>`s from a previous `@snippet` conversion.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   shorten wording

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16891#pullrequestreview-1776397562

From duke at openjdk.org  Tue Dec 12 01:45:47 2023
From: duke at openjdk.org (duke)
Date: Tue, 12 Dec 2023 01:45:47 GMT
Subject: Withdrawn: 8316150: Refactor get chars and string size
In-Reply-To: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.91666616-d2f5-4fa4-8cc9-fb2d82d79f25@github.com>
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.91666616-d2f5-4fa4-8cc9-fb2d82d79f25@github.com>
Message-ID: <pFz6dTpydJyZmyDLG8zlZSvGZBVk25Mv40isN-0sTWY=.8559cbce-b0ef-4034-a603-a7691277fa3e@github.com>

On Wed, 13 Sep 2023 01:24:05 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> 1. Reduce duplicate stringSize code
> 2. Move java.lang.StringLatin1.getChars to jdk.internal.util.DecimalDigits::getCharLatin1?not only java.lang, other packages also need to use this method

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/15699

From kbarrett at openjdk.org  Tue Dec 12 02:34:22 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 12 Dec 2023 02:34:22 GMT
Subject: RFR: 8321688: Build on linux with GCC 7.5.0 fails after 8319577
In-Reply-To: <vIByQ06ftSU9o1Rb4YOWXPrry1LkYSj-vJqLXaMXQ5g=.d5a0ea33-f57a-4549-addf-b7a9c5eaa67d@github.com>
References: <vIByQ06ftSU9o1Rb4YOWXPrry1LkYSj-vJqLXaMXQ5g=.d5a0ea33-f57a-4549-addf-b7a9c5eaa67d@github.com>
Message-ID: <URTRfgkcxtEH80-ZT92CekMf0oVLnKOsABeI8h0LHPc=.90f9329e-2f6f-4c4b-8083-5a455dc81968@github.com>

On Mon, 11 Dec 2023 02:36:30 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch fixes the building failure introduced by [JDK-8319577](https://bugs.openjdk.org/browse/JDK-8319577) in old GCC version (linux & GCC 7.5.0 locally).
> 
> Thanks for the review.
> 
>  Best Regards,
> -- Guoxiong

Please hold off on this change while I follow up on JDK-8319577.  This code
requires C++17, which was turned on for a relevant small subset of the JDK by
that change.  There was some discussion there about version limiting that
change, but that doesn't seem to have been done, with this breakage being a
consequence.

-------------

PR Review: https://git.openjdk.org/jdk/pull/17047#pullrequestreview-1776491102

From vromero at openjdk.org  Tue Dec 12 03:34:46 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 12 Dec 2023 03:34:46 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 [v3]
In-Reply-To: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
Message-ID: <ESAoUze0VjuBDZdbGKagGh5_12a81YozaxzAr8vm9RE=.3a953835-0b91-448b-bf6a-2c1cf1da89cc@github.com>

> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17070/files
  - new: https://git.openjdk.org/jdk/pull/17070/files/0cc1bc5a..f2b65c16

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=01-02

  Stats: 9 lines in 1 file changed: 4 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/17070.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17070/head:pull/17070

PR: https://git.openjdk.org/jdk/pull/17070

From vromero at openjdk.org  Tue Dec 12 03:51:47 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 12 Dec 2023 03:51:47 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 [v4]
In-Reply-To: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
Message-ID: <8GGBmLzBkj2IEzkj5zhPoATKbFq7gL56ScmBhEkYetE=.43d90dab-236c-41bb-9fa2-f3f5156e7c4c@github.com>

> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17070/files
  - new: https://git.openjdk.org/jdk/pull/17070/files/f2b65c16..f4a4f5b3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=02-03

  Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/17070.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17070/head:pull/17070

PR: https://git.openjdk.org/jdk/pull/17070

From vromero at openjdk.org  Tue Dec 12 03:56:43 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 12 Dec 2023 03:56:43 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 [v5]
In-Reply-To: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
Message-ID: <PMGB_1SaVU5cKKosvDzvgVpjIJPyhoKs-S6bzhOyjqA=.18a84e58-6e4d-46ff-bea2-8b79fa080280@github.com>

> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  removing comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17070/files
  - new: https://git.openjdk.org/jdk/pull/17070/files/f4a4f5b3..6de5dff8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17070.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17070/head:pull/17070

PR: https://git.openjdk.org/jdk/pull/17070

From vromero at openjdk.org  Tue Dec 12 04:03:30 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 12 Dec 2023 04:03:30 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 [v5]
In-Reply-To: <PMGB_1SaVU5cKKosvDzvgVpjIJPyhoKs-S6bzhOyjqA=.18a84e58-6e4d-46ff-bea2-8b79fa080280@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
 <PMGB_1SaVU5cKKosvDzvgVpjIJPyhoKs-S6bzhOyjqA=.18a84e58-6e4d-46ff-bea2-8b79fa080280@github.com>
Message-ID: <9K0A2Ct4hxHAPfUr0Sc8O_sPScSYcmGDvoz13UlD_Vg=.bf01d19a-911c-4682-ba8c-1fa6b2ef695d@github.com>

On Tue, 12 Dec 2023 03:56:43 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removing comment

src/java.base/share/classes/java/lang/reflect/Executable.java line 343:

> 341:                 final Type[] out = new Type[nonGenericParamTypes.length];
> 342:                 final Parameter[] params = getParameters();
> 343:                 int fromidx = genericParamTypes.length - 1;

so provided that the parameters order is: synthetic parameters first, then mandated, if any, and finally explicit parameters. I think that it is safe to get as many parameters as possible from the genericParamTypes array, starting from the last element of the array, and if this array is shorter than the nonGenericParamTypes array, then the difference must be due to the presence of synthetic parameters, and we take the type of those from the nonGenericParamTypes array

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17070#discussion_r1423374618

From vromero at openjdk.org  Tue Dec 12 04:20:43 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 12 Dec 2023 04:20:43 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 [v6]
In-Reply-To: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
Message-ID: <8zFnhKwOAnbFQqt9oJGtOWeJKVbEFJGHTg4vaVFw3tM=.79aee2d7-4e8a-4ec2-9838-236ed7b93ee8@github.com>

> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  simplifying code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17070/files
  - new: https://git.openjdk.org/jdk/pull/17070/files/6de5dff8..65a4b399

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=04-05

  Stats: 8 lines in 1 file changed: 0 ins; 7 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17070.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17070/head:pull/17070

PR: https://git.openjdk.org/jdk/pull/17070

From vromero at openjdk.org  Tue Dec 12 04:26:25 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 12 Dec 2023 04:26:25 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 [v7]
In-Reply-To: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
Message-ID: <UHA4xz5Ute6D_dTNMO4Ki4Jw7I3U7i6D5idwqPiuQ_w=.d44fe606-37f4-4451-9674-a0b1fa823647@github.com>

> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  fixing comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17070/files
  - new: https://git.openjdk.org/jdk/pull/17070/files/65a4b399..e48c7989

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17070.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17070/head:pull/17070

PR: https://git.openjdk.org/jdk/pull/17070

From dholmes at openjdk.org  Tue Dec 12 07:50:38 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 12 Dec 2023 07:50:38 GMT
Subject: RFR: 8321718: ProcessTools.executeProcess calls waitFor before
 logging
In-Reply-To: <fK27CacDG-QccKV-QpUT3z9p8eppW4wbw0ALbNCJn5w=.a1b6a824-5a8d-4a99-83ad-147fcd773dbd@github.com>
References: <fK27CacDG-QccKV-QpUT3z9p8eppW4wbw0ALbNCJn5w=.a1b6a824-5a8d-4a99-83ad-147fcd773dbd@github.com>
Message-ID: <SiX0mK0Krs5qzr3FDzVBIjErUMoZA35DsQDMf9j5los=.f0771934-84fc-43bd-90d2-14ad7129492b@github.com>

On Mon, 11 Dec 2023 11:16:05 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> There is some logging printed when tests spawns processes. This logging is triggered from calls to `OutputAnalyzer`, when it delegates calls to `LazyOutputBuffer`.
> 
> If we write code like this:
> 
> ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...);
> OutputAnalyzer output = new OutputAnalyzer(pb.start());
> int exitValue = output.getExitValue();
> 
> 
> We get the following logging:
> 
> [timestamp0] "Gathering output for process <pid>
> [timestamp1] Waiting for completion for process <pid>
> [timestamp2] Waiting for completion finished for process <pid>
> 
> 
> The first line comes from the `OutputAnalyzer` constructor and the two other lines comes from the `getExitValue` call, which calls logs the above messages around the call to `waitFor`.
> 
> If instead write the code above as:
> 
> ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...);
> OutputAnalyzer output = ProcessTools.executeProcess(pb);
> int exitValue = output.getExitValue();
> 
> 
> We get the same logging, but timestamp1 and timestamp2 are almost the same. This happens because there's an extra call to `waitFor` inside `executeProcess`, but that `waitFor` does not have the "wait for" logging. So, instead we get the logging for the no-op `waitFor` inside `getExitValue`.
> 
> I would like to propose a small workaround to solve this. The workaround is that `executeProcess` delegates the `waitFor` call to the `LazyOutputBuffer` via `OutputAnalyzer`.  This is a small, limited workaround for this issue. Ideally I would like to extract the entire Process handling code out of LazyOutputBuffer and OutputAnalyzer, but the prototype for that rewrites all usages of `new OutputAnalyzer(pb.start())` and stretches far and wide in the test directories, so I'm starting out with this suggestion.
> 
> We can see of this patch by looking at the timestamps generated from the included test. Without the proposed workaround:
> 
> Without
> 
> testExecuteProcessExit
> [2023-12-11T11:05:41.854579260Z] Gathering output for process 2547719
> [2023-12-11T11:05:44.018335073Z] Waiting for completion for process 2547719
> [2023-12-11T11:05:44.018851972Z] Waiting for completion finished for process 2547719
> 
> testExecuteProcessStdout
> [2023-12-11T11:05:44.049509860Z] Gathering output for process 2547741
> [2023-12-11T11:05:46.227768897Z] Waiting for completion for process 2547741
> [2023-12-11T11:05:46.228021173Z] Waiting for completion finished for process 2547741
> 
> 
> testNewOutputAnalyzerExit
> [2023-12-11T11:05:46.231475003Z] Gathering output for process 2547782
> [2023...

Looks good.

Thanks

test/lib/jdk/test/lib/process/OutputAnalyzer.java line 111:

> 109:     /**
> 110:      * Delegate waitFor to the OutputBuffer. This ensures that
> 111:      * the progress and timestmaps are logged correctly.

Typo: timestmaps

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17052#pullrequestreview-1776831148
PR Review Comment: https://git.openjdk.org/jdk/pull/17052#discussion_r1423565527

From duke at openjdk.org  Tue Dec 12 07:52:48 2023
From: duke at openjdk.org (phuchau1989)
Date: Tue, 12 Dec 2023 07:52:48 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v12]
In-Reply-To: <dJ_GmL3sg48JA0dRYd8vmmO9BADligcbTu08iWkSJ3Y=.0ebc6510-9272-4177-8f8a-8c4030037f0a@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <dJ_GmL3sg48JA0dRYd8vmmO9BADligcbTu08iWkSJ3Y=.0ebc6510-9272-4177-8f8a-8c4030037f0a@github.com>
Message-ID: <bdQVH9VBBnwQ8ruHs3Q1lDNJhj1LqHaJNDkFiVjnsDQ=.5d57712e-3c64-4992-8e9f-fb98a4a8fb89@github.com>

On Fri, 19 May 2023 12:42:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
>> 
>>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>>  - parenthesized patterns are removed.
>>  - qualified enum constants are supported for case labels.
>> 
>> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing obsolette test, as suggested.

Marked as reviewed by phuchau1989 at github.com (no known OpenJDK username).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13074#pullrequestreview-1776839680

From stefank at openjdk.org  Tue Dec 12 09:01:12 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 12 Dec 2023 09:01:12 GMT
Subject: RFR: 8321718: ProcessTools.executeProcess calls waitFor before
 logging [v2]
In-Reply-To: <SiX0mK0Krs5qzr3FDzVBIjErUMoZA35DsQDMf9j5los=.f0771934-84fc-43bd-90d2-14ad7129492b@github.com>
References: <fK27CacDG-QccKV-QpUT3z9p8eppW4wbw0ALbNCJn5w=.a1b6a824-5a8d-4a99-83ad-147fcd773dbd@github.com>
 <SiX0mK0Krs5qzr3FDzVBIjErUMoZA35DsQDMf9j5los=.f0771934-84fc-43bd-90d2-14ad7129492b@github.com>
Message-ID: <cBmzvnz3pZJ-2owubc1pUwTYEU7db96uIIOSCdCWJgw=.eb564247-b5f4-428f-a286-7ddb616d9861@github.com>

On Tue, 12 Dec 2023 07:43:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Typo
>
> test/lib/jdk/test/lib/process/OutputAnalyzer.java line 111:
> 
>> 109:     /**
>> 110:      * Delegate waitFor to the OutputBuffer. This ensures that
>> 111:      * the progress and timestmaps are logged correctly.
> 
> Typo: timestmaps

Thanks. Updated

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17052#discussion_r1423664193

From stefank at openjdk.org  Tue Dec 12 09:01:08 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 12 Dec 2023 09:01:08 GMT
Subject: RFR: 8321718: ProcessTools.executeProcess calls waitFor before
 logging [v2]
In-Reply-To: <fK27CacDG-QccKV-QpUT3z9p8eppW4wbw0ALbNCJn5w=.a1b6a824-5a8d-4a99-83ad-147fcd773dbd@github.com>
References: <fK27CacDG-QccKV-QpUT3z9p8eppW4wbw0ALbNCJn5w=.a1b6a824-5a8d-4a99-83ad-147fcd773dbd@github.com>
Message-ID: <83m_6ZmOSvwQtzfUOTfDYKXOJJclctwMMLo6h_qnxgE=.48e6c6c2-a13c-46a4-a541-341f915683a0@github.com>

> There is some logging printed when tests spawns processes. This logging is triggered from calls to `OutputAnalyzer`, when it delegates calls to `LazyOutputBuffer`.
> 
> If we write code like this:
> 
> ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...);
> OutputAnalyzer output = new OutputAnalyzer(pb.start());
> int exitValue = output.getExitValue();
> 
> 
> We get the following logging:
> 
> [timestamp0] "Gathering output for process <pid>
> [timestamp1] Waiting for completion for process <pid>
> [timestamp2] Waiting for completion finished for process <pid>
> 
> 
> The first line comes from the `OutputAnalyzer` constructor and the two other lines comes from the `getExitValue` call, which calls logs the above messages around the call to `waitFor`.
> 
> If instead write the code above as:
> 
> ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...);
> OutputAnalyzer output = ProcessTools.executeProcess(pb);
> int exitValue = output.getExitValue();
> 
> 
> We get the same logging, but timestamp1 and timestamp2 are almost the same. This happens because there's an extra call to `waitFor` inside `executeProcess`, but that `waitFor` does not have the "wait for" logging. So, instead we get the logging for the no-op `waitFor` inside `getExitValue`.
> 
> I would like to propose a small workaround to solve this. The workaround is that `executeProcess` delegates the `waitFor` call to the `LazyOutputBuffer` via `OutputAnalyzer`.  This is a small, limited workaround for this issue. Ideally I would like to extract the entire Process handling code out of LazyOutputBuffer and OutputAnalyzer, but the prototype for that rewrites all usages of `new OutputAnalyzer(pb.start())` and stretches far and wide in the test directories, so I'm starting out with this suggestion.
> 
> We can see of this patch by looking at the timestamps generated from the included test. Without the proposed workaround:
> 
> Without
> 
> testExecuteProcessExit
> [2023-12-11T11:05:41.854579260Z] Gathering output for process 2547719
> [2023-12-11T11:05:44.018335073Z] Waiting for completion for process 2547719
> [2023-12-11T11:05:44.018851972Z] Waiting for completion finished for process 2547719
> 
> testExecuteProcessStdout
> [2023-12-11T11:05:44.049509860Z] Gathering output for process 2547741
> [2023-12-11T11:05:46.227768897Z] Waiting for completion for process 2547741
> [2023-12-11T11:05:46.228021173Z] Waiting for completion finished for process 2547741
> 
> 
> testNewOutputAnalyzerExit
> [2023-12-11T11:05:46.231475003Z] Gathering output for process 2547782
> [2023...

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17052/files
  - new: https://git.openjdk.org/jdk/pull/17052/files/145e1eaa..3275136c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17052&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17052&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17052.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17052/head:pull/17052

PR: https://git.openjdk.org/jdk/pull/17052

From stefank at openjdk.org  Tue Dec 12 09:01:10 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 12 Dec 2023 09:01:10 GMT
Subject: RFR: 8321718: ProcessTools.executeProcess calls waitFor before
 logging
In-Reply-To: <fK27CacDG-QccKV-QpUT3z9p8eppW4wbw0ALbNCJn5w=.a1b6a824-5a8d-4a99-83ad-147fcd773dbd@github.com>
References: <fK27CacDG-QccKV-QpUT3z9p8eppW4wbw0ALbNCJn5w=.a1b6a824-5a8d-4a99-83ad-147fcd773dbd@github.com>
Message-ID: <e24bhnuspHFFDnHBLVP0cUxREmTyxo5MBi8ALwNPEpw=.8a3b5bc1-fde6-47ba-a954-749d9f32724d@github.com>

On Mon, 11 Dec 2023 11:16:05 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> There is some logging printed when tests spawns processes. This logging is triggered from calls to `OutputAnalyzer`, when it delegates calls to `LazyOutputBuffer`.
> 
> If we write code like this:
> 
> ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...);
> OutputAnalyzer output = new OutputAnalyzer(pb.start());
> int exitValue = output.getExitValue();
> 
> 
> We get the following logging:
> 
> [timestamp0] "Gathering output for process <pid>
> [timestamp1] Waiting for completion for process <pid>
> [timestamp2] Waiting for completion finished for process <pid>
> 
> 
> The first line comes from the `OutputAnalyzer` constructor and the two other lines comes from the `getExitValue` call, which calls logs the above messages around the call to `waitFor`.
> 
> If instead write the code above as:
> 
> ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...);
> OutputAnalyzer output = ProcessTools.executeProcess(pb);
> int exitValue = output.getExitValue();
> 
> 
> We get the same logging, but timestamp1 and timestamp2 are almost the same. This happens because there's an extra call to `waitFor` inside `executeProcess`, but that `waitFor` does not have the "wait for" logging. So, instead we get the logging for the no-op `waitFor` inside `getExitValue`.
> 
> I would like to propose a small workaround to solve this. The workaround is that `executeProcess` delegates the `waitFor` call to the `LazyOutputBuffer` via `OutputAnalyzer`.  This is a small, limited workaround for this issue. Ideally I would like to extract the entire Process handling code out of LazyOutputBuffer and OutputAnalyzer, but the prototype for that rewrites all usages of `new OutputAnalyzer(pb.start())` and stretches far and wide in the test directories, so I'm starting out with this suggestion.
> 
> We can see of this patch by looking at the timestamps generated from the included test. Without the proposed workaround:
> 
> Without
> 
> testExecuteProcessExit
> [2023-12-11T11:05:41.854579260Z] Gathering output for process 2547719
> [2023-12-11T11:05:44.018335073Z] Waiting for completion for process 2547719
> [2023-12-11T11:05:44.018851972Z] Waiting for completion finished for process 2547719
> 
> testExecuteProcessStdout
> [2023-12-11T11:05:44.049509860Z] Gathering output for process 2547741
> [2023-12-11T11:05:46.227768897Z] Waiting for completion for process 2547741
> [2023-12-11T11:05:46.228021173Z] Waiting for completion finished for process 2547741
> 
> 
> testNewOutputAnalyzerExit
> [2023-12-11T11:05:46.231475003Z] Gathering output for process 2547782
> [2023...

Thanks for reviewing! I'm considering removing the test before integrating, as it currently takes >8s to run and it was mainly used to show the difference between the implementations. Do you agree that it would be OK to remove the test?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17052#issuecomment-1851564295

From dholmes at openjdk.org  Tue Dec 12 09:37:30 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 12 Dec 2023 09:37:30 GMT
Subject: RFR: 8321718: ProcessTools.executeProcess calls waitFor before
 logging
In-Reply-To: <e24bhnuspHFFDnHBLVP0cUxREmTyxo5MBi8ALwNPEpw=.8a3b5bc1-fde6-47ba-a954-749d9f32724d@github.com>
References: <fK27CacDG-QccKV-QpUT3z9p8eppW4wbw0ALbNCJn5w=.a1b6a824-5a8d-4a99-83ad-147fcd773dbd@github.com>
 <e24bhnuspHFFDnHBLVP0cUxREmTyxo5MBi8ALwNPEpw=.8a3b5bc1-fde6-47ba-a954-749d9f32724d@github.com>
Message-ID: <BbVjIDZ7vRYX619lBLSD5TF7J_JYVh_jD0Lv_UQNT6Y=.45db4a48-6ab3-46c4-8f5e-eb4ad6ffde11@github.com>

On Tue, 12 Dec 2023 08:57:08 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Do you agree that it would be OK to remove the test?

Sure that's fine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17052#issuecomment-1851644385

From jpai at openjdk.org  Tue Dec 12 09:42:36 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 12 Dec 2023 09:42:36 GMT
Subject: RFR: JDK-8319626: Override toString() for ZipFile [v8]
In-Reply-To: <EEHjubpyde8VF6w4shuUjROZWwIabcGCI9DYMva_gy8=.afba4e81-0f88-4530-8e32-23ca7f949157@github.com>
References: <UEVJDXC8Cs_RSBUEsWgmq8SPvI-T4LSydbPKr8u29iA=.fdce7d47-87a8-42ba-9cd4-119bf9023ad9@github.com>
 <EEHjubpyde8VF6w4shuUjROZWwIabcGCI9DYMva_gy8=.afba4e81-0f88-4530-8e32-23ca7f949157@github.com>
Message-ID: <CM89iDsGkAU1qcttFqsJk70iNzcwwVXAK9HVVVLj9T0=.7d8df3d2-82a0-4ce2-9e95-aab96a48dd9c@github.com>

On Mon, 11 Dec 2023 05:47:33 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319982) which overrides and provides an implementation of `toString()` in _java.util.zip.ZipFile_ (and by extension, _java.util.jar.JarFile_).
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8319626
>  - break line
>  - reflect review: change impl to store field name
>  - drop additional specification
>  - drop 2nd paragraph
>  - return base name, not full path
>  - shorten wording
>  - reflect review: use separator, clarify spec
>  - reflect review: change string value and drop spec
>  - init

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16643#pullrequestreview-1777044578

From jpai at openjdk.org  Tue Dec 12 09:42:39 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 12 Dec 2023 09:42:39 GMT
Subject: RFR: JDK-8319626: Override toString() for ZipFile [v7]
In-Reply-To: <sm6nW4R1ivI_7o60aQ3gNEcEDefA1YWiZOlkqnZ7sOU=.1a7cd4c0-805f-4c1a-aadb-f88c91d393cc@github.com>
References: <UEVJDXC8Cs_RSBUEsWgmq8SPvI-T4LSydbPKr8u29iA=.fdce7d47-87a8-42ba-9cd4-119bf9023ad9@github.com>
 <Iy4p9slUnyrWD5XUd6IER-MMmX0VgMyPdV6lYPWzLq4=.6e54f547-9bce-4469-8e37-3a2be9e02ac1@github.com>
 <0TKNGz1hOQmuTyplP7UhHD_7qV5_P0sPq5acTMXJsv0=.399049d0-79bd-48d4-8a42-ef7fbe5835e2@github.com>
 <sm6nW4R1ivI_7o60aQ3gNEcEDefA1YWiZOlkqnZ7sOU=.1a7cd4c0-805f-4c1a-aadb-f88c91d393cc@github.com>
Message-ID: <hKbWbAExztsTXfhst7FXnUWd64PEsrWuh0hPkrtGC-c=.91c77286-068a-4f16-b177-a6b5c09b8f01@github.com>

On Mon, 11 Dec 2023 05:44:38 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/zip/ZipFile.java line 494:
>> 
>>> 492:     @Override
>>> 493:     public String toString() {
>>> 494:         return res.zsrc.key.file.getName()
>> 
>> Hello Justin, relying on `res.zsrc.key.file` to get to the file name can cause troubles. For example, consider this usage (which I ran in jshell) with this proposed change in this PR:
>> 
>> 
>> jshell> import java.util.zip.*
>> 
>> jshell> ZipFile zf = new ZipFile("/tmp/workdir.zip")
>> zf ==> workdir.zip at 34c45dca
>> 
>> jshell> zf.close()
>> 
>> jshell> zf.toString()
>> |  Exception java.lang.NullPointerException: Cannot read field "key" because "this.res.zsrc" is null
>> |        at ZipFile.toString (ZipFile.java:494)
>> |        at (#4:1)
>> 
>> 
>> 
>> What I do here is that I call `ZipFile.toString()` after I (intentionally) close the `ZipFile`. The `toString()` call leads to `NullPointerException` because on closing the `ZipFile` instance we clean up the resource it holds on to.
>> 
>> I think what we can do here is, something like (the following diff was generated on top of the current state of this PR):
>> 
>> 
>> diff --git a/src/java.base/share/classes/java/util/zip/ZipFile.java b/src/java.base/share/classes/java/util/zip/ZipFile.java
>> index 67a5e65089f..2b6996294e1 100644
>> --- a/src/java.base/share/classes/java/util/zip/ZipFile.java
>> +++ b/src/java.base/share/classes/java/util/zip/ZipFile.java
>> @@ -95,7 +95,8 @@
>>   */
>>  public class ZipFile implements ZipConstants, Closeable {
>>  
>> -    private final String name;     // zip file name
>> +    private final String filePath;     // zip file path
>> +    private final String fileName;     // name of the file
>>      private volatile boolean closeRequested;
>>  
>>      // The "resource" used by this zip file that needs to be
>> @@ -245,7 +246,8 @@ public ZipFile(File file, int mode, Charset charset) throws IOException
>>          }
>>          Objects.requireNonNull(charset, "charset");
>>  
>> -        this.name = name;
>> +        this.filePath = name;
>> +        this.fileName = file.getName();
>>          long t0 = System.nanoTime();
>>  
>>          this.res = new CleanableResource(this, ZipCoder.get(charset), file, mode);
>> @@ -483,7 +485,7 @@ public int available() throws IOException {
>>       * @return the path name of the ZIP file
>>       */
>>      public String getName() {
>> -        return name;
>> +        return filePath;
>>      }
>>  
>>      /**
>> @@ -491,7 +493,7 @@ public String getName() {
>>       */
>>      @Override
>>      publi...
>
> Hi Jai,
> 
> Thank you for the detailed response and suggested alternative.
> 
> My intentions were to get the file name by leveraging the existing code without introducing an additional field if possible, but I did not realize the `NPE` it would cause when closing the ZipFile as you demonstrated.
> 
> I appreciate your guidance, updated the PR to reflect your suggestions. I don't see how this would cause any issues with tests as you stated, but checked tiers 1-3 and all is good there.

Hello Justin, thank you for doing the update and running the tests. This latest state of the PR (commit `4ba2bd47`) looks good to me. I have no other review comments.

Please wait for an additional review from someone else before integrating.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16643#discussion_r1423725222

From duke at openjdk.org  Tue Dec 12 09:52:44 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 12 Dec 2023 09:52:44 GMT
Subject: RFR: 8321802: (zipfs) Add validation of incorrect LOC signature in
 ZipFileSystem
Message-ID: <9OyZCEKEcOKOhnzSo8Ls4EfxijWzTVhp1H_SBaisYY8=.b82a211b-b98a-451d-8ce2-47b53314c492@github.com>

Please review this PR which adds validation of incorrect LOC signatures in `ZipFileSystem`.

`ZipFile` already rejects the case where the  offset pointed to from the CEN header does not start with the expected LOC signature. It makes sense to add this check to `ZipFileSystem` as well.

-------------

Commit messages:
 - Vaidate that LOC offset pointed to from the CEN actually starts with the expected LOC signature

Changes: https://git.openjdk.org/jdk/pull/17059/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17059&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321802
  Stats: 14 lines in 2 files changed: 13 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17059.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17059/head:pull/17059

PR: https://git.openjdk.org/jdk/pull/17059

From alanb at openjdk.org  Tue Dec 12 09:52:45 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 12 Dec 2023 09:52:45 GMT
Subject: RFR: 8321802: (zipfs) Add validation of incorrect LOC signature in
 ZipFileSystem
In-Reply-To: <9OyZCEKEcOKOhnzSo8Ls4EfxijWzTVhp1H_SBaisYY8=.b82a211b-b98a-451d-8ce2-47b53314c492@github.com>
References: <9OyZCEKEcOKOhnzSo8Ls4EfxijWzTVhp1H_SBaisYY8=.b82a211b-b98a-451d-8ce2-47b53314c492@github.com>
Message-ID: <SZjeDuh_LsZIeY9umLAeLyAqod5tbdtOLPPhbpypjUM=.2324204c-94d1-494a-967d-b3ef96e8a382@github.com>

On Mon, 11 Dec 2023 15:38:28 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Please review this PR which adds validation of incorrect LOC signatures in `ZipFileSystem`.
> 
> `ZipFile` already rejects the case where the  offset pointed to from the CEN header does not start with the expected LOC signature. It makes sense to add this check to `ZipFileSystem` as well.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17059#pullrequestreview-1776849857

From hannesw at openjdk.org  Tue Dec 12 09:53:40 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 12 Dec 2023 09:53:40 GMT
Subject: RFR: JDK-8321889: JavaDoc method references with wrong (nested) type
Message-ID: <H7x_wJyb9TK8FRey8yQjtveUAP5SUv4pJ2sBLaZQf-8=.15040532-074d-4296-9909-7fb4397bc039@github.com>

Please review a change to fix JavaDoc references using a nested class instead of the enclosing class containing the target method. Until now this is accepted by JavaDoc (with the correct link being created). With [JDK-8164094](https://bugs.openjdk.org/browse/JDK-8164094) these references are reported as errors.

-------------

Commit messages:
 - JDK-8321889: JavaDoc method references with wrong (nested) type

Changes: https://git.openjdk.org/jdk/pull/17078/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17078&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321889
  Stats: 6 lines in 3 files changed: 0 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/17078.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17078/head:pull/17078

PR: https://git.openjdk.org/jdk/pull/17078

From pminborg at openjdk.org  Tue Dec 12 10:09:45 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 12 Dec 2023 10:09:45 GMT
Subject: RFR: 8321786: SegmentAllocator:allocateFrom(ValueLayout,
 MemorySegment,ValueLayout,long,long) spec mismatch in exception scenario
Message-ID: <-VY5wYQXjxv1dg1I0pqwcsONzuSQDcKVLIST-4HJUqw=.360b5491-8d6d-48fd-acb1-7e477e71d654@github.com>

This PR proposes to change the specification for some methods that take `long` offsets so that they will throw an `IllegalArgumentException` rather than an `IndexOutOfBoundsException` for negative values.

The PR also proposes to fix a bug where the allocation size would overflow and the specified exception was not thrown.

-------------

Commit messages:
 - Change the exception thrown for certain negative long values

Changes: https://git.openjdk.org/jdk/pull/17079/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17079&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321786
  Stats: 185 lines in 9 files changed: 162 ins; 12 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/17079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17079/head:pull/17079

PR: https://git.openjdk.org/jdk/pull/17079

From hannesw at openjdk.org  Tue Dec 12 10:42:32 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 12 Dec 2023 10:42:32 GMT
Subject: RFR: JDK-8321889: JavaDoc method references with wrong (nested)
 type [v2]
In-Reply-To: <H7x_wJyb9TK8FRey8yQjtveUAP5SUv4pJ2sBLaZQf-8=.15040532-074d-4296-9909-7fb4397bc039@github.com>
References: <H7x_wJyb9TK8FRey8yQjtveUAP5SUv4pJ2sBLaZQf-8=.15040532-074d-4296-9909-7fb4397bc039@github.com>
Message-ID: <nIlO1py1sZyxn4mfUUOtbAk7RVMLW1E1_uP4d4r6Vac=.437e6803-3cab-4963-a559-8c09ec794886@github.com>

> Please review a doc-only change for JavaDoc references using a nested class instead of the enclosing class containing the target method. Until now this is accepted by JavaDoc, but with [JDK-8164094](https://bugs.openjdk.org/browse/JDK-8164094) these references are reported as errors.
> 
> I made sure the rendered documentation is identical before and after the change (JavaDoc previously generated the correct links for these references).

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  Restore explicit label and remove duplicate word

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17078/files
  - new: https://git.openjdk.org/jdk/pull/17078/files/53e9cfa0..c7a76b17

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17078&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17078&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17078.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17078/head:pull/17078

PR: https://git.openjdk.org/jdk/pull/17078

From avoitylov at openjdk.org  Tue Dec 12 10:47:48 2023
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Tue, 12 Dec 2023 10:47:48 GMT
Subject: RFR: 8321514: UTF16 string gets constructed incorrectly from
 codepoints if CompactStrings is not enabled [v2]
In-Reply-To: <1azLdWceEALX1v_hfgt03ncVu_wtZyk3_lZ0B0J_cto=.a59aff49-50a9-498e-bc78-fd5468d87cd6@github.com>
References: <1azLdWceEALX1v_hfgt03ncVu_wtZyk3_lZ0B0J_cto=.a59aff49-50a9-498e-bc78-fd5468d87cd6@github.com>
Message-ID: <P1bqGRS3bqxB3VBm-dDbGShSmRBnOEFz-nKfpvSbBFQ=.4e3a4629-a880-4b67-aab1-d77e0a09c4bf@github.com>

> Since JDK-8311906, if CompactStrings is not enabled, index is not considered when calling extractCodepoints from StringUTF16.toBytes(). Because of that the last elements of the source codepoints array are stripped from the resulting UTF16 string, which fires in other places (e.g. during RegEx processing).
>  
> The fix replaces len in extractCodepoints parameters with end that is index + len.

Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:

  review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17057/files
  - new: https://git.openjdk.org/jdk/pull/17057/files/50c09846..759068e8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17057&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17057&range=00-01

  Stats: 70 lines in 2 files changed: 24 ins; 45 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17057.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17057/head:pull/17057

PR: https://git.openjdk.org/jdk/pull/17057

From avoitylov at openjdk.org  Tue Dec 12 11:00:25 2023
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Tue, 12 Dec 2023 11:00:25 GMT
Subject: RFR: 8321514: UTF16 string gets constructed incorrectly from
 codepoints if CompactStrings is not enabled [v2]
In-Reply-To: <P1bqGRS3bqxB3VBm-dDbGShSmRBnOEFz-nKfpvSbBFQ=.4e3a4629-a880-4b67-aab1-d77e0a09c4bf@github.com>
References: <1azLdWceEALX1v_hfgt03ncVu_wtZyk3_lZ0B0J_cto=.a59aff49-50a9-498e-bc78-fd5468d87cd6@github.com>
 <P1bqGRS3bqxB3VBm-dDbGShSmRBnOEFz-nKfpvSbBFQ=.4e3a4629-a880-4b67-aab1-d77e0a09c4bf@github.com>
Message-ID: <FLY0cYlCliYHcnGviTSzrXR2gGhRQ-ao4mMRrbxAkGQ=.539d5b50-97c1-4dd1-b27f-a77e0a9203a4@github.com>

On Tue, 12 Dec 2023 10:47:48 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

>> Since JDK-8311906, if CompactStrings is not enabled, index is not considered when calling extractCodepoints from StringUTF16.toBytes(). Because of that the last elements of the source codepoints array are stripped from the resulting UTF16 string, which fires in other places (e.g. during RegEx processing).
>>  
>> The fix replaces len in extractCodepoints parameters with end that is index + len.
>
> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Thanks Roger. I agree with your point and pulled your suggested test in the PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17057#issuecomment-1851807686

From alanb at openjdk.org  Tue Dec 12 11:07:22 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 12 Dec 2023 11:07:22 GMT
Subject: RFR: JDK-8321889: JavaDoc method references with wrong (nested)
 type [v2]
In-Reply-To: <nIlO1py1sZyxn4mfUUOtbAk7RVMLW1E1_uP4d4r6Vac=.437e6803-3cab-4963-a559-8c09ec794886@github.com>
References: <H7x_wJyb9TK8FRey8yQjtveUAP5SUv4pJ2sBLaZQf-8=.15040532-074d-4296-9909-7fb4397bc039@github.com>
 <nIlO1py1sZyxn4mfUUOtbAk7RVMLW1E1_uP4d4r6Vac=.437e6803-3cab-4963-a559-8c09ec794886@github.com>
Message-ID: <4dIjqukV52060edEa6j0AiOv5psHgpEFYXOzYqLKNf4=.cede50ce-09da-484e-9b5d-fc185631e419@github.com>

On Tue, 12 Dec 2023 10:42:32 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a doc-only change for JavaDoc references using a nested class instead of the enclosing class containing the target method. Until now this is accepted by JavaDoc, but with [JDK-8164094](https://bugs.openjdk.org/browse/JDK-8164094) these references are reported as errors.
>> 
>> I made sure the rendered documentation is identical before and after the change (JavaDoc previously generated the correct links for these references).
>> 
>> Update: I also fixed two typos in `javax/smartcardio/CardTerminals.java` by removing the duplicate "call" in "... latest call to waitForChange() call".
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore explicit label and remove duplicate word

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17078#pullrequestreview-1777214660

From mcimadamore at openjdk.org  Tue Dec 12 11:09:25 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 12 Dec 2023 11:09:25 GMT
Subject: RFR: 8321786: SegmentAllocator:allocateFrom(ValueLayout,
 MemorySegment,ValueLayout,long,long) spec mismatch in exception scenario
In-Reply-To: <-VY5wYQXjxv1dg1I0pqwcsONzuSQDcKVLIST-4HJUqw=.360b5491-8d6d-48fd-acb1-7e477e71d654@github.com>
References: <-VY5wYQXjxv1dg1I0pqwcsONzuSQDcKVLIST-4HJUqw=.360b5491-8d6d-48fd-acb1-7e477e71d654@github.com>
Message-ID: <fMF3Bb_5csdsf6MGw2N5i4Uor-WJV5fKsWyIjimBEhI=.3f098da7-638e-4f2b-803a-3904fb356c03@github.com>

On Tue, 12 Dec 2023 10:02:00 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to change the specification for some methods that take `long` offsets so that they will throw an `IllegalArgumentException` rather than an `IndexOutOfBoundsException` for negative values.
> 
> The PR also proposes to fix a bug where the allocation size would overflow and the specified exception was not thrown.

src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 737:

> 735:     private MemorySegment allocateNoInit(MemoryLayout layout, long size) {
> 736:         long byteSize;
> 737:         try {

I don't think we want this. While it is more correct, that would negatively affect performance. If there's an overflow, let it go negative, it will be caught anyway

src/java.base/share/classes/jdk/internal/foreign/layout/AbstractLayout.java line 156:

> 154:         Utils.checkNonNegative(offset, "offset");
> 155:         Utils.checkNonNegative(index, "index");
> 156:         if (offset < 0) {

Duplicate check?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17079#discussion_r1423834990
PR Review Comment: https://git.openjdk.org/jdk/pull/17079#discussion_r1423835592

From hannesw at openjdk.org  Tue Dec 12 11:30:32 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 12 Dec 2023 11:30:32 GMT
Subject: Integrated: JDK-8321889: JavaDoc method references with wrong (nested)
 type
In-Reply-To: <H7x_wJyb9TK8FRey8yQjtveUAP5SUv4pJ2sBLaZQf-8=.15040532-074d-4296-9909-7fb4397bc039@github.com>
References: <H7x_wJyb9TK8FRey8yQjtveUAP5SUv4pJ2sBLaZQf-8=.15040532-074d-4296-9909-7fb4397bc039@github.com>
Message-ID: <wIQscL9sqcYsC8GKpLom4OdGAf7k7bJOuX8V6Y4ZCCw=.3f99cffa-2c24-4e13-b02a-3ca010977c70@github.com>

On Tue, 12 Dec 2023 09:46:29 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a doc-only change for JavaDoc references using a nested class instead of the enclosing class containing the target method. Until now this is accepted by JavaDoc, but with [JDK-8164094](https://bugs.openjdk.org/browse/JDK-8164094) these references are reported as errors.
> 
> I made sure the rendered documentation is identical before and after the change (JavaDoc previously generated the correct links for these references).
> 
> Update: I also fixed two typos in `javax/smartcardio/CardTerminals.java` by removing the duplicate "call" in "... latest call to waitForChange() call".

This pull request has now been integrated.

Changeset: c5168526
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c51685267c7bd5a7cee27ebc2bf0d9899cda9d4c
Stats:     7 lines in 3 files changed: 0 ins; 2 del; 5 mod

8321889: JavaDoc method references with wrong (nested) type

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/17078

From pminborg at openjdk.org  Tue Dec 12 11:48:32 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 12 Dec 2023 11:48:32 GMT
Subject: RFR: 8321786: SegmentAllocator:allocateFrom(ValueLayout,
 MemorySegment,ValueLayout,long,long) spec mismatch in exception scenario
In-Reply-To: <fMF3Bb_5csdsf6MGw2N5i4Uor-WJV5fKsWyIjimBEhI=.3f098da7-638e-4f2b-803a-3904fb356c03@github.com>
References: <-VY5wYQXjxv1dg1I0pqwcsONzuSQDcKVLIST-4HJUqw=.360b5491-8d6d-48fd-acb1-7e477e71d654@github.com>
 <fMF3Bb_5csdsf6MGw2N5i4Uor-WJV5fKsWyIjimBEhI=.3f098da7-638e-4f2b-803a-3904fb356c03@github.com>
Message-ID: <IaQKV6oJ6l2xT7E0vms9H4wuqY90S2EZoTYhQ1xLfL8=.a10a6a5a-5c73-4d43-ac1e-fe652268ddd4@github.com>

On Tue, 12 Dec 2023 11:05:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR proposes to change the specification for some methods that take `long` offsets so that they will throw an `IllegalArgumentException` rather than an `IndexOutOfBoundsException` for negative values.
>> 
>> The PR also proposes to fix a bug where the allocation size would overflow and the specified exception was not thrown.
>
> src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 737:
> 
>> 735:     private MemorySegment allocateNoInit(MemoryLayout layout, long size) {
>> 736:         long byteSize;
>> 737:         try {
> 
> I don't think we want this. While it is more correct, that would negatively affect performance. If there's an overflow, let it go negative, it will be caught anyway

True. But we will get the wrong type of exception.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17079#discussion_r1423876941

From lancea at openjdk.org  Tue Dec 12 11:50:33 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 12 Dec 2023 11:50:33 GMT
Subject: RFR: 8321802: (zipfs) Add validation of incorrect LOC signature in
 ZipFileSystem
In-Reply-To: <9OyZCEKEcOKOhnzSo8Ls4EfxijWzTVhp1H_SBaisYY8=.b82a211b-b98a-451d-8ce2-47b53314c492@github.com>
References: <9OyZCEKEcOKOhnzSo8Ls4EfxijWzTVhp1H_SBaisYY8=.b82a211b-b98a-451d-8ce2-47b53314c492@github.com>
Message-ID: <BDlKZkKGLaECMLQFjnWMFhQEsYUKfXoRk1To_470RGM=.1d37290f-cd88-4fa6-94ab-0ace377faa98@github.com>

On Mon, 11 Dec 2023 15:38:28 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Please review this PR which adds validation of incorrect LOC signatures in `ZipFileSystem`.
> 
> `ZipFile` already rejects the case where the  offset pointed to from the CEN header does not start with the expected LOC signature. It makes sense to add this check to `ZipFileSystem` as well.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 2579:

> 2577:                 }
> 2578:                 if (LOCSIG(buf) != LOCSIG) {
> 2579:                     throw new ZipException("invalid loc header (bad signature)");

Please change loc -> LOC

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17059#discussion_r1423879142

From pminborg at openjdk.org  Tue Dec 12 11:52:31 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 12 Dec 2023 11:52:31 GMT
Subject: RFR: 8321786: SegmentAllocator:allocateFrom(ValueLayout,
 MemorySegment,ValueLayout,long,long) spec mismatch in exception scenario
In-Reply-To: <IaQKV6oJ6l2xT7E0vms9H4wuqY90S2EZoTYhQ1xLfL8=.a10a6a5a-5c73-4d43-ac1e-fe652268ddd4@github.com>
References: <-VY5wYQXjxv1dg1I0pqwcsONzuSQDcKVLIST-4HJUqw=.360b5491-8d6d-48fd-acb1-7e477e71d654@github.com>
 <fMF3Bb_5csdsf6MGw2N5i4Uor-WJV5fKsWyIjimBEhI=.3f098da7-638e-4f2b-803a-3904fb356c03@github.com>
 <IaQKV6oJ6l2xT7E0vms9H4wuqY90S2EZoTYhQ1xLfL8=.a10a6a5a-5c73-4d43-ac1e-fe652268ddd4@github.com>
Message-ID: <P_mTM3VT5KrhSbVTgQlptMJOpTCX8Xu8apjIMiqGRKQ=.10905146-bf8a-448b-b3ae-af5ea557778f@github.com>

On Tue, 12 Dec 2023 11:45:22 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 737:
>> 
>>> 735:     private MemorySegment allocateNoInit(MemoryLayout layout, long size) {
>>> 736:         long byteSize;
>>> 737:         try {
>> 
>> I don't think we want this. While it is more correct, that would negatively affect performance. If there's an overflow, let it go negative, it will be caught anyway
>
> True. But we will get the wrong type of exception.

We could change the exception type to `ArithmeticException` in this case and get performance and correctness at the same time.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17079#discussion_r1423880997

From duke at openjdk.org  Tue Dec 12 11:59:36 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 12 Dec 2023 11:59:36 GMT
Subject: RFR: 8321802: (zipfs) Add validation of incorrect LOC signature in
 ZipFileSystem [v2]
In-Reply-To: <9OyZCEKEcOKOhnzSo8Ls4EfxijWzTVhp1H_SBaisYY8=.b82a211b-b98a-451d-8ce2-47b53314c492@github.com>
References: <9OyZCEKEcOKOhnzSo8Ls4EfxijWzTVhp1H_SBaisYY8=.b82a211b-b98a-451d-8ce2-47b53314c492@github.com>
Message-ID: <4tMOaFRnlcSLhVgiBj9eDfRI0u9mOVQpx6kCAvpVgS0=.3dbe700c-2f7e-40ed-a644-4175d41bb69c@github.com>

> Please review this PR which adds validation of incorrect LOC signatures in `ZipFileSystem`.
> 
> `ZipFile` already rejects the case where the  offset pointed to from the CEN header does not start with the expected LOC signature. It makes sense to add this check to `ZipFileSystem` as well.

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Use uppercase LOC in ZipException messages

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17059/files
  - new: https://git.openjdk.org/jdk/pull/17059/files/bd18ce34..c7ca450e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17059&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17059&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17059.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17059/head:pull/17059

PR: https://git.openjdk.org/jdk/pull/17059

From duke at openjdk.org  Tue Dec 12 11:59:39 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 12 Dec 2023 11:59:39 GMT
Subject: RFR: 8321802: (zipfs) Add validation of incorrect LOC signature in
 ZipFileSystem [v2]
In-Reply-To: <BDlKZkKGLaECMLQFjnWMFhQEsYUKfXoRk1To_470RGM=.1d37290f-cd88-4fa6-94ab-0ace377faa98@github.com>
References: <9OyZCEKEcOKOhnzSo8Ls4EfxijWzTVhp1H_SBaisYY8=.b82a211b-b98a-451d-8ce2-47b53314c492@github.com>
 <BDlKZkKGLaECMLQFjnWMFhQEsYUKfXoRk1To_470RGM=.1d37290f-cd88-4fa6-94ab-0ace377faa98@github.com>
Message-ID: <3IT0ujPJf4zfh8T36Tylrstg6xxdYAo3ljQaGVkBL3M=.a894ce02-3a9c-4181-8202-e8871746fa41@github.com>

On Tue, 12 Dec 2023 11:47:35 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use uppercase LOC in ZipException messages
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 2579:
> 
>> 2577:                 }
>> 2578:                 if (LOCSIG(buf) != LOCSIG) {
>> 2579:                     throw new ZipException("invalid loc header (bad signature)");
> 
> Please change loc -> LOC

Fixed, including the ZipException for the preceding read check.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17059#discussion_r1423888116

From mcimadamore at openjdk.org  Tue Dec 12 12:07:15 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 12 Dec 2023 12:07:15 GMT
Subject: RFR: 8321786: SegmentAllocator:allocateFrom(ValueLayout,
 MemorySegment,ValueLayout,long,long) spec mismatch in exception scenario
In-Reply-To: <P_mTM3VT5KrhSbVTgQlptMJOpTCX8Xu8apjIMiqGRKQ=.10905146-bf8a-448b-b3ae-af5ea557778f@github.com>
References: <-VY5wYQXjxv1dg1I0pqwcsONzuSQDcKVLIST-4HJUqw=.360b5491-8d6d-48fd-acb1-7e477e71d654@github.com>
 <fMF3Bb_5csdsf6MGw2N5i4Uor-WJV5fKsWyIjimBEhI=.3f098da7-638e-4f2b-803a-3904fb356c03@github.com>
 <IaQKV6oJ6l2xT7E0vms9H4wuqY90S2EZoTYhQ1xLfL8=.a10a6a5a-5c73-4d43-ac1e-fe652268ddd4@github.com>
 <P_mTM3VT5KrhSbVTgQlptMJOpTCX8Xu8apjIMiqGRKQ=.10905146-bf8a-448b-b3ae-af5ea557778f@github.com>
Message-ID: <9IxiNrjj_9x95rBTwtp8fdYDAd6wVE4hQsqz1KABHQU=.57f08c50-c7e4-4fb6-842c-d468c131869e@github.com>

On Tue, 12 Dec 2023 11:49:17 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> True. But we will get the wrong type of exception.
>
> We could change the exception type to `ArithmeticException` in this case and get performance and correctness at the same time.

I simply don't think we should be using `multiplyExact` here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17079#discussion_r1423896653

From lancea at openjdk.org  Tue Dec 12 12:07:16 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 12 Dec 2023 12:07:16 GMT
Subject: RFR: 8321802: (zipfs) Add validation of incorrect LOC signature in
 ZipFileSystem [v2]
In-Reply-To: <4tMOaFRnlcSLhVgiBj9eDfRI0u9mOVQpx6kCAvpVgS0=.3dbe700c-2f7e-40ed-a644-4175d41bb69c@github.com>
References: <9OyZCEKEcOKOhnzSo8Ls4EfxijWzTVhp1H_SBaisYY8=.b82a211b-b98a-451d-8ce2-47b53314c492@github.com>
 <4tMOaFRnlcSLhVgiBj9eDfRI0u9mOVQpx6kCAvpVgS0=.3dbe700c-2f7e-40ed-a644-4175d41bb69c@github.com>
Message-ID: <Aba29AnNcy3YiL8kQhVyRNFPrAF3Zfll-0EUWIbj58U=.95c21258-ee8a-4c78-b2cf-cc5788dc90c1@github.com>

On Tue, 12 Dec 2023 11:59:36 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Please review this PR which adds validation of incorrect LOC signatures in `ZipFileSystem`.
>> 
>> `ZipFile` already rejects the case where the  offset pointed to from the CEN header does not start with the expected LOC signature. It makes sense to add this check to `ZipFileSystem` as well.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use uppercase LOC in ZipException messages

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17059#pullrequestreview-1777315017

From mcimadamore at openjdk.org  Tue Dec 12 12:12:31 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 12 Dec 2023 12:12:31 GMT
Subject: RFR: 8321400: java/foreign/TestStubAllocFailure.java fails with
 code cache exhaustion
In-Reply-To: <GzvkhIYT0Bz6jHuS5o-q_DvNTRCKfj5hqDRHPvN2MxY=.8ce04894-a4e6-4339-9dfb-26a1933d3e59@github.com>
References: <GzvkhIYT0Bz6jHuS5o-q_DvNTRCKfj5hqDRHPvN2MxY=.8ce04894-a4e6-4339-9dfb-26a1933d3e59@github.com>
Message-ID: <ikpi6oZGEvUEtP6l2A7n2VS9bZugFJJqBRtpx83U7Xs=.ffae3c5f-23a2-4472-b5a6-4442284482fd@github.com>

On Mon, 11 Dec 2023 13:01:25 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Improve the test by being more lenient to related code cache exhaustion errors. The important thing is that we don't terminate with a fatal error, which the new code now checks for explicitly. The check for that is based on what is done by `./test/hotspot/jtreg/runtime/ErrorHandling/HsErrFileUtils.java` .
> 
> The existing `UpcallTestHelper.Output` class that was previously used to assert on stdout/stderr contents did not have the capability to look for patterns in the output. So, I've taken the opportunity to replace it with the more canonical `OutputAnalyzer` which comes from the test library.
> 
> Finally, I've also added back the test for downcall stub allocation failure which was removed as part of the initial patch because it was too inconsistent [1]. With the now approach, it should pass reliably as well.
> 
> Testing: `jdk_foreign`  suite (which contains all the affected tests)
> 
> [1]: https://github.com/openjdk/jdk/pull/16311/commits/9a1360598a91871ce6ec48330849c0e4e0279c64

Marked as reviewed by mcimadamore (Reviewer).

test/lib/jdk/test/lib/process/OutputAnalyzer.java line 870:

> 868:      * Assert that we did not crash with a hard VM error (generating an hs_err_pidXXX.log)
> 869:      */
> 870:     public void shouldNotHaveFatalError() {

Looking at the usages, I wonder if this should be `checkFatalError(boolean)` and, similarly, for the exit value `checkExitValue(int value)` ?

-------------

PR Review: https://git.openjdk.org/jdk/pull/17056#pullrequestreview-1777325219
PR Review Comment: https://git.openjdk.org/jdk/pull/17056#discussion_r1423901980

From pminborg at openjdk.org  Tue Dec 12 13:13:45 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 12 Dec 2023 13:13:45 GMT
Subject: RFR: 8321786: SegmentAllocator:allocateFrom(ValueLayout,
 MemorySegment, ValueLayout, long,
 long) spec mismatch in exception scenario [v2]
In-Reply-To: <-VY5wYQXjxv1dg1I0pqwcsONzuSQDcKVLIST-4HJUqw=.360b5491-8d6d-48fd-acb1-7e477e71d654@github.com>
References: <-VY5wYQXjxv1dg1I0pqwcsONzuSQDcKVLIST-4HJUqw=.360b5491-8d6d-48fd-acb1-7e477e71d654@github.com>
Message-ID: <jlUDaLNy5y_MgvylTkFXV-jA7Qnass23AENS9vcsV8g=.25397d0d-add4-4c9f-9148-b2de7dfec120@github.com>

> This PR proposes to change the specification for some methods that take `long` offsets so that they will throw an `IllegalArgumentException` rather than an `IndexOutOfBoundsException` for negative values.
> 
> The PR also proposes to fix a bug where the allocation size would overflow and the specified exception was not thrown.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Update after comments and discussion

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17079/files
  - new: https://git.openjdk.org/jdk/pull/17079/files/27fc39fe..28a33930

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17079&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17079&range=00-01

  Stats: 136 lines in 10 files changed: 77 ins; 14 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/17079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17079/head:pull/17079

PR: https://git.openjdk.org/jdk/pull/17079

From pminborg at openjdk.org  Tue Dec 12 13:20:48 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 12 Dec 2023 13:20:48 GMT
Subject: RFR: 8321786: SegmentAllocator:allocateFrom(ValueLayout,
 MemorySegment, ValueLayout, long,
 long) spec mismatch in exception scenario [v3]
In-Reply-To: <-VY5wYQXjxv1dg1I0pqwcsONzuSQDcKVLIST-4HJUqw=.360b5491-8d6d-48fd-acb1-7e477e71d654@github.com>
References: <-VY5wYQXjxv1dg1I0pqwcsONzuSQDcKVLIST-4HJUqw=.360b5491-8d6d-48fd-acb1-7e477e71d654@github.com>
Message-ID: <gU-EVsx_ohgvpFG5kOI7yN_TuyGs_9hBGd7HfpZUYKU=.07c912f0-6cf8-4804-a340-4391ee9340b9@github.com>

> This PR proposes to change the specification for some methods that take `long` offsets so that they will throw an `IllegalArgumentException` rather than an `IndexOutOfBoundsException` for negative values.
> 
> The PR also proposes to fix a bug where the allocation size would overflow and the specified exception was not thrown.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove Math.multiply exact and change exception type

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17079/files
  - new: https://git.openjdk.org/jdk/pull/17079/files/28a33930..f601b2f1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17079&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17079&range=01-02

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17079/head:pull/17079

PR: https://git.openjdk.org/jdk/pull/17079

From pminborg at openjdk.org  Tue Dec 12 13:23:27 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 12 Dec 2023 13:23:27 GMT
Subject: RFR: 8321786: SegmentAllocator:allocateFrom(ValueLayout,
 MemorySegment, ValueLayout, long,
 long) spec mismatch in exception scenario [v4]
In-Reply-To: <-VY5wYQXjxv1dg1I0pqwcsONzuSQDcKVLIST-4HJUqw=.360b5491-8d6d-48fd-acb1-7e477e71d654@github.com>
References: <-VY5wYQXjxv1dg1I0pqwcsONzuSQDcKVLIST-4HJUqw=.360b5491-8d6d-48fd-acb1-7e477e71d654@github.com>
Message-ID: <WAOzW3SyeVWENQzT5jo4NgM9qY4YLWvS7i2h3g0fGbM=.e1982304-cde2-4e49-891b-4076edc39f98@github.com>

> This PR proposes to change the specification for some methods that take `long` offsets so that they will throw an `IllegalArgumentException` rather than an `IndexOutOfBoundsException` for negative values.
> 
> The PR also proposes to fix a bug where the allocation size would overflow and the specified exception was not thrown.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Revert change in allocateNoInit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17079/files
  - new: https://git.openjdk.org/jdk/pull/17079/files/f601b2f1..71b21734

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17079&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17079&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17079/head:pull/17079

PR: https://git.openjdk.org/jdk/pull/17079

From mcimadamore at openjdk.org  Tue Dec 12 13:55:33 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 12 Dec 2023 13:55:33 GMT
Subject: RFR: 8321786: SegmentAllocator:allocateFrom(ValueLayout,
 MemorySegment, ValueLayout, long,
 long) spec mismatch in exception scenario [v4]
In-Reply-To: <WAOzW3SyeVWENQzT5jo4NgM9qY4YLWvS7i2h3g0fGbM=.e1982304-cde2-4e49-891b-4076edc39f98@github.com>
References: <-VY5wYQXjxv1dg1I0pqwcsONzuSQDcKVLIST-4HJUqw=.360b5491-8d6d-48fd-acb1-7e477e71d654@github.com>
 <WAOzW3SyeVWENQzT5jo4NgM9qY4YLWvS7i2h3g0fGbM=.e1982304-cde2-4e49-891b-4076edc39f98@github.com>
Message-ID: <Hs3dJU4FFT8L5M5wMTdwZTBbc8DCDTDI3O94efJXzEg=.6cddd84f-7685-45e2-ad33-d3a89fcd5fec@github.com>

On Tue, 12 Dec 2023 13:23:27 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to change the specification for some methods that take `long` offsets so that they will throw an `IllegalArgumentException` rather than an `IndexOutOfBoundsException` for negative values.
>> 
>> The PR also proposes to fix a bug where the allocation size would overflow and the specified exception was not thrown.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert change in allocateNoInit

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2380:

> 2378:      * @throws IndexOutOfBoundsException if {@code index * layout.byteSize()} overflows
> 2379:      * @throws IndexOutOfBoundsException if {@code index * layout.byteSize() > byteSize() - layout.byteSize()}
> 2380:      *         or {@code offset < 0}

All these should say `index` not `offset`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17079#discussion_r1424024406

From mcimadamore at openjdk.org  Tue Dec 12 14:09:30 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 12 Dec 2023 14:09:30 GMT
Subject: RFR: 8321786: SegmentAllocator:allocateFrom(ValueLayout,
 MemorySegment, ValueLayout, long,
 long) spec mismatch in exception scenario [v4]
In-Reply-To: <WAOzW3SyeVWENQzT5jo4NgM9qY4YLWvS7i2h3g0fGbM=.e1982304-cde2-4e49-891b-4076edc39f98@github.com>
References: <-VY5wYQXjxv1dg1I0pqwcsONzuSQDcKVLIST-4HJUqw=.360b5491-8d6d-48fd-acb1-7e477e71d654@github.com>
 <WAOzW3SyeVWENQzT5jo4NgM9qY4YLWvS7i2h3g0fGbM=.e1982304-cde2-4e49-891b-4076edc39f98@github.com>
Message-ID: <SsG6zs3kS0CsLhIWast2Kn1z2uIOKetE4oJS3LJCX9M=.1ad7a38f-5fe2-4b86-9314-fa4505fbc22a@github.com>

On Tue, 12 Dec 2023 13:23:27 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to change the specification for some methods that take `long` offsets so that they will throw an `IllegalArgumentException` rather than an `IndexOutOfBoundsException` for negative values.
>> 
>> The PR also proposes to fix a bug where the allocation size would overflow and the specified exception was not thrown.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert change in allocateNoInit

src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 396:

> 394:      * @throws IllegalArgumentException if {@code elementCount * sourceElementLayout.byteSize()} overflows
> 395:      * @throws IndexOutOfBoundsException if {@code sourceOffset > source.byteSize() - (elementCount * sourceElementLayout.byteSize())}
> 396:      * @throws IndexOutOfBoundsException if either {@code sourceOffset} or {@code elementCount} are {@code < 0}

I think that if elementCount < 0, we should throw IAE, not IOOBE. Note that we explain this method as:

 MemorySegment dest = this.allocate(elementLayout, elementCount);
 MemorySegment.copy(source, sourceElementLayout, sourceOffset, dest, elementLayout, 0, elementCount);


So, the set of exceptions thrown by these two methods should be preserved. This means that `allocate(MemoryLayout, long)` gets a first pass at checking - this means IAE for overflows and also for negative element count.

After that, the exceptions we can have are those specified in MemorySegment.copy.

src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 407:

> 405:         Objects.requireNonNull(sourceElementLayout);
> 406:         Objects.requireNonNull(elementLayout);
> 407:         Utils.checkNonNegativeIndex(elementCount, "elementCount");

I think this check should be omitted (see comment above)

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 595:

> 593:                             long elementCount) {
> 594: 
> 595:         Utils.checkNonNegativeIndex(srcOffset, "srcOffset");

These new checks don't change the behavior, right? E.g. they will end up issuing an IIOBE, as before? So, why the changes? (note that these change might lead to double checks)

src/java.base/share/classes/jdk/internal/foreign/Utils.java line 216:

> 214:     }
> 215: 
> 216:     public static void checkNonNegativeArgument(long value, String name) {

Add `@ForceInline` to these

test/jdk/java/foreign/TestSegmentAllocators.java line 230:

> 228:             // IllegalStateException if the {@linkplain MemorySegment#scope() scope} associated
> 229:             // with {@code source} is not {@linkplain MemorySegment.Scope#isAlive() alive}
> 230:             Arena closedArena = Arena.ofConfined();

the scope/thread assertions are already checked in TestScopedOperations - I don't think we need this, but you might want to make sure a test case for this new allocator method is added there

test/jdk/java/foreign/TestSegmentAllocators.java line 248:

> 246:             }
> 247: 
> 248:             // ArithmeticException if {@code elementCount * sourceElementLayout.byteSize()} overflows

comment is wrong

test/jdk/java/foreign/TestSegments.java line 194:

> 192: 
> 193:     @Test(expectedExceptions = IndexOutOfBoundsException.class)
> 194:     public void testNegativeGetOffset() {

We have a test specifically for instance segment accessors (TestMemoryAccessInstance) which covers _all_ accessors - maybe better to move these new tests there?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17079#discussion_r1424033026
PR Review Comment: https://git.openjdk.org/jdk/pull/17079#discussion_r1424035187
PR Review Comment: https://git.openjdk.org/jdk/pull/17079#discussion_r1424037078
PR Review Comment: https://git.openjdk.org/jdk/pull/17079#discussion_r1424037878
PR Review Comment: https://git.openjdk.org/jdk/pull/17079#discussion_r1424041046
PR Review Comment: https://git.openjdk.org/jdk/pull/17079#discussion_r1424041984
PR Review Comment: https://git.openjdk.org/jdk/pull/17079#discussion_r1424043834

From mcimadamore at openjdk.org  Tue Dec 12 14:09:30 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 12 Dec 2023 14:09:30 GMT
Subject: RFR: 8321786: SegmentAllocator:allocateFrom(ValueLayout,
 MemorySegment, ValueLayout, long,
 long) spec mismatch in exception scenario [v4]
In-Reply-To: <SsG6zs3kS0CsLhIWast2Kn1z2uIOKetE4oJS3LJCX9M=.1ad7a38f-5fe2-4b86-9314-fa4505fbc22a@github.com>
References: <-VY5wYQXjxv1dg1I0pqwcsONzuSQDcKVLIST-4HJUqw=.360b5491-8d6d-48fd-acb1-7e477e71d654@github.com>
 <WAOzW3SyeVWENQzT5jo4NgM9qY4YLWvS7i2h3g0fGbM=.e1982304-cde2-4e49-891b-4076edc39f98@github.com>
 <SsG6zs3kS0CsLhIWast2Kn1z2uIOKetE4oJS3LJCX9M=.1ad7a38f-5fe2-4b86-9314-fa4505fbc22a@github.com>
Message-ID: <TVg7n9FHauuQN4JB3-TIUy_NOq0X-t4SSsUY4oEA5FM=.d9ba1ac6-6c4d-4251-9a44-2b305c7defa0@github.com>

On Tue, 12 Dec 2023 13:58:42 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert change in allocateNoInit
>
> src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 396:
> 
>> 394:      * @throws IllegalArgumentException if {@code elementCount * sourceElementLayout.byteSize()} overflows
>> 395:      * @throws IndexOutOfBoundsException if {@code sourceOffset > source.byteSize() - (elementCount * sourceElementLayout.byteSize())}
>> 396:      * @throws IndexOutOfBoundsException if either {@code sourceOffset} or {@code elementCount} are {@code < 0}
> 
> I think that if elementCount < 0, we should throw IAE, not IOOBE. Note that we explain this method as:
> 
>  MemorySegment dest = this.allocate(elementLayout, elementCount);
>  MemorySegment.copy(source, sourceElementLayout, sourceOffset, dest, elementLayout, 0, elementCount);
> 
> 
> So, the set of exceptions thrown by these two methods should be preserved. This means that `allocate(MemoryLayout, long)` gets a first pass at checking - this means IAE for overflows and also for negative element count.
> 
> After that, the exceptions we can have are those specified in MemorySegment.copy.

(as we did in other patches, I think it's important here to remain true to the semantics of the "desugared" code, because that will guarantee that developers can refactor their code w/o worrying about exceptions changing from under them)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17079#discussion_r1424034360

From mcimadamore at openjdk.org  Tue Dec 12 14:13:33 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 12 Dec 2023 14:13:33 GMT
Subject: RFR: 8321786: SegmentAllocator:allocateFrom(ValueLayout,
 MemorySegment, ValueLayout, long,
 long) spec mismatch in exception scenario [v4]
In-Reply-To: <SsG6zs3kS0CsLhIWast2Kn1z2uIOKetE4oJS3LJCX9M=.1ad7a38f-5fe2-4b86-9314-fa4505fbc22a@github.com>
References: <-VY5wYQXjxv1dg1I0pqwcsONzuSQDcKVLIST-4HJUqw=.360b5491-8d6d-48fd-acb1-7e477e71d654@github.com>
 <WAOzW3SyeVWENQzT5jo4NgM9qY4YLWvS7i2h3g0fGbM=.e1982304-cde2-4e49-891b-4076edc39f98@github.com>
 <SsG6zs3kS0CsLhIWast2Kn1z2uIOKetE4oJS3LJCX9M=.1ad7a38f-5fe2-4b86-9314-fa4505fbc22a@github.com>
Message-ID: <8K1EuKgaZIUbkM-BZtcdac-08FjntK6DD0F17WxuEzk=.0e353ef7-ac8a-4a31-829c-5e3b97d2eb7f@github.com>

On Tue, 12 Dec 2023 14:01:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert change in allocateNoInit
>
> src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 595:
> 
>> 593:                             long elementCount) {
>> 594: 
>> 595:         Utils.checkNonNegativeIndex(srcOffset, "srcOffset");
> 
> These new checks don't change the behavior, right? E.g. they will end up issuing an IIOBE, as before? So, why the changes? (note that these change might lead to double checks)

It seems like this is about generating better exception (while leaving the exception type unchanged). If so, I support the change, as I agree that this patch does improve some of the messages.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17079#discussion_r1424048808

From jvernee at openjdk.org  Tue Dec 12 14:26:25 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 12 Dec 2023 14:26:25 GMT
Subject: RFR: 8321400: java/foreign/TestStubAllocFailure.java fails with
 code cache exhaustion
In-Reply-To: <ikpi6oZGEvUEtP6l2A7n2VS9bZugFJJqBRtpx83U7Xs=.ffae3c5f-23a2-4472-b5a6-4442284482fd@github.com>
References: <GzvkhIYT0Bz6jHuS5o-q_DvNTRCKfj5hqDRHPvN2MxY=.8ce04894-a4e6-4339-9dfb-26a1933d3e59@github.com>
 <ikpi6oZGEvUEtP6l2A7n2VS9bZugFJJqBRtpx83U7Xs=.ffae3c5f-23a2-4472-b5a6-4442284482fd@github.com>
Message-ID: <1Fu89BIuIbdkxTHet7yTv1sto9jDsyMQC_cJjDxSQtc=.834afe59-d90a-4e54-94c7-70cb2aa0a89e@github.com>

On Tue, 12 Dec 2023 12:09:50 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Improve the test by being more lenient to related code cache exhaustion errors. The important thing is that we don't terminate with a fatal error, which the new code now checks for explicitly. The check for that is based on what is done by `./test/hotspot/jtreg/runtime/ErrorHandling/HsErrFileUtils.java` .
>> 
>> The existing `UpcallTestHelper.Output` class that was previously used to assert on stdout/stderr contents did not have the capability to look for patterns in the output. So, I've taken the opportunity to replace it with the more canonical `OutputAnalyzer` which comes from the test library.
>> 
>> Finally, I've also added back the test for downcall stub allocation failure which was removed as part of the initial patch because it was too inconsistent [1]. With the now approach, it should pass reliably as well.
>> 
>> Testing: `jdk_foreign`  suite (which contains all the affected tests)
>> 
>> [1]: https://github.com/openjdk/jdk/pull/16311/commits/9a1360598a91871ce6ec48330849c0e4e0279c64
>
> test/lib/jdk/test/lib/process/OutputAnalyzer.java line 870:
> 
>> 868:      * Assert that we did not crash with a hard VM error (generating an hs_err_pidXXX.log)
>> 869:      */
>> 870:     public void shouldNotHaveFatalError() {
> 
> Looking at the usages, I wonder if this should be `checkFatalError(boolean)` and, similarly, for the exit value `checkExitValue(int value)` ?

Are you suggesting to rename the existing methods? I don't see `checkExistValue(int value)` in `OutputAnalyzer`. The existing method naming pattern for the assertions is always `should(Not)XXX` though, so that's what I followed here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17056#discussion_r1424066457

From pminborg at openjdk.org  Tue Dec 12 15:09:45 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 12 Dec 2023 15:09:45 GMT
Subject: RFR: 8321786: SegmentAllocator:allocateFrom(ValueLayout,
 MemorySegment, ValueLayout, long,
 long) spec mismatch in exception scenario [v5]
In-Reply-To: <-VY5wYQXjxv1dg1I0pqwcsONzuSQDcKVLIST-4HJUqw=.360b5491-8d6d-48fd-acb1-7e477e71d654@github.com>
References: <-VY5wYQXjxv1dg1I0pqwcsONzuSQDcKVLIST-4HJUqw=.360b5491-8d6d-48fd-acb1-7e477e71d654@github.com>
Message-ID: <XFP2o1iXAVr1W3uhqcBzniTGcwuQU8byRkHu03pkILI=.40661eb4-790a-4159-bddb-602d29735a8e@github.com>

> This PR proposes to change the specification for some methods that take `long` offsets so that they will throw an `IllegalArgumentException` rather than an `IndexOutOfBoundsException` for negative values.
> 
> The PR also proposes to fix a bug where the allocation size would overflow and the specified exception was not thrown.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Update after comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17079/files
  - new: https://git.openjdk.org/jdk/pull/17079/files/71b21734..d67e079e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17079&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17079&range=03-04

  Stats: 82 lines in 8 files changed: 14 ins; 45 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/17079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17079/head:pull/17079

PR: https://git.openjdk.org/jdk/pull/17079

From mcimadamore at openjdk.org  Tue Dec 12 15:21:44 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 12 Dec 2023 15:21:44 GMT
Subject: RFR: 8321786: SegmentAllocator:allocateFrom(ValueLayout,
 MemorySegment, ValueLayout, long,
 long) spec mismatch in exception scenario [v5]
In-Reply-To: <XFP2o1iXAVr1W3uhqcBzniTGcwuQU8byRkHu03pkILI=.40661eb4-790a-4159-bddb-602d29735a8e@github.com>
References: <-VY5wYQXjxv1dg1I0pqwcsONzuSQDcKVLIST-4HJUqw=.360b5491-8d6d-48fd-acb1-7e477e71d654@github.com>
 <XFP2o1iXAVr1W3uhqcBzniTGcwuQU8byRkHu03pkILI=.40661eb4-790a-4159-bddb-602d29735a8e@github.com>
Message-ID: <yHu0iUTNEoDSBYCnxXMMJkHz4U_XybK6NoT-3vBnPm0=.1fb56977-dda9-47ec-9e65-bf8e535c9224@github.com>

On Tue, 12 Dec 2023 15:09:45 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to change the specification for some methods that take `long` offsets so that they will throw an `IllegalArgumentException` rather than an `IndexOutOfBoundsException` for negative values.
>> 
>> The PR also proposes to fix a bug where the allocation size would overflow and the specified exception was not thrown.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update after comments

src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 394:

> 392:      * @throws WrongThreadException if this method is called from a thread {@code T},
> 393:      *         such that {@code source.isAccessibleBy(T) == false}
> 394:      * @throws IllegalArgumentException if {@code elementCount * sourceElementLayout.byteSize()} overflows

if `elementCount < 0` -> IAE, as per allocate(layout, size)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17079#discussion_r1424158822

From pminborg at openjdk.org  Tue Dec 12 15:29:46 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 12 Dec 2023 15:29:46 GMT
Subject: RFR: 8321786: SegmentAllocator:allocateFrom(ValueLayout,
 MemorySegment, ValueLayout, long,
 long) spec mismatch in exception scenario [v6]
In-Reply-To: <-VY5wYQXjxv1dg1I0pqwcsONzuSQDcKVLIST-4HJUqw=.360b5491-8d6d-48fd-acb1-7e477e71d654@github.com>
References: <-VY5wYQXjxv1dg1I0pqwcsONzuSQDcKVLIST-4HJUqw=.360b5491-8d6d-48fd-acb1-7e477e71d654@github.com>
Message-ID: <YaFUZSPViK04361zpcVNsrySNapOtcgxao-kSKDY9Hk=.da24f074-de18-4ad8-bd47-292c4e95995e@github.com>

> This PR proposes to change the specification for some methods that take `long` offsets so that they will throw an `IllegalArgumentException` rather than an `IndexOutOfBoundsException` for negative values.
> 
> The PR also proposes to fix a bug where the allocation size would overflow and the specified exception was not thrown.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Correct exception type in JavaDocs for SA:allocateFrom

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17079/files
  - new: https://git.openjdk.org/jdk/pull/17079/files/d67e079e..c1407f77

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17079&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17079&range=04-05

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17079/head:pull/17079

PR: https://git.openjdk.org/jdk/pull/17079

From mcimadamore at openjdk.org  Tue Dec 12 15:42:17 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 12 Dec 2023 15:42:17 GMT
Subject: RFR: 8321786: SegmentAllocator:allocateFrom(ValueLayout,
 MemorySegment, ValueLayout, long,
 long) spec mismatch in exception scenario [v6]
In-Reply-To: <YaFUZSPViK04361zpcVNsrySNapOtcgxao-kSKDY9Hk=.da24f074-de18-4ad8-bd47-292c4e95995e@github.com>
References: <-VY5wYQXjxv1dg1I0pqwcsONzuSQDcKVLIST-4HJUqw=.360b5491-8d6d-48fd-acb1-7e477e71d654@github.com>
 <YaFUZSPViK04361zpcVNsrySNapOtcgxao-kSKDY9Hk=.da24f074-de18-4ad8-bd47-292c4e95995e@github.com>
Message-ID: <_FoRJC7mTsYIQuS9gdfvSPaLTsj8El_6lz-pL8CgB4g=.6d8c88bc-6f79-463e-9ec5-6a28f62268a2@github.com>

On Tue, 12 Dec 2023 15:29:46 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to change the specification for some methods that take `long` offsets so that they will throw an `IllegalArgumentException` rather than an `IndexOutOfBoundsException` for negative values.
>> 
>> The PR also proposes to fix a bug where the allocation size would overflow and the specified exception was not thrown.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct exception type in JavaDocs for SA:allocateFrom

Marked as reviewed by mcimadamore (Reviewer).

src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 397:

> 395:      * @throws IndexOutOfBoundsException if {@code sourceOffset > source.byteSize() - (elementCount * sourceElementLayout.byteSize())}
> 396:      * @throws IndexOutOfBoundsException if {@code sourceOffset < 0}
> 397:      * @throws IllegalArgumentException if {@code elementCount < 0}

Please move this closer to the other IAE

-------------

PR Review: https://git.openjdk.org/jdk/pull/17079#pullrequestreview-1777819153
PR Review Comment: https://git.openjdk.org/jdk/pull/17079#discussion_r1424195197

From ihse at openjdk.org  Tue Dec 12 15:43:36 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 12 Dec 2023 15:43:36 GMT
Subject: RFR: 8321688: Build on linux with GCC 7.5.0 fails after 8319577
In-Reply-To: <URTRfgkcxtEH80-ZT92CekMf0oVLnKOsABeI8h0LHPc=.90f9329e-2f6f-4c4b-8083-5a455dc81968@github.com>
References: <vIByQ06ftSU9o1Rb4YOWXPrry1LkYSj-vJqLXaMXQ5g=.d5a0ea33-f57a-4549-addf-b7a9c5eaa67d@github.com>
 <URTRfgkcxtEH80-ZT92CekMf0oVLnKOsABeI8h0LHPc=.90f9329e-2f6f-4c4b-8083-5a455dc81968@github.com>
Message-ID: <Fan7QOtiOBXpM17uB4fmxMqQzcHB0jWM-jVYOCfSqBw=.f1b737e4-4386-40b8-ac60-d669a3d774ef@github.com>

On Tue, 12 Dec 2023 02:31:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch fixes the building failure introduced by [JDK-8319577](https://bugs.openjdk.org/browse/JDK-8319577) in old GCC version (linux & GCC 7.5.0 locally).
>> 
>> Thanks for the review.
>> 
>>  Best Regards,
>> -- Guoxiong
>
> Please hold off on this change while I follow up on JDK-8319577.  This code
> requires C++17, which was turned on for a relevant small subset of the JDK by
> that change.  There was some discussion there about version limiting that
> change, but that doesn't seem to have been done, with this breakage being a
> consequence.

@kimbarrett There were a long discussion about the C++17 support. The end result, which led me to approve the build changes, was the claims made beginning with https://github.com/openjdk/jdk/pull/16534#discussion_r1414570644:

>  [...] the updated code which added guards to check for GCC version >= 7.5 in src/java.base/linux/native/libsimdsort/{avx2-linux-qsort.cpp, avx512-linux-qsort.cpp}. GCC >= 7.5 is needed to compile libsimdsort using C++17 features. Made sure that OpenJDK builds without errors using both GCC 7.5 and GCC 6.4.

> The GCC complier for versions 6 (and even 5) silently ignores the flag -std=c++17

Somehow the JDK compiled with 7.5 for the author of that patch, but fails for the author of this patch. I don't understand how this both can be true.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17047#issuecomment-1852290498

From pminborg at openjdk.org  Tue Dec 12 15:45:47 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 12 Dec 2023 15:45:47 GMT
Subject: RFR: 8321786: SegmentAllocator:allocateFrom(ValueLayout,
 MemorySegment, ValueLayout, long,
 long) spec mismatch in exception scenario [v7]
In-Reply-To: <-VY5wYQXjxv1dg1I0pqwcsONzuSQDcKVLIST-4HJUqw=.360b5491-8d6d-48fd-acb1-7e477e71d654@github.com>
References: <-VY5wYQXjxv1dg1I0pqwcsONzuSQDcKVLIST-4HJUqw=.360b5491-8d6d-48fd-acb1-7e477e71d654@github.com>
Message-ID: <fIgTI18rDEAOjj1I2lsKGD8-fLIvLxKijZVY-0alQos=.d776b77e-1415-4952-9de8-baf43960b5f5@github.com>

> This PR proposes to change the specification for some methods that take `long` offsets so that they will throw an `IllegalArgumentException` rather than an `IndexOutOfBoundsException` for negative values.
> 
> The PR also proposes to fix a bug where the allocation size would overflow and the specified exception was not thrown.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Move @throws tag

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17079/files
  - new: https://git.openjdk.org/jdk/pull/17079/files/c1407f77..115b6ea6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17079&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17079&range=05-06

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17079/head:pull/17079

PR: https://git.openjdk.org/jdk/pull/17079

From ihse at openjdk.org  Tue Dec 12 15:45:57 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 12 Dec 2023 15:45:57 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v12]
In-Reply-To: <M2KPFFgTiBmYcdxO7_wNRYYokECxNAHmgsvbt-s8_k0=.6320d2de-2710-4ca7-a6b4-d1954167ca01@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <e5w5YZ0WD8S3UVFBYz6I0PdKZ6yOkD77BCq2arDd6i4=.7eecadcb-e627-4e9b-8f1e-3fc41c63243b@github.com>
 <bopxvLCquUtZQxt8kAJskzXBR2YE_I0PW13i3NBJNNY=.e65abf3d-0ff4-4450-875b-ca3717170485@github.com>
 <DeQgR1PaXlk2yzlxV15N3ViZY26wXtlgfVKxRY6vuWo=.6d38f729-0ca9-4f43-9e23-f5e73a01cc23@github.com>
 <b1Nv5Y7Klpvp5ACcHJTTblwGmnA64cyRg-3YzotaHvc=.0bd8a0f0-0844-44a9-a3bb-4af2e8514ee1@github.com>
 <t_23EA--aX8v2US9Lsib1ZF3bl4HQx_Z4RXqlgQo8LE=.6f1f2873-015c-4b69-ad47-b449e5b77a45@github.com>
 <pRcJlU1a4jG9gMaftLn5IerudMSDIrvr70KBefkpNSo=.f442f0d4-887f-4376-a66e-8254fa35927c@github.com>
 <OJ1ZK4a8c_bZik60v503VUtZoweFFv6VhhGg1sp4qSY=.e8852bf1-2d7f-4164-b952-d88b294ec1f7@github.com>
 <_gSNXk0qGAtpY-WJ5OCHk_3-nuGrwwSn-ffK9f2TEcs=.40f785ba-83dd-40fe-8075-a7a7872ea600@github.com>
 <v95kXnbADF5XriLfeg2v5yVYBo-BUzR-dhpcubuMDcI=.03d8e5a7-8b0c-4291-99df-2d3ec6cd356c@github.com>
 <D2AGAYSictxU124OSQMg3V5bpM1oKBdxKLd
 BS0X7ow8=.326a6f38-e9ab-4b24-a6d6-d8eebdb346f7@github.com>
 <wpFxnb5dr5v2UHZYPPdi4XsBUiLtFXGxRySgr6xCmJM=.74175d6e-0f30-464e-9c76-cc4e8bd6f36a@github.com>
 <7_T6sM3wjbSzZ0ab9FsptbpPnlQ2J4NNctQNkdbDFdI=.b595a8cc-4b14-44c6-8319-00e68fea21c3@github.com>
 <M2KPFFgTiBmYcdxO7_wNRYYokECxNAHmgsvbt-s8_k0=.6320d2de-2710-4ca7-a6b4-d1954167ca01@github.com>
Message-ID: <miE0bEN_JyzIhfmBGCV7OkWags8LM9jM4oQYz1S5z20=.87be0fa6-3860-4bf8-8f57-3b8daaa1e996@github.com>

On Wed, 6 Dec 2023 17:20:10 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> Okay, then I guess I am fine with this.
>
> Thank you Magnus!

@vamsi-parasa You said:
> Made sure that OpenJDK builds without errors using both GCC 7.5 and GCC 6.4.

but now we have https://bugs.openjdk.org/browse/JDK-8321688. Did you introduce any changes after you tested with GCC 7.5? It seems strange to me that the code simultaneously both works and not works with gcc 7.5.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1424200521

From duke at openjdk.org  Tue Dec 12 17:36:55 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 12 Dec 2023 17:36:55 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v12]
In-Reply-To: <miE0bEN_JyzIhfmBGCV7OkWags8LM9jM4oQYz1S5z20=.87be0fa6-3860-4bf8-8f57-3b8daaa1e996@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <e5w5YZ0WD8S3UVFBYz6I0PdKZ6yOkD77BCq2arDd6i4=.7eecadcb-e627-4e9b-8f1e-3fc41c63243b@github.com>
 <bopxvLCquUtZQxt8kAJskzXBR2YE_I0PW13i3NBJNNY=.e65abf3d-0ff4-4450-875b-ca3717170485@github.com>
 <DeQgR1PaXlk2yzlxV15N3ViZY26wXtlgfVKxRY6vuWo=.6d38f729-0ca9-4f43-9e23-f5e73a01cc23@github.com>
 <b1Nv5Y7Klpvp5ACcHJTTblwGmnA64cyRg-3YzotaHvc=.0bd8a0f0-0844-44a9-a3bb-4af2e8514ee1@github.com>
 <t_23EA--aX8v2US9Lsib1ZF3bl4HQx_Z4RXqlgQo8LE=.6f1f2873-015c-4b69-ad47-b449e5b77a45@github.com>
 <pRcJlU1a4jG9gMaftLn5IerudMSDIrvr70KBefkpNSo=.f442f0d4-887f-4376-a66e-8254fa35927c@github.com>
 <OJ1ZK4a8c_bZik60v503VUtZoweFFv6VhhGg1sp4qSY=.e8852bf1-2d7f-4164-b952-d88b294ec1f7@github.com>
 <_gSNXk0qGAtpY-WJ5OCHk_3-nuGrwwSn-ffK9f2TEcs=.40f785ba-83dd-40fe-8075-a7a7872ea600@github.com>
 <v95kXnbADF5XriLfeg2v5yVYBo-BUzR-dhpcubuMDcI=.03d8e5a7-8b0c-4291-99df-2d3ec6cd356c@github.com>
 <D2AGAYSictxU124OSQMg3V5bpM1oKBdxKLd
 BS0X7ow8=.326a6f38-e9ab-4b24-a6d6-d8eebdb346f7@github.com>
 <wpFxnb5dr5v2UHZYPPdi4XsBUiLtFXGxRySgr6xCmJM=.74175d6e-0f30-464e-9c76-cc4e8bd6f36a@github.com>
 <7_T6sM3wjbSzZ0ab9FsptbpPnlQ2J4NNctQNkdbDFdI=.b595a8cc-4b14-44c6-8319-00e68fea21c3@github.com>
 <M2KPFFgTiBmYcdxO7_wNRYYokECxNAHmgsvbt-s8_k0=.6320d2de-2710-4ca7-a6b4-d1954167ca01@github.com>
 <miE0bEN_JyzIhfmBGCV7OkWags8LM9jM4oQYz1S5z20=.87be0fa6-3860-4bf8-8f57-3b8daaa1e996@github.com>
Message-ID: <pZiF9EcYqj3s4xZg8nGaZKslA3PgzQFJEpcSM54r6QA=.dc100d45-ed72-4a32-a9bc-22e21425b033@github.com>

On Tue, 12 Dec 2023 15:42:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Thank you Magnus!
>
> @vamsi-parasa You said:
>> Made sure that OpenJDK builds without errors using both GCC 7.5 and GCC 6.4.
> 
> but now we have https://bugs.openjdk.org/browse/JDK-8321688. Did you introduce any changes after you tested with GCC 7.5? It seems strange to me that the code simultaneously both works and not works with gcc 7.5.

Hi Magnus (@magicus), did a fresh pull of the OpenJDK and was able to build it successfully (without any errors) using GCC 7.5.0 on Ubuntu Linux machine. 
(I am on vacation till Jan7th, 2024. Our team will look into this issue)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1424352122

From rriggs at openjdk.org  Tue Dec 12 19:15:29 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 12 Dec 2023 19:15:29 GMT
Subject: RFR: 8321514: UTF16 string gets constructed incorrectly from
 codepoints if CompactStrings is not enabled [v2]
In-Reply-To: <P1bqGRS3bqxB3VBm-dDbGShSmRBnOEFz-nKfpvSbBFQ=.4e3a4629-a880-4b67-aab1-d77e0a09c4bf@github.com>
References: <1azLdWceEALX1v_hfgt03ncVu_wtZyk3_lZ0B0J_cto=.a59aff49-50a9-498e-bc78-fd5468d87cd6@github.com>
 <P1bqGRS3bqxB3VBm-dDbGShSmRBnOEFz-nKfpvSbBFQ=.4e3a4629-a880-4b67-aab1-d77e0a09c4bf@github.com>
Message-ID: <6at803p4T4BkisD3Ekw7ixsHAQFOdpJKIEpY9nHHov8=.1025f693-a562-46cf-bce7-b3a1ea00b240@github.com>

On Tue, 12 Dec 2023 10:47:48 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

>> Since JDK-8311906, if CompactStrings is not enabled, index is not considered when calling extractCodepoints from StringUTF16.toBytes(). Because of that the last elements of the source codepoints array are stripped from the resulting UTF16 string, which fires in other places (e.g. during RegEx processing).
>>  
>> The fix replaces len in extractCodepoints parameters with end that is index + len.
>
> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

test/jdk/java/lang/String/Chars.java line 50:

> 48:             testChars(cc, ccExp);
> 49:             testCharsSubrange(cc, ccExp);
> 50:             testIntsSubrange(ccExp);

Please also add the same call after line 74 to apply the test to the surrogates case.
(As suggested by @rgiulietti in https://github.com/openjdk/jdk/pull/17066)

test/jdk/java/lang/String/Chars.java line 126:

> 124:                 System.err.println("expected: " + Arrays.toString(expected));
> 125:                 System.err.println("actual: " + Arrays.toString(actual));
> 126:                 throw new RuntimeException("testCharsSubrange failed!");

"testCharsSubrange" -> "testIntsSubrange"  as commented in the dependent PR#17066.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17057#discussion_r1424466407
PR Review Comment: https://git.openjdk.org/jdk/pull/17057#discussion_r1424451093

From bchristi at openjdk.org  Tue Dec 12 19:15:42 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 12 Dec 2023 19:15:42 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v3]
In-Reply-To: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
Message-ID: <P4FpMYTcEapBOAUSxGogCmIxGE5fqVZgAADYkhC0Ah0=.045214d9-9ec7-4708-b198-0eb7d3169462@github.com>

> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing.
> 
> A couple key things we want to be able to say are:
> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'.
> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action.
> 
> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  Describe whole chain of hb relationships

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16644/files
  - new: https://git.openjdk.org/jdk/pull/16644/files/84d8b61f..05477522

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=01-02

  Stats: 14 lines in 1 file changed: 13 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16644.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16644/head:pull/16644

PR: https://git.openjdk.org/jdk/pull/16644

From jlu at openjdk.org  Tue Dec 12 19:28:43 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 12 Dec 2023 19:28:43 GMT
Subject: Integrated: 6230751: [Fmt-Ch] Recursive MessageFormats in
 ChoiceFormats ignore indicated subformats
In-Reply-To: <7wIjtUukVVmPac0CLynJTK8zIx7Difi9122zthoFj_w=.8e65ff5d-816b-4383-b833-0df272efaede@github.com>
References: <7wIjtUukVVmPac0CLynJTK8zIx7Difi9122zthoFj_w=.8e65ff5d-816b-4383-b833-0df272efaede@github.com>
Message-ID: <MP2pVld6Y9fV5ZBl3tUHbm6S9mC3I2OTHEsEtPwBdnA=.76794ea0-fee8-4ab1-9158-16af975fcbf5@github.com>

On Wed, 29 Nov 2023 22:41:26 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates an incorrect code example in _java/text/ChoiceFormat_.
> 
> ChoiceFormat (and MessageFormat) provide an example of how to produce a pattern that supports singular and plural forms. The ChoiceFormat example is incorrect, as recursive MessageFormats produced by a ChoiceFormat subformat only recognize subformats defined through the MessageFormat pattern syntax, not through the subformats contained within the top level MessageFormat. 
> 
> In the original example,
> `Format[] testFormats = {fileform, null, NumberFormat.getInstance()};` could have been replaced with 
> `Format[] testFormats = {fileform, null, new ChoiceFormat("0#BROKEN")};` and the original output would have been the same.
> 
> This PR replaces the example with the one used in MessageFormat, which is correct. 
> 
> This PR also includes a drive-by fix to remove leftover `<blockquote>`s from a previous `@snippet` conversion.

This pull request has now been integrated.

Changeset: aadf3680
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aadf36809c5daee8897601d33d8e6d6cedb57b9b
Stats:     63 lines in 2 files changed: 6 ins; 27 del; 30 mod

6230751: [Fmt-Ch] Recursive MessageFormats in ChoiceFormats ignore indicated subformats

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/16891

From naoto at openjdk.org  Tue Dec 12 19:40:33 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 12 Dec 2023 19:40:33 GMT
Subject: RFR: 8321480: ISO 4217 Amendment 176 Update [v3]
In-Reply-To: <_Mb_yvfsGFhcLdQ3REh5R5CNbXpZ15Gi50JyqRs2fyg=.c6289fab-f0bf-419b-9506-f27b8e16a37c@github.com>
References: <kLWpfbMrAiEskU8JqeFoGaEBzx1aTHI_vq5gxjjdoVw=.2b1af423-59c7-44e8-b4d4-deca303ec2a8@github.com>
 <_Mb_yvfsGFhcLdQ3REh5R5CNbXpZ15Gi50JyqRs2fyg=.c6289fab-f0bf-419b-9506-f27b8e16a37c@github.com>
Message-ID: <A-TC1FL-V99bsfQO5xTu6pFRTglv61pFFFBADa69Vxk=.5fe32026-a5fd-4f35-906f-113bd37a4170@github.com>

On Mon, 11 Dec 2023 22:15:42 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which incorporates the ISO 4217 Amendment 176 Update. As the replacement of `ANG` to `XCG` won't occur until 2025, this change does not need to go into JDK22. `HR` was also updated to remove the past cutover dates.
>> 
>> This update also demonstrated that `Currency::getAvailableCurrencies` may return a future currency that should not be returned. _GenerateCurrencyData.java_ was updated to ensure such currencies are not added to the other currency list.
>> 
>> Additionally, this change also converted a parameterized test to a normal JUnit test, due to output overflow.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove redundant conditionals

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17023#pullrequestreview-1778307137

From javalists at cbfiddle.com  Tue Dec 12 20:17:05 2023
From: javalists at cbfiddle.com (Alan Snyder)
Date: Tue, 12 Dec 2023 12:17:05 -0800
Subject: ZipEntry
Message-ID: <C4F64D96-2BE6-4436-BD44-600316D9E05B@cbfiddle.com>

ZipEntry is a public class and I am aware that it is used outside the JDK. Presumably that is not a problem.

I?m wondering why the class stores the external file attributes field but does not provide public accessors for it.

I would find it useful to have access to this field. I would rather not have to switch to using a third party library just for this reason.

I understand that the interpretation of the external file attributes is not standardized, but the field itself is defined in the standard
cited by the package info page, so I don?t see the harm in making it accessible without interpretation.

  Alan




From stsypanov at openjdk.org  Tue Dec 12 20:18:15 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 12 Dec 2023 20:18:15 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v12]
In-Reply-To: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
Message-ID: <etf_Tj0GsgwX88TgB9TN0twomrZnF87AQ0rwsDuh5qQ=.eecac5e8-b291-444a-9bbc-5feb545b0a2e@github.com>

> It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`.
> 
> See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  8320971: Whitespaces

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16879/files
  - new: https://git.openjdk.org/jdk/pull/16879/files/50e4e4e5..a3ba43fd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16879&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16879&range=10-11

  Stats: 58 lines in 1 file changed: 0 ins; 0 del; 58 mod
  Patch: https://git.openjdk.org/jdk/pull/16879.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16879/head:pull/16879

PR: https://git.openjdk.org/jdk/pull/16879

From stsypanov at openjdk.org  Tue Dec 12 20:48:36 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 12 Dec 2023 20:48:36 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v9]
In-Reply-To: <0ate3u4LIF3vjOJsRw5TLNQn4qIRNNNT_VUTGu1g6hI=.f41de4d9-c0ae-4179-941a-d7f55c184067@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <t_HBR4K_uT5fZ4Njc_2HDTNaISnakvNfJMwwe2h0aF0=.3998926d-88ae-4e4f-9494-c4a8f2dae233@github.com>
 <WyZs0JKvA7aIG-HYMC4Mx1b28PqMBat6k7nLD8MED28=.dfe48d68-4593-48c3-9938-1689321b35de@github.com>
 <0ate3u4LIF3vjOJsRw5TLNQn4qIRNNNT_VUTGu1g6hI=.f41de4d9-c0ae-4179-941a-d7f55c184067@github.com>
Message-ID: <_REhFy3CpmXQkNM7TyxWeTkYE6wYCEAG8su_FmqfpwU=.bcd81d61-e000-4cec-8aa5-bd481a44746b@github.com>

On Mon, 11 Dec 2023 19:53:40 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/IOStreams.java line 1:
>> 
>>> 1: /*
>> 
>> Please fix Whitespace errors. Thanks. :-)
>
> I've just copy-pasted the header from another class. How should I fix it?

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1424555556

From eirbjo at gmail.com  Tue Dec 12 20:57:09 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Tue, 12 Dec 2023 21:57:09 +0100
Subject: ZipEntry
In-Reply-To: <C4F64D96-2BE6-4436-BD44-600316D9E05B@cbfiddle.com>
References: <C4F64D96-2BE6-4436-BD44-600316D9E05B@cbfiddle.com>
Message-ID: <CA+pBWhta87ecMkvzu86CU6TMnW0ebe5eFkj4tnbpTjYTPj4P4g@mail.gmail.com>

Alan,

ZipOutputStream is a relatively high-level API for producing ZIP files.
There are many shapes and corner cases allowed by APPNOTE.TXT which
ZipOutputStream has no means to produce. So while exposing the "external
file attributes" field (which was incorrectly named "extraAttributes" in
ZipEntry) is perhaps not harmful in itself, the question is: Where do we
stop?

It's worth noting that the ZipFileSystem API has the
"enablePosixFileAttributes" env option which lets you set POSIX permissions
on ZIP file entries using Files.setPosixFilePermissions()

The following OpenJDK test can serve as an example:

https://github.com/openjdk/jdk/blob/master/test/jdk/sun/security/tools/jarsigner/PosixPermissionsTest.java#L151

Cheers,
Eirik,

On Tue, Dec 12, 2023 at 9:17?PM Alan Snyder <javalists at cbfiddle.com> wrote:

> ZipEntry is a public class and I am aware that it is used outside the JDK.
> Presumably that is not a problem.
>
> I?m wondering why the class stores the external file attributes field but
> does not provide public accessors for it.
>
> I would find it useful to have access to this field. I would rather not
> have to switch to using a third party library just for this reason.
>
> I understand that the interpretation of the external file attributes is
> not standardized, but the field itself is defined in the standard
> cited by the package info page, so I don?t see the harm in making it
> accessible without interpretation.
>
>   Alan
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20231212/1dca24ef/attachment.htm>

From rriggs at openjdk.org  Tue Dec 12 20:58:31 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 12 Dec 2023 20:58:31 GMT
Subject: Integrated: 8321180: Condition for non-latin1 string size too large
 exception is off by one
In-Reply-To: <a7-9Y_75hNj9RjvAAY12LLfQFwdQ0c-YOV2LfwHgVrQ=.0463c47f-c925-4800-bef7-50cbb715405d@github.com>
References: <a7-9Y_75hNj9RjvAAY12LLfQFwdQ0c-YOV2LfwHgVrQ=.0463c47f-c925-4800-bef7-50cbb715405d@github.com>
Message-ID: <RUxCh89IsZJEML8H0GO6CdTeX1zwZP-XF0OkRT05sCc=.f25274f3-43d1-486e-9863-6222c7a54a1a@github.com>

On Wed, 6 Dec 2023 23:31:26 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> In the compact string implementation of non-latin1 (UTF16) strings the length is constrained by VM implementation limit on the size a byte array that can be allocated. To produce a useful exception the implementation checks the string size against the maximum byte array size. The exception message is correct
> 
> "UTF16 String size is " + len + ", should be less than or equal to " + MAX_LENGTH
> 
> The code should match the message, otherwise the exception thrown is: 
> 
> java.lang.OutOfMemoryError: Requested array size exceeds VM limit

This pull request has now been integrated.

Changeset: 4fb5c128
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4fb5c12813c6d447709d3fef690387ddab0e8dae
Stats:     118 lines in 2 files changed: 109 ins; 7 del; 2 mod

8321180: Condition for non-latin1 string size too large exception is off by one

Reviewed-by: rgiulietti

-------------

PR: https://git.openjdk.org/jdk/pull/17008

From rriggs at openjdk.org  Tue Dec 12 21:06:31 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 12 Dec 2023 21:06:31 GMT
Subject: RFR: 8321514: UTF16 string gets constructed incorrectly from
 codepoints if CompactStrings is not enabled [v2]
In-Reply-To: <FLY0cYlCliYHcnGviTSzrXR2gGhRQ-ao4mMRrbxAkGQ=.539d5b50-97c1-4dd1-b27f-a77e0a9203a4@github.com>
References: <1azLdWceEALX1v_hfgt03ncVu_wtZyk3_lZ0B0J_cto=.a59aff49-50a9-498e-bc78-fd5468d87cd6@github.com>
 <P1bqGRS3bqxB3VBm-dDbGShSmRBnOEFz-nKfpvSbBFQ=.4e3a4629-a880-4b67-aab1-d77e0a09c4bf@github.com>
 <FLY0cYlCliYHcnGviTSzrXR2gGhRQ-ao4mMRrbxAkGQ=.539d5b50-97c1-4dd1-b27f-a77e0a9203a4@github.com>
Message-ID: <c1xu-4cqh9tBoGPYtLBmSmCAqqgO3ax-5pc0nhtG4dU=.4f7a680d-8b95-4749-b74b-1a7b24602574@github.com>

On Tue, 12 Dec 2023 10:57:20 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

>> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments
>
> Thanks Roger. I agree with your point and pulled your suggested test in the PR.

@voitylov Are you aware of -XX:-CompactStrings being used in production or was this discovered as part of release testing?
Thanks

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17057#issuecomment-1852807622

From javalists at cbfiddle.com  Tue Dec 12 21:15:35 2023
From: javalists at cbfiddle.com (Alan Snyder)
Date: Tue, 12 Dec 2023 13:15:35 -0800
Subject: ZipEntry
In-Reply-To: <CA+pBWhta87ecMkvzu86CU6TMnW0ebe5eFkj4tnbpTjYTPj4P4g@mail.gmail.com>
References: <C4F64D96-2BE6-4436-BD44-600316D9E05B@cbfiddle.com>
 <CA+pBWhta87ecMkvzu86CU6TMnW0ebe5eFkj4tnbpTjYTPj4P4g@mail.gmail.com>
Message-ID: <DBBA5790-31F3-4175-9AA0-943299ECDB15@cbfiddle.com>



> On Dec 12, 2023, at 12:57?PM, Eirik Bj?rsn?s <eirbjo at gmail.com> wrote:
> 
> Alan,
> 
> ZipOutputStream is a relatively high-level API for producing ZIP files. There are many shapes and corner cases allowed by APPNOTE.TXT which ZipOutputStream has no means to produce. So while exposing the "external file attributes" field (which was incorrectly named "extraAttributes" in ZipEntry) is perhaps not harmful in itself, the question is: Where do we stop?
> 

Right now, I?m more interested in reading zip files, but to answer your question: we can stop at any point.


> It's worth noting that the ZipFileSystem API has the "enablePosixFileAttributes" env option which lets you set POSIX permissions on ZIP file entries using Files.setPosixFilePermissions()
> 

I?m more interested in the symlink bit, and do not currently have any need to use ZipFileSystem.

I?m wondering, though, why it is OK to access information via ZipFileSystem and not directly via ZipEntry?



> The following OpenJDK test can serve as an example:
> 
> https://github.com/openjdk/jdk/blob/master/test/jdk/sun/security/tools/jarsigner/PosixPermissionsTest.java#L151
> 
> Cheers,
> Eirik,
> 
> On Tue, Dec 12, 2023 at 9:17?PM Alan Snyder <javalists at cbfiddle.com <mailto:javalists at cbfiddle.com>> wrote:
>> ZipEntry is a public class and I am aware that it is used outside the JDK. Presumably that is not a problem.
>> 
>> I?m wondering why the class stores the external file attributes field but does not provide public accessors for it.
>> 
>> I would find it useful to have access to this field. I would rather not have to switch to using a third party library just for this reason.
>> 
>> I understand that the interpretation of the external file attributes is not standardized, but the field itself is defined in the standard
>> cited by the package info page, so I don?t see the harm in making it accessible without interpretation.
>> 
>>   Alan
>> 
>> 
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20231212/bd64b9ef/attachment.htm>

From lance.andersen at oracle.com  Tue Dec 12 21:52:54 2023
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 12 Dec 2023 21:52:54 +0000
Subject: ZipEntry
In-Reply-To: <DBBA5790-31F3-4175-9AA0-943299ECDB15@cbfiddle.com>
References: <C4F64D96-2BE6-4436-BD44-600316D9E05B@cbfiddle.com>
 <CA+pBWhta87ecMkvzu86CU6TMnW0ebe5eFkj4tnbpTjYTPj4P4g@mail.gmail.com>
 <DBBA5790-31F3-4175-9AA0-943299ECDB15@cbfiddle.com>
Message-ID: <A77EAAC0-CC7C-4827-B9DF-121B49ACE094@oracle.com>

Please refer to JDK-8250968<https://bugs.openjdk.org/browse/JDK-8250968> which why the field in question was added.  If you are interested in additional support,  you can open an enhancement request for consideration.

Best
Lance

On Dec 12, 2023, at 4:15 PM, Alan Snyder <javalists at cbfiddle.com<mailto:javalists at cbfiddle.com>> wrote:



On Dec 12, 2023, at 12:57?PM, Eirik Bj?rsn?s <eirbjo at gmail.com<mailto:eirbjo at gmail.com>> wrote:

Alan,

ZipOutputStream is a relatively high-level API for producing ZIP files. There are many shapes and corner cases allowed by APPNOTE.TXT which ZipOutputStream has no means to produce. So while exposing the "external file attributes" field (which was incorrectly named "extraAttributes" in ZipEntry) is perhaps not harmful in itself, the question is: Where do we stop?


Right now, I?m more interested in reading zip files, but to answer your question: we can stop at any point.


It's worth noting that the ZipFileSystem API has the "enablePosixFileAttributes" env option which lets you set POSIX permissions on ZIP file entries using Files.setPosixFilePermissions()


I?m more interested in the symlink bit, and do not currently have any need to use ZipFileSystem.

I?m wondering, though, why it is OK to access information via ZipFileSystem and not directly via ZipEntry?



The following OpenJDK test can serve as an example:

https://github.com/openjdk/jdk/blob/master/test/jdk/sun/security/tools/jarsigner/PosixPermissionsTest.java#L151

Cheers,
Eirik,

On Tue, Dec 12, 2023 at 9:17?PM Alan Snyder <javalists at cbfiddle.com<mailto:javalists at cbfiddle.com>> wrote:
ZipEntry is a public class and I am aware that it is used outside the JDK. Presumably that is not a problem.

I?m wondering why the class stores the external file attributes field but does not provide public accessors for it.

I would find it useful to have access to this field. I would rather not have to switch to using a third party library just for this reason.

I understand that the interpretation of the external file attributes is not standardized, but the field itself is defined in the standard
cited by the package info page, so I don?t see the harm in making it accessible without interpretation.

  Alan

[cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home]






Lance Andersen | Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com<mailto:Lance.Andersen at oracle.com>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20231212/6cb849a0/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: oracle_sig_logo.gif
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20231212/6cb849a0/oracle_sig_logo-0001.gif>

From darcy at openjdk.org  Tue Dec 12 22:24:32 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 12 Dec 2023 22:24:32 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 [v7]
In-Reply-To: <UHA4xz5Ute6D_dTNMO4Ki4Jw7I3U7i6D5idwqPiuQ_w=.d44fe606-37f4-4451-9674-a0b1fa823647@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
 <UHA4xz5Ute6D_dTNMO4Ki4Jw7I3U7i6D5idwqPiuQ_w=.d44fe606-37f4-4451-9674-a0b1fa823647@github.com>
Message-ID: <8kc1FcJ-ilYErhHEJRu9S_64FWwg8lI5kZfTPDEeHYA=.7b75a759-2927-4434-8ec6-24f127f01a7e@github.com>

On Tue, 12 Dec 2023 04:26:25 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing comment

As the core reflection code will encounter record classes compiled before and after the javac code generation change, if the old behavior can be triggered in javac using `--release $OLD`/`--source $OLD`, that would be helpful to include as part of the testing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17070#issuecomment-1852905546

From darcy at openjdk.org  Tue Dec 12 22:33:33 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 12 Dec 2023 22:33:33 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 [v7]
In-Reply-To: <UHA4xz5Ute6D_dTNMO4Ki4Jw7I3U7i6D5idwqPiuQ_w=.d44fe606-37f4-4451-9674-a0b1fa823647@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
 <UHA4xz5Ute6D_dTNMO4Ki4Jw7I3U7i6D5idwqPiuQ_w=.d44fe606-37f4-4451-9674-a0b1fa823647@github.com>
Message-ID: <kJ6EV-dGzvi2cOpp5UDiHN4tBiwlRQqj2rNkoZKFvZk=.5e732237-3aff-494d-bb0a-6a00720a9106@github.com>

On Tue, 12 Dec 2023 04:26:25 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing comment

src/java.base/share/classes/java/lang/reflect/Executable.java line 289:

> 287:      * artifact</a>, the number of returned parameters can differ
> 288:      * depending on whether or not generic information is present. If
> 289:      * generic information is present, only parameters implicitly or

It may be helpful to link to javax.lang.model.util.Elements.Origin.MANDATED and  javax.lang.model.util.Elements.Origin.SYNTHETIC to give the reader some more context here. If you do that, you may need to add some SuppressWarnings to make the compile-time doclint checking work due to the cross-module linkage.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17070#discussion_r1424643273

From darcy at openjdk.org  Tue Dec 12 22:33:34 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 12 Dec 2023 22:33:34 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 [v7]
In-Reply-To: <kJ6EV-dGzvi2cOpp5UDiHN4tBiwlRQqj2rNkoZKFvZk=.5e732237-3aff-494d-bb0a-6a00720a9106@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
 <UHA4xz5Ute6D_dTNMO4Ki4Jw7I3U7i6D5idwqPiuQ_w=.d44fe606-37f4-4451-9674-a0b1fa823647@github.com>
 <kJ6EV-dGzvi2cOpp5UDiHN4tBiwlRQqj2rNkoZKFvZk=.5e732237-3aff-494d-bb0a-6a00720a9106@github.com>
Message-ID: <Vxst7oxKVZh9S0NRh-f0hYdze8u9zRyk3w99QRo582o=.78296455-b2d8-4032-a599-41fb0ec3b9e6@github.com>

On Tue, 12 Dec 2023 22:30:02 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> It may be helpful to link to javax.lang.model.util.Elements.Origin.MANDATED and javax.lang.model.util.Elements.Origin.SYNTHETIC to give the reader some more context here. If you do that, you may need to add some SuppressWarnings to make the compile-time doclint checking work due to the cross-module linkage.

PS Under a separate bug, we could add "compact constructor parameters" to the list of mandated constructs in Origin.MANDATED.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17070#discussion_r1424643922

From lmesnik at openjdk.org  Tue Dec 12 22:55:22 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 12 Dec 2023 22:55:22 GMT
Subject: RFR: 8321713: Harmonize executeTestJvm with
 create[Limited]TestJavaProcessBuilder [v3]
In-Reply-To: <rOdHN6_YCb1J7nbJbJ3uAZ0_octri-wWhlPPrC04HYQ=.a13d7a73-71f2-403b-8efa-6aa614a0c11e@github.com>
References: <fIIn7OfSFIv_Or1dUx5NasB9s0qgov89khLMR73wFQs=.b026b011-764d-48cc-a728-baf350e1a30a@github.com>
 <rOdHN6_YCb1J7nbJbJ3uAZ0_octri-wWhlPPrC04HYQ=.a13d7a73-71f2-403b-8efa-6aa614a0c11e@github.com>
Message-ID: <EHXy4M1_vmtXK10EOzazRoLWXos1B3EGy4bsYch8G7U=.edd664cb-ed1b-43a1-9d53-8a492c669b52@github.com>

On Mon, 11 Dec 2023 14:06:43 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> [JDK-8315097](https://bugs.openjdk.org/browse/JDK-8315097): 'Rename createJavaProcessBuilder' changed the name of the ProcessTools helper functions used to create `ProcessBuilder`s used to spawn new java test processes.
>> 
>> We now have `createTestJavaProcessBuilder` and `createLimitedTestJavaProcess`. The former prepends jvm options from jtreg, while the latter doesn't.
>> 
>> With these functions it is common to see the following pattern in tests:
>> 
>> ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...);
>> OutputAnalyzer output = executeProcess(pb);
>> 
>> 
>> We have a couple of thin wrapper in `ProcessTools` that does exactly this, so that the code can be written as a one-liner:
>> 
>> OutputAnalyzer output = ProcessTools.executeTestJvm();
>> 
>> 
>> I propose that we name this functions using the same naming scheme we used for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`. That is, we change `executeTestJvm` to `executeTestJava` and add a new `executeLimitedTestJava` function.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test cleanup

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17049#pullrequestreview-1778566038

From dholmes at openjdk.org  Tue Dec 12 23:21:49 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 12 Dec 2023 23:21:49 GMT
Subject: RFR: 8321206: Make Locale related system properties
 `StaticProperty` [v2]
In-Reply-To: <CcKGxJp4T09SzhWQ3TBXPqH5TBPb9GbD6QRO0opn8Pg=.3054f472-f801-4846-bbfb-5f29cc8e8512@github.com>
References: <EKzdSEIjrFq0mXKLGOdRCePeu29DWWQnpAY5FDVAK40=.3bcd4037-e3e5-4cf1-948d-665355914106@github.com>
 <CcKGxJp4T09SzhWQ3TBXPqH5TBPb9GbD6QRO0opn8Pg=.3054f472-f801-4846-bbfb-5f29cc8e8512@github.com>
Message-ID: <XZHWjTJ7ZJnw9DUIW7xbyzTUrcJsi2zCr6T2aUIPsxY=.093e3fcc-4bab-4f5e-95b3-2de45c844e4a@github.com>

On Wed, 6 Dec 2023 20:55:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Currently, Locale-related system properties, such as `user.language` or `user.country`, are initialized when the `Locale` class is loaded. Making them static properties is safer than relying on the `Locale` class loading timing, which could potentially be changed depending on the implementation.
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Reflects review comments
>  - Merge branch 'master' into JDK-8321206-Locale-static-properties
>  - Add exclusions in cdsHeapVerifier for new StaticProperties
>  - initial commit

@iklam or @calvinccheung  could either of you take a look at the CDS changes here please. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16986#issuecomment-1852949624

From bchristi at openjdk.org  Tue Dec 12 23:36:30 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 12 Dec 2023 23:36:30 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v4]
In-Reply-To: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
Message-ID: <JvpXTdUylo-lBIa57VvYzHGWB7TKUFfg-J5xsKb6tVc=.7d9aef07-3a4d-44b0-a79e-27201f5d8b1e@github.com>

> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing.
> 
> A couple key things we want to be able to say are:
> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'.
> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action.
> 
> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  Add links to new Memory Consistency section in package doc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16644/files
  - new: https://git.openjdk.org/jdk/pull/16644/files/05477522..c09db360

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=02-03

  Stats: 10 lines in 3 files changed: 2 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/16644.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16644/head:pull/16644

PR: https://git.openjdk.org/jdk/pull/16644

From bchristi at openjdk.org  Tue Dec 12 23:36:31 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 12 Dec 2023 23:36:31 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v4]
In-Reply-To: <uSL1mFzmt9GfK56i5WpFtSJWgGJeXeFcm6Z-f_kHuOc=.98ca0e53-fd63-415d-a079-001932b582f2@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <CdQYa3Tc8iq8VyFtdloSXvT1SVIYMqjOYmnNK22KT7I=.5a3063c6-9341-44e7-a051-156c5c67f479@github.com>
 <UNyY7EdguPAlR3_bfP_NY8PBBD0FXiriyIDNRaThH80=.1b0d3af0-e04c-47ca-944b-2b788ba47ae1@github.com>
 <uSL1mFzmt9GfK56i5WpFtSJWgGJeXeFcm6Z-f_kHuOc=.98ca0e53-fd63-415d-a079-001932b582f2@github.com>
Message-ID: <-Pl4l_S1IUaiq0X6aMjzIyYbo3bduZsiMAfNfdq7AWc=.c6520dfa-0ad9-4de3-ab89-21ceefc48a82@github.com>

On Wed, 6 Dec 2023 01:24:51 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Perhaps in each of these places add a link to #Memory Consistency Properties
>
> I can flesh out the new Memory Consistency Properties section in the package info to cover the whole chain. Adding links to it sounds like a good idea.

I've converted "Memory consistency effects:" to be a link to the new/updated section in the package doc. Maybe that's fine, or maybe we want to do a little more to direct the user to that section.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1424682474

From lmesnik at openjdk.org  Wed Dec 13 00:04:44 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 13 Dec 2023 00:04:44 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v3]
In-Reply-To: <-3HkgdDQk9480AnHQeIxaNsqK0nVzjaf6UZJ5E9LGHo=.bdff2ed6-db98-4a77-832f-6accad54245f@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
 <-3HkgdDQk9480AnHQeIxaNsqK0nVzjaf6UZJ5E9LGHo=.bdff2ed6-db98-4a77-832f-6accad54245f@github.com>
Message-ID: <FzoKcM3_vYTnfZoA9mK5vkMl4wm4rXSzi73x6-aH4eI=.66ecbb2d-4da1-4153-a1a1-c20b88e24d19@github.com>

On Fri, 8 Dec 2023 11:54:40 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fix is for JDK 23 but the intention is to back port it to 22 in RDP-1 time frame.
>> It is fixing a deadlock issue between `VirtualThread` class critical sections with the `interruptLock` (in methods: `unpark()`, `interrupt()`, `getAndClearInterrupt()`, `threadState()`, `toString()`), `JvmtiVTMSTransitionDisabler` and JVMTI `Suspend/Resume` mechanisms.
>> The deadlocking scenario is well described by Patricio in a bug report comment.
>> In simple words, a virtual thread should not be suspended during 'interruptLock' critical sections.
>> 
>> The fix is to record that a virtual thread is in a critical section (`JavaThread`'s `_in_critical_section` bit) by notifying the VM/JVMTI about begin/end of critical section.
>> This bit is used in `HandshakeState::get_op_for_self()` to filter out any `HandshakeOperation` if a target `JavaThread` is in a critical section.
>> 
>> Some of new notifications with `notifyJvmtiSync()` method is on a performance critical path. It is why this method has been intrincified.
>> 
>> New test was developed by Patricio:
>>  `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
>> The test is very nice as it reliably in 100% reproduces the deadlock without the fix.
>> The test is never failing with this fix.
>> 
>> Testing:
>>  - tested with newly added test: `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: (1) rename notifyJvmti method; (2) add try-final statements to VirtualThread methods

Changes requested by lmesnik (Reviewer).

src/hotspot/share/prims/jvm.cpp line 4013:

> 4011: // Notification from VirtualThread about entering/exiting sync critical section.
> 4012: // Needed to avoid deadlocks with JVMTI suspend mechanism.
> 4013: JVM_ENTRY(void, JVM_VirtualThreadCriticalLock(JNIEnv* env, jobject vthread, jboolean enter))

the jobject vthread is not used. Can't be the method made static to reduce the number of arguments? 
It is the performance-critical code,  I don't know if it is optimized by C2.

src/hotspot/share/runtime/javaThread.hpp line 320:

> 318:   bool                  _is_in_VTMS_transition;          // thread is in virtual thread mount state transition
> 319:   bool                  _is_in_tmp_VTMS_transition;      // thread is in temporary virtual thread mount state transition
> 320:   bool                  _is_in_critical_section;         // thread is in a locking critical section

might make sense to add a comment, that his variable Is changed/read only by current thread and no sync is needed.

src/java.base/share/classes/java/lang/VirtualThread.java line 1164:

> 1162: 
> 1163:     @IntrinsicCandidate
> 1164:     private native void notifyJvmtiCriticalLock(boolean enter);

The name is confusing to me, the CriticalLock looks like it is the section is critical and might be taken by a single thread only. Or it's just unclear what is critical here. 
However, the purpose is to disable suspend
Wouldn't be 'notifyJvmtiSuspendLock notifyJvmtiDisableSuspend' better name here? 
or comment what critical means here.

test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock/SuspendWithInterruptLock.java line 30:

> 28:  * @requires vm.continuations
> 29:  * @library /testlibrary
> 30:  * @run main/othervm -Xint SuspendWithInterruptLock

Doesn't it make sense to add a testcase without -Xint also? Just to give stress testing with compilation.

test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock/SuspendWithInterruptLock.java line 36:

> 34: 
> 35: public class SuspendWithInterruptLock {
> 36:     static boolean done;

done is accessed from different threads, should be volatile.

test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock/SuspendWithInterruptLock.java line 54:

> 52:             Thread.yield();
> 53:         }
> 54:         done = true;

I think it is better to use done to stop all threads and set it to true in the main thread after some time. So you could be sure that the yielder hadn't been completed before the suspender started. But it is just proposal.

-------------

PR Review: https://git.openjdk.org/jdk/pull/17011#pullrequestreview-1778571090
PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1424694672
PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1424697179
PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1424687810
PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1424662055
PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1424663078
PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1424683585

From iklam at openjdk.org  Wed Dec 13 00:59:49 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 13 Dec 2023 00:59:49 GMT
Subject: RFR: 8321206: Make Locale related system properties
 `StaticProperty` [v2]
In-Reply-To: <CcKGxJp4T09SzhWQ3TBXPqH5TBPb9GbD6QRO0opn8Pg=.3054f472-f801-4846-bbfb-5f29cc8e8512@github.com>
References: <EKzdSEIjrFq0mXKLGOdRCePeu29DWWQnpAY5FDVAK40=.3bcd4037-e3e5-4cf1-948d-665355914106@github.com>
 <CcKGxJp4T09SzhWQ3TBXPqH5TBPb9GbD6QRO0opn8Pg=.3054f472-f801-4846-bbfb-5f29cc8e8512@github.com>
Message-ID: <1h0n1MESjTfKSe79VDe4JH9TjZKuMfxy2CWqoLmu_gk=.6687965e-7bea-49c9-b3b4-c557cc243450@github.com>

On Wed, 6 Dec 2023 20:55:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Currently, Locale-related system properties, such as `user.language` or `user.country`, are initialized when the `Locale` class is loaded. Making them static properties is safer than relying on the `Locale` class loading timing, which could potentially be changed depending on the implementation.
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Reflects review comments
>  - Merge branch 'master' into JDK-8321206-Locale-static-properties
>  - Add exclusions in cdsHeapVerifier for new StaticProperties
>  - initial commit

> @iklam or @calvinccheung could either of you take a look at the CDS changes here please. Thanks.

> I'm not following the changes to cdsHeapVerifier.cpp. You've marked the new entries as C but the definition is:
> ```
> // [C] A non-final static string that is assigned a string literal during class
> // initialization; this string is never changed during -Xshare:dump.
>```
> and these are final static strings not non-final. ???

Hi David, you're correct that the new entries are not of type "C", as the new strings are `static final`. Anyway, the whole reason of this table is to work around the weakness of cdsHeapVerifier, which can sometimes report false positives. The new entries follow the same pattern of the previous entries (which are also wrong ... i.e., `StaticProperty::FILE_ENCODING`)

I have file https://bugs.openjdk.org/browse/JDK-8321940 to improve cdsHeapVerifier. Hopefully I can remove all the entries in cdsHeapVerifier.cpp added by this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16986#issuecomment-1853097367

From gli at openjdk.org  Wed Dec 13 01:53:44 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 13 Dec 2023 01:53:44 GMT
Subject: RFR: 8321688: Build on linux with GCC 7.5.0 fails after 8319577
In-Reply-To: <Fan7QOtiOBXpM17uB4fmxMqQzcHB0jWM-jVYOCfSqBw=.f1b737e4-4386-40b8-ac60-d669a3d774ef@github.com>
References: <vIByQ06ftSU9o1Rb4YOWXPrry1LkYSj-vJqLXaMXQ5g=.d5a0ea33-f57a-4549-addf-b7a9c5eaa67d@github.com>
 <URTRfgkcxtEH80-ZT92CekMf0oVLnKOsABeI8h0LHPc=.90f9329e-2f6f-4c4b-8083-5a455dc81968@github.com>
 <Fan7QOtiOBXpM17uB4fmxMqQzcHB0jWM-jVYOCfSqBw=.f1b737e4-4386-40b8-ac60-d669a3d774ef@github.com>
Message-ID: <2Vuqdjm6Qg3VOE6w8GMav5jkQEvgoufDm104D46zjxM=.223fee9d-24c9-4bf0-b4e0-6c4598629a3a@github.com>

On Tue, 12 Dec 2023 15:40:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Somehow the JDK compiled with 7.5 for the author of that patch, but fails for the author of this patch. I don't understand how this both can be true.

I noticed my previous build is `slowdebug`. Today, I tested the `release` and `fastdebug` locally. These builds succeeded. 
So only the `slowdebug` build fails. What's the difference between `fastdebug` and `slowdebug`?
It seems that `slow-debug` disables some optimizations, such as constant propagation, which may cause this issue.
Should we adjust the concrete code (like this PR) or revise the build system to avoid the potential problem in the future?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17047#issuecomment-1853142192

From smarks at openjdk.org  Wed Dec 13 05:21:43 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 13 Dec 2023 05:21:43 GMT
Subject: RFR: 8320919: Clarify Locale related system properties [v3]
In-Reply-To: <jscui0aN2Uv1aaFWxSp01sut1zKf7OLiS7EcboXEUYU=.790a7407-f595-415d-9dc9-561801a6e7db@github.com>
References: <IruGxIK9DXnXFDANt1y4sCMJEGZh1PTOKhOWZZxJEdc=.77092e02-fb4f-4c9e-8d53-0fa0cf3bae7d@github.com>
 <T6amp0e6d8fH2bV2UYXHkXphSgU567xIt1dZWFZq26I=.d1e2cc6b-3094-4100-91d9-b105ac8351ee@github.com>
 <jscui0aN2Uv1aaFWxSp01sut1zKf7OLiS7EcboXEUYU=.790a7407-f595-415d-9dc9-561801a6e7db@github.com>
Message-ID: <EHYMQZ9G-ruEcpO5ugSBZafCvsXCpMktJxrBlCrEFU0=.57ed1953-73d6-44c9-9776-2a3e6db4127b@github.com>

On Mon, 11 Dec 2023 23:17:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/Locale.java line 301:
>> 
>>> 299:  * is unparsable, it is ignored. The overriding values of other properties are not
>>> 300:  * checked for syntax or validity and are used directly in the default Locale.
>>> 301:  * (Typically, system property values can be provided using the {@code -D} command-line
>> 
>> Do these last two sentences need to be enclosed in a parentheses? It seems pretty important as it is the main way to override the properties via command-line.
>
> The `-D` command-line option is not a part of the Java SE specification but an allowed behavior, so it may not be a normative description here.

Right, I suggested putting that in parentheses. Historically we haven't been very formal about distinguishing between normative (Java SE) specifications and informative text that talks about implementations. In this case I felt that enclosing the text in parentheses and also adding hedging words ("typically") made it clear that this text isn't normative.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17065#discussion_r1424859379

From smarks at openjdk.org  Wed Dec 13 05:36:43 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 13 Dec 2023 05:36:43 GMT
Subject: RFR: 8320919: Clarify Locale related system properties [v3]
In-Reply-To: <wty1T1zBJzvCBz9c2z1nPeD7316D_p9kU4CbQCeuUZs=.156e712d-b269-4bdf-b87d-f07a7057e2a2@github.com>
References: <IruGxIK9DXnXFDANt1y4sCMJEGZh1PTOKhOWZZxJEdc=.77092e02-fb4f-4c9e-8d53-0fa0cf3bae7d@github.com>
 <wty1T1zBJzvCBz9c2z1nPeD7316D_p9kU4CbQCeuUZs=.156e712d-b269-4bdf-b87d-f07a7057e2a2@github.com>
Message-ID: <rXKb0O3admDlGqXSFpsxRwV2gOMeueCKLBnq30VOsqY=.ffa1b4a5-53cb-48a6-9bc4-9be1a3696b20@github.com>

On Mon, 11 Dec 2023 23:20:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a doc change to clarify what the `Default Locale` is, and how it is established during the system startup using the system properties. Those locale-related system properties have existed since the early days of Java, but have never been publicly documented before. It is also the intention of this PR to clarify those system properties and how they are overridden. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Looks good, with a couple small wording changes.

src/java.base/share/classes/java/util/Locale.java line 318:

> 316:  * If the default Locale is changed with {@link #setDefault(Locale)}, the corresponding
> 317:  * system properties are not altered. It is not recommended that applications read
> 318:  * these system properties and parse/interpret them as their values may be out of sync.

Small wordsmithing: I would say "out of date" instead.

src/java.base/share/classes/java/util/Locale.java line 324:

> 322:  * and set by {@link #setDefault(Category, Locale)}. Construction of these category
> 323:  * specific default Locales are determined by the corresponding system properties,
> 324:  * which consist of the base system properties as listed above, appended by either

"appended" => "suffixed"

-------------

Marked as reviewed by smarks (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17065#pullrequestreview-1778870505
PR Review Comment: https://git.openjdk.org/jdk/pull/17065#discussion_r1424865972
PR Review Comment: https://git.openjdk.org/jdk/pull/17065#discussion_r1424866579

From dholmes at openjdk.org  Wed Dec 13 07:11:39 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 13 Dec 2023 07:11:39 GMT
Subject: RFR: 8321400: java/foreign/TestStubAllocFailure.java fails with
 code cache exhaustion
In-Reply-To: <GzvkhIYT0Bz6jHuS5o-q_DvNTRCKfj5hqDRHPvN2MxY=.8ce04894-a4e6-4339-9dfb-26a1933d3e59@github.com>
References: <GzvkhIYT0Bz6jHuS5o-q_DvNTRCKfj5hqDRHPvN2MxY=.8ce04894-a4e6-4339-9dfb-26a1933d3e59@github.com>
Message-ID: <Qu9R1yyh7SkP0VwxYDVFjFCRRY-xE-lRlyFNMG750d8=.915f6560-81fe-4efe-b98b-06054b31c591@github.com>

On Mon, 11 Dec 2023 13:01:25 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Improve the test by being more lenient to related code cache exhaustion errors. The important thing is that we don't terminate with a fatal error, which the new code now checks for explicitly. The check for that is based on what is done by `./test/hotspot/jtreg/runtime/ErrorHandling/HsErrFileUtils.java` .
> 
> The existing `UpcallTestHelper.Output` class that was previously used to assert on stdout/stderr contents did not have the capability to look for patterns in the output. So, I've taken the opportunity to replace it with the more canonical `OutputAnalyzer` which comes from the test library.
> 
> Finally, I've also added back the test for downcall stub allocation failure which was removed as part of the initial patch because it was too inconsistent [1]. With the new approach, it should pass reliably as well.
> 
> Testing: `jdk_foreign`  suite (which contains all the affected tests)
> 
> [1]: https://github.com/openjdk/jdk/pull/16311/commits/9a1360598a91871ce6ec48330849c0e4e0279c64

test/jdk/java/foreign/TestStubAllocFailure.java line 51:

> 49:         runInNewProcess(UpcallRunner.class, true, List.of("-XX:ReservedCodeCacheSize=3M"), List.of())
> 50:                 .shouldNotHaveExitValue(0)
> 51:                 .shouldNotHaveFatalError();

Just curious what non-zero exit value is actually expected here and below?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17056#discussion_r1424930505

From duke at openjdk.org  Wed Dec 13 07:57:48 2023
From: duke at openjdk.org (Markus KARG)
Date: Wed, 13 Dec 2023 07:57:48 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v9]
In-Reply-To: <xf8uLxck-PHXDF1_hCv-ia7uGE5Ns8Srlu8T4q-QYG8=.3e07c338-ba6f-44a7-979b-3295c7167052@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <t_HBR4K_uT5fZ4Njc_2HDTNaISnakvNfJMwwe2h0aF0=.3998926d-88ae-4e4f-9494-c4a8f2dae233@github.com>
 <WyZs0JKvA7aIG-HYMC4Mx1b28PqMBat6k7nLD8MED28=.dfe48d68-4593-48c3-9938-1689321b35de@github.com>
 <xf8uLxck-PHXDF1_hCv-ia7uGE5Ns8Srlu8T4q-QYG8=.3e07c338-ba6f-44a7-979b-3295c7167052@github.com>
Message-ID: <6yji9cu-cXtwYQpFnpyh-33gTgPYGcTpfm3a84etMuw=.aee3a29b-dcdf-4382-b27a-6c2a68f03d6d@github.com>

On Mon, 11 Dec 2023 20:09:09 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/ByteArrayInputStream.java line 212:
>> 
>>> 210:             // 'tmpbuf' is null if and only if 'out' is trusted
>>> 211:             byte[] tmpbuf;
>>> 212:             if (IOStreams.isTrusted(out))
>> 
>> IMHO we should use `IOStreams.isTrusted(out)` in BAIS, too.
>
> BAIS - ByteArrayInputStream? It's already there

Sorry, it seems I missed that. ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1424972112

From alanb at openjdk.org  Wed Dec 13 08:05:50 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Dec 2023 08:05:50 GMT
Subject: [jdk22] RFR: 8321641: ClassFile
 ModuleAttribute.ModuleAttributeBuilder::moduleVersion spec contains a
 copy-paste error
In-Reply-To: <yCvzV4jYn8vlfL8yCFOyRbPmRdrgfDmgZLC18pNnx5k=.359a9f6a-77dd-41a6-9d76-3be2e3f4b643@github.com>
References: <yCvzV4jYn8vlfL8yCFOyRbPmRdrgfDmgZLC18pNnx5k=.359a9f6a-77dd-41a6-9d76-3be2e3f4b643@github.com>
Message-ID: <45aTsQ_KEwrVTuJQLGj6A543UWxS0kUvRk1YTdVxZ9M=.c398e90f-0df8-467c-838e-5995fe04f53f@github.com>

On Mon, 11 Dec 2023 10:19:52 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> 8321641: ClassFile ModuleAttribute.ModuleAttributeBuilder::moduleVersion spec contains a copy-paste error

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk22/pull/5#pullrequestreview-1779043371

From duke at openjdk.org  Wed Dec 13 08:07:49 2023
From: duke at openjdk.org (Markus KARG)
Date: Wed, 13 Dec 2023 08:07:49 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v12]
In-Reply-To: <etf_Tj0GsgwX88TgB9TN0twomrZnF87AQ0rwsDuh5qQ=.eecac5e8-b291-444a-9bbc-5feb545b0a2e@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <etf_Tj0GsgwX88TgB9TN0twomrZnF87AQ0rwsDuh5qQ=.eecac5e8-b291-444a-9bbc-5feb545b0a2e@github.com>
Message-ID: <nuvkaL-FkNCF036tp8X2RB0eHfXQwgq7bbw8shytdiE=.9529148a-26ab-48eb-85cd-4d4e23d8f31f@github.com>

On Tue, 12 Dec 2023 20:18:15 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`.
>> 
>> See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8320971: Whitespaces

src/java.base/share/classes/com/sun/io/IOStreams.java line 53:

> 51:     public static boolean isTrusted(OutputStream os) {
> 52:         var clazz = os.getClass();
> 53:         return clazz == ByteArrayOutputStream.class

I wonder what the committers think: Do we need a unit test for each trusted class to proof that they actually behave accordingly to the rules of trust listed in the Javadocs?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1424981445

From stsypanov at openjdk.org  Wed Dec 13 08:15:21 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 13 Dec 2023 08:15:21 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v13]
In-Reply-To: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
Message-ID: <9dHae2TsRpC75QWWLwT8zj5wgU3sNE9BruMOsO9-lGg=.2425bed0-13f8-496d-903c-702953337207@github.com>

> It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`.
> 
> See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  8320971: Fix JavaDoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16879/files
  - new: https://git.openjdk.org/jdk/pull/16879/files/a3ba43fd..c6696e27

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16879&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16879&range=11-12

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/16879.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16879/head:pull/16879

PR: https://git.openjdk.org/jdk/pull/16879

From duke at openjdk.org  Wed Dec 13 08:44:44 2023
From: duke at openjdk.org (Markus KARG)
Date: Wed, 13 Dec 2023 08:44:44 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v12]
In-Reply-To: <etf_Tj0GsgwX88TgB9TN0twomrZnF87AQ0rwsDuh5qQ=.eecac5e8-b291-444a-9bbc-5feb545b0a2e@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <etf_Tj0GsgwX88TgB9TN0twomrZnF87AQ0rwsDuh5qQ=.eecac5e8-b291-444a-9bbc-5feb545b0a2e@github.com>
Message-ID: <kUl-uD6OGidvfxTVCJGbHwC13GDzRDO4t1UaLWBmRhk=.7be2e91d-a059-4787-a432-e818d060e016@github.com>

On Tue, 12 Dec 2023 20:18:15 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`.
>> 
>> See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8320971: Whitespaces

Thank you for this contribution. If I were a committer I would be voting +1. :-)

-------------

Marked as reviewed by mkarg at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/16879#pullrequestreview-1779047929

From vsitnikov at openjdk.org  Wed Dec 13 08:44:47 2023
From: vsitnikov at openjdk.org (Vladimir Sitnikov)
Date: Wed, 13 Dec 2023 08:44:47 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v13]
In-Reply-To: <9dHae2TsRpC75QWWLwT8zj5wgU3sNE9BruMOsO9-lGg=.2425bed0-13f8-496d-903c-702953337207@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <9dHae2TsRpC75QWWLwT8zj5wgU3sNE9BruMOsO9-lGg=.2425bed0-13f8-496d-903c-702953337207@github.com>
Message-ID: <iR1U-YCF5xWqPgMo2y_mtGy_bgR142DY992awqsdzVM=.23721c0f-aac6-4590-b1ae-3a3e404e3f44@github.com>

On Wed, 13 Dec 2023 08:15:21 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`.
>> 
>> See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8320971: Fix JavaDoc

test/jdk/java/io/BufferedInputStream/TransferToTrusted.java line 52:

> 50:             byte[] tmp = new byte[len];
> 51:             RND.nextBytes(tmp);
> 52:             System.arraycopy(tmp, 0, b, off, len);

It is sad there's no `Random#nextBytes(byte[] buf, int offs, int len)`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1425023714

From asotona at openjdk.org  Wed Dec 13 08:52:09 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 13 Dec 2023 08:52:09 GMT
Subject: [jdk22] Integrated: 8321641: ClassFile
 ModuleAttribute.ModuleAttributeBuilder::moduleVersion spec contains a
 copy-paste error
In-Reply-To: <yCvzV4jYn8vlfL8yCFOyRbPmRdrgfDmgZLC18pNnx5k=.359a9f6a-77dd-41a6-9d76-3be2e3f4b643@github.com>
References: <yCvzV4jYn8vlfL8yCFOyRbPmRdrgfDmgZLC18pNnx5k=.359a9f6a-77dd-41a6-9d76-3be2e3f4b643@github.com>
Message-ID: <_eGbsf3jjLpeM1IeTYAtZZlVGo5aJOJap33Y7ly1GjY=.2d4aed88-b07e-4cf0-90a7-905aa9d2352d@github.com>

On Mon, 11 Dec 2023 10:19:52 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> 8321641: ClassFile ModuleAttribute.ModuleAttributeBuilder::moduleVersion spec contains a copy-paste error

This pull request has now been integrated.

Changeset: a55e18ba
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/a55e18baf093aa53aae954e3c9650770d703266e
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8321641: ClassFile ModuleAttribute.ModuleAttributeBuilder::moduleVersion spec contains a copy-paste error

Reviewed-by: alanb
Backport-of: 3c6459e1de9e75898a1b32a95acf684050fbe1af

-------------

PR: https://git.openjdk.org/jdk22/pull/5

From asotona at openjdk.org  Wed Dec 13 09:01:40 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 13 Dec 2023 09:01:40 GMT
Subject: RFR: 8320360: ClassFile.parse: Some defect class files cause
 unexpected exceptions to be thrown [v2]
In-Reply-To: <71S-mvJz6ZUKrEESzAAWbiwfs5sd0JkSTqavQtkHdfo=.f75af6fd-fb6e-4fe2-9dc1-15ca245a73f9@github.com>
References: <jbASOjz9CTAwfu_m0H5z3XpWmcuMmuF2aPkyjyLE7PE=.fe0e8a24-50c0-4c20-9de3-34834c8fa8c3@github.com>
 <71S-mvJz6ZUKrEESzAAWbiwfs5sd0JkSTqavQtkHdfo=.f75af6fd-fb6e-4fe2-9dc1-15ca245a73f9@github.com>
Message-ID: <G21kApnjL9cMfkz50pSw8PcQuDCc-TPjmxk2ZuZiIbk=.2f3a2504-af90-49d0-8d33-8ff584781736@github.com>

On Thu, 7 Dec 2023 07:53:58 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ClassFile API throws `IndexOutOfBoundsException` when classfile structure is corrupted so the parser attempts to read beyond the classfile bounds.
>> General contract is that only `IllegalArgumentException` or its subclasses is expected when parser fails.
>> This patch wraps `IndexOutOfBoundsExceptions` thrown from all `ClassReaderImpl.buffer` manipulations into an  `IllegalArgumentException("Reading beyond classfile bounds", iOOBECause)`.
>> Relevant tests are added.
>> 
>> Please review.
>> 
>> Thanks,
>> 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 three commits:
> 
>  - Merge branch 'master' into JDK-8320360-bounds
>    
>    # Conflicts:
>    #	test/jdk/jdk/classfile/LimitsTest.java
>  - added bug # to the test
>  - 8320360: ClassFile.parse: Some defect class files cause unexpected exceptions to be thrown

May I ask for review of this fix?

Thank you.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16762#issuecomment-1853511673

From stsypanov at openjdk.org  Wed Dec 13 09:03:02 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 13 Dec 2023 09:03:02 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v14]
In-Reply-To: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
Message-ID: <7HaUF6s5HMgwO9Qcg7FrYEYPUhNKG6TBhLer_1TCyBU=.f91d926c-8085-44b7-8691-a3f62d444f12@github.com>

> It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`.
> 
> See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  8320971: Add more tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16879/files
  - new: https://git.openjdk.org/jdk/pull/16879/files/c6696e27..42147ce8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16879&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16879&range=12-13

  Stats: 40 lines in 1 file changed: 36 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/16879.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16879/head:pull/16879

PR: https://git.openjdk.org/jdk/pull/16879

From stsypanov at openjdk.org  Wed Dec 13 09:08:50 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 13 Dec 2023 09:08:50 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v12]
In-Reply-To: <nuvkaL-FkNCF036tp8X2RB0eHfXQwgq7bbw8shytdiE=.9529148a-26ab-48eb-85cd-4d4e23d8f31f@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <etf_Tj0GsgwX88TgB9TN0twomrZnF87AQ0rwsDuh5qQ=.eecac5e8-b291-444a-9bbc-5feb545b0a2e@github.com>
 <nuvkaL-FkNCF036tp8X2RB0eHfXQwgq7bbw8shytdiE=.9529148a-26ab-48eb-85cd-4d4e23d8f31f@github.com>
Message-ID: <_cVAPr4wQdjFdhORtlXuy2eJ9nImAy-sV17j88-CW38=.c3230554-92cc-4d22-81b6-bb61213fc070@github.com>

On Wed, 13 Dec 2023 08:04:59 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8320971: Whitespaces
>
> src/java.base/share/classes/com/sun/io/IOStreams.java line 53:
> 
>> 51:     public static boolean isTrusted(OutputStream os) {
>> 52:         var clazz = os.getClass();
>> 53:         return clazz == ByteArrayOutputStream.class
> 
> I wonder what the committers think: Do we need a unit test for each trusted class to proof that they actually behave accordingly to the rules of trust listed in the Javadocs?

Added tests for all involved OutputStreams

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1425050812

From duke at openjdk.org  Wed Dec 13 09:08:53 2023
From: duke at openjdk.org (Markus KARG)
Date: Wed, 13 Dec 2023 09:08:53 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v13]
In-Reply-To: <iR1U-YCF5xWqPgMo2y_mtGy_bgR142DY992awqsdzVM=.23721c0f-aac6-4590-b1ae-3a3e404e3f44@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <9dHae2TsRpC75QWWLwT8zj5wgU3sNE9BruMOsO9-lGg=.2425bed0-13f8-496d-903c-702953337207@github.com>
 <iR1U-YCF5xWqPgMo2y_mtGy_bgR142DY992awqsdzVM=.23721c0f-aac6-4590-b1ae-3a3e404e3f44@github.com>
Message-ID: <PVzAorMV7_El0h4V-Biztrl5o6s1j824Ek51hA4-g3A=.ac9e3eb0-8294-4fe7-8be7-3f71f5fe4431@github.com>

On Wed, 13 Dec 2023 08:41:37 GMT, Vladimir Sitnikov <vsitnikov at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8320971: Fix JavaDoc
>
> test/jdk/java/io/BufferedInputStream/TransferToTrusted.java line 52:
> 
>> 50:             byte[] tmp = new byte[len];
>> 51:             RND.nextBytes(tmp);
>> 52:             System.arraycopy(tmp, 0, b, off, len);
> 
> It is sad there's no `Random#nextBytes(byte[] buf, int offs, int len)`

Feel free to open a PR. :-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1425052398

From alanb at openjdk.org  Wed Dec 13 09:12:48 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Dec 2023 09:12:48 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v13]
In-Reply-To: <9dHae2TsRpC75QWWLwT8zj5wgU3sNE9BruMOsO9-lGg=.2425bed0-13f8-496d-903c-702953337207@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <9dHae2TsRpC75QWWLwT8zj5wgU3sNE9BruMOsO9-lGg=.2425bed0-13f8-496d-903c-702953337207@github.com>
Message-ID: <wUG3o0T-exRTP0N363aDkzV0-5XN3XVWmNHKx2SMZXg=.ccc4faf2-2de4-447c-a57a-92a24fe28bf0@github.com>

On Wed, 13 Dec 2023 08:15:21 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`.
>> 
>> See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8320971: Fix JavaDoc

src/java.base/share/classes/com/sun/io/IOStreams.java line 26:

> 24:  */
> 25: 
> 26: package com.sun.io;

The starting point for this PR is getting agreement to relax the checks in BufferedInputStream.transferTo so ideally the changes would be limited to that one method initially. If you really want a supporting utility class then a non-public class like java.io.TransferSupport or something like that would be easier to discuss. We don't need to adding a new package com.sun.io for this.

I think drop  j.u.zip.CheckedOutputStream from the initial discussion as it it "too far away" to be in the mix at this point.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1425055930

From stsypanov at openjdk.org  Wed Dec 13 09:50:45 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 13 Dec 2023 09:50:45 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v13]
In-Reply-To: <wUG3o0T-exRTP0N363aDkzV0-5XN3XVWmNHKx2SMZXg=.ccc4faf2-2de4-447c-a57a-92a24fe28bf0@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <9dHae2TsRpC75QWWLwT8zj5wgU3sNE9BruMOsO9-lGg=.2425bed0-13f8-496d-903c-702953337207@github.com>
 <wUG3o0T-exRTP0N363aDkzV0-5XN3XVWmNHKx2SMZXg=.ccc4faf2-2de4-447c-a57a-92a24fe28bf0@github.com>
Message-ID: <ys78iaetW5O84JUvHY7R5E1GspSEIuvsUUwRI0gVoBs=.6a1916e0-57dc-409d-983b-70f8ca2b6d6e@github.com>

On Wed, 13 Dec 2023 09:09:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8320971: Fix JavaDoc
>
> src/java.base/share/classes/com/sun/io/IOStreams.java line 26:
> 
>> 24:  */
>> 25: 
>> 26: package com.sun.io;
> 
> The starting point for this PR is getting agreement to relax the checks in BufferedInputStream.transferTo so ideally the changes would be limited to that one method initially. If you really want a supporting utility class then a non-public class like java.io.TransferSupport or something like that would be easier to discuss. We don't need to adding a new package com.sun.io for this.
> 
> I think drop  j.u.zip.CheckedOutputStream from the initial discussion as it it "too far away" to be in the mix at this point.

So what is the target package for this utility class?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1425104701

From ihse at openjdk.org  Wed Dec 13 09:52:02 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 13 Dec 2023 09:52:02 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v12]
In-Reply-To: <pZiF9EcYqj3s4xZg8nGaZKslA3PgzQFJEpcSM54r6QA=.dc100d45-ed72-4a32-a9bc-22e21425b033@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <e5w5YZ0WD8S3UVFBYz6I0PdKZ6yOkD77BCq2arDd6i4=.7eecadcb-e627-4e9b-8f1e-3fc41c63243b@github.com>
 <bopxvLCquUtZQxt8kAJskzXBR2YE_I0PW13i3NBJNNY=.e65abf3d-0ff4-4450-875b-ca3717170485@github.com>
 <DeQgR1PaXlk2yzlxV15N3ViZY26wXtlgfVKxRY6vuWo=.6d38f729-0ca9-4f43-9e23-f5e73a01cc23@github.com>
 <b1Nv5Y7Klpvp5ACcHJTTblwGmnA64cyRg-3YzotaHvc=.0bd8a0f0-0844-44a9-a3bb-4af2e8514ee1@github.com>
 <t_23EA--aX8v2US9Lsib1ZF3bl4HQx_Z4RXqlgQo8LE=.6f1f2873-015c-4b69-ad47-b449e5b77a45@github.com>
 <pRcJlU1a4jG9gMaftLn5IerudMSDIrvr70KBefkpNSo=.f442f0d4-887f-4376-a66e-8254fa35927c@github.com>
 <OJ1ZK4a8c_bZik60v503VUtZoweFFv6VhhGg1sp4qSY=.e8852bf1-2d7f-4164-b952-d88b294ec1f7@github.com>
 <_gSNXk0qGAtpY-WJ5OCHk_3-nuGrwwSn-ffK9f2TEcs=.40f785ba-83dd-40fe-8075-a7a7872ea600@github.com>
 <v95kXnbADF5XriLfeg2v5yVYBo-BUzR-dhpcubuMDcI=.03d8e5a7-8b0c-4291-99df-2d3ec6cd356c@github.com>
 <D2AGAYSictxU124OSQMg3V5bpM1oKBdxKLd
 BS0X7ow8=.326a6f38-e9ab-4b24-a6d6-d8eebdb346f7@github.com>
 <wpFxnb5dr5v2UHZYPPdi4XsBUiLtFXGxRySgr6xCmJM=.74175d6e-0f30-464e-9c76-cc4e8bd6f36a@github.com>
 <7_T6sM3wjbSzZ0ab9FsptbpPnlQ2J4NNctQNkdbDFdI=.b595a8cc-4b14-44c6-8319-00e68fea21c3@github.com>
 <M2KPFFgTiBmYcdxO7_wNRYYokECxNAHmgsvbt-s8_k0=.6320d2de-2710-4ca7-a6b4-d1954167ca01@github.com>
 <miE0bEN_JyzIhfmBGCV7OkWags8LM9jM4oQYz1S5z20=.87be0fa6-3860-4bf8-8f57-3b8daaa1e996@github.com>
 <pZiF9EcYqj3s4xZg8nGaZKslA3PgzQFJEpcSM54r6QA=.dc100d45-ed72-4a32-a9bc-22e21425b033@github.com>
Message-ID: <wXOSMHIAVb46JQ85dujzmA0LAdQlsL-iDnQoxosc9Z4=.c8b13738-9007-4fe7-a96b-18fdcaf6462b@github.com>

On Tue, 12 Dec 2023 17:33:12 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> @vamsi-parasa You said:
>>> Made sure that OpenJDK builds without errors using both GCC 7.5 and GCC 6.4.
>> 
>> but now we have https://bugs.openjdk.org/browse/JDK-8321688. Did you introduce any changes after you tested with GCC 7.5? It seems strange to me that the code simultaneously both works and not works with gcc 7.5.
>
> Hi Magnus (@magicus), did a fresh pull of the OpenJDK and was able to build it successfully (without any errors) using GCC 7.5.0 on Ubuntu Linux machine. 
> (I am on vacation till Jan7th, 2024. Our team will look into this issue)

New information in JDK-8321688 says it is only happening on slowdebug. This is probably why it was missed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1425106097

From Alan.Bateman at oracle.com  Wed Dec 13 09:55:54 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 13 Dec 2023 09:55:54 +0000
Subject: ZipEntry
In-Reply-To: <C4F64D96-2BE6-4436-BD44-600316D9E05B@cbfiddle.com>
References: <C4F64D96-2BE6-4436-BD44-600316D9E05B@cbfiddle.com>
Message-ID: <54b08abb-502c-4daa-94ca-7f41c46e1d2d@oracle.com>

On 12/12/2023 20:17, Alan Snyder wrote:
> ZipEntry is a public class and I am aware that it is used outside the JDK. Presumably that is not a problem.
>
> I?m wondering why the class stores the external file attributes field but does not provide public accessors for it.
>
> I would find it useful to have access to this field. I would rather not have to switch to using a third party library just for this reason.
>
> I understand that the interpretation of the external file attributes is not standardized, but the field itself is defined in the standard
> cited by the package info page, so I don?t see the harm in making it accessible without interpretation.

It might be useful if you would expand a bit on what your usage is. Is 
it file permissions, symbolic links, or something else?

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20231213/22887fac/attachment-0001.htm>

From alanb at openjdk.org  Wed Dec 13 10:04:46 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Dec 2023 10:04:46 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v13]
In-Reply-To: <ys78iaetW5O84JUvHY7R5E1GspSEIuvsUUwRI0gVoBs=.6a1916e0-57dc-409d-983b-70f8ca2b6d6e@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <9dHae2TsRpC75QWWLwT8zj5wgU3sNE9BruMOsO9-lGg=.2425bed0-13f8-496d-903c-702953337207@github.com>
 <wUG3o0T-exRTP0N363aDkzV0-5XN3XVWmNHKx2SMZXg=.ccc4faf2-2de4-447c-a57a-92a24fe28bf0@github.com>
 <ys78iaetW5O84JUvHY7R5E1GspSEIuvsUUwRI0gVoBs=.6a1916e0-57dc-409d-983b-70f8ca2b6d6e@github.com>
Message-ID: <WAylJsCs3L767CCjDmqFVkwM7z3ZAw2_HXjvXWt-m3k=.1d8ac7ac-4e01-42a4-a977-8e37a73aaf54@github.com>

On Wed, 13 Dec 2023 09:47:50 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> So what is the target package for this utility class?

If you really want a utility class then a non-public class in java.io is okay. However, I think the starting point for this change is not the utility class, it's about deciding whether to relax the check on the target or do nothing. The concerns with BIS and BAIS do overlap but they are not identical. More specifically, for BAIS, the underlying byte[] can outlive the BAIS object. For BIS, transferTo may return a positive value more than once because the underlying stream is growing. These are the details that need to be worked through.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1425121886

From avoitylov at openjdk.org  Wed Dec 13 11:39:19 2023
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Wed, 13 Dec 2023 11:39:19 GMT
Subject: RFR: 8321514: UTF16 string gets constructed incorrectly from
 codepoints if CompactStrings is not enabled [v3]
In-Reply-To: <1azLdWceEALX1v_hfgt03ncVu_wtZyk3_lZ0B0J_cto=.a59aff49-50a9-498e-bc78-fd5468d87cd6@github.com>
References: <1azLdWceEALX1v_hfgt03ncVu_wtZyk3_lZ0B0J_cto=.a59aff49-50a9-498e-bc78-fd5468d87cd6@github.com>
Message-ID: <V_zRwOAFyFF-Ff3cUi1ujMNfPNClg59tQBN_Jet0LYE=.74b9e01c-0d32-41f9-a89f-37767c08d829@github.com>

> Since JDK-8311906, if CompactStrings is not enabled, index is not considered when calling extractCodepoints from StringUTF16.toBytes(). Because of that the last elements of the source codepoints array are stripped from the resulting UTF16 string, which fires in other places (e.g. during RegEx processing).
>  
> The fix replaces len in extractCodepoints parameters with end that is index + len.

Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:

  review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17057/files
  - new: https://git.openjdk.org/jdk/pull/17057/files/759068e8..cf622fae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17057&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17057&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17057.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17057/head:pull/17057

PR: https://git.openjdk.org/jdk/pull/17057

From avoitylov at openjdk.org  Wed Dec 13 11:42:39 2023
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Wed, 13 Dec 2023 11:42:39 GMT
Subject: RFR: 8321514: UTF16 string gets constructed incorrectly from
 codepoints if CompactStrings is not enabled [v3]
In-Reply-To: <V_zRwOAFyFF-Ff3cUi1ujMNfPNClg59tQBN_Jet0LYE=.74b9e01c-0d32-41f9-a89f-37767c08d829@github.com>
References: <1azLdWceEALX1v_hfgt03ncVu_wtZyk3_lZ0B0J_cto=.a59aff49-50a9-498e-bc78-fd5468d87cd6@github.com>
 <V_zRwOAFyFF-Ff3cUi1ujMNfPNClg59tQBN_Jet0LYE=.74b9e01c-0d32-41f9-a89f-37767c08d829@github.com>
Message-ID: <Npo6zu7qpfXa1PbNvnI8TzK07BJA-YfnQAEu5UajJzg=.d8c85158-9712-4f3c-ac36-4e99091b580d@github.com>

On Wed, 13 Dec 2023 11:39:19 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

>> Since JDK-8311906, if CompactStrings is not enabled, index is not considered when calling extractCodepoints from StringUTF16.toBytes(). Because of that the last elements of the source codepoints array are stripped from the resulting UTF16 string, which fires in other places (e.g. during RegEx processing).
>>  
>> The fix replaces len in extractCodepoints parameters with end that is index + len.
>
> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

1. Yes, I'm aware of -XX:-CompactStrings being used in production in server deployments (no, I didn't collect the reasons for that).
2. Yes, it was discovered as part of release testing. Also related to our support efforts for ARM32, but not just that.

If you think it's worth it, I can go through some tests and add some more -XX:-CompactStrings mode to java.lang.String tests here and there, lightly. It's not the first time we hit this issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17057#issuecomment-1853758819

From avoitylov at openjdk.org  Wed Dec 13 11:49:39 2023
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Wed, 13 Dec 2023 11:49:39 GMT
Subject: RFR: 8321514: UTF16 string gets constructed incorrectly from
 codepoints if CompactStrings is not enabled [v2]
In-Reply-To: <6at803p4T4BkisD3Ekw7ixsHAQFOdpJKIEpY9nHHov8=.1025f693-a562-46cf-bce7-b3a1ea00b240@github.com>
References: <1azLdWceEALX1v_hfgt03ncVu_wtZyk3_lZ0B0J_cto=.a59aff49-50a9-498e-bc78-fd5468d87cd6@github.com>
 <P1bqGRS3bqxB3VBm-dDbGShSmRBnOEFz-nKfpvSbBFQ=.4e3a4629-a880-4b67-aab1-d77e0a09c4bf@github.com>
 <6at803p4T4BkisD3Ekw7ixsHAQFOdpJKIEpY9nHHov8=.1025f693-a562-46cf-bce7-b3a1ea00b240@github.com>
Message-ID: <SsKUUoMI5FLclg8-1oIkDPxOk0iftW4o1reFa9GQSX0=.aaa0fc2b-544e-41ce-a432-8924433451bb@github.com>

On Tue, 12 Dec 2023 19:11:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments
>
> test/jdk/java/lang/String/Chars.java line 50:
> 
>> 48:             testChars(cc, ccExp);
>> 49:             testCharsSubrange(cc, ccExp);
>> 50:             testIntsSubrange(ccExp);
> 
> Please also add the same call after line 74 to apply the test to the surrogates case.
> (As suggested by @rgiulietti in https://github.com/openjdk/jdk/pull/17066)

Just pulled the update from that branch.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17057#discussion_r1425241518

From jvernee at openjdk.org  Wed Dec 13 13:32:39 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 13 Dec 2023 13:32:39 GMT
Subject: RFR: 8321400: java/foreign/TestStubAllocFailure.java fails with
 code cache exhaustion
In-Reply-To: <Qu9R1yyh7SkP0VwxYDVFjFCRRY-xE-lRlyFNMG750d8=.915f6560-81fe-4efe-b98b-06054b31c591@github.com>
References: <GzvkhIYT0Bz6jHuS5o-q_DvNTRCKfj5hqDRHPvN2MxY=.8ce04894-a4e6-4339-9dfb-26a1933d3e59@github.com>
 <Qu9R1yyh7SkP0VwxYDVFjFCRRY-xE-lRlyFNMG750d8=.915f6560-81fe-4efe-b98b-06054b31c591@github.com>
Message-ID: <wlohswVQSIo7JBcsZBP4yS93SVEj8Ic78Hgvzy_I-d8=.06fd69b0-d059-4b5e-aee5-77c015a2ad17@github.com>

On Wed, 13 Dec 2023 07:08:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Improve the test by being more lenient to related code cache exhaustion errors. The important thing is that we don't terminate with a fatal error, which the new code now checks for explicitly. The check for that is based on what is done by `./test/hotspot/jtreg/runtime/ErrorHandling/HsErrFileUtils.java` .
>> 
>> The existing `UpcallTestHelper.Output` class that was previously used to assert on stdout/stderr contents did not have the capability to look for patterns in the output. So, I've taken the opportunity to replace it with the more canonical `OutputAnalyzer` which comes from the test library.
>> 
>> Finally, I've also added back the test for downcall stub allocation failure which was removed as part of the initial patch because it was too inconsistent [1]. With the new approach, it should pass reliably as well.
>> 
>> Testing: `jdk_foreign`  suite (which contains all the affected tests)
>> 
>> [1]: https://github.com/openjdk/jdk/pull/16311/commits/9a1360598a91871ce6ec48330849c0e4e0279c64
>
> test/jdk/java/foreign/TestStubAllocFailure.java line 51:
> 
>> 49:         runInNewProcess(UpcallRunner.class, true, List.of("-XX:ReservedCodeCacheSize=3M"), List.of())
>> 50:                 .shouldNotHaveExitValue(0)
>> 51:                 .shouldNotHaveFatalError();
> 
> Just curious what non-zero exit value is actually expected here and below?

Any non-zero exit value is acceptable. The intent here is to check that the process didn't complete normally.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17056#discussion_r1425357636

From rriggs at openjdk.org  Wed Dec 13 14:40:42 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Dec 2023 14:40:42 GMT
Subject: RFR: 8321514: UTF16 string gets constructed incorrectly from
 codepoints if CompactStrings is not enabled [v3]
In-Reply-To: <V_zRwOAFyFF-Ff3cUi1ujMNfPNClg59tQBN_Jet0LYE=.74b9e01c-0d32-41f9-a89f-37767c08d829@github.com>
References: <1azLdWceEALX1v_hfgt03ncVu_wtZyk3_lZ0B0J_cto=.a59aff49-50a9-498e-bc78-fd5468d87cd6@github.com>
 <V_zRwOAFyFF-Ff3cUi1ujMNfPNClg59tQBN_Jet0LYE=.74b9e01c-0d32-41f9-a89f-37767c08d829@github.com>
Message-ID: <iBloiJbHXPOmEBJN-ZN9WVZofUu9_RK2BaXu3tR413U=.d4aab2b7-278a-416d-b9ca-9705c89382d9@github.com>

On Wed, 13 Dec 2023 11:39:19 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

>> Since JDK-8311906, if CompactStrings is not enabled, index is not considered when calling extractCodepoints from StringUTF16.toBytes(). Because of that the last elements of the source codepoints array are stripped from the resulting UTF16 string, which fires in other places (e.g. during RegEx processing).
>>  
>> The fix replaces len in extractCodepoints parameters with end that is index + len.
>
> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Looks good, thanks for the followup.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17057#pullrequestreview-1779792024

From rriggs at openjdk.org  Wed Dec 13 14:45:40 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Dec 2023 14:45:40 GMT
Subject: RFR: 8321514: UTF16 string gets constructed incorrectly from
 codepoints if CompactStrings is not enabled [v3]
In-Reply-To: <Npo6zu7qpfXa1PbNvnI8TzK07BJA-YfnQAEu5UajJzg=.d8c85158-9712-4f3c-ac36-4e99091b580d@github.com>
References: <1azLdWceEALX1v_hfgt03ncVu_wtZyk3_lZ0B0J_cto=.a59aff49-50a9-498e-bc78-fd5468d87cd6@github.com>
 <V_zRwOAFyFF-Ff3cUi1ujMNfPNClg59tQBN_Jet0LYE=.74b9e01c-0d32-41f9-a89f-37767c08d829@github.com>
 <Npo6zu7qpfXa1PbNvnI8TzK07BJA-YfnQAEu5UajJzg=.d8c85158-9712-4f3c-ac36-4e99091b580d@github.com>
Message-ID: <uS-IKnAg-6J9igFWXAV0UsiuN1rMqKMSuowPCiqzjhs=.7b750f69-dc3e-47c9-8a8a-f27c278fb554@github.com>

On Wed, 13 Dec 2023 11:39:29 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

> If you think it's worth it, I can go through some tests and add some more -XX:-CompactStrings mode to java.lang.String tests here and there, lightly. It's not the first time we hit this issue.

Verifying the coverage of the tests would be useful. I noticed in many tests of the API signatures that include offset and length, the offset is frequently zero.

As for -XX:-CompactStrings, it was originally a precaution about backward compatibility. From time to time it comes up to consider simplifying the code to remove it. It would be good to know the use cases where it is needed and the rationale.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17057#issuecomment-1854045141

From rriggs at openjdk.org  Wed Dec 13 14:48:41 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Dec 2023 14:48:41 GMT
Subject: RFR: 8321514: UTF16 string gets constructed incorrectly from
 codepoints if CompactStrings is not enabled [v3]
In-Reply-To: <V_zRwOAFyFF-Ff3cUi1ujMNfPNClg59tQBN_Jet0LYE=.74b9e01c-0d32-41f9-a89f-37767c08d829@github.com>
References: <1azLdWceEALX1v_hfgt03ncVu_wtZyk3_lZ0B0J_cto=.a59aff49-50a9-498e-bc78-fd5468d87cd6@github.com>
 <V_zRwOAFyFF-Ff3cUi1ujMNfPNClg59tQBN_Jet0LYE=.74b9e01c-0d32-41f9-a89f-37767c08d829@github.com>
Message-ID: <tuQZXkyNGjiMbiWHGq_Vhzw8BVPZDj3b5nV0morcYSA=.09dbad27-914a-41c2-b45e-5d29590d0a92@github.com>

On Wed, 13 Dec 2023 11:39:19 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

>> Since JDK-8311906, if CompactStrings is not enabled, index is not considered when calling extractCodepoints from StringUTF16.toBytes(). Because of that the last elements of the source codepoints array are stripped from the resulting UTF16 string, which fires in other places (e.g. during RegEx processing).
>>  
>> The fix replaces len in extractCodepoints parameters with end that is index + len.
>
> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

I'll keep an eye out for the backport to jdk 21 if a review is needed for that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17057#issuecomment-1854050370

From duke at openjdk.org  Wed Dec 13 15:32:47 2023
From: duke at openjdk.org (Markus KARG)
Date: Wed, 13 Dec 2023 15:32:47 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v13]
In-Reply-To: <WAylJsCs3L767CCjDmqFVkwM7z3ZAw2_HXjvXWt-m3k=.1d8ac7ac-4e01-42a4-a977-8e37a73aaf54@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <9dHae2TsRpC75QWWLwT8zj5wgU3sNE9BruMOsO9-lGg=.2425bed0-13f8-496d-903c-702953337207@github.com>
 <wUG3o0T-exRTP0N363aDkzV0-5XN3XVWmNHKx2SMZXg=.ccc4faf2-2de4-447c-a57a-92a24fe28bf0@github.com>
 <ys78iaetW5O84JUvHY7R5E1GspSEIuvsUUwRI0gVoBs=.6a1916e0-57dc-409d-983b-70f8ca2b6d6e@github.com>
 <WAylJsCs3L767CCjDmqFVkwM7z3ZAw2_HXjvXWt-m3k=.1d8ac7ac-4e01-42a4-a977-8e37a73aaf54@github.com>
Message-ID: <aLoYPo-yg5s64QmQ3URAANXAgW1U45MYs3SIr-UhltM=.a94f6d5e-df07-4b3f-9271-e3c5312820db@github.com>

On Wed, 13 Dec 2023 10:01:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> So what is the target package for this utility class?
>
>> So what is the target package for this utility class?
> 
> If you really want a utility class then a non-public class in java.io is okay. However, I think the starting point for this change is not the utility class, it's about deciding whether to relax the check on the target or do nothing. The concerns with BIS and BAIS do overlap but they are not identical. More specifically, for BAIS, the underlying byte[] can outlive the BAIS object. For BIS, transferTo may return a positive value more than once because the underlying stream is growing. These are the details that need to be worked through.

@AlanBateman Why not using com.sun as we did it with other internal classes like ChannelInputStream etc.? Regarding your last sentence actually I do not see what "return a positive value more than once" has to do with the actual changed proposed by this PR?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1425523315

From alanb at openjdk.org  Wed Dec 13 15:55:49 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Dec 2023 15:55:49 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v13]
In-Reply-To: <WAylJsCs3L767CCjDmqFVkwM7z3ZAw2_HXjvXWt-m3k=.1d8ac7ac-4e01-42a4-a977-8e37a73aaf54@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <9dHae2TsRpC75QWWLwT8zj5wgU3sNE9BruMOsO9-lGg=.2425bed0-13f8-496d-903c-702953337207@github.com>
 <wUG3o0T-exRTP0N363aDkzV0-5XN3XVWmNHKx2SMZXg=.ccc4faf2-2de4-447c-a57a-92a24fe28bf0@github.com>
 <ys78iaetW5O84JUvHY7R5E1GspSEIuvsUUwRI0gVoBs=.6a1916e0-57dc-409d-983b-70f8ca2b6d6e@github.com>
 <WAylJsCs3L767CCjDmqFVkwM7z3ZAw2_HXjvXWt-m3k=.1d8ac7ac-4e01-42a4-a977-8e37a73aaf54@github.com>
Message-ID: <_miSXEzpwwc2L6PItAeDnmHMJcj--IWC-rCHZBQAWo0=.bc6646a8-1600-4ecd-9268-6de6dfc25d65@github.com>

On Wed, 13 Dec 2023 10:01:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> So what is the target package for this utility class?
>
>> So what is the target package for this utility class?
> 
> If you really want a utility class then a non-public class in java.io is okay. However, I think the starting point for this change is not the utility class, it's about deciding whether to relax the check on the target or do nothing. The concerns with BIS and BAIS do overlap but they are not identical. More specifically, for BAIS, the underlying byte[] can outlive the BAIS object. For BIS, transferTo may return a positive value more than once because the underlying stream is growing. These are the details that need to be worked through.

> @AlanBateman Why not using com.sun as we did it with other internal classes like ChannelInputStream etc.? 

com.sun.* is the name space we used a long time ago for JDK-specific APIs and some internal classes. A lot more internal classes in sun.*.   It doesn't make sense here to add a new package com.sun.io for a single method class. This PR does not need to introduce any new classes at this point. I think this PR needs to focus solely on BIS.

> Regarding your last sentence actually I do not see what "return a positive value more than once" has to do with the actual changed proposed by this PR?

On the surface, transferTo reads to EOF so there are no more bytes to read from the underlying stream or byte[]. Adding a "growing file" and it breaks assumptions. So it's an important discussion point in this topic.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1425555299

From javalists at cbfiddle.com  Wed Dec 13 15:56:25 2023
From: javalists at cbfiddle.com (Alan Snyder)
Date: Wed, 13 Dec 2023 07:56:25 -0800
Subject: ZipEntry
In-Reply-To: <54b08abb-502c-4daa-94ca-7f41c46e1d2d@oracle.com>
References: <C4F64D96-2BE6-4436-BD44-600316D9E05B@cbfiddle.com>
 <54b08abb-502c-4daa-94ca-7f41c46e1d2d@oracle.com>
Message-ID: <C122D389-7FD3-4DCD-A896-C4051A561821@cbfiddle.com>

My immediate interest is symlinks.

  Alan

> On Dec 13, 2023, at 1:55?AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 12/12/2023 20:17, Alan Snyder wrote:
>> ZipEntry is a public class and I am aware that it is used outside the JDK. Presumably that is not a problem.
>> 
>> I?m wondering why the class stores the external file attributes field but does not provide public accessors for it.
>> 
>> I would find it useful to have access to this field. I would rather not have to switch to using a third party library just for this reason.
>> 
>> I understand that the interpretation of the external file attributes is not standardized, but the field itself is defined in the standard
>> cited by the package info page, so I don?t see the harm in making it accessible without interpretation.
> 
> It might be useful if you would expand a bit on what your usage is. Is it file permissions, symbolic links, or something else?
> 
> -Alan


From duke at openjdk.org  Wed Dec 13 16:23:44 2023
From: duke at openjdk.org (Markus KARG)
Date: Wed, 13 Dec 2023 16:23:44 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v13]
In-Reply-To: <_miSXEzpwwc2L6PItAeDnmHMJcj--IWC-rCHZBQAWo0=.bc6646a8-1600-4ecd-9268-6de6dfc25d65@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <9dHae2TsRpC75QWWLwT8zj5wgU3sNE9BruMOsO9-lGg=.2425bed0-13f8-496d-903c-702953337207@github.com>
 <wUG3o0T-exRTP0N363aDkzV0-5XN3XVWmNHKx2SMZXg=.ccc4faf2-2de4-447c-a57a-92a24fe28bf0@github.com>
 <ys78iaetW5O84JUvHY7R5E1GspSEIuvsUUwRI0gVoBs=.6a1916e0-57dc-409d-983b-70f8ca2b6d6e@github.com>
 <WAylJsCs3L767CCjDmqFVkwM7z3ZAw2_HXjvXWt-m3k=.1d8ac7ac-4e01-42a4-a977-8e37a73aaf54@github.com>
 <_miSXEzpwwc2L6PItAeDnmHMJcj--IWC-rCHZBQAWo0=.bc6646a8-1600-4ecd-9268-6de6dfc25d65@github.com>
Message-ID: <9FZlGCKRceiNKLBtz1LASHzLP1icDBftgwEWqxCx7Dg=.92be3d2e-7aef-40a0-a508-1e6b47fac529@github.com>

On Wed, 13 Dec 2023 15:53:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> It doesn't make sense here to add a new package com.sun.io for a single method class. This PR does not need to introduce any new classes at this point. I think this PR needs to focus solely on BIS.

So you actually prefer copy-and-paste and duplicated code?

> On the surface, transferTo reads to EOF so there are no more bytes to read from the underlying stream or byte[]. Adding a "growing file" and it breaks assumptions. So it's an important discussion point in this topic.

I still do not see what this has to do with the *actual* changes proposed by this PR. Can you please provide an example in what situation the *actual* changes proposed by this PR will fail in that case, while the original code will succeed?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1425592402

From alanb at openjdk.org  Wed Dec 13 16:48:44 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Dec 2023 16:48:44 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v13]
In-Reply-To: <9FZlGCKRceiNKLBtz1LASHzLP1icDBftgwEWqxCx7Dg=.92be3d2e-7aef-40a0-a508-1e6b47fac529@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <9dHae2TsRpC75QWWLwT8zj5wgU3sNE9BruMOsO9-lGg=.2425bed0-13f8-496d-903c-702953337207@github.com>
 <wUG3o0T-exRTP0N363aDkzV0-5XN3XVWmNHKx2SMZXg=.ccc4faf2-2de4-447c-a57a-92a24fe28bf0@github.com>
 <ys78iaetW5O84JUvHY7R5E1GspSEIuvsUUwRI0gVoBs=.6a1916e0-57dc-409d-983b-70f8ca2b6d6e@github.com>
 <WAylJsCs3L767CCjDmqFVkwM7z3ZAw2_HXjvXWt-m3k=.1d8ac7ac-4e01-42a4-a977-8e37a73aaf54@github.com>
 <_miSXEzpwwc2L6PItAeDnmHMJcj--IWC-rCHZBQAWo0=.bc6646a8-1600-4ecd-9268-6de6dfc25d65@github.com>
 <9FZlGCKRceiNKLBtz1LASHzLP1icDBftgwEWqxCx7Dg=.92be3d2e-7aef-40a0-a508-1e6b47fac529@github.com>
Message-ID: <YBNZbkzA40qmeLhJvjxKEzc6TqkxK2AV7uGxi2G2RoA=.01841c04-4b96-4ba3-ba12-f9ba3c543d8f@github.com>

On Wed, 13 Dec 2023 16:20:58 GMT, Markus KARG <duke at openjdk.org> wrote:

> > It doesn't make sense here to add a new package com.sun.io for a single method class. This PR does not need to introduce any new classes at this point. I think this PR needs to focus solely on BIS.
> 
> So you actually prefer copy-and-paste and duplicated code?

It's not important at this time, the starting point is to decide if BIS.transferTo should be changed or not. It does shared some concerns with BAIS but the set of concerns for both is not identical.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1425625184

From jvernee at openjdk.org  Wed Dec 13 17:39:48 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 13 Dec 2023 17:39:48 GMT
Subject: Integrated: 8321400: java/foreign/TestStubAllocFailure.java fails with
 code cache exhaustion
In-Reply-To: <GzvkhIYT0Bz6jHuS5o-q_DvNTRCKfj5hqDRHPvN2MxY=.8ce04894-a4e6-4339-9dfb-26a1933d3e59@github.com>
References: <GzvkhIYT0Bz6jHuS5o-q_DvNTRCKfj5hqDRHPvN2MxY=.8ce04894-a4e6-4339-9dfb-26a1933d3e59@github.com>
Message-ID: <eLlZmmcTEIU7-TBz-BJojRxESCFCMOi_vRfjElK_UBE=.cf1f98ea-0e30-4d40-9415-845edd4596ab@github.com>

On Mon, 11 Dec 2023 13:01:25 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Improve the test by being more lenient to related code cache exhaustion errors. The important thing is that we don't terminate with a fatal error, which the new code now checks for explicitly. The check for that is based on what is done by `./test/hotspot/jtreg/runtime/ErrorHandling/HsErrFileUtils.java` .
> 
> The existing `UpcallTestHelper.Output` class that was previously used to assert on stdout/stderr contents did not have the capability to look for patterns in the output. So, I've taken the opportunity to replace it with the more canonical `OutputAnalyzer` which comes from the test library.
> 
> Finally, I've also added back the test for downcall stub allocation failure which was removed as part of the initial patch because it was too inconsistent [1]. With the new approach, it should pass reliably as well.
> 
> Testing: `jdk_foreign`  suite (which contains all the affected tests)
> 
> [1]: https://github.com/openjdk/jdk/pull/16311/commits/9a1360598a91871ce6ec48330849c0e4e0279c64

This pull request has now been integrated.

Changeset: 7ece9e90
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7ece9e90c0198f92cdf8d620e346c4a9832724cd
Stats:     106 lines in 7 files changed: 47 ins; 42 del; 17 mod

8321400: java/foreign/TestStubAllocFailure.java fails with code cache exhaustion

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/17056

From jvernee at openjdk.org  Wed Dec 13 17:45:58 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 13 Dec 2023 17:45:58 GMT
Subject: [jdk22] RFR: 8321400: java/foreign/TestStubAllocFailure.java fails
 with code cache exhaustion
Message-ID: <U4vW9bQgNTa5ATbgZvH0q4v_vxGZ3oXYqoaTbZWA0iw=.feb4b156-2083-437e-8a1d-3523c1ad21cf@github.com>

Hi all,

This pull request contains a backport of commit [7ece9e90](https://github.com/openjdk/jdk/commit/7ece9e90c0198f92cdf8d620e346c4a9832724cd) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Jorn Vernee on 13 Dec 2023 and was reviewed by Maurizio Cimadamore.

Thanks!

-------------

Commit messages:
 - Backport 7ece9e90c0198f92cdf8d620e346c4a9832724cd

Changes: https://git.openjdk.org/jdk22/pull/11/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=11&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321400
  Stats: 106 lines in 7 files changed: 47 ins; 42 del; 17 mod
  Patch: https://git.openjdk.org/jdk22/pull/11.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/11/head:pull/11

PR: https://git.openjdk.org/jdk22/pull/11

From naoto at openjdk.org  Wed Dec 13 18:01:55 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 13 Dec 2023 18:01:55 GMT
Subject: RFR: 8320919: Clarify Locale related system properties [v4]
In-Reply-To: <IruGxIK9DXnXFDANt1y4sCMJEGZh1PTOKhOWZZxJEdc=.77092e02-fb4f-4c9e-8d53-0fa0cf3bae7d@github.com>
References: <IruGxIK9DXnXFDANt1y4sCMJEGZh1PTOKhOWZZxJEdc=.77092e02-fb4f-4c9e-8d53-0fa0cf3bae7d@github.com>
Message-ID: <fKq7_3dDkmdejZLwDy4YZ6WLT_qMs8cAF_yDn2XT8_E=.3421ea19-e468-42e3-90be-cea266b4adbb@github.com>

> This is a doc change to clarify what the `Default Locale` is, and how it is established during the system startup using the system properties. Those locale-related system properties have existed since the early days of Java, but have never been publicly documented before. It is also the intention of this PR to clarify those system properties and how they are overridden. A corresponding CSR has been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Reflects review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17065/files
  - new: https://git.openjdk.org/jdk/pull/17065/files/8baa56a9..60b891a2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17065&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17065&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17065.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17065/head:pull/17065

PR: https://git.openjdk.org/jdk/pull/17065

From naoto at openjdk.org  Wed Dec 13 18:04:40 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 13 Dec 2023 18:04:40 GMT
Subject: RFR: 8320919: Clarify Locale related system properties [v3]
In-Reply-To: <wty1T1zBJzvCBz9c2z1nPeD7316D_p9kU4CbQCeuUZs=.156e712d-b269-4bdf-b87d-f07a7057e2a2@github.com>
References: <IruGxIK9DXnXFDANt1y4sCMJEGZh1PTOKhOWZZxJEdc=.77092e02-fb4f-4c9e-8d53-0fa0cf3bae7d@github.com>
 <wty1T1zBJzvCBz9c2z1nPeD7316D_p9kU4CbQCeuUZs=.156e712d-b269-4bdf-b87d-f07a7057e2a2@github.com>
Message-ID: <0pzel4PP4XfVmYV9TWUQ1GdFG1uiT-vInRbSazXmEpM=.9adfb593-d1fb-4ceb-b001-6abf2a765af8@github.com>

On Mon, 11 Dec 2023 23:20:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a doc change to clarify what the `Default Locale` is, and how it is established during the system startup using the system properties. Those locale-related system properties have existed since the early days of Java, but have never been publicly documented before. It is also the intention of this PR to clarify those system properties and how they are overridden. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Thanks, Stuart. Modified the wordings as suggested.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17065#issuecomment-1854460819

From duke at openjdk.org  Wed Dec 13 18:21:49 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Wed, 13 Dec 2023 18:21:49 GMT
Subject: RFR: 8318971 : Better Error Handling for Jar Tool Processing of @File
Message-ID: <xht1jEn-KP8Fhz4Xa4MBxlhsvlxk3mdAkpdv9dF77oQ=.3fdc9a36-e7da-4230-9b26-40dacb8e92b6@github.com>

Better Error Handling for Jar Tool Processing of "@File" <br>

This is a new PR for this PR since the original developer left the team. See all of the review history at https://github.com/openjdk/jdk/pull/16423.

Thank you.

-------------

Commit messages:
 - 8318971 : Better Error Handling for Jar Tool Processing of @File

Changes: https://git.openjdk.org/jdk/pull/17088/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17088&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318971
  Stats: 56 lines in 2 files changed: 54 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17088.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17088/head:pull/17088

PR: https://git.openjdk.org/jdk/pull/17088

From rriggs at openjdk.org  Wed Dec 13 18:37:43 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Dec 2023 18:37:43 GMT
Subject: RFR: 8320919: Clarify Locale related system properties [v4]
In-Reply-To: <fKq7_3dDkmdejZLwDy4YZ6WLT_qMs8cAF_yDn2XT8_E=.3421ea19-e468-42e3-90be-cea266b4adbb@github.com>
References: <IruGxIK9DXnXFDANt1y4sCMJEGZh1PTOKhOWZZxJEdc=.77092e02-fb4f-4c9e-8d53-0fa0cf3bae7d@github.com>
 <fKq7_3dDkmdejZLwDy4YZ6WLT_qMs8cAF_yDn2XT8_E=.3421ea19-e468-42e3-90be-cea266b4adbb@github.com>
Message-ID: <Wnj-AwdLTHcs8VPJfcGhSDM05BVrtlB6y8iNEjQT6oo=.3eef183c-1259-42e7-a58d-0da8aa15a417@github.com>

On Wed, 13 Dec 2023 18:01:55 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a doc change to clarify what the `Default Locale` is, and how it is established during the system startup using the system properties. Those locale-related system properties have existed since the early days of Java, but have never been publicly documented before. It is also the intention of this PR to clarify those system properties and how they are overridden. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

Marked as reviewed by rriggs (Reviewer).

src/java.base/share/classes/java/util/Locale.java line 305:

> 303:  * results in a default Locale with no extensions, while specifying
> 304:  * {@code -Duser.language=foobarbaz} results in a default Locale whose language is
> 305:  * "foobarbaz".)

The parenthesized sentence is so long that its not effective in making it seem like an option.
The "Typical," is sufficient to indicate it is not part of the spec. Drop the parens.

src/java.base/share/classes/java/util/Locale.java line 317:

> 315:  * If the default Locale is changed with {@link #setDefault(Locale)}, the corresponding
> 316:  * system properties are not altered. It is not recommended that applications read
> 317:  * these system properties and parse/interpret them as their values may be out of date.

"parse/interpret" -> "parse or interpret".

-------------

PR Review: https://git.openjdk.org/jdk/pull/17065#pullrequestreview-1780257611
PR Review Comment: https://git.openjdk.org/jdk/pull/17065#discussion_r1425741255
PR Review Comment: https://git.openjdk.org/jdk/pull/17065#discussion_r1425740095

From tprinzing at openjdk.org  Wed Dec 13 18:38:09 2023
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Wed, 13 Dec 2023 18:38:09 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v2]
In-Reply-To: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
Message-ID: <ykUHh71hzDHZPZl4_Pp0ZUC94c0HZeXiqu0FDY9OkSI=.9d98a8b1-8b46-45a7-b799-715fa3d7d0fe@github.com>

> Added mirror event with static methods: jdk.internal.event.SelectionEvent that provides the duration of select calls and the count of how many keys are available.
> 
> Emit the event from SelectorImpl::lockAndDoSelect
> 
> Test at jdk.jfr.event.io.TestSelectionEvents

Tim Prinzing has updated the pull request with a new target base 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:

 - Change event generation:
   
   - selectNow is filtered out
   - select that times out is always sent
   - select without timeout uses duration test
 - rename event to SelectorSelect, field to selectionKeyCount.
 - Merge branch 'master' into JDK-8310994
 - remove trailing whitespace
 - event logic outside of the lock, selector in try block
 - remove unused import
 - fix TestConfigure failure
 - add event defaults
 - Merge branch 'master' into JDK-8310994
 - minor test cleanup
 - ... and 2 more: https://git.openjdk.org/jdk/compare/a4905c7c...2f7dafd8

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16710/files
  - new: https://git.openjdk.org/jdk/pull/16710/files/fbb93112..2f7dafd8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16710&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16710&range=00-01

  Stats: 73918 lines in 2175 files changed: 42613 ins; 21404 del; 9901 mod
  Patch: https://git.openjdk.org/jdk/pull/16710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16710/head:pull/16710

PR: https://git.openjdk.org/jdk/pull/16710

From duke at openjdk.org  Wed Dec 13 18:38:46 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 13 Dec 2023 18:38:46 GMT
Subject: RFR: JDK-8319626: Override toString() for ZipFile [v8]
In-Reply-To: <EEHjubpyde8VF6w4shuUjROZWwIabcGCI9DYMva_gy8=.afba4e81-0f88-4530-8e32-23ca7f949157@github.com>
References: <UEVJDXC8Cs_RSBUEsWgmq8SPvI-T4LSydbPKr8u29iA=.fdce7d47-87a8-42ba-9cd4-119bf9023ad9@github.com>
 <EEHjubpyde8VF6w4shuUjROZWwIabcGCI9DYMva_gy8=.afba4e81-0f88-4530-8e32-23ca7f949157@github.com>
Message-ID: <__6rDvcUmyOqJxKsGh8f5m0Nyhvcan0ou9aWOUJd040=.8500b0ba-c3c4-481a-a473-2d09a86341e5@github.com>

On Mon, 11 Dec 2023 05:47:33 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319982) which overrides and provides an implementation of `toString()` in _java.util.zip.ZipFile_ (and by extension, _java.util.jar.JarFile_).
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8319626
>  - break line
>  - reflect review: change impl to store field name
>  - drop additional specification
>  - drop 2nd paragraph
>  - return base name, not full path
>  - shorten wording
>  - reflect review: use separator, clarify spec
>  - reflect review: change string value and drop spec
>  - init

I'm seeing the `ZipSourceCache` fail on GHA on `windows-x64`:


FAILED     ZipSourceCache::testKeySourceMapping 'testKeySourceMapping()'
java.nio.file.FileSystemException: 1702471080605-bug8317678.zip: The process cannot access the file because it is being used by another process
	at java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:92)
	at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
	at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108)
	at java.base/sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:273)
	at java.base/sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:109)
	at java.base/java.nio.file.Files.deleteIfExists(Files.java:1191)
	at ZipSourceCache.cleanup(ZipSourceCache.java:65)


Build summary: https://github.com/eirbjo/jdk/actions/runs/7194395508

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16643#issuecomment-1854508435

From tprinzing at openjdk.org  Wed Dec 13 18:42:41 2023
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Wed, 13 Dec 2023 18:42:41 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v2]
In-Reply-To: <eFGT4ltuYb7Rs4hf5QcNaqf4klAl1ilxfjETsPv9A8w=.1618e4ff-51ab-499c-a653-7606f2825767@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
 <c6WoSzZK6rgiOJwmPYTwCQk1ZIJr31CKXhjP7oD2GI4=.0526ba79-a228-4d58-9911-06315892f713@github.com>
 <eFGT4ltuYb7Rs4hf5QcNaqf4klAl1ilxfjETsPv9A8w=.1618e4ff-51ab-499c-a653-7606f2825767@github.com>
Message-ID: <Pr4UBkH4oAvM5KnB-W7FkPLVb3F78qsmQDK2XdNISE0=.f4a6ca39-d545-429d-8cc5-bee7ee52e2cb@github.com>

On Fri, 8 Dec 2023 06:30:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/event/SelectionEvent.java line 38:
>> 
>>> 36: public class SelectionEvent extends Event {
>>> 37: 
>>> 38:     public int count;
>> 
>> It could also be interesting to provide the `timeout` that was given to the selection operation.
>
>> It could also be interesting to provide the `timeout` that was given to the selection operation.
> 
> I've tried to work through issues, esp. around selector spinning, and being able to distinguish select from selectNow is important for all of them, so yes, the timeout is needed or else no emit when the timeout == 0 as that's the case you have to filter out when troubleshooting.

I've added filtering of selectNow(), and an event is emitted if there is a timeout independent of the threshold.  The duration should roughly equal the timout in that case.  I added more test cases to cover those two changes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1425744977

From tprinzing at openjdk.org  Wed Dec 13 18:42:44 2023
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Wed, 13 Dec 2023 18:42:44 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v2]
In-Reply-To: <ncJXeymS_uhVivLPakDv7P5mmuhCa73sjrNsHCgvboc=.8660cab0-0489-457b-8b0d-4c74d33109cf@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
 <TpBvd-lDCVnncyvaWYbIRkYDAO9UWGIcTOCGp2dtVfs=.a45f3fd4-1a67-4646-b7a2-84a6592e2f8a@github.com>
 <ncJXeymS_uhVivLPakDv7P5mmuhCa73sjrNsHCgvboc=.8660cab0-0489-457b-8b0d-4c74d33109cf@github.com>
Message-ID: <OmGx2lIlcXGn2UhLWZOQWJ_SQ1CFYK4n9qFzMoOFHG0=.592baa58-f726-45ab-bc9b-c31a0d7d0308@github.com>

On Thu, 23 Nov 2023 11:18:45 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> src/jdk.jfr/share/classes/jdk/jfr/events/SelectionEvent.java line 43:
>> 
>>> 41: 
>>> 42:     @Label("Selection Count")
>>> 43:     @Description("Number of channels selected")
>> 
>> I suspect you'll need to rename this event to something like "SelectorSelect" as "Selection" could be anything.
>> 
>> We'll to find a better name for the field and the label too. There are two forms of selection operations. One form operates on a selected-key set where the select/selectNow methods returns the number of keys aded to the Selector's ready set. The other form performs an action on each selected key. I'll try to come up a suggestions for the names, I suspect a label "number of channels ready for I/O or added to ready set" would be the most accurate.
>
> It would also be good if the name reflect that it is related to channels so it won't clash with other events in the future.

I've made the suggested changes.  I changed the "count" field to "selectorKeyCount" which hopefully seems reasonable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1425746321

From dfuchs at openjdk.org  Wed Dec 13 18:57:42 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 13 Dec 2023 18:57:42 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v2]
In-Reply-To: <Pr4UBkH4oAvM5KnB-W7FkPLVb3F78qsmQDK2XdNISE0=.f4a6ca39-d545-429d-8cc5-bee7ee52e2cb@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
 <c6WoSzZK6rgiOJwmPYTwCQk1ZIJr31CKXhjP7oD2GI4=.0526ba79-a228-4d58-9911-06315892f713@github.com>
 <eFGT4ltuYb7Rs4hf5QcNaqf4klAl1ilxfjETsPv9A8w=.1618e4ff-51ab-499c-a653-7606f2825767@github.com>
 <Pr4UBkH4oAvM5KnB-W7FkPLVb3F78qsmQDK2XdNISE0=.f4a6ca39-d545-429d-8cc5-bee7ee52e2cb@github.com>
Message-ID: <Msw6Sl87blgqQYyk5_-tNtbz45NMuS9Xj-XUXMnUaGs=.7a671141-c10b-47ac-a2bb-66f1203fd0cd@github.com>

On Wed, 13 Dec 2023 18:38:11 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>>> It could also be interesting to provide the `timeout` that was given to the selection operation.
>> 
>> I've tried to work through issues, esp. around selector spinning, and being able to distinguish select from selectNow is important for all of them, so yes, the timeout is needed or else no emit when the timeout == 0 as that's the case you have to filter out when troubleshooting.
>
> I've added filtering of selectNow(), and an event is emitted if there is a timeout independent of the threshold.  The duration should roughly equal the timout in that case.  I added more test cases to cover those two changes.

The select call may also exit early with 0 key selected if it was woken up by a call to Selector::wakeup and this is not necessarily indicative of an issue in the API. We use this facility a lot in the HttpClient as we also use the selector thread as a timer thread.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1425760691

From dfuchs at openjdk.org  Wed Dec 13 18:57:49 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 13 Dec 2023 18:57:49 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v2]
In-Reply-To: <ykUHh71hzDHZPZl4_Pp0ZUC94c0HZeXiqu0FDY9OkSI=.9d98a8b1-8b46-45a7-b799-715fa3d7d0fe@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
 <ykUHh71hzDHZPZl4_Pp0ZUC94c0HZeXiqu0FDY9OkSI=.9d98a8b1-8b46-45a7-b799-715fa3d7d0fe@github.com>
Message-ID: <cllaSnL5ysKqFUGUVec3sz3WR8tuQUgy0YhKYhCsq4A=.72d15d51-a7ab-4441-8ca8-14e9e773f42e@github.com>

On Wed, 13 Dec 2023 18:38:09 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Added mirror event with static methods: jdk.internal.event.SelectionEvent that provides the duration of select calls and the count of how many keys are available.
>> 
>> Emit the event from SelectorImpl::lockAndDoSelect
>> 
>> Test at jdk.jfr.event.io.TestSelectionEvents
>
> Tim Prinzing has updated the pull request with a new target base 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:
> 
>  - Change event generation:
>    
>    - selectNow is filtered out
>    - select that times out is always sent
>    - select without timeout uses duration test
>  - rename event to SelectorSelect, field to selectionKeyCount.
>  - Merge branch 'master' into JDK-8310994
>  - remove trailing whitespace
>  - event logic outside of the lock, selector in try block
>  - remove unused import
>  - fix TestConfigure failure
>  - add event defaults
>  - Merge branch 'master' into JDK-8310994
>  - minor test cleanup
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/ddad6141...2f7dafd8

src/java.base/share/classes/jdk/internal/event/SelectorSelectEvent.java line 41:

> 39: public class SelectorSelectEvent extends Event {
> 40: 
> 41:     public int selectionKeyCount;

I still believe we should record the timeout parameter in the event.

src/jdk.jfr/share/classes/jdk/jfr/events/SelectorSelectEvent.java line 44:

> 42:     @Label("SelectionKey Count")
> 43:     @Description("Number of channels ready for I/O or added to ready set")
> 44:     public int selectionKeyCount;

same here

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1425754281
PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1425755618

From naoto at openjdk.org  Wed Dec 13 19:00:52 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 13 Dec 2023 19:00:52 GMT
Subject: RFR: 8320919: Clarify Locale related system properties [v5]
In-Reply-To: <IruGxIK9DXnXFDANt1y4sCMJEGZh1PTOKhOWZZxJEdc=.77092e02-fb4f-4c9e-8d53-0fa0cf3bae7d@github.com>
References: <IruGxIK9DXnXFDANt1y4sCMJEGZh1PTOKhOWZZxJEdc=.77092e02-fb4f-4c9e-8d53-0fa0cf3bae7d@github.com>
Message-ID: <iSzKhtqd-n0z1KroMxDdCGkdyzx-WFpbTnHCkGbdJcY=.48f2574f-1a08-415d-bdab-e699ee6a465d@github.com>

> This is a doc change to clarify what the `Default Locale` is, and how it is established during the system startup using the system properties. Those locale-related system properties have existed since the early days of Java, but have never been publicly documented before. It is also the intention of this PR to clarify those system properties and how they are overridden. A corresponding CSR has been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Reflects review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17065/files
  - new: https://git.openjdk.org/jdk/pull/17065/files/60b891a2..48466817

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17065&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17065&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17065.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17065/head:pull/17065

PR: https://git.openjdk.org/jdk/pull/17065

From naoto at openjdk.org  Wed Dec 13 19:00:55 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 13 Dec 2023 19:00:55 GMT
Subject: RFR: 8320919: Clarify Locale related system properties [v4]
In-Reply-To: <Wnj-AwdLTHcs8VPJfcGhSDM05BVrtlB6y8iNEjQT6oo=.3eef183c-1259-42e7-a58d-0da8aa15a417@github.com>
References: <IruGxIK9DXnXFDANt1y4sCMJEGZh1PTOKhOWZZxJEdc=.77092e02-fb4f-4c9e-8d53-0fa0cf3bae7d@github.com>
 <fKq7_3dDkmdejZLwDy4YZ6WLT_qMs8cAF_yDn2XT8_E=.3421ea19-e468-42e3-90be-cea266b4adbb@github.com>
 <Wnj-AwdLTHcs8VPJfcGhSDM05BVrtlB6y8iNEjQT6oo=.3eef183c-1259-42e7-a58d-0da8aa15a417@github.com>
Message-ID: <u8A2uelXJ5zddcqnPAXg7ves92FOv8MddZtXxs2Xsc4=.e4eb6cc6-1a16-4ecc-a4a2-c565dc4ed27e@github.com>

On Wed, 13 Dec 2023 18:33:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflects review comments
>
> src/java.base/share/classes/java/util/Locale.java line 317:
> 
>> 315:  * If the default Locale is changed with {@link #setDefault(Locale)}, the corresponding
>> 316:  * system properties are not altered. It is not recommended that applications read
>> 317:  * these system properties and parse/interpret them as their values may be out of date.
> 
> "parse/interpret" -> "parse or interpret".

Thanks, Roger. Modified.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17065#discussion_r1425763234

From tprinzing at openjdk.org  Wed Dec 13 19:01:49 2023
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Wed, 13 Dec 2023 19:01:49 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v2]
In-Reply-To: <cllaSnL5ysKqFUGUVec3sz3WR8tuQUgy0YhKYhCsq4A=.72d15d51-a7ab-4441-8ca8-14e9e773f42e@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
 <ykUHh71hzDHZPZl4_Pp0ZUC94c0HZeXiqu0FDY9OkSI=.9d98a8b1-8b46-45a7-b799-715fa3d7d0fe@github.com>
 <cllaSnL5ysKqFUGUVec3sz3WR8tuQUgy0YhKYhCsq4A=.72d15d51-a7ab-4441-8ca8-14e9e773f42e@github.com>
Message-ID: <QmtnxQPzjTYtCTEi9nQnQdCpoVwupl_5aCy6hMqks1w=.6f01b41e-eb22-463c-9189-39194dbd9aa2@github.com>

On Wed, 13 Dec 2023 18:47:50 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Tim Prinzing has updated the pull request with a new target base 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:
>> 
>>  - Change event generation:
>>    
>>    - selectNow is filtered out
>>    - select that times out is always sent
>>    - select without timeout uses duration test
>>  - rename event to SelectorSelect, field to selectionKeyCount.
>>  - Merge branch 'master' into JDK-8310994
>>  - remove trailing whitespace
>>  - event logic outside of the lock, selector in try block
>>  - remove unused import
>>  - fix TestConfigure failure
>>  - add event defaults
>>  - Merge branch 'master' into JDK-8310994
>>  - minor test cleanup
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/f9910028...2f7dafd8
>
> src/java.base/share/classes/jdk/internal/event/SelectorSelectEvent.java line 41:
> 
>> 39: public class SelectorSelectEvent extends Event {
>> 40: 
>> 41:     public int selectionKeyCount;
> 
> I still believe we should record the timeout parameter in the event.

Good point about the wakeup.  I'll add the field.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1425765145

From stsypanov at openjdk.org  Wed Dec 13 19:31:46 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 13 Dec 2023 19:31:46 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v13]
In-Reply-To: <YBNZbkzA40qmeLhJvjxKEzc6TqkxK2AV7uGxi2G2RoA=.01841c04-4b96-4ba3-ba12-f9ba3c543d8f@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <9dHae2TsRpC75QWWLwT8zj5wgU3sNE9BruMOsO9-lGg=.2425bed0-13f8-496d-903c-702953337207@github.com>
 <wUG3o0T-exRTP0N363aDkzV0-5XN3XVWmNHKx2SMZXg=.ccc4faf2-2de4-447c-a57a-92a24fe28bf0@github.com>
 <ys78iaetW5O84JUvHY7R5E1GspSEIuvsUUwRI0gVoBs=.6a1916e0-57dc-409d-983b-70f8ca2b6d6e@github.com>
 <WAylJsCs3L767CCjDmqFVkwM7z3ZAw2_HXjvXWt-m3k=.1d8ac7ac-4e01-42a4-a977-8e37a73aaf54@github.com>
 <_miSXEzpwwc2L6PItAeDnmHMJcj--IWC-rCHZBQAWo0=.bc6646a8-1600-4ecd-9268-6de6dfc25d65@github.com>
 <9FZlGCKRceiNKLBtz1LASHzLP1icDBftgwEWqxCx7Dg=.92be3d2e-7aef-40a0-a508-1e6b47fac529@github.com>
 <YBNZbkzA40qmeLhJvjxKEzc6TqkxK2AV7uGxi2G2RoA=.01841c04-4b96-4ba3-ba12-f9ba3c543d8f@github.com>
Message-ID: <jjODBFZ6iTDHTOYNmQkXXCSYXUwvXZATAbuwPaGZoys=.a45faac1-0b0f-4919-82ad-4a84c03db321@github.com>

On Wed, 13 Dec 2023 16:46:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> It doesn't make sense here to add a new package com.sun.io for a single method class. This PR does not need to introduce any new classes at this point. I think this PR needs to focus solely on BIS.
>> 
>> So you actually prefer copy-and-paste and duplicated code?
>> 
>>> On the surface, transferTo reads to EOF so there are no more bytes to read from the underlying stream or byte[]. Adding a "growing file" and it breaks assumptions. So it's an important discussion point in this topic.
>> 
>> I still do not see what this has to do with the *actual* changes proposed by this PR. Can you please provide an example in what situation the *actual* changes proposed by this PR will fail in that case, while the original code will succeed?
>
>> > It doesn't make sense here to add a new package com.sun.io for a single method class. This PR does not need to introduce any new classes at this point. I think this PR needs to focus solely on BIS.
>> 
>> So you actually prefer copy-and-paste and duplicated code?
> 
> It's not important at this time, the starting point is to decide if BIS.transferTo should be changed or not. It does shared some concerns with BAIS but the set of concerns for both is not identical.

> the underlying byte[] can outlive the BAIS object

I guess this is true only for target OutputStreams incorporating another one or OutputStreams deliberately made malicious. For classes enumerated in IOStreams this is not a case, I think.

>  For BIS, transferTo may return a positive value more than once because the underlying stream is growing

As of this I don't understand how it affects the change. The JavaDoc of InputStream.transferTo() explicitly says that the method ` Reads all bytes from this input stream and writes the bytes to the given output stream` and I guess all the data is read only once

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1425794463

From bpb at openjdk.org  Wed Dec 13 19:43:20 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 13 Dec 2023 19:43:20 GMT
Subject: RFR: 8259637: java.io.File.getCanonicalPath() returns different values
 for same path
Message-ID: <uClvCZ0hgjGS7z2k81iXiC5PJ1VbvzJwvvnlPd-nkxE=.da23f584-9126-41c7-b8ab-e86e1680127f@github.com>

Modify the `collapse()` function to remove each instance of ".." when the path is absolute and there is no preceding name.

-------------

Commit messages:
 - 8259637: java.io.File.getCanonicalPath() returns different values for same path

Changes: https://git.openjdk.org/jdk/pull/17089/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17089&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8259637
  Stats: 44 lines in 2 files changed: 37 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/17089.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17089/head:pull/17089

PR: https://git.openjdk.org/jdk/pull/17089

From bpb at openjdk.org  Wed Dec 13 19:43:20 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 13 Dec 2023 19:43:20 GMT
Subject: RFR: 8259637: java.io.File.getCanonicalPath() returns different
 values for same path
In-Reply-To: <uClvCZ0hgjGS7z2k81iXiC5PJ1VbvzJwvvnlPd-nkxE=.da23f584-9126-41c7-b8ab-e86e1680127f@github.com>
References: <uClvCZ0hgjGS7z2k81iXiC5PJ1VbvzJwvvnlPd-nkxE=.da23f584-9126-41c7-b8ab-e86e1680127f@github.com>
Message-ID: <sCu0AlXNx3x1YGeYmxvQd_2vIHtOWSklWYexDtnWvJw=.64de3a42-ef50-457e-9fda-e19d84547386@github.com>

On Wed, 13 Dec 2023 19:37:15 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify the `collapse()` function to remove each instance of ".." when the path is absolute and there is no preceding name.

Without this change the updated test fails as:

FAILED     GetCanonicalPath::goodPathsUnix '[3] /../../../../../a/../../b/c, /b/c'
org.opentest4j.AssertionFailedError: expected: </b/c> but was: </../b/c>

FAILED     GetCanonicalPath::goodPathsUnix '[5] /../../../../../a/../../../../b/c, /b/c'
org.opentest4j.AssertionFailedError: expected: </b/c> but was: </../b/c>

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17089#issuecomment-1854591185

From acobbs at openjdk.org  Wed Dec 13 20:10:56 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 13 Dec 2023 20:10:56 GMT
Subject: RFR: 8322027: One XMLStreamException constructor fails to initialize
 cause
Message-ID: <u7DJBcsIFuCxTDzXam9n5PViiYT-JBphdRh_2MAFVPk=.94e7ef25-1089-41e9-9606-b6820a71527f@github.com>

One of the three `XMLStreamException` constructors that takes a `Throwable` fails to pass it to the superclass constructor.

This simple patch fixes that omission.

-------------

Commit messages:
 - Propagate cause to superclass constructor in XMLStreamException constructor.

Changes: https://git.openjdk.org/jdk/pull/17090/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17090&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322027
  Stats: 63 lines in 2 files changed: 62 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17090.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17090/head:pull/17090

PR: https://git.openjdk.org/jdk/pull/17090

From jlu at openjdk.org  Wed Dec 13 20:55:38 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 13 Dec 2023 20:55:38 GMT
Subject: RFR: JDK-8319626: Override toString() for ZipFile [v8]
In-Reply-To: <__6rDvcUmyOqJxKsGh8f5m0Nyhvcan0ou9aWOUJd040=.8500b0ba-c3c4-481a-a473-2d09a86341e5@github.com>
References: <UEVJDXC8Cs_RSBUEsWgmq8SPvI-T4LSydbPKr8u29iA=.fdce7d47-87a8-42ba-9cd4-119bf9023ad9@github.com>
 <EEHjubpyde8VF6w4shuUjROZWwIabcGCI9DYMva_gy8=.afba4e81-0f88-4530-8e32-23ca7f949157@github.com>
 <__6rDvcUmyOqJxKsGh8f5m0Nyhvcan0ou9aWOUJd040=.8500b0ba-c3c4-481a-a473-2d09a86341e5@github.com>
Message-ID: <V8jjKWaLbV3j3NxQDR4bbcR80EPAo-mREFYNNrKePWc=.76e4f20f-3f76-451d-8dec-9b864ce7cff4@github.com>

On Wed, 13 Dec 2023 18:35:40 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> I'm seeing the `ZipSourceCache` fail on GHA on `windows-x64`:

Hi Eirik,

Please let me know if I'm misunderstanding,

But this change hasn't been integrated into the master branch yet. Your linked PR does not appear to contain the contents of this change either. So I would expect that GHA error is unrelated to this change.  I have re-ran the test from the GHA failure (against this PR's contents) on various platforms and all appear to pass for me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16643#issuecomment-1854685052

From joehw at openjdk.org  Wed Dec 13 20:58:46 2023
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 13 Dec 2023 20:58:46 GMT
Subject: RFR: 8320279: Link issues in java.xml module-info.java
Message-ID: <d_p9B3k9VdDOteoHShICJRM1QHJMXgy1VxrchBEam8s=.fddcb7a4-f96f-4bc0-b10f-4d104d89c973@github.com>

Doc-only change: fix incorrect links in module-info.java and StAX factories.

-------------

Commit messages:
 - 8320279: Link issues in java.xml module-info.java

Changes: https://git.openjdk.org/jdk/pull/17093/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17093&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8320279
  Stats: 20 lines in 5 files changed: 0 ins; 0 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/17093.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17093/head:pull/17093

PR: https://git.openjdk.org/jdk/pull/17093

From duke at openjdk.org  Wed Dec 13 21:05:40 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 13 Dec 2023 21:05:40 GMT
Subject: RFR: JDK-8319626: Override toString() for ZipFile [v8]
In-Reply-To: <V8jjKWaLbV3j3NxQDR4bbcR80EPAo-mREFYNNrKePWc=.76e4f20f-3f76-451d-8dec-9b864ce7cff4@github.com>
References: <UEVJDXC8Cs_RSBUEsWgmq8SPvI-T4LSydbPKr8u29iA=.fdce7d47-87a8-42ba-9cd4-119bf9023ad9@github.com>
 <EEHjubpyde8VF6w4shuUjROZWwIabcGCI9DYMva_gy8=.afba4e81-0f88-4530-8e32-23ca7f949157@github.com>
 <__6rDvcUmyOqJxKsGh8f5m0Nyhvcan0ou9aWOUJd040=.8500b0ba-c3c4-481a-a473-2d09a86341e5@github.com>
 <V8jjKWaLbV3j3NxQDR4bbcR80EPAo-mREFYNNrKePWc=.76e4f20f-3f76-451d-8dec-9b864ce7cff4@github.com>
Message-ID: <-DhTTRb_jBNIiQR36VM4rVd7i_9ExA0QeTPMyVxfLPU=.0b7c28ec-3e18-49d5-a46a-4d1a2e1bdd25@github.com>

On Wed, 13 Dec 2023 20:53:17 GMT, Justin Lu <jlu at openjdk.org> wrote:

> > I'm seeing the `ZipSourceCache` fail on GHA on `windows-x64`:
> 
> Hi Eirik,
> 
> Please let me know if I'm misunderstanding,

I claim `TooManyOpenTabsException` :-) Sorry, this comment was for #16115

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16643#issuecomment-1854696711

From iris at openjdk.org  Wed Dec 13 21:07:38 2023
From: iris at openjdk.org (Iris Clark)
Date: Wed, 13 Dec 2023 21:07:38 GMT
Subject: RFR: 8320279: Link issues in java.xml module-info.java
In-Reply-To: <d_p9B3k9VdDOteoHShICJRM1QHJMXgy1VxrchBEam8s=.fddcb7a4-f96f-4bc0-b10f-4d104d89c973@github.com>
References: <d_p9B3k9VdDOteoHShICJRM1QHJMXgy1VxrchBEam8s=.fddcb7a4-f96f-4bc0-b10f-4d104d89c973@github.com>
Message-ID: <W1nsiWBvYQpIGIsg6QN67qGPe2dMdraxZt0QRkIesPk=.88f9cb0b-d896-476c-99ab-8cdfa97824da@github.com>

On Wed, 13 Dec 2023 20:54:16 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Doc-only change: fix incorrect links in module-info.java and StAX factories.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17093#pullrequestreview-1780486241

From lancea at openjdk.org  Wed Dec 13 21:07:39 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 13 Dec 2023 21:07:39 GMT
Subject: RFR: 8320279: Link issues in java.xml module-info.java
In-Reply-To: <d_p9B3k9VdDOteoHShICJRM1QHJMXgy1VxrchBEam8s=.fddcb7a4-f96f-4bc0-b10f-4d104d89c973@github.com>
References: <d_p9B3k9VdDOteoHShICJRM1QHJMXgy1VxrchBEam8s=.fddcb7a4-f96f-4bc0-b10f-4d104d89c973@github.com>
Message-ID: <fZHXEnpRbZx2ZfIGZCpVg0ix1dHWyXdSksW1av27o_Y=.e57fcde8-8305-4bf6-bc9b-3a5fbbe4935c@github.com>

On Wed, 13 Dec 2023 20:54:16 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Doc-only change: fix incorrect links in module-info.java and StAX factories.

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17093#pullrequestreview-1780488559

From duke at openjdk.org  Wed Dec 13 21:10:53 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 13 Dec 2023 21:10:53 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v11]
In-Reply-To: <lP4u6pT1DnuoHpG4k-_Rjv2Va3IerlXNB357xXyDnBY=.6b127578-0f88-422a-9f05-b991b5b55250@github.com>
References: <l29EQEjJwcckNUGfzuZX_pfqbBcy0MXt2SM4p_dBXRw=.ffde4d8f-e261-4256-bbde-b7aad43ee630@github.com>
 <lP4u6pT1DnuoHpG4k-_Rjv2Va3IerlXNB357xXyDnBY=.6b127578-0f88-422a-9f05-b991b5b55250@github.com>
Message-ID: <oitwZ3sT6PqCG3nXQBTt9XRD3nni8jqEX-uudWHU4Ss=.d872694c-597c-4432-a753-d94447d46c12@github.com>

On Mon, 23 Oct 2023 16:12:45 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update jmh test comments

I noticed the ZipSourceCache test fail on GHA on windows-x64:


FAILED     ZipSourceCache::testKeySourceMapping 'testKeySourceMapping()'
java.nio.file.FileSystemException: 1702471080605-bug8317678.zip: The process cannot access the file because it is being used by another process
	at java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:92)
	at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
	at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108)
	at java.base/sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:273)
	at java.base/sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:109)
	at java.base/java.nio.file.Files.deleteIfExists(Files.java:1191)
	at ZipSourceCache.cleanup(ZipSourceCache.java:65)


On a re-run of the jobs, the test ran green again on the same source. So this seems timing related.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16115#issuecomment-1854702162

From naoto at openjdk.org  Wed Dec 13 21:15:37 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 13 Dec 2023 21:15:37 GMT
Subject: RFR: 8320279: Link issues in java.xml module-info.java
In-Reply-To: <d_p9B3k9VdDOteoHShICJRM1QHJMXgy1VxrchBEam8s=.fddcb7a4-f96f-4bc0-b10f-4d104d89c973@github.com>
References: <d_p9B3k9VdDOteoHShICJRM1QHJMXgy1VxrchBEam8s=.fddcb7a4-f96f-4bc0-b10f-4d104d89c973@github.com>
Message-ID: <NNYaPcQ2-IDi3hShXvZF1kjf_Gz2md-ICJU0o1SH0Jk=.9e2a77e0-ee88-4072-b9d0-1456a76efbcd@github.com>

On Wed, 13 Dec 2023 20:54:16 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Doc-only change: fix incorrect links in module-info.java and StAX factories.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17093#pullrequestreview-1780499321

From joehw at openjdk.org  Wed Dec 13 21:24:39 2023
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 13 Dec 2023 21:24:39 GMT
Subject: RFR: 8322027: One XMLStreamException constructor fails to
 initialize cause
In-Reply-To: <u7DJBcsIFuCxTDzXam9n5PViiYT-JBphdRh_2MAFVPk=.94e7ef25-1089-41e9-9606-b6820a71527f@github.com>
References: <u7DJBcsIFuCxTDzXam9n5PViiYT-JBphdRh_2MAFVPk=.94e7ef25-1089-41e9-9606-b6820a71527f@github.com>
Message-ID: <TjdBZYIV58bAl1U2SGFUEDvGpSuBfxvdnDNBpdBdUvA=.135caf0b-115d-42ac-8391-225dd280e172@github.com>

On Wed, 13 Dec 2023 20:06:03 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> One of the three `XMLStreamException` constructors that takes a `Throwable` fails to pass it to the superclass constructor.
> 
> This simple patch fixes that omission.
> 
> It's worth considering if there is any code out there that is working around this problem already by invoking `initCause()` manually. If so, that code would start throwing an `IllegalStateException` after this change.
> 
> So a more conservative fix would be to just add another constructor taking the same arguments in a different order. But then again that's not much better than just saying "always use initCause() with the broken constructor", i.e., don't change anything.
> 
> Hmm.

Looks good to me. Thanks.

test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamExceptionTest/ExceptionCauseTest.java line 38:

> 36:  * @test
> 37:  * @library /javax/xml/jaxp/libs /javax/xml/jaxp/unittest
> 38:  * @run testng/othervm -DrunSecMngr=true -Djava.security.manager=allow stream.XMLStreamExceptionTest.ExceptionCauseTest

We no longer add this run in new tests as the Security Manager has been deprecated (https://openjdk.org/jeps/411).

-------------

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17090#pullrequestreview-1780507743
PR Review Comment: https://git.openjdk.org/jdk/pull/17090#discussion_r1425895822

From lancea at openjdk.org  Wed Dec 13 21:24:41 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 13 Dec 2023 21:24:41 GMT
Subject: RFR: 8322027: One XMLStreamException constructor fails to
 initialize cause
In-Reply-To: <TjdBZYIV58bAl1U2SGFUEDvGpSuBfxvdnDNBpdBdUvA=.135caf0b-115d-42ac-8391-225dd280e172@github.com>
References: <u7DJBcsIFuCxTDzXam9n5PViiYT-JBphdRh_2MAFVPk=.94e7ef25-1089-41e9-9606-b6820a71527f@github.com>
 <TjdBZYIV58bAl1U2SGFUEDvGpSuBfxvdnDNBpdBdUvA=.135caf0b-115d-42ac-8391-225dd280e172@github.com>
Message-ID: <gxgyhUIJ7Qrbu98zu92VIe-Zsr_jZeGNv2AUJo4e0H0=.7306318c-af1e-4961-98ed-6d3604136135@github.com>

On Wed, 13 Dec 2023 21:19:34 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> One of the three `XMLStreamException` constructors that takes a `Throwable` fails to pass it to the superclass constructor.
>> 
>> This simple patch fixes that omission.
>> 
>> It's worth considering if there is any code out there that is working around this problem already by invoking `initCause()` manually. If so, that code would start throwing an `IllegalStateException` after this change.
>> 
>> So a more conservative fix would be to just add another constructor taking the same arguments in a different order. But then again that's not much better than just saying "always use initCause() with the broken constructor", i.e., don't change anything.
>> 
>> Hmm.
>
> test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamExceptionTest/ExceptionCauseTest.java line 38:
> 
>> 36:  * @test
>> 37:  * @library /javax/xml/jaxp/libs /javax/xml/jaxp/unittest
>> 38:  * @run testng/othervm -DrunSecMngr=true -Djava.security.manager=allow stream.XMLStreamExceptionTest.ExceptionCauseTest
> 
> We no longer add this run in new tests as the Security Manager has been deprecated (https://openjdk.org/jeps/411).

Well, the SM is still technically supported so until we remove it, I would leave the run with SM in

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17090#discussion_r1425898345

From jvernee at openjdk.org  Wed Dec 13 21:27:40 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 13 Dec 2023 21:27:40 GMT
Subject: RFR: 8320919: Clarify Locale related system properties [v5]
In-Reply-To: <EHYMQZ9G-ruEcpO5ugSBZafCvsXCpMktJxrBlCrEFU0=.57ed1953-73d6-44c9-9776-2a3e6db4127b@github.com>
References: <IruGxIK9DXnXFDANt1y4sCMJEGZh1PTOKhOWZZxJEdc=.77092e02-fb4f-4c9e-8d53-0fa0cf3bae7d@github.com>
 <T6amp0e6d8fH2bV2UYXHkXphSgU567xIt1dZWFZq26I=.d1e2cc6b-3094-4100-91d9-b105ac8351ee@github.com>
 <jscui0aN2Uv1aaFWxSp01sut1zKf7OLiS7EcboXEUYU=.790a7407-f595-415d-9dc9-561801a6e7db@github.com>
 <EHYMQZ9G-ruEcpO5ugSBZafCvsXCpMktJxrBlCrEFU0=.57ed1953-73d6-44c9-9776-2a3e6db4127b@github.com>
Message-ID: <A0It5MlTTSRRWkLP6UKFTA29nIKR2P_EHFfgkXIZDk4=.3e62e641-1d3e-412e-af73-a01e633f1c2e@github.com>

On Wed, 13 Dec 2023 05:19:25 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> The `-D` command-line option is not a part of the Java SE specification but an allowed behavior, so it may not be a normative description here.
>
> Right, I suggested putting that in parentheses. Historically we haven't been very formal about distinguishing between normative (Java SE) specifications and informative text that talks about implementations. In this case I felt that enclosing the text in parentheses and also adding hedging words ("typically") made it clear that this text isn't normative.

FWIW, for the FFM API, we describe the `--enable-native-access` command line flag in a separate `@implNote`: https://github.com/openjdk/jdk/blob/cf948548c390c42ca63525d41a9d63ff31349c3a/src/java.base/share/classes/java/lang/foreign/package-info.java#L164-L171

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17065#discussion_r1425900844

From acobbs at openjdk.org  Wed Dec 13 21:27:40 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 13 Dec 2023 21:27:40 GMT
Subject: RFR: 8322027: One XMLStreamException constructor fails to
 initialize cause
In-Reply-To: <u7DJBcsIFuCxTDzXam9n5PViiYT-JBphdRh_2MAFVPk=.94e7ef25-1089-41e9-9606-b6820a71527f@github.com>
References: <u7DJBcsIFuCxTDzXam9n5PViiYT-JBphdRh_2MAFVPk=.94e7ef25-1089-41e9-9606-b6820a71527f@github.com>
Message-ID: <xf8pPEe5y0FMqqd49evp9MaMOwcqf7_9WFn40tzoVMU=.60d5f3d1-18f5-4405-aeb6-b953f0b2e68b@github.com>

On Wed, 13 Dec 2023 20:06:03 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> One of the three `XMLStreamException` constructors that takes a `Throwable` fails to pass it to the superclass constructor.
> 
> This simple patch fixes that omission.
> 
> It's worth considering if there is any code out there that is working around this problem already by invoking `initCause()` manually. If so, that code would start throwing an `IllegalStateException` after this change.
> 
> So a more conservative fix would be to just add another constructor taking the same arguments in a different order. But then again that's not much better than just saying "always use initCause() with the broken constructor", i.e., don't change anything.
> 
> Hmm.

After filing this PR, I had some second thoughts and added them to the summary but by then it was too late for the `core-libs-dev` email, so I'll repeat here in case anyone has some comments:

> It's worth considering if there is any code out there that is working around this problem already by invoking `initCause()` manually. If so, that code would start throwing an `IllegalStateException` after this change.
> 
> So a more conservative fix would be to just add another constructor taking the same arguments in a different order. But then again that's not much better than just saying "always use `initCause()` with the broken constructor", i.e., don't change anything.
> 
> Hmm.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17090#issuecomment-1854723627

From rriggs at openjdk.org  Wed Dec 13 21:44:47 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Dec 2023 21:44:47 GMT
Subject: RFR: 8322018: Test
 java/lang/String/CompactString/MaxSizeUTF16String.java fails with -Xcomp
Message-ID: <7qbrvSGT9oZvj9tjokk17uxT5_032AY_GjyrD_QGa_g=.e6a674ea-f4f6-49b0-8ece-2910c4531bc4@github.com>

The test java/lang/String/CompactString/MaxSizeUTF16String.java fails when run with -Xcomp.

Both the java implementation and the intrinsic for StringUTF16.toBytes() allocate memory for a copy of the string.
The java implementation of `toBytes()` throws an exception with a message in terms of length of the string.
The intrinsic uses a generic message when allocating a byte array that is too large for the implementation.

Test should accept either message on the OOME exception, the message is an implementation detail and should reflect the cause of the error and not be confused with a general out of java heap message.

-------------

Commit messages:
 - Handle the case of insufficient heap distinctly from the wrong message
 - 8322018: Test java/lang/String/CompactString/MaxSizeUTF16String.java fails with -Xcomp

Changes: https://git.openjdk.org/jdk/pull/17095/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17095&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322018
  Stats: 19 lines in 1 file changed: 14 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/17095.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17095/head:pull/17095

PR: https://git.openjdk.org/jdk/pull/17095

From naoto at openjdk.org  Wed Dec 13 21:52:40 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 13 Dec 2023 21:52:40 GMT
Subject: RFR: 8320919: Clarify Locale related system properties [v5]
In-Reply-To: <A0It5MlTTSRRWkLP6UKFTA29nIKR2P_EHFfgkXIZDk4=.3e62e641-1d3e-412e-af73-a01e633f1c2e@github.com>
References: <IruGxIK9DXnXFDANt1y4sCMJEGZh1PTOKhOWZZxJEdc=.77092e02-fb4f-4c9e-8d53-0fa0cf3bae7d@github.com>
 <T6amp0e6d8fH2bV2UYXHkXphSgU567xIt1dZWFZq26I=.d1e2cc6b-3094-4100-91d9-b105ac8351ee@github.com>
 <jscui0aN2Uv1aaFWxSp01sut1zKf7OLiS7EcboXEUYU=.790a7407-f595-415d-9dc9-561801a6e7db@github.com>
 <EHYMQZ9G-ruEcpO5ugSBZafCvsXCpMktJxrBlCrEFU0=.57ed1953-73d6-44c9-9776-2a3e6db4127b@github.com>
 <A0It5MlTTSRRWkLP6UKFTA29nIKR2P_EHFfgkXIZDk4=.3e62e641-1d3e-412e-af73-a01e633f1c2e@github.com>
Message-ID: <3nM28gbA8-SdJwSygIZ79dP1ooT-4ENtJFEinv463E8=.901b54cd-f192-4638-8fc1-0549ed640579@github.com>

On Wed, 13 Dec 2023 21:25:13 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Right, I suggested putting that in parentheses. Historically we haven't been very formal about distinguishing between normative (Java SE) specifications and informative text that talks about implementations. In this case I felt that enclosing the text in parentheses and also adding hedging words ("typically") made it clear that this text isn't normative.
>
> FWIW, for the FFM API, we describe the `--enable-native-access` command line flag in a separate `@implNote`: https://github.com/openjdk/jdk/blob/cf948548c390c42ca63525d41a9d63ff31349c3a/src/java.base/share/classes/java/lang/foreign/package-info.java#L164-L171

Thanks for the suggestion, Jorn. I tried embedding `@implNote` within the ordered list, but looks like it is not allowed. It would be nice if we could use it inside a list, but since it is about overriding the property values, I would rather not have the description apart from that list item.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17065#discussion_r1425921350

From vromero at openjdk.org  Wed Dec 13 22:13:39 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 13 Dec 2023 22:13:39 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 [v7]
In-Reply-To: <8kc1FcJ-ilYErhHEJRu9S_64FWwg8lI5kZfTPDEeHYA=.7b75a759-2927-4434-8ec6-24f127f01a7e@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
 <UHA4xz5Ute6D_dTNMO4Ki4Jw7I3U7i6D5idwqPiuQ_w=.d44fe606-37f4-4451-9674-a0b1fa823647@github.com>
 <8kc1FcJ-ilYErhHEJRu9S_64FWwg8lI5kZfTPDEeHYA=.7b75a759-2927-4434-8ec6-24f127f01a7e@github.com>
Message-ID: <zaeD9vsUm7DrpjdioVFDx8j6XVz13EZ_K6ojksmFucw=.8e34c627-5e83-4783-a3f8-a64daa8198a9@github.com>

On Tue, 12 Dec 2023 22:21:29 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> As the core reflection code will encounter record classes compiled before and after the javac code generation change, if the old behavior can be triggered in javac using `--release $OLD`/`--source $OLD`, that would be helpful to include as part of the testing.

I don't think that the old behavior can be triggered using --release $OLD as fix for https://bugs.openjdk.org/browse/JDK-8292275 was applicable to all targets / sources. But I think I can create a .jcod file with a compact constructor of a record class for which the parameters are not mandated and check that the generic information is correctly retrieved.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17070#issuecomment-1854778693

From tprinzing at openjdk.org  Wed Dec 13 22:20:55 2023
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Wed, 13 Dec 2023 22:20:55 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v3]
In-Reply-To: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
Message-ID: <8lBiUxq1EYaux0j6rOnzmScfwFWfBRbYYT1IwEvSQWQ=.bc31666d-4f00-4ac9-a4f2-242abe231db1@github.com>

> Added mirror event with static methods: jdk.internal.event.SelectionEvent that provides the duration of select calls and the count of how many keys are available.
> 
> Emit the event from SelectorImpl::lockAndDoSelect
> 
> Test at jdk.jfr.event.io.TestSelectionEvents

Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:

  add select timeout field to the event

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16710/files
  - new: https://git.openjdk.org/jdk/pull/16710/files/2f7dafd8..13262293

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16710&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16710&range=01-02

  Stats: 21 lines in 4 files changed: 12 ins; 3 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/16710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16710/head:pull/16710

PR: https://git.openjdk.org/jdk/pull/16710

From achung at openjdk.org  Wed Dec 13 22:26:45 2023
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 13 Dec 2023 22:26:45 GMT
Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update
Message-ID: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>

Translation drop for JDK22 RDP1

-------------

Commit messages:
 - translated files

Changes: https://git.openjdk.org/jdk/pull/17096/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17096&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322041
  Stats: 290 lines in 36 files changed: 166 ins; 15 del; 109 mod
  Patch: https://git.openjdk.org/jdk/pull/17096.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17096/head:pull/17096

PR: https://git.openjdk.org/jdk/pull/17096

From valeh.hajiyev at gmail.com  Wed Dec 13 23:09:19 2023
From: valeh.hajiyev at gmail.com (Valeh Hajiyev)
Date: Thu, 14 Dec 2023 00:09:19 +0100
Subject: Introduce constructor for PriorityQueue with existing collection and
 custom comparator
Message-ID: <CAJXoXUBjq5GeXoNqdBhspvpsPOvT7EXhz6VuZhZVD5=RLOjg4g@mail.gmail.com>

Hi all,

I have raised the following PR, could someone please help me to get it
merged?

https://github.com/openjdk/jdk/pull/17045


*More details:*











*This commit addresses the current limitation in the `PriorityQueue`
implementation, which lacks a constructor to efficiently create a priority
queue with a custom comparator and an existing collection. In order to
create such a queue, we currently need to initialize a new queue with
custom comparator, and after that populate the queue using `addAll()`
method, which in the background calls `add()` method (which takes `O(logn)`
time) for each element of the collection (`n` times).  This is resulting in
an overall time complexity of `O(nlogn)`. ```PriorityQueue<String> pq = new
PriorityQueue<>(customComparator);pq.addAll(existingCollection);```The pull
request introduces a new constructor to streamline this process and reduce
the time complexity to `O(n)`.  If you create the queue above using the new
constructor, the contents of the collection will be copied (which takes
`O(n)` time) and then later  `heapify()` operation (Floyd's algorithm) will
be called once (another `O(n)` time). Overall the operation will be reduced
from `O(nlogn)` to `O(2n)` -> `O(n)` time.```PriorityQueue<String> pq = new
PriorityQueue<>(existingCollection, customComparator);```*

Best regards,
Valeh Hajiyev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20231214/9df2be61/attachment-0001.htm>

From naoto at openjdk.org  Wed Dec 13 23:15:44 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 13 Dec 2023 23:15:44 GMT
Subject: RFR: 8321958: javadoc error: @returns of ZoneRules#isDaylightSavings()
 is incorrect
Message-ID: <2150UeprX2CQ34CmEIROihDODlQMKsuPPv3gB-gjChE=.ff26e4a5-48e8-4153-85dc-6f9a7b554116@github.com>

Small document correction on a return description.

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/17098/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17098&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321958
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17098.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17098/head:pull/17098

PR: https://git.openjdk.org/jdk/pull/17098

From vdyakov at openjdk.org  Wed Dec 13 23:25:37 2023
From: vdyakov at openjdk.org (Victor Dyakov)
Date: Wed, 13 Dec 2023 23:25:37 GMT
Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update
In-Reply-To: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
References: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
Message-ID: <0oGMQEYflrpIHgrQQ60XHXx1jR1fEbqjmZZAD4B8YXk=.dc1a7f14-1d24-4f8d-8471-6846e65863df@github.com>

On Wed, 13 Dec 2023 22:12:48 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Translation drop for JDK22 RDP1

@alexeysemenyukoracle please review jpackage part

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17096#issuecomment-1854847266

From pavel.rappo at oracle.com  Wed Dec 13 23:25:59 2023
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Wed, 13 Dec 2023 23:25:59 +0000
Subject: Introduce constructor for PriorityQueue with existing collection
 and custom comparator
In-Reply-To: <CAJXoXUBjq5GeXoNqdBhspvpsPOvT7EXhz6VuZhZVD5=RLOjg4g@mail.gmail.com>
References: <CAJXoXUBjq5GeXoNqdBhspvpsPOvT7EXhz6VuZhZVD5=RLOjg4g@mail.gmail.com>
Message-ID: <F9804F9F-0726-4E27-AFFC-B05062459AF1@oracle.com>

Sorry, there's a necessary process that a PR must follow. You seem to have signed OCA already. For the rest, see this resource: https://openjdk.org/guide/. In particular, this part: https://openjdk.org/guide/#contributing-to-an-openjdk-project.

-Pavel

> On 13 Dec 2023, at 23:09, Valeh Hajiyev <valeh.hajiyev at gmail.com> wrote:
> 
> Hi all,
> 
> I have raised the following PR, could someone please help me to get it merged?
> 
> https://github.com/openjdk/jdk/pull/17045
> 
> More details:
> 
> This commit addresses the current limitation in the `PriorityQueue` implementation, which lacks a constructor to efficiently create a priority queue with a custom comparator and an existing collection. In order to create such a queue, we currently need to initialize a new queue with custom comparator, and after that populate the queue using `addAll()` method, which in the background calls `add()` method (which takes `O(logn)` time) for each element of the collection (`n` times).  This is resulting in an overall time complexity of `O(nlogn)`. 
> 
> ```
> PriorityQueue<String> pq = new PriorityQueue<>(customComparator);
> pq.addAll(existingCollection);
> ```
> 
> The pull request introduces a new constructor to streamline this process and reduce the time complexity to `O(n)`.  If you create the queue above using the new constructor, the contents of the collection will be copied (which takes `O(n)` time) and then later  `heapify()` operation (Floyd's algorithm) will be called once (another `O(n)` time). Overall the operation will be reduced from `O(nlogn)` to `O(2n)` -> `O(n)` time.
> 
> ```
> PriorityQueue<String> pq = new PriorityQueue<>(existingCollection, customComparator);
> ```
> 
> Best regards,
> Valeh Hajiyev
> 


From achung at openjdk.org  Wed Dec 13 23:34:37 2023
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 13 Dec 2023 23:34:37 GMT
Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update
In-Reply-To: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
References: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
Message-ID: <03lwg8mSWD_UyU_XMYspZO9EzplluKXuLnsIYbtVCw8=.99fca7b7-98d3-4643-be9c-01983a3b2772@github.com>

On Wed, 13 Dec 2023 22:12:48 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Translation drop for JDK22 RDP1

@JoeWang-Java can u review the xml changes?

@jonathan-gibbons can u review the compiler changes?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17096#issuecomment-1854853944
PR Comment: https://git.openjdk.org/jdk/pull/17096#issuecomment-1854854368

From valeh.hajiyev at gmail.com  Wed Dec 13 23:37:58 2023
From: valeh.hajiyev at gmail.com (Valeh Hajiyev)
Date: Thu, 14 Dec 2023 00:37:58 +0100
Subject: Introduce constructor for PriorityQueue with existing collection
 and custom comparator
In-Reply-To: <F9804F9F-0726-4E27-AFFC-B05062459AF1@oracle.com>
References: <CAJXoXUBjq5GeXoNqdBhspvpsPOvT7EXhz6VuZhZVD5=RLOjg4g@mail.gmail.com>
 <F9804F9F-0726-4E27-AFFC-B05062459AF1@oracle.com>
Message-ID: <CAJXoXUBzNW94rcOzzOj5x3uxAy1y96=BBRu+OeEcX964DUWcdA@mail.gmail.com>

Hi Pavel,

Thanks for the reply. If I understand correctly, I need this change to be
discussed in one of the mailing lists there, so that someone would sponsor
me to create a tracking issue in JBS. Do you know which mailing list is the
most relevant for me to propose the change?

Thanks,
Valeh

On Thu, Dec 14, 2023 at 12:26?AM Pavel Rappo <pavel.rappo at oracle.com> wrote:

> Sorry, there's a necessary process that a PR must follow. You seem to have
> signed OCA already. For the rest, see this resource:
> https://openjdk.org/guide/. In particular, this part:
> https://openjdk.org/guide/#contributing-to-an-openjdk-project.
>
> -Pavel
>
> > On 13 Dec 2023, at 23:09, Valeh Hajiyev <valeh.hajiyev at gmail.com> wrote:
> >
> > Hi all,
> >
> > I have raised the following PR, could someone please help me to get it
> merged?
> >
> > https://github.com/openjdk/jdk/pull/17045
> >
> > More details:
> >
> > This commit addresses the current limitation in the `PriorityQueue`
> implementation, which lacks a constructor to efficiently create a priority
> queue with a custom comparator and an existing collection. In order to
> create such a queue, we currently need to initialize a new queue with
> custom comparator, and after that populate the queue using `addAll()`
> method, which in the background calls `add()` method (which takes `O(logn)`
> time) for each element of the collection (`n` times).  This is resulting in
> an overall time complexity of `O(nlogn)`.
> >
> > ```
> > PriorityQueue<String> pq = new PriorityQueue<>(customComparator);
> > pq.addAll(existingCollection);
> > ```
> >
> > The pull request introduces a new constructor to streamline this process
> and reduce the time complexity to `O(n)`.  If you create the queue above
> using the new constructor, the contents of the collection will be copied
> (which takes `O(n)` time) and then later  `heapify()` operation (Floyd's
> algorithm) will be called once (another `O(n)` time). Overall the operation
> will be reduced from `O(nlogn)` to `O(2n)` -> `O(n)` time.
> >
> > ```
> > PriorityQueue<String> pq = new PriorityQueue<>(existingCollection,
> customComparator);
> > ```
> >
> > Best regards,
> > Valeh Hajiyev
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20231214/5e574d3e/attachment.htm>

From jlu at openjdk.org  Wed Dec 13 23:56:37 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 13 Dec 2023 23:56:37 GMT
Subject: RFR: 8321958: javadoc error: @returns of
 ZoneRules#isDaylightSavings() is incorrect
In-Reply-To: <2150UeprX2CQ34CmEIROihDODlQMKsuPPv3gB-gjChE=.ff26e4a5-48e8-4153-85dc-6f9a7b554116@github.com>
References: <2150UeprX2CQ34CmEIROihDODlQMKsuPPv3gB-gjChE=.ff26e4a5-48e8-4153-85dc-6f9a7b554116@github.com>
Message-ID: <NTY26H_0RBcJE0QO63ytswLGxGwjFM3IYKoxR3LZVHw=.5c1cdc2b-f216-4ce1-b6b9-43db0586e624@github.com>

On Wed, 13 Dec 2023 23:10:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Small document correction on a return description.

Marked as reviewed by jlu (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17098#pullrequestreview-1780672305

From almatvee at openjdk.org  Thu Dec 14 00:39:39 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 14 Dec 2023 00:39:39 GMT
Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update
In-Reply-To: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
References: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
Message-ID: <vaylowtWRfhbYxAQD5dvyZLrtomUTsW3v5IcUjnULRE=.d2a5e01d-b2e8-49e0-b9b5-b79bcea89603@github.com>

On Wed, 13 Dec 2023 22:12:48 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Translation drop for JDK22 RDP1

jpackage part looks fine.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17096#pullrequestreview-1780705685

From vromero at openjdk.org  Thu Dec 14 03:52:19 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 14 Dec 2023 03:52:19 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 [v8]
In-Reply-To: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
Message-ID: <upX7KGE0NEDYf4PZ9A7RUvf3_WJeTVaWiw7V-ce0u_o=.26fdba3b-dab4-47ec-9f79-b0927ac33928@github.com>

> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  addressing review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17070/files
  - new: https://git.openjdk.org/jdk/pull/17070/files/e48c7989..89032d47

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=06-07

  Stats: 278 lines in 3 files changed: 269 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/17070.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17070/head:pull/17070

PR: https://git.openjdk.org/jdk/pull/17070

From vromero at openjdk.org  Thu Dec 14 03:56:11 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 14 Dec 2023 03:56:11 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 [v9]
In-Reply-To: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
Message-ID: <9vvYEZjv8zKpu6I8TyBP2vg9vz9V4fgLjXYKgpom3uA=.fc14a299-145a-429d-bf6c-d382af05f398@github.com>

> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  adding a comment to the test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17070/files
  - new: https://git.openjdk.org/jdk/pull/17070/files/89032d47..03ecb887

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=07-08

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17070.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17070/head:pull/17070

PR: https://git.openjdk.org/jdk/pull/17070

From vromero at openjdk.org  Thu Dec 14 04:00:58 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 14 Dec 2023 04:00:58 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 [v10]
In-Reply-To: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
Message-ID: <dlqD_1CkX1z3xkuRCTaXPWBbeMx5Ey1l5GsHIC36sEY=.086ee49b-8506-41e0-b4db-c988eb4f91a7@github.com>

> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  adding comment to jcod file

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17070/files
  - new: https://git.openjdk.org/jdk/pull/17070/files/03ecb887..f6e837d3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=08-09

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17070.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17070/head:pull/17070

PR: https://git.openjdk.org/jdk/pull/17070

From vromero at openjdk.org  Thu Dec 14 04:01:00 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 14 Dec 2023 04:01:00 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 [v9]
In-Reply-To: <9vvYEZjv8zKpu6I8TyBP2vg9vz9V4fgLjXYKgpom3uA=.fc14a299-145a-429d-bf6c-d382af05f398@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
 <9vvYEZjv8zKpu6I8TyBP2vg9vz9V4fgLjXYKgpom3uA=.fc14a299-145a-429d-bf6c-d382af05f398@github.com>
Message-ID: <tMpLsgXL-ga7sMfSgt-qTnfZfmsjktlgYaBqfakI7nk=.d47d97a0-497a-4fd7-a56c-b5dec02fdbdb@github.com>

On Thu, 14 Dec 2023 03:56:11 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding a comment to the test

I have uploaded a few commits addressing the review comments, thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17070#issuecomment-1855089636

From dholmes at openjdk.org  Thu Dec 14 05:51:45 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 14 Dec 2023 05:51:45 GMT
Subject: RFR: 8322065: Initial nroff manpage generation for JDK 23
Message-ID: <UboOhUcAkH6L4qSOWy_uV5qieIX6IQNBhZxWsIvbLzc=.68cfd313-6718-4a7f-9233-f9fd04269e7a@github.com>

Updated the version to 23-ea and year to 2024.

This initial generation also picks up the unpublished changes from:

- [JDK-8302233](https://bugs.openjdk.org/browse/JDK-8302233) (keytool & jarsigner)
- [JDK-8290702](https://bugs.openjdk.org/browse/JDK-8290702) (javadoc) (JDK 23 backport)
- [JDK-8321384](https://bugs.openjdk.org/browse/JDK-8321384) (javadoc)


In addition this includes the updates for

- [JDK-8309981](https://bugs.openjdk.org/browse/8309981) Remove expired flags in JDK 23

Thanks

-------------

Commit messages:
 - 8322065: Initial nroff manpage generation for JDK 23
 - 8309981: Remove expired flags in JDK 23

Changes: https://git.openjdk.org/jdk/pull/17101/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17101&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322065
  Stats: 216 lines in 29 files changed: 47 ins; 61 del; 108 mod
  Patch: https://git.openjdk.org/jdk/pull/17101.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17101/head:pull/17101

PR: https://git.openjdk.org/jdk/pull/17101

From vsitnikov at openjdk.org  Thu Dec 14 06:15:56 2023
From: vsitnikov at openjdk.org (Vladimir Sitnikov)
Date: Thu, 14 Dec 2023 06:15:56 GMT
Subject: RFR: 8297632: InputStream.transferTo() method should specify what
 the return value should be when the number of bytes transfered is
 larger than Long.MAX_VALUE [v7]
In-Reply-To: <_9WmGHHPiqNaJ2l5vg1qvYvgj9rTKtnYYLt7Gi2x2uQ=.d56479a0-8948-4f76-9e7a-f9661766a281@github.com>
References: <T38kO1hcz3rhpqOOPYmoPl1TlRORJBifQWtXLl10x8Y=.595338d3-df98-4202-95b5-eda88a4ed0a2@github.com>
 <_9WmGHHPiqNaJ2l5vg1qvYvgj9rTKtnYYLt7Gi2x2uQ=.d56479a0-8948-4f76-9e7a-f9661766a281@github.com>
Message-ID: <9huCKnW7RWabo1GGXTDzXEVpXL3mt31s9BXc5bpQ6_8=.924b4b05-0943-45e0-92d2-fd36042d6495@github.com>

On Fri, 10 Feb 2023 17:38:51 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> `java.io.InputStream::transferTo` could conceivably return a negative value if the count of bytes transferred overflows a `long`. Modify the method to limit the number of bytes transferred to `Long.MAX_VALUE` per invocation.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8297632: Align SequenceInputStream style with other changes in patch

src/java.base/share/classes/java/io/SequenceInputStream.java line 249:

> 247:                         transferred = Math.addExact(transferred, in.transferTo(out));
> 248:                     } catch (ArithmeticException ignore) {
> 249:                         return Long.MAX_VALUE;

@bplb , this looks like a bug to me: once `transferred` reaches `Long.MAX_VALUE` the transfer loop will terminate and the transfer will stop even in the case there are more streams available in the sequence.

I think the proper code should be `transferred = Long.MAX_VALUE` instead of `return Long.MAX_VALUE`.

What do you think?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11403#discussion_r1426217875

From joehw at openjdk.org  Thu Dec 14 07:44:42 2023
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 14 Dec 2023 07:44:42 GMT
Subject: RFR: 8321958: javadoc error: @returns of
 ZoneRules#isDaylightSavings() is incorrect
In-Reply-To: <2150UeprX2CQ34CmEIROihDODlQMKsuPPv3gB-gjChE=.ff26e4a5-48e8-4153-85dc-6f9a7b554116@github.com>
References: <2150UeprX2CQ34CmEIROihDODlQMKsuPPv3gB-gjChE=.ff26e4a5-48e8-4153-85dc-6f9a7b554116@github.com>
Message-ID: <OIYKTP5IHFPGaMphep8lSYBRAMUBZAauxpkOU2ZUA-M=.e1b26fe2-b82c-4ee0-89af-072df3946ae6@github.com>

On Wed, 13 Dec 2023 23:10:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Small document correction on a return description.

Marked as reviewed by joehw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17098#pullrequestreview-1781215288

From joehw at openjdk.org  Thu Dec 14 07:47:49 2023
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 14 Dec 2023 07:47:49 GMT
Subject: Integrated: 8320279: Link issues in java.xml module-info.java
In-Reply-To: <d_p9B3k9VdDOteoHShICJRM1QHJMXgy1VxrchBEam8s=.fddcb7a4-f96f-4bc0-b10f-4d104d89c973@github.com>
References: <d_p9B3k9VdDOteoHShICJRM1QHJMXgy1VxrchBEam8s=.fddcb7a4-f96f-4bc0-b10f-4d104d89c973@github.com>
Message-ID: <PD0eaASB9BUDqI9zGkGgdk8qDOZ0kLacYFJom5cjwRw=.61d8556a-85ac-49c0-9d21-67a564a2cc32@github.com>

On Wed, 13 Dec 2023 20:54:16 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Doc-only change: fix incorrect links in module-info.java and StAX factories.

This pull request has now been integrated.

Changeset: ddbbd36e
Author:    Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ddbbd36e4b064b9e7433f0a55973d72cd6dbc0d3
Stats:     20 lines in 5 files changed: 0 ins; 0 del; 20 mod

8320279: Link issues in java.xml module-info.java

Reviewed-by: iris, lancea, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/17093

From david.holmes at oracle.com  Thu Dec 14 08:16:07 2023
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 14 Dec 2023 18:16:07 +1000
Subject: Introduce constructor for PriorityQueue with existing collection
 and custom comparator
In-Reply-To: <CAJXoXUBzNW94rcOzzOj5x3uxAy1y96=BBRu+OeEcX964DUWcdA@mail.gmail.com>
References: <CAJXoXUBjq5GeXoNqdBhspvpsPOvT7EXhz6VuZhZVD5=RLOjg4g@mail.gmail.com>
 <F9804F9F-0726-4E27-AFFC-B05062459AF1@oracle.com>
 <CAJXoXUBzNW94rcOzzOj5x3uxAy1y96=BBRu+OeEcX964DUWcdA@mail.gmail.com>
Message-ID: <91f18cfe-7fd6-4d56-87e0-c6b88bf7dc27@oracle.com>

The current mailing list, core-libs-dev, is the correct one.

Cheers,
David

On 14/12/2023 9:37 am, Valeh Hajiyev wrote:
> Hi Pavel,
> 
> Thanks for the reply. If I understand correctly, I need this change to 
> be discussed in one of the mailing lists there, so that someone would 
> sponsor me to create a tracking issue in JBS. Do you know which mailing 
> list is the most relevant for me to propose the change?
> 
> Thanks,
> Valeh
> 
> On Thu, Dec 14, 2023 at 12:26?AM Pavel Rappo <pavel.rappo at oracle.com 
> <mailto:pavel.rappo at oracle.com>> wrote:
> 
>     Sorry, there's a necessary process that a PR must follow. You seem
>     to have signed OCA already. For the rest, see this resource:
>     https://openjdk.org/guide/ <https://openjdk.org/guide/>. In
>     particular, this part:
>     https://openjdk.org/guide/#contributing-to-an-openjdk-project
>     <https://openjdk.org/guide/#contributing-to-an-openjdk-project>.
> 
>     -Pavel
> 
>      > On 13 Dec 2023, at 23:09, Valeh Hajiyev <valeh.hajiyev at gmail.com
>     <mailto:valeh.hajiyev at gmail.com>> wrote:
>      >
>      > Hi all,
>      >
>      > I have raised the following PR, could someone please help me to
>     get it merged?
>      >
>      > https://github.com/openjdk/jdk/pull/17045
>     <https://github.com/openjdk/jdk/pull/17045>
>      >
>      > More details:
>      >
>      > This commit addresses the current limitation in the
>     `PriorityQueue` implementation, which lacks a constructor to
>     efficiently create a priority queue with a custom comparator and an
>     existing collection. In order to create such a queue, we currently
>     need to initialize a new queue with custom comparator, and after
>     that populate the queue using `addAll()` method, which in the
>     background calls `add()` method (which takes `O(logn)` time) for
>     each element of the collection (`n` times).? This is resulting in an
>     overall time complexity of `O(nlogn)`.
>      >
>      > ```
>      > PriorityQueue<String> pq = new PriorityQueue<>(customComparator);
>      > pq.addAll(existingCollection);
>      > ```
>      >
>      > The pull request introduces a new constructor to streamline this
>     process and reduce the time complexity to `O(n)`.? If you create the
>     queue above using the new constructor, the contents of the
>     collection will be copied (which takes `O(n)` time) and then later 
>     `heapify()` operation (Floyd's algorithm) will be called once
>     (another `O(n)` time). Overall the operation will be reduced from
>     `O(nlogn)` to `O(2n)` -> `O(n)` time.
>      >
>      > ```
>      > PriorityQueue<String> pq = new
>     PriorityQueue<>(existingCollection, customComparator);
>      > ```
>      >
>      > Best regards,
>      > Valeh Hajiyev
>      >
> 

From stsypanov at openjdk.org  Thu Dec 14 08:47:03 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 14 Dec 2023 08:47:03 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v15]
In-Reply-To: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
Message-ID: <8SYx9TqaT4rL2o4BZ_Fnu_ZxD3vVMdYJS51dtGMK22I=.4b226895-ec4a-49bc-ab1a-c46a2e290405@github.com>

> It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`.
> 
> See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  8320971: Revert irrelevant changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16879/files
  - new: https://git.openjdk.org/jdk/pull/16879/files/42147ce8..8626e926

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16879&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16879&range=13-14

  Stats: 84 lines in 3 files changed: 22 ins; 60 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16879.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16879/head:pull/16879

PR: https://git.openjdk.org/jdk/pull/16879

From alanb at openjdk.org  Thu Dec 14 09:03:38 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 14 Dec 2023 09:03:38 GMT
Subject: RFR: 8322065: Initial nroff manpage generation for JDK 23
In-Reply-To: <UboOhUcAkH6L4qSOWy_uV5qieIX6IQNBhZxWsIvbLzc=.68cfd313-6718-4a7f-9233-f9fd04269e7a@github.com>
References: <UboOhUcAkH6L4qSOWy_uV5qieIX6IQNBhZxWsIvbLzc=.68cfd313-6718-4a7f-9233-f9fd04269e7a@github.com>
Message-ID: <TXQNeaff7Jd_CyhpTkq-o_TBH27cU01p8G0Thq7E5F0=.46bddd4a-9baa-4d4e-ad01-0f48b4d836e1@github.com>

On Thu, 14 Dec 2023 05:46:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Updated the version to 23-ea and year to 2024.
> 
> This initial generation also picks up the unpublished changes from:
> 
> - [JDK-8302233](https://bugs.openjdk.org/browse/JDK-8302233) (keytool & jarsigner)
> - [JDK-8290702](https://bugs.openjdk.org/browse/JDK-8290702) (javadoc) (JDK 23 backport)
> - [JDK-8321384](https://bugs.openjdk.org/browse/JDK-8321384) (javadoc)
> 
> 
> In addition this includes the updates for
> 
> - [JDK-8309981](https://bugs.openjdk.org/browse/8309981) Remove expired flags in JDK 23
> 
> Thanks

Initially I wondered if JDK-8309981 should be separated but include keeps things in sync so I think okay.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17101#pullrequestreview-1781343785

From jpai at openjdk.org  Thu Dec 14 09:18:55 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 14 Dec 2023 09:18:55 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v11]
In-Reply-To: <lP4u6pT1DnuoHpG4k-_Rjv2Va3IerlXNB357xXyDnBY=.6b127578-0f88-422a-9f05-b991b5b55250@github.com>
References: <l29EQEjJwcckNUGfzuZX_pfqbBcy0MXt2SM4p_dBXRw=.ffde4d8f-e261-4256-bbde-b7aad43ee630@github.com>
 <lP4u6pT1DnuoHpG4k-_Rjv2Va3IerlXNB357xXyDnBY=.6b127578-0f88-422a-9f05-b991b5b55250@github.com>
Message-ID: <aWfwHRvoma_LyQa4_sN_Q9UBetkb6uPwfAQXK9tv-qU=.cf88d57b-c57d-4051-8c33-2bbbc7c4081f@github.com>

On Mon, 23 Oct 2023 16:12:45 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update jmh test comments

Hello Eirik, I have opened https://bugs.openjdk.org/browse/JDK-8322078 to track this failure.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16115#issuecomment-1855465863

From prappo at openjdk.org  Thu Dec 14 09:19:37 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 14 Dec 2023 09:19:37 GMT
Subject: RFR: 8322065: Initial nroff manpage generation for JDK 23
In-Reply-To: <UboOhUcAkH6L4qSOWy_uV5qieIX6IQNBhZxWsIvbLzc=.68cfd313-6718-4a7f-9233-f9fd04269e7a@github.com>
References: <UboOhUcAkH6L4qSOWy_uV5qieIX6IQNBhZxWsIvbLzc=.68cfd313-6718-4a7f-9233-f9fd04269e7a@github.com>
Message-ID: <wc-9qyyMKcPQDfB2BQmDNHfSXFlPo1-X7RlNVr3BoA8=.5771d53d-9553-4747-99a7-e51f1a22260d@github.com>

On Thu, 14 Dec 2023 05:46:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Updated the version to 23-ea and year to 2024.
> 
> This initial generation also picks up the unpublished changes from:
> 
> - [JDK-8302233](https://bugs.openjdk.org/browse/JDK-8302233) (keytool & jarsigner)
> - [JDK-8290702](https://bugs.openjdk.org/browse/JDK-8290702) (javadoc) (JDK 23 backport)
> - [JDK-8321384](https://bugs.openjdk.org/browse/JDK-8321384) (javadoc)
> 
> 
> In addition this includes the updates for
> 
> - [JDK-8309981](https://bugs.openjdk.org/browse/8309981) Remove expired flags in JDK 23
> 
> Thanks

> Updated the version to 23-ea and year to 2024.
> 
> This initial generation also picks up the unpublished changes from:
> 

> * [JDK-8321384](https://bugs.openjdk.org/browse/JDK-8321384) (javadoc)

Thanks for doing this, David. I only note that the changes for JDK-8321384 were published in [JDK-8308715](https://bugs.openjdk.org/browse/JDK-8308715), which was integrated in the mainline before JDK 22 RDP 1. So they are already present in the mainline.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17101#issuecomment-1855467435

From jpai at openjdk.org  Thu Dec 14 09:34:40 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 14 Dec 2023 09:34:40 GMT
Subject: RFR: 8321958: javadoc error: @returns of
 ZoneRules#isDaylightSavings() is incorrect
In-Reply-To: <2150UeprX2CQ34CmEIROihDODlQMKsuPPv3gB-gjChE=.ff26e4a5-48e8-4153-85dc-6f9a7b554116@github.com>
References: <2150UeprX2CQ34CmEIROihDODlQMKsuPPv3gB-gjChE=.ff26e4a5-48e8-4153-85dc-6f9a7b554116@github.com>
Message-ID: <X-ggYwX3D9dAs0-wI0f8Pa5slzF0mUhhae6yjg2FQXQ=.66b63284-2b20-41b1-9bd0-afd26156d191@github.com>

On Wed, 13 Dec 2023 23:10:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Small document correction on a return description.

src/java.base/share/classes/java/time/zone/ZoneRules.java line 831:

> 829:      * and {@link #getStandardOffset(java.time.Instant) standard} offsets.
> 830:      *
> 831:      * @param instant  the instant to find the offset information for, not null, but null

Hello Naoto, do you think this `@param` description too will have to be reworded? It seems to be a copy/paste of the `getDaylightSavings()` method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17098#discussion_r1426464323

From jpai at openjdk.org  Thu Dec 14 09:43:41 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 14 Dec 2023 09:43:41 GMT
Subject: RFR: 8321718: ProcessTools.executeProcess calls waitFor before
 logging [v2]
In-Reply-To: <83m_6ZmOSvwQtzfUOTfDYKXOJJclctwMMLo6h_qnxgE=.48e6c6c2-a13c-46a4-a541-341f915683a0@github.com>
References: <fK27CacDG-QccKV-QpUT3z9p8eppW4wbw0ALbNCJn5w=.a1b6a824-5a8d-4a99-83ad-147fcd773dbd@github.com>
 <83m_6ZmOSvwQtzfUOTfDYKXOJJclctwMMLo6h_qnxgE=.48e6c6c2-a13c-46a4-a541-341f915683a0@github.com>
Message-ID: <OMLk8zE7WfKJfjOcppjCk-rFfzTua5-p-pnNtRWecn0=.9d713f70-f48e-494d-864b-cd726f1398f8@github.com>

On Tue, 12 Dec 2023 09:01:08 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> There is some logging printed when tests spawns processes. This logging is triggered from calls to `OutputAnalyzer`, when it delegates calls to `LazyOutputBuffer`.
>> 
>> If we write code like this:
>> 
>> ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...);
>> OutputAnalyzer output = new OutputAnalyzer(pb.start());
>> int exitValue = output.getExitValue();
>> 
>> 
>> We get the following logging:
>> 
>> [timestamp0] "Gathering output for process <pid>
>> [timestamp1] Waiting for completion for process <pid>
>> [timestamp2] Waiting for completion finished for process <pid>
>> 
>> 
>> The first line comes from the `OutputAnalyzer` constructor and the two other lines comes from the `getExitValue` call, which calls logs the above messages around the call to `waitFor`.
>> 
>> If instead write the code above as:
>> 
>> ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...);
>> OutputAnalyzer output = ProcessTools.executeProcess(pb);
>> int exitValue = output.getExitValue();
>> 
>> 
>> We get the same logging, but timestamp1 and timestamp2 are almost the same. This happens because there's an extra call to `waitFor` inside `executeProcess`, but that `waitFor` does not have the "wait for" logging. So, instead we get the logging for the no-op `waitFor` inside `getExitValue`.
>> 
>> I would like to propose a small workaround to solve this. The workaround is that `executeProcess` delegates the `waitFor` call to the `LazyOutputBuffer` via `OutputAnalyzer`.  This is a small, limited workaround for this issue. Ideally I would like to extract the entire Process handling code out of LazyOutputBuffer and OutputAnalyzer, but the prototype for that rewrites all usages of `new OutputAnalyzer(pb.start())` and stretches far and wide in the test directories, so I'm starting out with this suggestion.
>> 
>> We can see of this patch by looking at the timestamps generated from the included test. Without the proposed workaround:
>> 
>> Without
>> 
>> testExecuteProcessExit
>> [2023-12-11T11:05:41.854579260Z] Gathering output for process 2547719
>> [2023-12-11T11:05:44.018335073Z] Waiting for completion for process 2547719
>> [2023-12-11T11:05:44.018851972Z] Waiting for completion finished for process 2547719
>> 
>> testExecuteProcessStdout
>> [2023-12-11T11:05:44.049509860Z] Gathering output for process 2547741
>> [2023-12-11T11:05:46.227768897Z] Waiting for completion for process 2547741
>> [2023-12-11T11:05:46.228021173Z] Waiting for completion finished for process 2547741
>> 
>> 
>> testNewOutp...
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo

Hello Stefan, these changes look good to me.

Like you note, the new test case in this PR, isn't needed, so can be removed.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17052#pullrequestreview-1781418785

From pavel.rappo at oracle.com  Thu Dec 14 09:44:24 2023
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Thu, 14 Dec 2023 09:44:24 +0000
Subject: [External] : Re: Introduce constructor for PriorityQueue with
 existing collection and custom comparator
In-Reply-To: <CAJXoXUBzNW94rcOzzOj5x3uxAy1y96=BBRu+OeEcX964DUWcdA@mail.gmail.com>
References: <CAJXoXUBjq5GeXoNqdBhspvpsPOvT7EXhz6VuZhZVD5=RLOjg4g@mail.gmail.com>
 <F9804F9F-0726-4E27-AFFC-B05062459AF1@oracle.com>
 <CAJXoXUBzNW94rcOzzOj5x3uxAy1y96=BBRu+OeEcX964DUWcdA@mail.gmail.com>
Message-ID: <BC3AB360-D5E8-4097-9E50-219C1376F285@oracle.com>

Like David said earlier, this is the correct list. However, given the festive season, expect some delays in communication.

> On 13 Dec 2023, at 23:37, Valeh Hajiyev <valeh.hajiyev at gmail.com> wrote:
> 
> Hi Pavel,
> 
> Thanks for the reply. If I understand correctly, I need this change to be discussed in one of the mailing lists there, so that someone would sponsor me to create a tracking issue in JBS. Do you know which mailing list is the most relevant for me to propose the change?
> 
> Thanks,
> Valeh
> 
> On Thu, Dec 14, 2023 at 12:26?AM Pavel Rappo <pavel.rappo at oracle.com> wrote:
> Sorry, there's a necessary process that a PR must follow. You seem to have signed OCA already. For the rest, see this resource: https://openjdk.org/guide/. In particular, this part: https://openjdk.org/guide/#contributing-to-an-openjdk-project.
> 
> -Pavel
> 
> > On 13 Dec 2023, at 23:09, Valeh Hajiyev <valeh.hajiyev at gmail.com> wrote:
> > 
> > Hi all,
> > 
> > I have raised the following PR, could someone please help me to get it merged?
> > 
> > https://github.com/openjdk/jdk/pull/17045
> > 
> > More details:
> > 
> > This commit addresses the current limitation in the `PriorityQueue` implementation, which lacks a constructor to efficiently create a priority queue with a custom comparator and an existing collection. In order to create such a queue, we currently need to initialize a new queue with custom comparator, and after that populate the queue using `addAll()` method, which in the background calls `add()` method (which takes `O(logn)` time) for each element of the collection (`n` times).  This is resulting in an overall time complexity of `O(nlogn)`. 
> > 
> > ```
> > PriorityQueue<String> pq = new PriorityQueue<>(customComparator);
> > pq.addAll(existingCollection);
> > ```
> > 
> > The pull request introduces a new constructor to streamline this process and reduce the time complexity to `O(n)`.  If you create the queue above using the new constructor, the contents of the collection will be copied (which takes `O(n)` time) and then later  `heapify()` operation (Floyd's algorithm) will be called once (another `O(n)` time). Overall the operation will be reduced from `O(nlogn)` to `O(2n)` -> `O(n)` time.
> > 
> > ```
> > PriorityQueue<String> pq = new PriorityQueue<>(existingCollection, customComparator);
> > ```
> > 
> > Best regards,
> > Valeh Hajiyev
> > 
> 


From pavel.rappo at oracle.com  Thu Dec 14 09:55:36 2023
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Thu, 14 Dec 2023 09:55:36 +0000
Subject: [External] : Re: Introduce constructor for PriorityQueue with
 existing collection and custom comparator
In-Reply-To: <CAJXoXUBzNW94rcOzzOj5x3uxAy1y96=BBRu+OeEcX964DUWcdA@mail.gmail.com>
References: <CAJXoXUBjq5GeXoNqdBhspvpsPOvT7EXhz6VuZhZVD5=RLOjg4g@mail.gmail.com>
 <F9804F9F-0726-4E27-AFFC-B05062459AF1@oracle.com>
 <CAJXoXUBzNW94rcOzzOj5x3uxAy1y96=BBRu+OeEcX964DUWcdA@mail.gmail.com>
Message-ID: <CC225658-D639-4E47-A08C-4DC6D4FA2606@oracle.com>

You might want to use this older, unresolved, duplicated bug for your PR: https://bugs.openjdk.org/browse/JDK-6356745

> On 13 Dec 2023, at 23:37, Valeh Hajiyev <valeh.hajiyev at gmail.com> wrote:
> 
> Hi Pavel,
> 
> Thanks for the reply. If I understand correctly, I need this change to be discussed in one of the mailing lists there, so that someone would sponsor me to create a tracking issue in JBS. Do you know which mailing list is the most relevant for me to propose the change?
> 
> Thanks,
> Valeh
> 
> On Thu, Dec 14, 2023 at 12:26?AM Pavel Rappo <pavel.rappo at oracle.com> wrote:
> Sorry, there's a necessary process that a PR must follow. You seem to have signed OCA already. For the rest, see this resource: https://openjdk.org/guide/. In particular, this part: https://openjdk.org/guide/#contributing-to-an-openjdk-project.
> 
> -Pavel
> 
> > On 13 Dec 2023, at 23:09, Valeh Hajiyev <valeh.hajiyev at gmail.com> wrote:
> > 
> > Hi all,
> > 
> > I have raised the following PR, could someone please help me to get it merged?
> > 
> > https://github.com/openjdk/jdk/pull/17045
> > 
> > More details:
> > 
> > This commit addresses the current limitation in the `PriorityQueue` implementation, which lacks a constructor to efficiently create a priority queue with a custom comparator and an existing collection. In order to create such a queue, we currently need to initialize a new queue with custom comparator, and after that populate the queue using `addAll()` method, which in the background calls `add()` method (which takes `O(logn)` time) for each element of the collection (`n` times).  This is resulting in an overall time complexity of `O(nlogn)`. 
> > 
> > ```
> > PriorityQueue<String> pq = new PriorityQueue<>(customComparator);
> > pq.addAll(existingCollection);
> > ```
> > 
> > The pull request introduces a new constructor to streamline this process and reduce the time complexity to `O(n)`.  If you create the queue above using the new constructor, the contents of the collection will be copied (which takes `O(n)` time) and then later  `heapify()` operation (Floyd's algorithm) will be called once (another `O(n)` time). Overall the operation will be reduced from `O(nlogn)` to `O(2n)` -> `O(n)` time.
> > 
> > ```
> > PriorityQueue<String> pq = new PriorityQueue<>(existingCollection, customComparator);
> > ```
> > 
> > Best regards,
> > Valeh Hajiyev
> > 
> 


From jpai at openjdk.org  Thu Dec 14 10:05:38 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 14 Dec 2023 10:05:38 GMT
Subject: RFR: 8322018: Test
 java/lang/String/CompactString/MaxSizeUTF16String.java fails with -Xcomp
In-Reply-To: <7qbrvSGT9oZvj9tjokk17uxT5_032AY_GjyrD_QGa_g=.e6a674ea-f4f6-49b0-8ece-2910c4531bc4@github.com>
References: <7qbrvSGT9oZvj9tjokk17uxT5_032AY_GjyrD_QGa_g=.e6a674ea-f4f6-49b0-8ece-2910c4531bc4@github.com>
Message-ID: <ieVK6tFOwVo4Z8MaiL5ZmERj3VObyZvMfBb9AKONK2I=.c7521573-0112-4f6b-a0ed-77af193e02fc@github.com>

On Wed, 13 Dec 2023 21:38:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The test java/lang/String/CompactString/MaxSizeUTF16String.java fails when run with -Xcomp.
> 
> Both the java implementation and the intrinsic for StringUTF16.toBytes() allocate memory for a copy of the string.
> The java implementation of `toBytes()` throws an exception with a message in terms of length of the string.
> The intrinsic uses a generic message when allocating a byte array that is too large for the implementation.
> 
> Test should accept either message on the OOME exception, the message is an implementation detail and should reflect the cause of the error and not be confused with a general out of java heap message.

The update to the definition introduces a new `@run` with `-Xcomp` so as to explicitly control the test run instead of relying on external test launch mechanisms to pass around the `-Xcomp`. That then means that the introduction of `@requires vm.flagless`, in this change, is fine.
The change in the test logic itself looks reasonable to me based on what's explained in the PR description.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17095#pullrequestreview-1781459943

From prappo at openjdk.org  Thu Dec 14 10:13:47 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 14 Dec 2023 10:13:47 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v8]
In-Reply-To: <KDDFjGNV-Nlx1zJrkJraLZSvcDr2P_rfrwH7B1Ww4MY=.f29b24f6-1e3a-49cf-a44b-f74be434fd97@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
 <KDDFjGNV-Nlx1zJrkJraLZSvcDr2P_rfrwH7B1Ww4MY=.f29b24f6-1e3a-49cf-a44b-f74be434fd97@github.com>
Message-ID: <0dzuLQWeoMxenO1b4D7H5eeAa3Q_o2ql6S3-MPc4iUM=.1305f9e3-12ea-45ab-ac8a-52f92be5ff29@github.com>

On Tue, 7 Nov 2023 07:58:40 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for BigInteger. If you have any performance concerns, please raise them.
>> 
>> This PR is cherry-picked from a bigger, not-yet-published PR, to test the waters. That latter PR will be published soon.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8310813
>  - Merge branch 'master' into 8310813
>  - Fix bugs in Shared.createSingle
>  - Merge branch 'master' into 8310813
>  - Group params coarser (suggested by @cl4es)
>    
>    - Splits 20 params into 3 groups: (S)mall, (M)edium and (L)arge.
>      Every testXYZ method invokes M operations, where M is the maximum
>      number of elements in a group. Shorter groups are cyclically padded.
>    - Uses the org.openjdk.jmh.infra.Blackhole API and increases
>      benchmark time.
>    - Fixes a bug in Shared that precluded 0 from being in a pair.
>  - Use better overloads (suggested by @cl4es)
>    
>    - Uses simpler, more suitable overloads for the subrange
>      starting from 0
>  - Improve benchmarks
>  - Merge branch 'master' into 8310813
>  - Restore hash code values
>    
>    BigInteger is old and ubiquitous enough so that there might be
>    inadvertent dependencies on its hash code.
>    
>    This commit also includes a test, to make sure hash code is
>    unchanged.
>  - Merge branch 'master' into 8310813
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/5a26cc03...155fedba

Dear reviewers, what do you think about that performance data I recently published?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14630#issuecomment-1855554882

From prappo at openjdk.org  Thu Dec 14 10:15:18 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 14 Dec 2023 10:15:18 GMT
Subject: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex,
 length, initialValue) [v3]
In-Reply-To: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>
References: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>
Message-ID: <SRcsJE68Jl-Wrt0bwNAvTmiQX8EGGErG0Ia9HOVVJQo=.2912bbba-794f-422d-9dda-d04a554b7de2@github.com>

> This PR adds an internal method to calculate hash code from the provided integer array, offset and length into that array, and the initial hash code value.
> 
> Current options for calculating a hash code for int[] are inflexible. It's either ArraysSupport.vectorizedHashCode with an offset, length and initial value, or Arrays.hashCode with just an array.
> 
> For an arbitrary int[], unconditional vectorization might be unwarranted or puzzling. Unfortunately, it's the only hash code method that operates on an array subrange or accepts the initial hash code value.
> 
> A more convenient method could be added and then used, for example, here:
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java#L1076-L1083
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/ArrayList.java#L669-L680
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/sun/security/pkcs10/PKCS10.java#L356-L362
> 
> This PR adds such a method and provides tests for it. Additionally, this PR adds tests for `null` passed to `java.util.Arrays.hashCode` overloads, behaviour which was specified but untested.

Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge remote-tracking branch 'jdk/master' into 8311864
 - Merge branch 'master' into 8311864
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14831/files
  - new: https://git.openjdk.org/jdk/pull/14831/files/f874f161..655442eb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14831&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14831&range=01-02

  Stats: 782591 lines in 3816 files changed: 173277 ins; 536256 del; 73058 mod
  Patch: https://git.openjdk.org/jdk/pull/14831.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14831/head:pull/14831

PR: https://git.openjdk.org/jdk/pull/14831

From duke at openjdk.org  Thu Dec 14 10:18:03 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 14 Dec 2023 10:18:03 GMT
Subject: RFR: 8321616: Retire binary test vectors ZipFile/input.jar and
 ZipFile/input.zip [v2]
In-Reply-To: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
References: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
Message-ID: <MUbS5ws1S08j0WWu2QaXfvWu6u5p-bVCtGoXRpRC6Y4=.895c1567-1da6-4ee5-93a4-1c2436b908d4@github.com>

> This PR suggests we retire the binary test vectors `ZipFile/input.zip` and `ZipFile/input.jar`.
> 
> Binary test vectors are harder to analyze,  and sharing test vectors across unrelated tests increases maintenance burden. It would be better to have each test produce its own test vectors independently.
> 
> While visiting these dusty tests, we should take the opportunity to convert them to JUnit, add more comments and perform some mild modernization and cleanups where appropriate. We should also consider whether any test are duplicated and can be retired, see comments below.
> 
> To help reviewers, here are some comments on the updated tests:
> 
> `Available.java`
> This test currently has no jtreg `@test` header, so isn't currently active. I added a jtreg header with  `@bug 4401122`. I added some checks to verify that reading from the stream reduces the number of available bytes accordingly, also checking the behavior when the stream is closed. An alternative action would be to remove this test. It seems to validate the current implementation more than the specification.
> 
> `CopyJar.java`
> The 1999 bug description JDK-4239446 is short and somewhat confusing. It seems at some point that the CRC of `ZipEntry` read by `ZipFile.getEntry` would be read from a LOC header instead of the CEN header, which means it could be zero for streaming entries with data descriptors. (However, the bug description also mentions calling `getNextEntry`, which is a `ZipInputStream` method?) In any case, this concern seems to now have better coverage in the test `zip/CopyZipFile` from 2020, so it would perhaps be desirable to simply remove `CopyJar.java` to reduce duplication?
> 
> `EnumAfterClose.java`
> To prevent confusion with Java Enums, I suggest we rename this test to `EnumerateAfterClose`.
> 
> `FinalizeInflater.java`  
> The code verified by this test has been updated to use cleaners instead of finalizers. Still, this test code relies on finalizers. Not sure if this is an issue, but this test will need to be updated when finalizers are finally removed.
> 
> `GetDirEntry.java`
> This test seems to duplicate the test `ReadZip.readDirectoryEntry`. It would perhaps be better to remove `GetDirEntry.java` to reduce duplication?
> 
> `ReadZip.java`
> Nothing exciting here, the single main method was split into multiple JUnit methods, each focusing on a separate concern.
> 
> `ReleaseInflater.java`
> Nothing exciting, tried to add some comment to help understanding of what is tested.
> 
> `StreamZipEntriesTest.java`
> This test was us...

Eirik Bjorsnos has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Add @bug reference 4401122 on the Available.java test
 - Merge branch 'master' into readzip-junit
 - The input.jar test vector included a META-INF/ directory before the manifest, lets keep it that way
 - Remove the use of binary test vector ZIP/JAR files input.zip and input.jar, converting affected tests to JUnit
 - Update copyright year
 - Convert ReadZip to JUnit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17038/files
  - new: https://git.openjdk.org/jdk/pull/17038/files/f6a00f0c..56f55d89

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17038&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17038&range=00-01

  Stats: 5608 lines in 92 files changed: 3340 ins; 1807 del; 461 mod
  Patch: https://git.openjdk.org/jdk/pull/17038.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17038/head:pull/17038

PR: https://git.openjdk.org/jdk/pull/17038

From duke at openjdk.org  Thu Dec 14 10:18:04 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 14 Dec 2023 10:18:04 GMT
Subject: RFR: 8321616: Retire binary test vectors ZipFile/input.jar and
 ZipFile/input.zip
In-Reply-To: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
References: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
Message-ID: <st5vbWLQkCgGsokszdWvaRBVdpInowrn5yOTonaol3E=.e262536c-edc1-4788-9acb-f373f120530a@github.com>

On Fri, 8 Dec 2023 20:28:20 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> This PR suggests we retire the binary test vectors `ZipFile/input.zip` and `ZipFile/input.jar`.
> 
> Binary test vectors are harder to analyze,  and sharing test vectors across unrelated tests increases maintenance burden. It would be better to have each test produce its own test vectors independently.
> 
> While visiting these dusty tests, we should take the opportunity to convert them to JUnit, add more comments and perform some mild modernization and cleanups where appropriate. We should also consider whether any test are duplicated and can be retired, see comments below.
> 
> To help reviewers, here are some comments on the updated tests:
> 
> `Available.java`
> This test currently has no jtreg `@test` header, so isn't currently active. I added a jtreg header with  `@bug 4401122`. I added some checks to verify that reading from the stream reduces the number of available bytes accordingly, also checking the behavior when the stream is closed. An alternative action would be to remove this test. It seems to validate the current implementation more than the specification.
> 
> `CopyJar.java`
> The 1999 bug description JDK-4239446 is short and somewhat confusing. It seems at some point that the CRC of `ZipEntry` read by `ZipFile.getEntry` would be read from a LOC header instead of the CEN header, which means it could be zero for streaming entries with data descriptors. (However, the bug description also mentions calling `getNextEntry`, which is a `ZipInputStream` method?) In any case, this concern seems to now have better coverage in the test `zip/CopyZipFile` from 2020, so it would perhaps be desirable to simply remove `CopyJar.java` to reduce duplication?
> 
> `EnumAfterClose.java`
> To prevent confusion with Java Enums, I suggest we rename this test to `EnumerateAfterClose`.
> 
> `FinalizeInflater.java`  
> The code verified by this test has been updated to use cleaners instead of finalizers. Still, this test code relies on finalizers. Not sure if this is an issue, but this test will need to be updated when finalizers are finally removed.
> 
> `GetDirEntry.java`
> This test seems to duplicate the test `ReadZip.readDirectoryEntry`. It would perhaps be better to remove `GetDirEntry.java` to reduce duplication?
> 
> `ReadZip.java`
> Nothing exciting here, the single main method was split into multiple JUnit methods, each focusing on a separate concern.
> 
> `ReleaseInflater.java`
> Nothing exciting, tried to add some comment to help understanding of what is tested.
> 
> `StreamZipEntriesTest.java`
> This test was us...

The scope of this PR has now expanded to removing uses of the `input.zip` and `input.jar` files, updating any test using them to produce their own test vectors, and convert affected tests to JUnit.

I'm marking the PR ready for review again. Before looking too closely at the code, it would be useful to discuss the following tests:

- `Available.java`: This test has no jtreg header. I've added one and converted the test. Is this worthwhile, or should we rather remove it?
- `CopyJar.java`: The concern tested seems to have superior coverage in the test `zip/CopyZipFile.java`. Should we retire `CopyJar.java` instead of coverting it?
- `DirEntry.java`: There is duplication between this test and `ReadZip. readDirectoryEntry`. Should we retire one of these?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17038#issuecomment-1855560373

From prappo at openjdk.org  Thu Dec 14 10:18:28 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 14 Dec 2023 10:18:28 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v9]
In-Reply-To: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
Message-ID: <OfCwbnoLubDCmZk6fblB4ap5i4BClZL6dIF0oYO0WrA=.5cef1804-350d-40b0-93e0-98a76da8556e@github.com>

> Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for BigInteger. If you have any performance concerns, please raise them.
> 
> This PR is cherry-picked from a bigger, not-yet-published PR, to test the waters. That latter PR will be published soon.

Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:

 - Merge branch 'master' into 8310813
 - Merge branch 'master' into 8310813
 - Merge branch 'master' into 8310813
 - Fix bugs in Shared.createSingle
 - Merge branch 'master' into 8310813
 - Group params coarser (suggested by @cl4es)
   
   - Splits 20 params into 3 groups: (S)mall, (M)edium and (L)arge.
     Every testXYZ method invokes M operations, where M is the maximum
     number of elements in a group. Shorter groups are cyclically padded.
   - Uses the org.openjdk.jmh.infra.Blackhole API and increases
     benchmark time.
   - Fixes a bug in Shared that precluded 0 from being in a pair.
 - Use better overloads (suggested by @cl4es)
   
   - Uses simpler, more suitable overloads for the subrange
     starting from 0
 - Improve benchmarks
 - Merge branch 'master' into 8310813
 - Restore hash code values
   
   BigInteger is old and ubiquitous enough so that there might be
   inadvertent dependencies on its hash code.
   
   This commit also includes a test, to make sure hash code is
   unchanged.
 - ... and 6 more: https://git.openjdk.org/jdk/compare/5f6cebff...ef8b0c46

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14630/files
  - new: https://git.openjdk.org/jdk/pull/14630/files/155fedba..ef8b0c46

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14630&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14630&range=07-08

  Stats: 782591 lines in 3816 files changed: 173277 ins; 536256 del; 73058 mod
  Patch: https://git.openjdk.org/jdk/pull/14630.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14630/head:pull/14630

PR: https://git.openjdk.org/jdk/pull/14630

From viktor.klang at oracle.com  Thu Dec 14 10:55:11 2023
From: viktor.klang at oracle.com (Viktor Klang)
Date: Thu, 14 Dec 2023 10:55:11 +0000
Subject: [External] : Re: Introduce constructor for PriorityQueue with
 existing collection and custom comparator
In-Reply-To: <CC225658-D639-4E47-A08C-4DC6D4FA2606@oracle.com>
References: <CAJXoXUBjq5GeXoNqdBhspvpsPOvT7EXhz6VuZhZVD5=RLOjg4g@mail.gmail.com>
 <F9804F9F-0726-4E27-AFFC-B05062459AF1@oracle.com>
 <CAJXoXUBzNW94rcOzzOj5x3uxAy1y96=BBRu+OeEcX964DUWcdA@mail.gmail.com>
 <CC225658-D639-4E47-A08C-4DC6D4FA2606@oracle.com>
Message-ID: <MW4PR10MB5774BD82000BCC031D7B8520FF8CA@MW4PR10MB5774.namprd10.prod.outlook.com>

I presume that the precondition to have the original collection be pre-ordered according to the supplied Comparator can be verified by checking before adding each element in the collection to the PQ that it compareTo equal-or-greater to the previous one?


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Pavel Rappo <pavel.rappo at oracle.com>
Sent: Thursday, 14 December 2023 10:55
To: Valeh Hajiyev <valeh.hajiyev at gmail.com>
Cc: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: Introduce constructor for PriorityQueue with existing collection and custom comparator

You might want to use this older, unresolved, duplicated bug for your PR: https://bugs.openjdk.org/browse/JDK-6356745

> On 13 Dec 2023, at 23:37, Valeh Hajiyev <valeh.hajiyev at gmail.com> wrote:
>
> Hi Pavel,
>
> Thanks for the reply. If I understand correctly, I need this change to be discussed in one of the mailing lists there, so that someone would sponsor me to create a tracking issue in JBS. Do you know which mailing list is the most relevant for me to propose the change?
>
> Thanks,
> Valeh
>
> On Thu, Dec 14, 2023 at 12:26?AM Pavel Rappo <pavel.rappo at oracle.com> wrote:
> Sorry, there's a necessary process that a PR must follow. You seem to have signed OCA already. For the rest, see this resource: https://openjdk.org/guide/. In particular, this part: https://openjdk.org/guide/#contributing-to-an-openjdk-project.
>
> -Pavel
>
> > On 13 Dec 2023, at 23:09, Valeh Hajiyev <valeh.hajiyev at gmail.com> wrote:
> >
> > Hi all,
> >
> > I have raised the following PR, could someone please help me to get it merged?
> >
> > https://github.com/openjdk/jdk/pull/17045
> >
> > More details:
> >
> > This commit addresses the current limitation in the `PriorityQueue` implementation, which lacks a constructor to efficiently create a priority queue with a custom comparator and an existing collection. In order to create such a queue, we currently need to initialize a new queue with custom comparator, and after that populate the queue using `addAll()` method, which in the background calls `add()` method (which takes `O(logn)` time) for each element of the collection (`n` times).  This is resulting in an overall time complexity of `O(nlogn)`.
> >
> > ```
> > PriorityQueue<String> pq = new PriorityQueue<>(customComparator);
> > pq.addAll(existingCollection);
> > ```
> >
> > The pull request introduces a new constructor to streamline this process and reduce the time complexity to `O(n)`.  If you create the queue above using the new constructor, the contents of the collection will be copied (which takes `O(n)` time) and then later  `heapify()` operation (Floyd's algorithm) will be called once (another `O(n)` time). Overall the operation will be reduced from `O(nlogn)` to `O(2n)` -> `O(n)` time.
> >
> > ```
> > PriorityQueue<String> pq = new PriorityQueue<>(existingCollection, customComparator);
> > ```
> >
> > Best regards,
> > Valeh Hajiyev
> >
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20231214/5c156fa8/attachment-0001.htm>

From abimpoudis at openjdk.org  Thu Dec 14 11:04:09 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 14 Dec 2023 11:04:09 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v38]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <3JvLQvkIPnCIy1JtnD6hKyVg2GvDUDvUqog8R7gbGJc=.21d55c1c-1476-4eea-8720-5424eda66678@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 54 commits:

 - Merge branch 'master' into primitive-patterns
 - Cleanup
 - Merge branch 'master' into primitive-patterns
 - Remove trailing spaces
 - Merge branch 'primitive-patterns-and-generating-dispatch' into primitive-patterns
 - Fixed switch in the cases of unboxing and widening
 - Merge branch 'JDK-8319220' into primitive-patterns
 - Merge branch 'master' into JDK-8319220
 - reflecting review comment: fixing letter case.
 - Reflecting review feedback.
 - ... and 44 more: https://git.openjdk.org/jdk/compare/d2ba3b1e...a03fea7c

-------------

Changes: https://git.openjdk.org/jdk/pull/15638/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=37
  Stats: 3248 lines in 41 files changed: 2985 ins; 110 del; 153 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From cstein at openjdk.org  Thu Dec 14 11:26:39 2023
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 14 Dec 2023 11:26:39 GMT
Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update
In-Reply-To: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
References: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
Message-ID: <y2kS17FHng7x9R8XzK_l2IeOTUw3f3AhjgEfKUqw-EY=.5a963a5a-4188-449e-be61-387e2f03badb@github.com>

On Wed, 13 Dec 2023 22:12:48 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Translation drop for JDK22 RDP1

Marked as reviewed by cstein (Committer).

German translations read OK.

Nit: some layouts get lost in translated files - it would be great to have similar usage of `\n` and `` in the translated files.

For example, the English file `src/java.base/share/classes/sun/launcher/resources/launcher.properties` has good (easy to compare) layout:

java.launcher.opt.header  =   Usage: {0} [options] <mainclass> [args...]\n\
\           (to execute a class)\n\
\   or  {0} [options] -jar <jarfile> [args...]\n\
\           (to execute a jar file)\n\
\   or  {0} [options] -m <module>[/<mainclass>] [args...]\n\
\       {0} [options] --module <module>[/<mainclass>] [args...]\n\
\           (to execute the main class in a module)\n\
\   or  {0} [options] <sourcefile> [args]\n\
\           (to execute a source-file program)\n\n\
[...]

The German translation in `src/java.base/share/classes/sun/launcher/resources/launcher_de.properties` uses only a single line in its properties file:

java.launcher.opt.header  =   Verwendung: {0} [Optionen] <Hauptklasse> [args...]\n           (zur Ausf?hrung einer Klasse)\n   oder  {0} [Optionen] -jar <JAR-Datei> [args...]\n           (zur Ausf?hrung einer JAR-Datei)\n   oder  {0} [Optionen] -m <Modul>[/<Hauptklasse>] [args...]\n       {0} [Optionen] --module <Modul>[/<Hauptklasse>] [args...]\n            (zur Ausf?hrung der Hauptklasse in einem Modul)\n   oder  {0} [Optionen] <Quelldatei> [args]\n           (zur Ausf?hrung eines Programms mit einer Quelldatei)\n\n[...]

Changes in the latter are not easy to spot and review.

-------------

PR Review: https://git.openjdk.org/jdk/pull/17096#pullrequestreview-1781603832
PR Comment: https://git.openjdk.org/jdk/pull/17096#issuecomment-1855667603

From lancea at openjdk.org  Thu Dec 14 11:41:41 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 14 Dec 2023 11:41:41 GMT
Subject: RFR: 8321616: Retire binary test vectors ZipFile/input.jar and
 ZipFile/input.zip
In-Reply-To: <st5vbWLQkCgGsokszdWvaRBVdpInowrn5yOTonaol3E=.e262536c-edc1-4788-9acb-f373f120530a@github.com>
References: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
 <st5vbWLQkCgGsokszdWvaRBVdpInowrn5yOTonaol3E=.e262536c-edc1-4788-9acb-f373f120530a@github.com>
Message-ID: <WJs0rTsUU0l0e085NjxdNgHq4XRut4m_2sMFZ6ZPQ0A=.26fe5c86-f307-4b61-9d88-4d00b4dbb46c@github.com>

On Thu, 14 Dec 2023 10:13:31 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> The scope of this PR has now expanded to removing uses of the `input.zip` and `input.jar` files, updating any test using them to produce their own test vectors, and convert affected tests to JUnit.
> 
> I'm marking the PR ready for review again. Before looking too closely at the code, it would be useful to discuss the following tests:
> 
> * `Available.java`: This test has no jtreg header. I've added one and converted the test. Is this worthwhile, or should we rather remove it?

This could be moved into ReadZip.  I do not believe we have a specific test and it is trivial

> * `CopyJar.java`: The concern tested seems to have superior coverage in the test `zip/CopyZipFile.java`. Should we retire `CopyJar.java` instead of coverting it?

Yes CopyZipFile already exercises Zipfile.ZipInputStream so it is safe to retire CopyJar (though CopyZipFile could use a junit conversion ;-) 
> * `DirEntry.java`: There is duplication between this test and `ReadZip.readDirectoryEntry()`. Should we retire one of these?

I believe you meant GetDirEntry.java not DirEntry.java?

Having a test that specifically validates we can read META-INF is not a bad thing, but I suspect we have a test that already does that if not in the java/util/zip tests or java/util/jar tests.  If not we should keep it but merge it as you suggest

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17038#issuecomment-1855690222

From avoitylov at openjdk.org  Thu Dec 14 12:06:40 2023
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Thu, 14 Dec 2023 12:06:40 GMT
Subject: RFR: 8321514: UTF16 string gets constructed incorrectly from
 codepoints if CompactStrings is not enabled [v3]
In-Reply-To: <V_zRwOAFyFF-Ff3cUi1ujMNfPNClg59tQBN_Jet0LYE=.74b9e01c-0d32-41f9-a89f-37767c08d829@github.com>
References: <1azLdWceEALX1v_hfgt03ncVu_wtZyk3_lZ0B0J_cto=.a59aff49-50a9-498e-bc78-fd5468d87cd6@github.com>
 <V_zRwOAFyFF-Ff3cUi1ujMNfPNClg59tQBN_Jet0LYE=.74b9e01c-0d32-41f9-a89f-37767c08d829@github.com>
Message-ID: <J1cQFUwodXMQWiwUYQ4nU-Kzq1wt4xUCTf8bB3PnkUY=.e013c379-5a42-49a5-bec4-ce7ec40f5fbf@github.com>

On Wed, 13 Dec 2023 11:39:19 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

>> Since JDK-8311906, if CompactStrings is not enabled, index is not considered when calling extractCodepoints from StringUTF16.toBytes(). Because of that the last elements of the source codepoints array are stripped from the resulting UTF16 string, which fires in other places (e.g. during RegEx processing).
>>  
>> The fix replaces len in extractCodepoints parameters with end that is index + len.
>
> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Thank you, Roger. Yes, I'll work on the 22 backport.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17057#issuecomment-1855725539

From sspitsyn at openjdk.org  Thu Dec 14 12:14:40 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 14 Dec 2023 12:14:40 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v3]
In-Reply-To: <-3HkgdDQk9480AnHQeIxaNsqK0nVzjaf6UZJ5E9LGHo=.bdff2ed6-db98-4a77-832f-6accad54245f@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
 <-3HkgdDQk9480AnHQeIxaNsqK0nVzjaf6UZJ5E9LGHo=.bdff2ed6-db98-4a77-832f-6accad54245f@github.com>
Message-ID: <iMRU38pTmsjrxRpF1aXV6gMrj5bei0FE325hwzZ8YB4=.68c88f85-f4a2-4e1f-8ba7-22f8ba70be21@github.com>

On Fri, 8 Dec 2023 11:54:40 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fix is for JDK 23 but the intention is to back port it to 22 in RDP-1 time frame.
>> It is fixing a deadlock issue between `VirtualThread` class critical sections with the `interruptLock` (in methods: `unpark()`, `interrupt()`, `getAndClearInterrupt()`, `threadState()`, `toString()`), `JvmtiVTMSTransitionDisabler` and JVMTI `Suspend/Resume` mechanisms.
>> The deadlocking scenario is well described by Patricio in a bug report comment.
>> In simple words, a virtual thread should not be suspended during 'interruptLock' critical sections.
>> 
>> The fix is to record that a virtual thread is in a critical section (`JavaThread`'s `_in_critical_section` bit) by notifying the VM/JVMTI about begin/end of critical section.
>> This bit is used in `HandshakeState::get_op_for_self()` to filter out any `HandshakeOperation` if a target `JavaThread` is in a critical section.
>> 
>> Some of new notifications with `notifyJvmtiSync()` method is on a performance critical path. It is why this method has been intrincified.
>> 
>> New test was developed by Patricio:
>>  `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
>> The test is very nice as it reliably in 100% reproduces the deadlock without the fix.
>> The test is never failing with this fix.
>> 
>> Testing:
>>  - tested with newly added test: `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: (1) rename notifyJvmti method; (2) add try-final statements to VirtualThread methods

@AlanBateman Thank you for reviewing an the comment.
>  It shouldn't be necessary to touch mount/unmount as the thread identity is the carrier, not the virtual thread, when executing the "critical code".

Carrier thread also can be suspended when executing the "critical code".
Why do you think it can't be a problem? Do you think the deadlocking scenario described in the bug report is not possible?

>  toggle_is_in_critical_section needs to detect reentrancy, it is otherwise too easy to  refactor the Java code, e.g. call threadState while holding the interrupt lock.

Is your concern a recursive `interruptLock` enter? I was also thinking if this scenario is possible, so a counter can be used instead of boolean.

>  All the use-sides will need to use try-finally to more reliably revert the critical section flag when rewinding.

Right, thanks. It is already done.

>  The naming is very problematic, we'll need to replace with methods that are clearly named enter and exit critical section. Ongoing work in this area to support monitors has to introduce some temporary pinning so there will be enter/exitCriticalSection methods, that's a better place for the JVMTI hooks.

Okay. What about the Leonid's suggestion to name it `notifyJvmtiDisableSuspend()` ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17011#issuecomment-1855730274

From sspitsyn at openjdk.org  Thu Dec 14 12:14:45 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 14 Dec 2023 12:14:45 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v3]
In-Reply-To: <FzoKcM3_vYTnfZoA9mK5vkMl4wm4rXSzi73x6-aH4eI=.66ecbb2d-4da1-4153-a1a1-c20b88e24d19@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
 <-3HkgdDQk9480AnHQeIxaNsqK0nVzjaf6UZJ5E9LGHo=.bdff2ed6-db98-4a77-832f-6accad54245f@github.com>
 <FzoKcM3_vYTnfZoA9mK5vkMl4wm4rXSzi73x6-aH4eI=.66ecbb2d-4da1-4153-a1a1-c20b88e24d19@github.com>
Message-ID: <AZFw8OfcHVn_mnAuNASY39po95wSvXYlcDwHDMY844Q=.4fc7918d-027a-4958-a54d-05fc0c5c86d2@github.com>

On Tue, 12 Dec 2023 23:42:07 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: (1) rename notifyJvmti method; (2) add try-final statements to VirtualThread methods
>
> src/java.base/share/classes/java/lang/VirtualThread.java line 1164:
> 
>> 1162: 
>> 1163:     @IntrinsicCandidate
>> 1164:     private native void notifyJvmtiCriticalLock(boolean enter);
> 
> The name is confusing to me, the CriticalLock looks like it is the section is critical and might be taken by a single thread only. Or it's just unclear what is critical here. 
> However, the purpose is to disable suspend
> Wouldn't be 'notifyJvmtiSuspendLock notifyJvmtiDisableSuspend' better name here? 
> or comment what critical means here.

Okay, thanks. I like your name suggestion but let's check with Alan first.

> test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock/SuspendWithInterruptLock.java line 30:
> 
>> 28:  * @requires vm.continuations
>> 29:  * @library /testlibrary
>> 30:  * @run main/othervm -Xint SuspendWithInterruptLock
> 
> Doesn't it make sense to add a testcase without -Xint also? Just to give stress testing with compilation.

Thanks. I was also thinking about this. Will add a sub-test without -Xint.

> test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock/SuspendWithInterruptLock.java line 36:
> 
>> 34: 
>> 35: public class SuspendWithInterruptLock {
>> 36:     static boolean done;
> 
> done is accessed from different threads, should be volatile.

Good suggestion, thanks.

> test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock/SuspendWithInterruptLock.java line 54:
> 
>> 52:             Thread.yield();
>> 53:         }
>> 54:         done = true;
> 
> I think it is better to use done to stop all threads and set it to true in the main thread after some time. So you could be sure that the yielder hadn't been completed before the suspender started. But it is just proposal.

Thank you. Will consider this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1426638981
PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1426635613
PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1426636196
PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1426637200

From sspitsyn at openjdk.org  Thu Dec 14 12:19:43 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 14 Dec 2023 12:19:43 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v3]
In-Reply-To: <FzoKcM3_vYTnfZoA9mK5vkMl4wm4rXSzi73x6-aH4eI=.66ecbb2d-4da1-4153-a1a1-c20b88e24d19@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
 <-3HkgdDQk9480AnHQeIxaNsqK0nVzjaf6UZJ5E9LGHo=.bdff2ed6-db98-4a77-832f-6accad54245f@github.com>
 <FzoKcM3_vYTnfZoA9mK5vkMl4wm4rXSzi73x6-aH4eI=.66ecbb2d-4da1-4153-a1a1-c20b88e24d19@github.com>
Message-ID: <fnYIsaA7ccrP0K-247Z0WiwpCpfypHDsy-ZxfsObw8I=.5e2c62d0-2c5c-459c-8e65-af399c086e1c@github.com>

On Tue, 12 Dec 2023 23:54:43 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: (1) rename notifyJvmti method; (2) add try-final statements to VirtualThread methods
>
> src/hotspot/share/prims/jvm.cpp line 4013:
> 
>> 4011: // Notification from VirtualThread about entering/exiting sync critical section.
>> 4012: // Needed to avoid deadlocks with JVMTI suspend mechanism.
>> 4013: JVM_ENTRY(void, JVM_VirtualThreadCriticalLock(JNIEnv* env, jobject vthread, jboolean enter))
> 
> the jobject vthread is not used. Can't be the method made static to reduce the number of arguments? 
> It is the performance-critical code,  I don't know if it is optimized by C2.

Good question.
In general, I'd like to keep this unified with the other `notiftJvmti` methods.
Let me double check how it fits together.
Also, I'm not sure how is going to impact the intrinsification.

> src/hotspot/share/runtime/javaThread.hpp line 320:
> 
>> 318:   bool                  _is_in_VTMS_transition;          // thread is in virtual thread mount state transition
>> 319:   bool                  _is_in_tmp_VTMS_transition;      // thread is in temporary virtual thread mount state transition
>> 320:   bool                  _is_in_critical_section;         // thread is in a locking critical section
> 
> might make sense to add a comment, that his variable Is changed/read only by current thread and no sync is needed.

Good suggestion, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1426643218
PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1426643663

From alanb at openjdk.org  Thu Dec 14 12:22:40 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 14 Dec 2023 12:22:40 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v3]
In-Reply-To: <iMRU38pTmsjrxRpF1aXV6gMrj5bei0FE325hwzZ8YB4=.68c88f85-f4a2-4e1f-8ba7-22f8ba70be21@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
 <-3HkgdDQk9480AnHQeIxaNsqK0nVzjaf6UZJ5E9LGHo=.bdff2ed6-db98-4a77-832f-6accad54245f@github.com>
 <iMRU38pTmsjrxRpF1aXV6gMrj5bei0FE325hwzZ8YB4=.68c88f85-f4a2-4e1f-8ba7-22f8ba70be21@github.com>
Message-ID: <Jq4j4mBXXX5qzG073iJLr8nU2792K6jVJ_CBcbfPG3U=.8765026e-234d-425a-b142-ff098afbf14a@github.com>

On Thu, 14 Dec 2023 12:06:41 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Carrier thread also can be suspended when executing the "critical code". Why do you think it can't be a problem? Do you think the deadlocking scenario described in the bug report is not possible?

It's a different scenario. When mounting, the coordination of the interrupt status is done before the thread identity is changed. Similarly, when unmounting, the coordination is done after reverting the thread identity to the carrier. So if there is an agent randomly suspending threads when it shouldn't be an issue here. 

> > toggle_is_in_critical_section needs to detect reentrancy, it is otherwise too easy to  refactor the Java code, e.g. call threadState while holding the interrupt lock.
> 
> Is your concern a recursive `interruptLock` enter? I was also thinking if this scenario is possible, so a counter can be used instead of boolean.

Minimally an assert. A counter might be needed later.


> Okay. What about the Leonid's suggestion to name it `notifyJvmtiDisableSuspend()` ?

We have changes in the works that require pinning during some critical sections so I think I prefer to use that terminology. We can move the notification to JVMTI to the enter/leave methods.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17011#issuecomment-1855748841

From duke at openjdk.org  Thu Dec 14 12:25:08 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 14 Dec 2023 12:25:08 GMT
Subject: RFR: 8321616: Retire binary test vectors ZipFile/input.jar and
 ZipFile/input.zip [v3]
In-Reply-To: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
References: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
Message-ID: <EYTZaROuoBrj5G2SIea2pyS7MgIRsJg8muXBGiD-AWw=.285154de-ee08-4334-a20a-45c0d605e95e@github.com>

> This PR suggests we retire the binary test vectors `ZipFile/input.zip` and `ZipFile/input.jar`.
> 
> Binary test vectors are harder to analyze,  and sharing test vectors across unrelated tests increases maintenance burden. It would be better to have each test produce its own test vectors independently.
> 
> While visiting these dusty tests, we should take the opportunity to convert them to JUnit, add more comments and perform some mild modernization and cleanups where appropriate. We should also consider whether any test are duplicated and can be retired, see comments below.
> 
> To help reviewers, here are some comments on the updated tests:
> 
> `Available.java`
> This test currently has no jtreg `@test` header, so isn't currently active. I added a jtreg header with  `@bug 4401122`. I added some checks to verify that reading from the stream reduces the number of available bytes accordingly, also checking the behavior when the stream is closed. An alternative action would be to remove this test. It seems to validate the current implementation more than the specification.
> 
> `CopyJar.java`
> The 1999 bug description JDK-4239446 is short and somewhat confusing. It seems at some point that the CRC of `ZipEntry` read by `ZipFile.getEntry` would be read from a LOC header instead of the CEN header, which means it could be zero for streaming entries with data descriptors. (However, the bug description also mentions calling `getNextEntry`, which is a `ZipInputStream` method?) In any case, this concern seems to now have better coverage in the test `zip/CopyZipFile` from 2020, so it would perhaps be desirable to simply remove `CopyJar.java` to reduce duplication?
> 
> `EnumAfterClose.java`
> To prevent confusion with Java Enums, I suggest we rename this test to `EnumerateAfterClose`.
> 
> `FinalizeInflater.java`  
> The code verified by this test has been updated to use cleaners instead of finalizers. Still, this test code relies on finalizers. Not sure if this is an issue, but this test will need to be updated when finalizers are finally removed.
> 
> `GetDirEntry.java`
> This test seems to duplicate the test `ReadZip.readDirectoryEntry`. It would perhaps be better to remove `GetDirEntry.java` to reduce duplication?
> 
> `ReadZip.java`
> Nothing exciting here, the single main method was split into multiple JUnit methods, each focusing on a separate concern.
> 
> `ReleaseInflater.java`
> Nothing exciting, tried to add some comment to help understanding of what is tested.
> 
> `StreamZipEntriesTest.java`
> This test was us...

Eirik Bjorsnos has updated the pull request incrementally with three additional commits since the last revision:

 - Merge GetDirEntry.java into ReadZip.readDirectoryEntries()
 - Retire redundant test ZipFile/CopyJar
 - Merge Available.java into ReadZip.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17038/files
  - new: https://git.openjdk.org/jdk/pull/17038/files/56f55d89..03cb8354

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17038&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17038&range=01-02

  Stats: 361 lines in 4 files changed: 59 ins; 296 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/17038.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17038/head:pull/17038

PR: https://git.openjdk.org/jdk/pull/17038

From duke at openjdk.org  Thu Dec 14 12:25:10 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 14 Dec 2023 12:25:10 GMT
Subject: RFR: 8321616: Retire binary test vectors ZipFile/input.jar and
 ZipFile/input.zip
In-Reply-To: <WJs0rTsUU0l0e085NjxdNgHq4XRut4m_2sMFZ6ZPQ0A=.26fe5c86-f307-4b61-9d88-4d00b4dbb46c@github.com>
References: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
 <st5vbWLQkCgGsokszdWvaRBVdpInowrn5yOTonaol3E=.e262536c-edc1-4788-9acb-f373f120530a@github.com>
 <WJs0rTsUU0l0e085NjxdNgHq4XRut4m_2sMFZ6ZPQ0A=.26fe5c86-f307-4b61-9d88-4d00b4dbb46c@github.com>
Message-ID: <rPtuWMlwln5mmSucEl2qroutuhDIb91gXVUe8sXgzZ4=.1f251515-21e9-49e8-b07c-1fa49fa84f63@github.com>

On Thu, 14 Dec 2023 11:39:22 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> The scope of this PR has now expanded to removing uses of the `input.zip` and `input.jar` files, updating any test using them to produce their own test vectors, and convert affected tests to JUnit.
>> 
>> I'm marking the PR ready for review again. Before looking too closely at the code, it would be useful to discuss the following tests:
>> 
>> - `Available.java`: This test has no jtreg header. I've added one and converted the test. Is this worthwhile, or should we rather remove it?
>> - `CopyJar.java`: The concern tested seems to have superior coverage in the test `zip/CopyZipFile.java`. Should we retire `CopyJar.java` instead of coverting it?
>> - `DirEntry.java`: There is duplication between this test and `ReadZip.readDirectoryEntry()`. Should we retire one of these?
>
>> The scope of this PR has now expanded to removing uses of the `input.zip` and `input.jar` files, updating any test using them to produce their own test vectors, and convert affected tests to JUnit.
>> 
>> I'm marking the PR ready for review again. Before looking too closely at the code, it would be useful to discuss the following tests:
>> 
>> * `Available.java`: This test has no jtreg header. I've added one and converted the test. Is this worthwhile, or should we rather remove it?
> 
> This could be moved into ReadZip.  I do not believe we have a specific test and it is trivial
> 
>> * `CopyJar.java`: The concern tested seems to have superior coverage in the test `zip/CopyZipFile.java`. Should we retire `CopyJar.java` instead of coverting it?
> 
> Yes CopyZipFile already exercises Zipfile.ZipInputStream so it is safe to retire CopyJar (though CopyZipFile could use a junit conversion ;-) 
>> * `DirEntry.java`: There is duplication between this test and `ReadZip.readDirectoryEntry()`. Should we retire one of these?
> 
> I believe you meant GetDirEntry.java not DirEntry.java?
> 
> Having a test that specifically validates we can read META-INF is not a bad thing, but I suspect we have a test that already does that if not in the java/util/zip tests or java/util/jar tests.  If not we should keep it but merge it as you suggest

@LanceAndersen 

Thanks for your guidance! I moved `Available` into `ReadZip`, deleted `CopyJar` and merged `GetDirEntry` into ReadZip.readDirectoryEntries (adding a 'META-INF/' directory just in case)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17038#issuecomment-1855753641

From dholmes at openjdk.org  Thu Dec 14 12:26:40 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 14 Dec 2023 12:26:40 GMT
Subject: RFR: 8322065: Initial nroff manpage generation for JDK 23
In-Reply-To: <wc-9qyyMKcPQDfB2BQmDNHfSXFlPo1-X7RlNVr3BoA8=.5771d53d-9553-4747-99a7-e51f1a22260d@github.com>
References: <UboOhUcAkH6L4qSOWy_uV5qieIX6IQNBhZxWsIvbLzc=.68cfd313-6718-4a7f-9233-f9fd04269e7a@github.com>
 <wc-9qyyMKcPQDfB2BQmDNHfSXFlPo1-X7RlNVr3BoA8=.5771d53d-9553-4747-99a7-e51f1a22260d@github.com>
Message-ID: <KGeNu7eyXiV1Xdi4G3O5pRd8-wLGYRLHLnvSOl0RJBk=.4cb49fb9-01f0-46c2-846d-be194ab1abaa@github.com>

On Thu, 14 Dec 2023 09:17:05 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Thanks for doing this, David. I only note that the changes for JDK-8321384 were published in [JDK-8308715](https://bugs.openjdk.org/browse/JDK-8308715), which was integrated in the mainline before JDK 22 RDP 1. So they are already present in the mainline.

Ah I see. Thanks for correcting that, I will update the PR and JBS issue.

And thanks for looking at this @pavelrappo .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17101#issuecomment-1855755042

From duke at openjdk.org  Thu Dec 14 12:28:53 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 14 Dec 2023 12:28:53 GMT
Subject: RFR: 8321616: Retire binary test vectors ZipFile/input.jar and
 ZipFile/input.zip [v4]
In-Reply-To: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
References: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
Message-ID: <plb-KyrQofc0cRjkx_Gkjdnu3d39FolMQP5nsB1BBF0=.4476d956-f358-4d7b-a13c-a2e1c800a73e@github.com>

> This PR suggests we retire the binary test vectors `ZipFile/input.zip` and `ZipFile/input.jar`.
> 
> Binary test vectors are harder to analyze,  and sharing test vectors across unrelated tests increases maintenance burden. It would be better to have each test produce its own test vectors independently.
> 
> While visiting these dusty tests, we should take the opportunity to convert them to JUnit, add more comments and perform some mild modernization and cleanups where appropriate. We should also consider whether any test are duplicated and can be retired, see comments below.
> 
> To help reviewers, here are some comments on the updated tests:
> 
> `Available.java`
> This test currently has no jtreg `@test` header, so isn't currently active. I added a jtreg header with  `@bug 4401122`. I added some checks to verify that reading from the stream reduces the number of available bytes accordingly, also checking the behavior when the stream is closed. An alternative action would be to remove this test. It seems to validate the current implementation more than the specification.
> 
> `CopyJar.java`
> The 1999 bug description JDK-4239446 is short and somewhat confusing. It seems at some point that the CRC of `ZipEntry` read by `ZipFile.getEntry` would be read from a LOC header instead of the CEN header, which means it could be zero for streaming entries with data descriptors. (However, the bug description also mentions calling `getNextEntry`, which is a `ZipInputStream` method?) In any case, this concern seems to now have better coverage in the test `zip/CopyZipFile` from 2020, so it would perhaps be desirable to simply remove `CopyJar.java` to reduce duplication?
> 
> `EnumAfterClose.java`
> To prevent confusion with Java Enums, I suggest we rename this test to `EnumerateAfterClose`.
> 
> `FinalizeInflater.java`  
> The code verified by this test has been updated to use cleaners instead of finalizers. Still, this test code relies on finalizers. Not sure if this is an issue, but this test will need to be updated when finalizers are finally removed.
> 
> `GetDirEntry.java`
> This test seems to duplicate the test `ReadZip.readDirectoryEntry`. It would perhaps be better to remove `GetDirEntry.java` to reduce duplication?
> 
> `ReadZip.java`
> Nothing exciting here, the single main method was split into multiple JUnit methods, each focusing on a separate concern.
> 
> `ReleaseInflater.java`
> Nothing exciting, tried to add some comment to help understanding of what is tested.
> 
> `StreamZipEntriesTest.java`
> This test was us...

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Remove trailing whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17038/files
  - new: https://git.openjdk.org/jdk/pull/17038/files/03cb8354..593a76cd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17038&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17038&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17038.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17038/head:pull/17038

PR: https://git.openjdk.org/jdk/pull/17038

From dholmes at openjdk.org  Thu Dec 14 12:30:38 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 14 Dec 2023 12:30:38 GMT
Subject: RFR: 8322065: Initial nroff manpage generation for JDK 23
In-Reply-To: <TXQNeaff7Jd_CyhpTkq-o_TBH27cU01p8G0Thq7E5F0=.46bddd4a-9baa-4d4e-ad01-0f48b4d836e1@github.com>
References: <UboOhUcAkH6L4qSOWy_uV5qieIX6IQNBhZxWsIvbLzc=.68cfd313-6718-4a7f-9233-f9fd04269e7a@github.com>
 <TXQNeaff7Jd_CyhpTkq-o_TBH27cU01p8G0Thq7E5F0=.46bddd4a-9baa-4d4e-ad01-0f48b4d836e1@github.com>
Message-ID: <mVw4r96UaGCiseQ8hJip4ForRXp8x4LSA6nx7lELxNo=.fc11214c-7229-4f2e-9667-0bcf42b26751@github.com>

On Thu, 14 Dec 2023 09:01:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Initially I wondered if JDK-8309981 should be separated but include keeps things in sync so I think okay.

Thanks for the review @AlanBateman .

Yeah I was in two minds there myself. I started fixing [JDK-8309981](https://bugs.openjdk.org/browse/JDK-8309981) only to discover that the start of release updates had not been done as part of the start of release, so I figured I may as well fix it all together given I'd generated all the updated files anyway. But I'm still a little unsure ... in fact I think I will remove it in the morning.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17101#issuecomment-1855761906

From dholmes at openjdk.org  Thu Dec 14 12:35:52 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 14 Dec 2023 12:35:52 GMT
Subject: RFR: 8322065: Initial nroff manpage generation for JDK 23 [v2]
In-Reply-To: <UboOhUcAkH6L4qSOWy_uV5qieIX6IQNBhZxWsIvbLzc=.68cfd313-6718-4a7f-9233-f9fd04269e7a@github.com>
References: <UboOhUcAkH6L4qSOWy_uV5qieIX6IQNBhZxWsIvbLzc=.68cfd313-6718-4a7f-9233-f9fd04269e7a@github.com>
Message-ID: <cLrnXzE4mmuGODVy7DfA7Zzq1ot2aquVTBG9PPGPwJQ=.e0f4b2b4-d567-462b-9ecd-5be70e461aa6@github.com>

> Updated the version to 23-ea and year to 2024.
> 
> This initial generation also picks up the unpublished changes from:
> 
> - [JDK-8302233](https://bugs.openjdk.org/browse/JDK-8302233) (keytool & jarsigner)
> - [JDK-8290702](https://bugs.openjdk.org/browse/JDK-8290702) (javadoc) (JDK 23 backport)
> 
> Thanks

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Revert "8309981: Remove expired flags in JDK 23"
  
  This reverts commit 0324a90e936ae01e42ae099e7235156326cc318a.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17101/files
  - new: https://git.openjdk.org/jdk/pull/17101/files/65a8c9ed..8b052141

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17101&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17101&range=00-01

  Stats: 23 lines in 2 files changed: 10 ins; 11 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17101.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17101/head:pull/17101

PR: https://git.openjdk.org/jdk/pull/17101

From dclarke at openjdk.org  Thu Dec 14 13:26:46 2023
From: dclarke at openjdk.org (Darragh Clarke)
Date: Thu, 14 Dec 2023 13:26:46 GMT
Subject: Integrated: 8319647: Few java/lang/System/LoggerFinder/modules tests
 ignore vm flags
In-Reply-To: <zOAssUyHlaTMKi-cdLp_YxE7Qdko-MfAnovE2cFR_9M=.269b68c9-57c5-4d32-bd3c-1874193ddefa@github.com>
References: <zOAssUyHlaTMKi-cdLp_YxE7Qdko-MfAnovE2cFR_9M=.269b68c9-57c5-4d32-bd3c-1874193ddefa@github.com>
Message-ID: <R4s5zxhsXsz-c2H1uUJ8KxbJsetysP-z61LQXL1C-AI=.6a788e5c-ae66-4fdc-ac60-f69ff9bfc2ea@github.com>

On Mon, 4 Dec 2023 10:39:05 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

> Updated tests to use vm.flagless as they already ignore Vm flags

This pull request has now been integrated.

Changeset: 62b7c5ea
Author:    Darragh Clarke <dclarke at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/62b7c5eaed1e6ffd6f2c8371eb4cf01dd9d53a06
Stats:     14 lines in 7 files changed: 7 ins; 0 del; 7 mod

8319647: Few java/lang/System/LoggerFinder/modules tests ignore vm flags

Reviewed-by: lmesnik

-------------

PR: https://git.openjdk.org/jdk/pull/16946

From reinier at zwitserloot.com  Thu Dec 14 13:46:59 2023
From: reinier at zwitserloot.com (Reinier Zwitserloot)
Date: Thu, 14 Dec 2023 05:46:59 -0800
Subject: Omission in javadoc Stream.toArray(): Safe array contract stipulation
Message-ID: <CAK6PxWMmLWkBWemO2E529TDwc1gGiPq6WUK2n+4v0kuP-_f_YQ@mail.gmail.com>

Hi core libs team,

I think I found a rather inconsequential and esoteric bug, though the term
is somewhat less objectively defined when the problem exists solely in how
complete some method?s javadoc is.

Two questions: Is there a plausible argument that the javadoc as is,
shouldn?t be updated? If not, what?s the right place to report this javadoc
?bug??

The issue:

A snippet of the javadoc of Collection.toArray, from current HEAD jdk22u:

    <p>The returned array will be "safe" in that no references to it are
     * maintained by this collection.  (In other words, this method must
     * allocate a new array even if this collection is backed by an array).
     * The caller is thus free to modify the returned array.

The javadoc of Stream.toArray, from current HEAD jdk22u - has no such rider
anywhere in its documentation nor on the javadoc of the Stream interface,
nor on the package javadoc. The javadoc is quite short; the complete docs
on toArray():

     /**
     * Returns an array containing the elements of this stream.
     *
     * <p>This is a <a href="package-summary.html#StreamOps">terminal
     * operation</a>.
     *
     * @return an array, whose {@linkplain Class#getComponentType runtime
component
     * type} is {@code Object}, containing the elements of this stream
     */

The more usually used variant taking a function that makes the array has
slightly longer javadoc, but it similarly makes no mention whatsoever about
the contract stipulation that any implementors must not keep a reference.

A snippet from Stuart Marks on a stack overflow question about a to the
asker weird choice about stream?s toList()?s default implementation (
https://stackoverflow.com/questions/77473755/is-it-necessary-to-copy-a-list-to-be-safe/77474199?noredirect=1#comment136909551_77474199
):

    @Holger The extra step in the default implementation is there to force
a defensive copy if this.toArray were to violate its spec and keep a
reference to the returned array. Without the defensive copy, it would be
possible to modify the list returned from the default toList implementation.



Which leads to the obvious question: Where is that ?spec? that Stuart is
referring to? Either the javadoc is the spec and therefore the javadoc is
buggy, in that it fails to mention this stipulation, or the spec is
elsewhere, in which case surely the javadoc should link to it or copy it.

Possibly this is jus filed away as: ?Unlike with Collection, Stream
instances are disposable; after a terminal operation (and toArray is
terminal) has been invoked on it, that stream object has ceased being
useful. Therefore, there is no perceived value to caching any created
array, therefore, it doesn?t need mentioning".

Except, as per Stuart?s comment, actual OpenJDK code is written partly to
deal with any violators of this invisible spec, and the discrepancy (where
Collection.toArray explicitly mentions the contract stipulation that
toArray() must make safe arrays, but Stream?s toArray() does not) suggests
a fundamental difference where none exists (in fact, literally: Apparently
its a spec violation if your Stream implementation return a non-safe array
from toArray!)

 --Reinier Zwitserloot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20231214/eaebaadd/attachment-0001.htm>

From duke at openjdk.org  Thu Dec 14 14:08:01 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 14 Dec 2023 14:08:01 GMT
Subject: RFR: 8321616: Retire binary test vectors ZipFile/input.jar and
 ZipFile/input.zip [v5]
In-Reply-To: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
References: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
Message-ID: <4EM--ukPzb5OjRtfhYE_YSbR6HmpOlovYLxuhO4KqCk=.a36a24fd-98e6-4d5e-9271-7e87baac5544@github.com>

> This PR suggests we retire the binary test vectors `ZipFile/input.zip` and `ZipFile/input.jar`.
> 
> Binary test vectors are harder to analyze,  and sharing test vectors across unrelated tests increases maintenance burden. It would be better to have each test produce its own test vectors independently.
> 
> While visiting these dusty tests, we should take the opportunity to convert them to JUnit, add more comments and perform some mild modernization and cleanups where appropriate. We should also consider whether any test are duplicated and can be retired, see comments below.
> 
> To help reviewers, here are some comments on the updated tests:
> 
> `Available.java`
> This test currently has no jtreg `@test` header, so isn't currently active. I added a jtreg header with  `@bug 4401122`. I added some checks to verify that reading from the stream reduces the number of available bytes accordingly, also checking the behavior when the stream is closed. An alternative action would be to remove this test. It seems to validate the current implementation more than the specification.
> 
> `CopyJar.java`
> The 1999 bug description JDK-4239446 is short and somewhat confusing. It seems at some point that the CRC of `ZipEntry` read by `ZipFile.getEntry` would be read from a LOC header instead of the CEN header, which means it could be zero for streaming entries with data descriptors. (However, the bug description also mentions calling `getNextEntry`, which is a `ZipInputStream` method?) In any case, this concern seems to now have better coverage in the test `zip/CopyZipFile` from 2020, so it would perhaps be desirable to simply remove `CopyJar.java` to reduce duplication?
> 
> `EnumAfterClose.java`
> To prevent confusion with Java Enums, I suggest we rename this test to `EnumerateAfterClose`.
> 
> `FinalizeInflater.java`  
> The code verified by this test has been updated to use cleaners instead of finalizers. Still, this test code relies on finalizers. Not sure if this is an issue, but this test will need to be updated when finalizers are finally removed.
> 
> `GetDirEntry.java`
> This test seems to duplicate the test `ReadZip.readDirectoryEntry`. It would perhaps be better to remove `GetDirEntry.java` to reduce duplication?
> 
> `ReadZip.java`
> Nothing exciting here, the single main method was split into multiple JUnit methods, each focusing on a separate concern.
> 
> `ReleaseInflater.java`
> Nothing exciting, tried to add some comment to help understanding of what is tested.
> 
> `StreamZipEntriesTest.java`
> This test was us...

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Convert CopyZipFile.java to JUnit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17038/files
  - new: https://git.openjdk.org/jdk/pull/17038/files/593a76cd..4e9c97d4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17038&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17038&range=03-04

  Stats: 195 lines in 1 file changed: 82 ins; 19 del; 94 mod
  Patch: https://git.openjdk.org/jdk/pull/17038.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17038/head:pull/17038

PR: https://git.openjdk.org/jdk/pull/17038

From duke at openjdk.org  Thu Dec 14 14:08:03 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 14 Dec 2023 14:08:03 GMT
Subject: RFR: 8321616: Retire binary test vectors ZipFile/input.jar and
 ZipFile/input.zip
In-Reply-To: <WJs0rTsUU0l0e085NjxdNgHq4XRut4m_2sMFZ6ZPQ0A=.26fe5c86-f307-4b61-9d88-4d00b4dbb46c@github.com>
References: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
 <st5vbWLQkCgGsokszdWvaRBVdpInowrn5yOTonaol3E=.e262536c-edc1-4788-9acb-f373f120530a@github.com>
 <WJs0rTsUU0l0e085NjxdNgHq4XRut4m_2sMFZ6ZPQ0A=.26fe5c86-f307-4b61-9d88-4d00b4dbb46c@github.com>
Message-ID: <XPS6DtfHVMSFLLCdEFQBCK7D0D5CIeVzPWisqN4871g=.7dce3a30-97f4-439f-83b6-49c18a667e8a@github.com>

On Thu, 14 Dec 2023 11:39:22 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> (though CopyZipFile could use a junit conversion ;-)

Agreed, I have included that conversion in this PR :-) This test can make good use of `assertThrows` and splitting different concerns into separate test methods.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17038#issuecomment-1855914377

From duke at openjdk.org  Thu Dec 14 14:28:56 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 14 Dec 2023 14:28:56 GMT
Subject: RFR: 8321616: Retire binary test vectors ZipFile/input.jar and
 ZipFile/input.zip [v6]
In-Reply-To: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
References: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
Message-ID: <EhT8NDD3Lbr6PL9sf7_pqH6oyXJUJkyviMHX1nR3ZDA=.242d49bb-f6ee-4cde-952b-46a509c8ab84@github.com>

> This PR suggests we retire the binary test vectors `ZipFile/input.zip` and `ZipFile/input.jar`.
> 
> Binary test vectors are harder to analyze,  and sharing test vectors across unrelated tests increases maintenance burden. It would be better to have each test produce its own test vectors independently.
> 
> While visiting these dusty tests, we should take the opportunity to convert them to JUnit, add more comments and perform some mild modernization and cleanups where appropriate. We should also consider whether any test are duplicated and can be retired, see comments below.
> 
> To help reviewers, here are some comments on the updated tests:
> 
> `Available.java`
> This test currently has no jtreg `@test` header, so isn't currently active. After discussion, we decided to merge this test into `ReadZip.java`. I added some checks to verify that reading from the stream reduces the number of available bytes accordingly, also checking the behavior when the stream is closed.
> 
> `CopyJar.java`
> The concern of copying entries seems to now have better coverage in the test `zip/CopyZipFile`. We decided to retire this test rather than convert it.
> 
> `EnumAfterClose.java`
> To prevent confusion with Java Enums, I suggest we rename this test to `EnumerateAfterClose`.
> 
> `FinalizeInflater.java`  
> The code verified by this test has been updated to use cleaners instead of finalizers. Still, this test code relies on finalizers. Not sure if this is an issue, but this test will need to be updated when finalizers are finally removed.
> 
> `GetDirEntry.java`
> We decided to merge this test into `ReadZip.readDirectoryEntries` rather than keeping it as a separate test.
> 
> `ReadZip.java`
> Nothing exciting here, the single main method was split into multiple JUnit methods, each focusing on a separate concern.
> 
> `ReleaseInflater.java`
> Nothing exciting, tried to add some comment to help understanding of what is tested.
> 
> `StreamZipEntriesTest.java`
> This test was using TestNG so was converted to JUnit for consistency. Added some comments to help understanding.

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Improve comment explaining what happens when ZipEntry.setCompressedSize is calledExplicitly

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17038/files
  - new: https://git.openjdk.org/jdk/pull/17038/files/4e9c97d4..8623effd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17038&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17038&range=04-05

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17038.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17038/head:pull/17038

PR: https://git.openjdk.org/jdk/pull/17038

From rriggs at openjdk.org  Thu Dec 14 14:41:48 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 14 Dec 2023 14:41:48 GMT
Subject: RFR: 8321514: UTF16 string gets constructed incorrectly from
 codepoints if CompactStrings is not enabled [v3]
In-Reply-To: <J1cQFUwodXMQWiwUYQ4nU-Kzq1wt4xUCTf8bB3PnkUY=.e013c379-5a42-49a5-bec4-ce7ec40f5fbf@github.com>
References: <1azLdWceEALX1v_hfgt03ncVu_wtZyk3_lZ0B0J_cto=.a59aff49-50a9-498e-bc78-fd5468d87cd6@github.com>
 <V_zRwOAFyFF-Ff3cUi1ujMNfPNClg59tQBN_Jet0LYE=.74b9e01c-0d32-41f9-a89f-37767c08d829@github.com>
 <J1cQFUwodXMQWiwUYQ4nU-Kzq1wt4xUCTf8bB3PnkUY=.e013c379-5a42-49a5-bec4-ce7ec40f5fbf@github.com>
Message-ID: <oAN9zYjDHYrs2pP66DU8pCQrV49cINKSWgDMAcVRpe0=.ec83b4b3-b7f5-4959-a467-535e40a84dc9@github.com>

On Thu, 14 Dec 2023 12:03:11 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

> Thank you, Roger. Yes, I'll work on the 22 backport.

See https://wiki.openjdk.org/display/SKARA/Backports

Once the mainline is integrated, find the commit and add a "/backport jdk21" comment.
Skara should do the rest (but read the directions also)

Thanks

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17057#issuecomment-1855969887

From avoitylov at openjdk.org  Thu Dec 14 14:41:49 2023
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Thu, 14 Dec 2023 14:41:49 GMT
Subject: Integrated: 8321514: UTF16 string gets constructed incorrectly from
 codepoints if CompactStrings is not enabled
In-Reply-To: <1azLdWceEALX1v_hfgt03ncVu_wtZyk3_lZ0B0J_cto=.a59aff49-50a9-498e-bc78-fd5468d87cd6@github.com>
References: <1azLdWceEALX1v_hfgt03ncVu_wtZyk3_lZ0B0J_cto=.a59aff49-50a9-498e-bc78-fd5468d87cd6@github.com>
Message-ID: <GSzB9p04MmH1kMX0qHFCbtEQo74TBddTyl7C_gVZESs=.b695dcdf-19a9-44e7-b067-8225d69e346e@github.com>

On Mon, 11 Dec 2023 13:48:18 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

> Since JDK-8311906, if CompactStrings is not enabled, index is not considered when calling extractCodepoints from StringUTF16.toBytes(). Because of that the last elements of the source codepoints array are stripped from the resulting UTF16 string, which fires in other places (e.g. during RegEx processing).
>  
> The fix replaces len in extractCodepoints parameters with end that is index + len.

This pull request has now been integrated.

Changeset: fde5b168
Author:    Aleksei Voitylov <avoitylov at openjdk.org>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fde5b16817c3263236993f2e8c2d2469610d99bd
Stats:     27 lines in 2 files changed: 25 ins; 0 del; 2 mod

8321514: UTF16 string gets constructed incorrectly from codepoints if CompactStrings is not enabled

Co-authored-by: Roger Riggs <rriggs at openjdk.org>
Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/17057

From duke at openjdk.org  Thu Dec 14 14:55:08 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 14 Dec 2023 14:55:08 GMT
Subject: RFR: 8321616: Retire binary test vectors ZipFile/input.jar and
 ZipFile/input.zip [v7]
In-Reply-To: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
References: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
Message-ID: <ip6qd-bohoWPTglfA3IVTBU7c46aNspVpVGAsvf_Na0=.b0ea34ea-2b18-430e-80eb-5d90df67a5b3@github.com>

> This PR suggests we retire the binary test vectors `ZipFile/input.zip` and `ZipFile/input.jar`.
> 
> Binary test vectors are harder to analyze,  and sharing test vectors across unrelated tests increases maintenance burden. It would be better to have each test produce its own test vectors independently.
> 
> While visiting these dusty tests, we should take the opportunity to convert them to JUnit, add more comments and perform some mild modernization and cleanups where appropriate. We should also consider whether any test are duplicated and can be retired, see comments below.
> 
> To help reviewers, here are some comments on the updated tests:
> 
> `Available.java`
> This test currently has no jtreg `@test` header, so isn't currently active. After discussion, we decided to merge this test into `ReadZip.java`. I added some checks to verify that reading from the stream reduces the number of available bytes accordingly, also checking the behavior when the stream is closed.
> 
> `CopyJar.java`
> The concern of copying entries seems to now have better coverage in the test `zip/CopyZipFile`. We decided to retire this test rather than convert it and instead convert `CopyZipFile` to JUnit.
> 
> `EnumAfterClose.java`
> To prevent confusion with Java Enums, I suggest we rename this test to `EnumerateAfterClose`.
> 
> `FinalizeInflater.java`  
> The code verified by this test has been updated to use cleaners instead of finalizers. Still, this test code relies on finalizers. Not sure if this is an issue, but this test will need to be updated when finalizers are finally removed.
> 
> `GetDirEntry.java`
> We decided to merge this test into `ReadZip.readDirectoryEntries` rather than keeping it as a separate test.
> 
> `ReadZip.java`
> Nothing exciting here, the single main method was split into multiple JUnit methods, each focusing on a separate concern.
> 
> `ReleaseInflater.java`
> Nothing exciting, tried to add some comment to help understanding of what is tested.
> 
> `StreamZipEntriesTest.java`
> This test was using TestNG so was converted to JUnit for consistency. Added some comments to help understanding.

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Merge the ReadAfterClose test into ReadZip, converting it to JUnit.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17038/files
  - new: https://git.openjdk.org/jdk/pull/17038/files/8623effd..27fe1131

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17038&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17038&range=05-06

  Stats: 84 lines in 3 files changed: 33 ins; 51 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17038.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17038/head:pull/17038

PR: https://git.openjdk.org/jdk/pull/17038

From mcimadamore at openjdk.org  Thu Dec 14 14:57:39 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 14 Dec 2023 14:57:39 GMT
Subject: [jdk22] RFR: 8321400: java/foreign/TestStubAllocFailure.java fails
 with code cache exhaustion
In-Reply-To: <U4vW9bQgNTa5ATbgZvH0q4v_vxGZ3oXYqoaTbZWA0iw=.feb4b156-2083-437e-8a1d-3523c1ad21cf@github.com>
References: <U4vW9bQgNTa5ATbgZvH0q4v_vxGZ3oXYqoaTbZWA0iw=.feb4b156-2083-437e-8a1d-3523c1ad21cf@github.com>
Message-ID: <J-wv9FTGaV5Atr0Xxy-trwW2v18VXr_TuRjKtQfnpmo=.c8609b79-4616-4c00-ba24-8a26b5fc5704@github.com>

On Wed, 13 Dec 2023 17:38:27 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [7ece9e90](https://github.com/openjdk/jdk/commit/7ece9e90c0198f92cdf8d620e346c4a9832724cd) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jorn Vernee on 13 Dec 2023 and was reviewed by Maurizio Cimadamore.
> 
> This is a test-only P4 change. So it's allowed under the release process in RDP1: https://openjdk.org/jeps/3
> 
> Thanks!

(already approved in 23)

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk22/pull/11#pullrequestreview-1782001700

From jvernee at openjdk.org  Thu Dec 14 15:00:44 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 14 Dec 2023 15:00:44 GMT
Subject: [jdk22] Integrated: 8321400: java/foreign/TestStubAllocFailure.java
 fails with code cache exhaustion
In-Reply-To: <U4vW9bQgNTa5ATbgZvH0q4v_vxGZ3oXYqoaTbZWA0iw=.feb4b156-2083-437e-8a1d-3523c1ad21cf@github.com>
References: <U4vW9bQgNTa5ATbgZvH0q4v_vxGZ3oXYqoaTbZWA0iw=.feb4b156-2083-437e-8a1d-3523c1ad21cf@github.com>
Message-ID: <it3JTCOkIxSFjbMKaZwu7wB8ZBQwCoH7ovaoAB38-ak=.b3f27131-cce1-47d8-bc7d-814211e0c274@github.com>

On Wed, 13 Dec 2023 17:38:27 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [7ece9e90](https://github.com/openjdk/jdk/commit/7ece9e90c0198f92cdf8d620e346c4a9832724cd) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jorn Vernee on 13 Dec 2023 and was reviewed by Maurizio Cimadamore.
> 
> This is a test-only P4 change. So it's allowed under the release process in RDP1: https://openjdk.org/jeps/3
> 
> Thanks!

This pull request has now been integrated.

Changeset: d62249a3
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/d62249a3abec28be0b3b9797f899adbdfd941cbe
Stats:     106 lines in 7 files changed: 47 ins; 42 del; 17 mod

8321400: java/foreign/TestStubAllocFailure.java fails with code cache exhaustion

Reviewed-by: mcimadamore
Backport-of: 7ece9e90c0198f92cdf8d620e346c4a9832724cd

-------------

PR: https://git.openjdk.org/jdk22/pull/11

From duke at openjdk.org  Thu Dec 14 15:02:45 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 14 Dec 2023 15:02:45 GMT
Subject: RFR: 8321616: Retire binary test vectors ZipFile/input.jar and
 ZipFile/input.zip [v7]
In-Reply-To: <ip6qd-bohoWPTglfA3IVTBU7c46aNspVpVGAsvf_Na0=.b0ea34ea-2b18-430e-80eb-5d90df67a5b3@github.com>
References: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
 <ip6qd-bohoWPTglfA3IVTBU7c46aNspVpVGAsvf_Na0=.b0ea34ea-2b18-430e-80eb-5d90df67a5b3@github.com>
Message-ID: <VOfG5f4fta1usmRtqkepWj4KSnN8BZ73QeRdxo02lDI=.f2905bde-0c3a-4833-b421-8c18068e356b@github.com>

On Thu, 14 Dec 2023 14:55:08 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR suggests we retire the binary test vectors `ZipFile/input.zip` and `ZipFile/input.jar`.
>> 
>> Binary test vectors are harder to analyze,  and sharing test vectors across unrelated tests increases maintenance burden. It would be better to have each test produce its own test vectors independently.
>> 
>> While visiting these dusty tests, we should take the opportunity to convert them to JUnit, add more comments and perform some mild modernization and cleanups where appropriate. We should also consider whether any test are duplicated and can be retired, see comments below.
>> 
>> To help reviewers, here are some comments on the updated tests:
>> 
>> `Available.java`
>> This test currently has no jtreg `@test` header, so isn't currently active. After discussion, we decided to merge this test into `ReadZip.java`. I added some checks to verify that reading from the stream reduces the number of available bytes accordingly, also checking the behavior when the stream is closed.
>> 
>> `CopyJar.java`
>> The concern of copying entries seems to now have better coverage in the test `zip/CopyZipFile`. We decided to retire this test rather than convert it and instead convert `CopyZipFile` to JUnit.
>> 
>> `EnumAfterClose.java`
>> To prevent confusion with Java Enums, I suggest we rename this test to `EnumerateAfterClose`.
>> 
>> `FinalizeInflater.java`  
>> The code verified by this test has been updated to use cleaners instead of finalizers. Still, this test code relies on finalizers. Not sure if this is an issue, but this test will need to be updated when finalizers are finally removed.
>> 
>> `GetDirEntry.java`
>> We decided to merge this test into `ReadZip.readDirectoryEntries` rather than keeping it as a separate test.
>> 
>> `ReadZip.java`
>> Nothing exciting here, the single main method was split into multiple JUnit methods, each focusing on a separate concern.
>> 
>> `ReleaseInflater.java`
>> Nothing exciting, tried to add some comment to help understanding of what is tested.
>> 
>> `StreamZipEntriesTest.java`
>> This test was using TestNG so was converted to JUnit for consistency. Added some comments to help understanding.
>> 
>> `ReadAfterClose.java`
>> This uses the binary test vector `crash.jar`. The test is converted to JUnit and moved to `ReadZip.readAfterClose?. The test is expanded to exercise more read methods.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merge the ReadAfterClose test into ReadZip, converting it to JUnit.

Seeing that `ReadAfterClose.java` uses a binary test vector `crash.jar`, I think it makes sense to include it in this PR, convert it to JUnit and move it into `ReadZip.readAfterClose`.

This removes the last remaining binary test vector ZIP in the `ZipFile/` directory.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17038#issuecomment-1856008970

From archie.cobbs at gmail.com  Thu Dec 14 15:22:20 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 14 Dec 2023 09:22:20 -0600
Subject: [External] : Re: Introduce constructor for PriorityQueue with
 existing collection and custom comparator
In-Reply-To: <MW4PR10MB5774BD82000BCC031D7B8520FF8CA@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAJXoXUBjq5GeXoNqdBhspvpsPOvT7EXhz6VuZhZVD5=RLOjg4g@mail.gmail.com>
 <F9804F9F-0726-4E27-AFFC-B05062459AF1@oracle.com>
 <CAJXoXUBzNW94rcOzzOj5x3uxAy1y96=BBRu+OeEcX964DUWcdA@mail.gmail.com>
 <CC225658-D639-4E47-A08C-4DC6D4FA2606@oracle.com>
 <MW4PR10MB5774BD82000BCC031D7B8520FF8CA@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CANSoFxsQJSv-LqbyN19+Ai=piLcpvhzR6o7R3E+sbSZ6SbdV5w@mail.gmail.com>

On Thu, Dec 14, 2023 at 4:56?AM Viktor Klang <viktor.klang at oracle.com>
wrote:

> I presume that the precondition to have the original collection be
> pre-ordered according to the supplied Comparator can be verified by
> checking before adding each element in the collection to the PQ that it
> compareTo equal-or-greater to the previous one?
>

Hmm...  something is not adding up.

Either (a) there is a precondition that the collection already be sorted or
(b) there's no such precondition.

In case (a):

   - Why isn't the new constructor invoking initElementsFromCollection()
   instead of initFromCollection()?
   - The precondition is not very obvious from the Javadoc description, and
   moreover what happens when the precondition is not met is not documented at
   all.

In case (b):

   - The Javadoc is misleading because it (ambiguously) implies there is a
   precondition with the wording "collection that orders its elements
   according to the specified comparator" (the referent of "that" is ambiguous
   - does it refer to the collection or the PriorityQueue?)

>From the PR description it seems clear that there is no such precondition.
So maybe the Javadoc should say this instead:

Creates a {@code PriorityQueue} containing the elements in the specified
> collection. The {@code PriorityQueue} will order its elements according to
> the specified comparator.
>

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20231214/4a5db8d1/attachment.htm>

From sspitsyn at openjdk.org  Thu Dec 14 16:59:40 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 14 Dec 2023 16:59:40 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v3]
In-Reply-To: <AZFw8OfcHVn_mnAuNASY39po95wSvXYlcDwHDMY844Q=.4fc7918d-027a-4958-a54d-05fc0c5c86d2@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
 <-3HkgdDQk9480AnHQeIxaNsqK0nVzjaf6UZJ5E9LGHo=.bdff2ed6-db98-4a77-832f-6accad54245f@github.com>
 <FzoKcM3_vYTnfZoA9mK5vkMl4wm4rXSzi73x6-aH4eI=.66ecbb2d-4da1-4153-a1a1-c20b88e24d19@github.com>
 <AZFw8OfcHVn_mnAuNASY39po95wSvXYlcDwHDMY844Q=.4fc7918d-027a-4958-a54d-05fc0c5c86d2@github.com>
Message-ID: <iuaHIgiKquwsoGHG0OOY7-Abu0oax-OC-tZ6efTc6Jc=.0a4975eb-535b-4a2b-8fbb-57e40cab6102@github.com>

On Thu, 14 Dec 2023 12:11:42 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/VirtualThread.java line 1164:
>> 
>>> 1162: 
>>> 1163:     @IntrinsicCandidate
>>> 1164:     private native void notifyJvmtiCriticalLock(boolean enter);
>> 
>> The name is confusing to me, the CriticalLock looks like it is the section is critical and might be taken by a single thread only. Or it's just unclear what is critical here. 
>> However, the purpose is to disable suspend
>> Wouldn't be 'notifyJvmtiSuspendLock notifyJvmtiDisableSuspend' better name here? 
>> or comment what critical means here.
>
> Okay, thanks. I like your name suggestion but let's check with Alan first.

Implemented this renaming suggestion. Let's wait if Alan ia okay with it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1426990736

From naoto at openjdk.org  Thu Dec 14 17:08:02 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 14 Dec 2023 17:08:02 GMT
Subject: RFR: 8321958: javadoc error: @returns of
 ZoneRules#isDaylightSavings() is incorrect [v2]
In-Reply-To: <2150UeprX2CQ34CmEIROihDODlQMKsuPPv3gB-gjChE=.ff26e4a5-48e8-4153-85dc-6f9a7b554116@github.com>
References: <2150UeprX2CQ34CmEIROihDODlQMKsuPPv3gB-gjChE=.ff26e4a5-48e8-4153-85dc-6f9a7b554116@github.com>
Message-ID: <15KaWyH94Qsmj6mnNkgwMVqkSvjVPnlaC6-PlDZZUcU=.e2eed2ca-feb2-4c87-859a-f236a8b7dc8f@github.com>

> Small document correction on a return description.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Corrected @param description

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17098/files
  - new: https://git.openjdk.org/jdk/pull/17098/files/1025c8a0..248fc643

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17098&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17098&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17098.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17098/head:pull/17098

PR: https://git.openjdk.org/jdk/pull/17098

From naoto at openjdk.org  Thu Dec 14 17:08:04 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 14 Dec 2023 17:08:04 GMT
Subject: RFR: 8321958: javadoc error: @returns of
 ZoneRules#isDaylightSavings() is incorrect [v2]
In-Reply-To: <X-ggYwX3D9dAs0-wI0f8Pa5slzF0mUhhae6yjg2FQXQ=.66b63284-2b20-41b1-9bd0-afd26156d191@github.com>
References: <2150UeprX2CQ34CmEIROihDODlQMKsuPPv3gB-gjChE=.ff26e4a5-48e8-4153-85dc-6f9a7b554116@github.com>
 <X-ggYwX3D9dAs0-wI0f8Pa5slzF0mUhhae6yjg2FQXQ=.66b63284-2b20-41b1-9bd0-afd26156d191@github.com>
Message-ID: <vwmEbDIddcQhvbEs5hVfJqvZUPjQ01NWRMYHHbJc5QU=.9b425744-fe19-404e-a138-9e6de50c1056@github.com>

On Thu, 14 Dec 2023 09:32:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Corrected @param description
>
> src/java.base/share/classes/java/time/zone/ZoneRules.java line 831:
> 
>> 829:      * and {@link #getStandardOffset(java.time.Instant) standard} offsets.
>> 830:      *
>> 831:      * @param instant  the instant to find the offset information for, not null, but null
> 
> Hello Naoto, do you think this `@param` description too will have to be reworded? It seems to be a copy/paste of the `getDaylightSavings()` method.

Hi Jai, looks like it was copied/pasted from `getStandardOffset()`, but you are right, the description needs to be corrected.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17098#discussion_r1426999528

From alanb at openjdk.org  Thu Dec 14 17:08:40 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 14 Dec 2023 17:08:40 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v3]
In-Reply-To: <iuaHIgiKquwsoGHG0OOY7-Abu0oax-OC-tZ6efTc6Jc=.0a4975eb-535b-4a2b-8fbb-57e40cab6102@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
 <-3HkgdDQk9480AnHQeIxaNsqK0nVzjaf6UZJ5E9LGHo=.bdff2ed6-db98-4a77-832f-6accad54245f@github.com>
 <FzoKcM3_vYTnfZoA9mK5vkMl4wm4rXSzi73x6-aH4eI=.66ecbb2d-4da1-4153-a1a1-c20b88e24d19@github.com>
 <AZFw8OfcHVn_mnAuNASY39po95wSvXYlcDwHDMY844Q=.4fc7918d-027a-4958-a54d-05fc0c5c86d2@github.com>
 <iuaHIgiKquwsoGHG0OOY7-Abu0oax-OC-tZ6efTc6Jc=.0a4975eb-535b-4a2b-8fbb-57e40cab6102@github.com>
Message-ID: <P7IhpR2SP1PYjAzZWY_SA_0oyX3QCg_aInMAOmodBWA=.1b49331d-c0eb-45d2-8baa-ac2275093530@github.com>

On Thu, 14 Dec 2023 16:57:25 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Implemented this renaming suggestion. Let's wait if Alan ia okay with it.

Are you planning to drop the changes to mount/unmount too? They shouldn't be needed.

notifyJvmtiCriticalLock(boolean) is okay for now but needs to be called before the try, not in the block. We have changes coming that will require moving these hooks to critical section enter/exit methods, so the naming will be less important then.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1427000950

From sspitsyn at openjdk.org  Thu Dec 14 17:30:54 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 14 Dec 2023 17:30:54 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v4]
In-Reply-To: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
Message-ID: <WzKXTFo2JBPvf3F8CvfajpNg1FKsDkSlDBIfpasH66A=.62c2fe31-8aa8-4918-95d6-cd452b18f969@github.com>

> This fix is for JDK 23 but the intention is to back port it to 22 in RDP-1 time frame.
> It is fixing a deadlock issue between `VirtualThread` class critical sections with the `interruptLock` (in methods: `unpark()`, `interrupt()`, `getAndClearInterrupt()`, `threadState()`, `toString()`), `JvmtiVTMSTransitionDisabler` and JVMTI `Suspend/Resume` mechanisms.
> The deadlocking scenario is well described by Patricio in a bug report comment.
> In simple words, a virtual thread should not be suspended during 'interruptLock' critical sections.
> 
> The fix is to record that a virtual thread is in a critical section (`JavaThread`'s `_in_critical_section` bit) by notifying the VM/JVMTI about begin/end of critical section.
> This bit is used in `HandshakeState::get_op_for_self()` to filter out any `HandshakeOperation` if a target `JavaThread` is in a critical section.
> 
> Some of new notifications with `notifyJvmtiSync()` method is on a performance critical path. It is why this method has been intrincified.
> 
> New test was developed by Patricio:
>  `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
> The test is very nice as it reliably in 100% reproduces the deadlock without the fix.
> The test is never failing with this fix.
> 
> Testing:
>  - tested with newly added test: `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
>  - tested with mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: 1) replace CriticalLock with DisableSuspend; 2) minor tweaks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17011/files
  - new: https://git.openjdk.org/jdk/pull/17011/files/18f1752e..4e5f6447

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17011&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17011&range=02-03

  Stats: 68 lines in 14 files changed: 9 ins; 10 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/17011.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17011/head:pull/17011

PR: https://git.openjdk.org/jdk/pull/17011

From sspitsyn at openjdk.org  Thu Dec 14 17:37:39 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 14 Dec 2023 17:37:39 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v3]
In-Reply-To: <P7IhpR2SP1PYjAzZWY_SA_0oyX3QCg_aInMAOmodBWA=.1b49331d-c0eb-45d2-8baa-ac2275093530@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
 <-3HkgdDQk9480AnHQeIxaNsqK0nVzjaf6UZJ5E9LGHo=.bdff2ed6-db98-4a77-832f-6accad54245f@github.com>
 <FzoKcM3_vYTnfZoA9mK5vkMl4wm4rXSzi73x6-aH4eI=.66ecbb2d-4da1-4153-a1a1-c20b88e24d19@github.com>
 <AZFw8OfcHVn_mnAuNASY39po95wSvXYlcDwHDMY844Q=.4fc7918d-027a-4958-a54d-05fc0c5c86d2@github.com>
 <iuaHIgiKquwsoGHG0OOY7-Abu0oax-OC-tZ6efTc6Jc=.0a4975eb-535b-4a2b-8fbb-57e40cab6102@github.com>
 <P7IhpR2SP1PYjAzZWY_SA_0oyX3QCg_aInMAOmodBWA=.1b49331d-c0eb-45d2-8baa-ac2275093530@github.com>
Message-ID: <JVe6SVxYGUoOmS7ppKbW1H28uoNNE3_5w8lbyP7Jfyc=.fd55767a-e044-413d-af1e-b3c0fdb947e6@github.com>

On Thu, 14 Dec 2023 17:06:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Implemented this renaming suggestion. Let's wait if Alan ia okay with it.
>
>> Implemented this renaming suggestion. Let's wait if Alan ia okay with it.
> 
> Are you planning to drop the changes to mount/unmount too? They shouldn't be needed.
> 
> notifyJvmtiCriticalLock(boolean) is okay for now but needs to be called before the try, not in the block. We have changes coming that will require moving these hooks to critical section enter/exit methods, so the naming will be less important then.

Yes, I've dropped changes in the mount/unmount methods.
I've already done renaming to `notifyJvmtiDisableSuspend(boolean)`.
Let's see if it is okay with you. It is not a problem to rename it back to `notifyJvmtiCriticalLock(boolean)`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1427032721

From alanb at openjdk.org  Thu Dec 14 18:06:40 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 14 Dec 2023 18:06:40 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v3]
In-Reply-To: <Jq4j4mBXXX5qzG073iJLr8nU2792K6jVJ_CBcbfPG3U=.8765026e-234d-425a-b142-ff098afbf14a@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
 <-3HkgdDQk9480AnHQeIxaNsqK0nVzjaf6UZJ5E9LGHo=.bdff2ed6-db98-4a77-832f-6accad54245f@github.com>
 <iMRU38pTmsjrxRpF1aXV6gMrj5bei0FE325hwzZ8YB4=.68c88f85-f4a2-4e1f-8ba7-22f8ba70be21@github.com>
 <Jq4j4mBXXX5qzG073iJLr8nU2792K6jVJ_CBcbfPG3U=.8765026e-234d-425a-b142-ff098afbf14a@github.com>
Message-ID: <0IfR_dHcE18gNj1SXT6J0RppMZ2bNU7U51iqi-25bh0=.728701de-31f3-4a6e-a454-a4395f4effe5@github.com>

On Thu, 14 Dec 2023 12:19:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Okay. What about the Leonid's suggestion to name it `notifyJvmtiDisableSuspend()` ?

Okay with me. We'll need to move the notifyJvmtiDisableSuspend(true) to before the try in all cases, I've pointed out the cases that we missed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17011#issuecomment-1856339508

From alanb at openjdk.org  Thu Dec 14 18:06:47 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 14 Dec 2023 18:06:47 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v4]
In-Reply-To: <WzKXTFo2JBPvf3F8CvfajpNg1FKsDkSlDBIfpasH66A=.62c2fe31-8aa8-4918-95d6-cd452b18f969@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
 <WzKXTFo2JBPvf3F8CvfajpNg1FKsDkSlDBIfpasH66A=.62c2fe31-8aa8-4918-95d6-cd452b18f969@github.com>
Message-ID: <7LcxdLPaxGRqXIER2MYIoCk6yk0CCnzLk-CtSn7A800=.1de3bfc7-4dc0-443f-bc48-983c22f24766@github.com>

On Thu, 14 Dec 2023 17:30:54 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fix is for JDK 23 but the intention is to back port it to 22 in RDP-1 time frame.
>> It is fixing a deadlock issue between `VirtualThread` class critical sections with the `interruptLock` (in methods: `unpark()`, `interrupt()`, `getAndClearInterrupt()`, `threadState()`, `toString()`), `JvmtiVTMSTransitionDisabler` and JVMTI `Suspend/Resume` mechanisms.
>> The deadlocking scenario is well described by Patricio in a bug report comment.
>> In simple words, a virtual thread should not be suspended during 'interruptLock' critical sections.
>> 
>> The fix is to record that a virtual thread is in a critical section (`JavaThread`'s `_in_critical_section` bit) by notifying the VM/JVMTI about begin/end of critical section.
>> This bit is used in `HandshakeState::get_op_for_self()` to filter out any `HandshakeOperation` if a target `JavaThread` is in a critical section.
>> 
>> Some of new notifications with `notifyJvmtiSync()` method is on a performance critical path. It is why this method has been intrincified.
>> 
>> New test was developed by Patricio:
>>  `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
>> The test is very nice as it reliably in 100% reproduces the deadlock without the fix.
>> The test is never failing with this fix.
>> 
>> Testing:
>>  - tested with newly added test: `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: 1) replace CriticalLock with DisableSuspend; 2) minor tweaks

src/java.base/share/classes/java/lang/VirtualThread.java line 746:

> 744:             } else if ((s == PINNED) || (s == TIMED_PINNED)) {
> 745:                 try {
> 746:                     notifyJvmtiDisableSuspend(true);

Move to before the try.

src/java.base/share/classes/java/lang/VirtualThread.java line 853:

> 851:             checkAccess();
> 852:             try {
> 853:                 notifyJvmtiDisableSuspend(true);

This one also needs to be before try.

src/java.base/share/classes/java/lang/VirtualThread.java line 886:

> 884:         if (oldValue) {
> 885:             try {
> 886:                 notifyJvmtiDisableSuspend(true);

This one also needs to be before try.

src/java.base/share/classes/java/lang/VirtualThread.java line 917:

> 915:             case RUNNING:
> 916:                 try {
> 917:                     notifyJvmtiDisableSuspend(true);

This one also needs to be before try.

src/java.base/share/classes/java/lang/VirtualThread.java line 1042:

> 1040:         if (carrier != null) {
> 1041:             try {
> 1042:                 notifyJvmtiDisableSuspend(true);

this one too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1427080057
PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1427080394
PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1427080484
PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1427080704
PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1427080811

From sspitsyn at openjdk.org  Thu Dec 14 18:26:55 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 14 Dec 2023 18:26:55 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v5]
In-Reply-To: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
Message-ID: <bR2FzlWdDHZ0LcbnsU_f95F1QlA5uMe-JHquxbJpOCg=.f441cf9f-9752-4eb4-a389-0da3c8938427@github.com>

> This fix is for JDK 23 but the intention is to back port it to 22 in RDP-1 time frame.
> It is fixing a deadlock issue between `VirtualThread` class critical sections with the `interruptLock` (in methods: `unpark()`, `interrupt()`, `getAndClearInterrupt()`, `threadState()`, `toString()`), `JvmtiVTMSTransitionDisabler` and JVMTI `Suspend/Resume` mechanisms.
> The deadlocking scenario is well described by Patricio in a bug report comment.
> In simple words, a virtual thread should not be suspended during 'interruptLock' critical sections.
> 
> The fix is to record that a virtual thread is in a critical section (`JavaThread`'s `_in_critical_section` bit) by notifying the VM/JVMTI about begin/end of critical section.
> This bit is used in `HandshakeState::get_op_for_self()` to filter out any `HandshakeOperation` if a target `JavaThread` is in a critical section.
> 
> Some of new notifications with `notifyJvmtiSync()` method is on a performance critical path. It is why this method has been intrincified.
> 
> New test was developed by Patricio:
>  `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
> The test is very nice as it reliably in 100% reproduces the deadlock without the fix.
> The test is never failing with this fix.
> 
> Testing:
>  - tested with newly added test: `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
>  - tested with mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: moved notifyJvmtiDisableSuspend(true) out of try-block

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17011/files
  - new: https://git.openjdk.org/jdk/pull/17011/files/4e5f6447..ad990422

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17011&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17011&range=03-04

  Stats: 10 lines in 1 file changed: 5 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17011.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17011/head:pull/17011

PR: https://git.openjdk.org/jdk/pull/17011

From sspitsyn at openjdk.org  Thu Dec 14 18:26:56 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 14 Dec 2023 18:26:56 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v3]
In-Reply-To: <0IfR_dHcE18gNj1SXT6J0RppMZ2bNU7U51iqi-25bh0=.728701de-31f3-4a6e-a454-a4395f4effe5@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
 <-3HkgdDQk9480AnHQeIxaNsqK0nVzjaf6UZJ5E9LGHo=.bdff2ed6-db98-4a77-832f-6accad54245f@github.com>
 <iMRU38pTmsjrxRpF1aXV6gMrj5bei0FE325hwzZ8YB4=.68c88f85-f4a2-4e1f-8ba7-22f8ba70be21@github.com>
 <Jq4j4mBXXX5qzG073iJLr8nU2792K6jVJ_CBcbfPG3U=.8765026e-234d-425a-b142-ff098afbf14a@github.com>
 <0IfR_dHcE18gNj1SXT6J0RppMZ2bNU7U51iqi-25bh0=.728701de-31f3-4a6e-a454-a4395f4effe5@github.com>
Message-ID: <pAUUTvuBz4ZsKwmtGTn35yKj7kw8rFG-FfrMb6hJDIA=.fb59fded-bbf2-47b9-8961-1f2001b67a01@github.com>

On Thu, 14 Dec 2023 18:04:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Okay with me. We'll need to move the notifyJvmtiDisableSuspend(true) to before the try in all cases, I've pointed out the cases that we missed.

Thank you, Alan. Fixed now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17011#issuecomment-1856366484

From sspitsyn at openjdk.org  Thu Dec 14 18:26:57 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 14 Dec 2023 18:26:57 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v3]
In-Reply-To: <fnYIsaA7ccrP0K-247Z0WiwpCpfypHDsy-ZxfsObw8I=.5e2c62d0-2c5c-459c-8e65-af399c086e1c@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
 <-3HkgdDQk9480AnHQeIxaNsqK0nVzjaf6UZJ5E9LGHo=.bdff2ed6-db98-4a77-832f-6accad54245f@github.com>
 <FzoKcM3_vYTnfZoA9mK5vkMl4wm4rXSzi73x6-aH4eI=.66ecbb2d-4da1-4153-a1a1-c20b88e24d19@github.com>
 <fnYIsaA7ccrP0K-247Z0WiwpCpfypHDsy-ZxfsObw8I=.5e2c62d0-2c5c-459c-8e65-af399c086e1c@github.com>
Message-ID: <EFxJPdrHjnUuuCyY73yo6dY2niGWtFaCiJZcka4Tp3c=.95792e31-8b40-43e8-91da-374dcee76720@github.com>

On Thu, 14 Dec 2023 12:16:34 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/runtime/javaThread.hpp line 320:
>> 
>>> 318:   bool                  _is_in_VTMS_transition;          // thread is in virtual thread mount state transition
>>> 319:   bool                  _is_in_tmp_VTMS_transition;      // thread is in temporary virtual thread mount state transition
>>> 320:   bool                  _is_in_critical_section;         // thread is in a locking critical section
>> 
>> might make sense to add a comment, that his variable Is changed/read only by current thread and no sync is needed.
>
> Good suggestion, thanks.

Fixed now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1427099325

From sspitsyn at openjdk.org  Thu Dec 14 18:27:00 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 14 Dec 2023 18:27:00 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v4]
In-Reply-To: <7LcxdLPaxGRqXIER2MYIoCk6yk0CCnzLk-CtSn7A800=.1de3bfc7-4dc0-443f-bc48-983c22f24766@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
 <WzKXTFo2JBPvf3F8CvfajpNg1FKsDkSlDBIfpasH66A=.62c2fe31-8aa8-4918-95d6-cd452b18f969@github.com>
 <7LcxdLPaxGRqXIER2MYIoCk6yk0CCnzLk-CtSn7A800=.1de3bfc7-4dc0-443f-bc48-983c22f24766@github.com>
Message-ID: <ejTIPhlOHYY200lC-dRuIa4KXYKESN3KDNQtYoP7cg4=.d96c0cd4-2c2e-4047-9063-c6c343304f24@github.com>

On Thu, 14 Dec 2023 18:03:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: 1) replace CriticalLock with DisableSuspend; 2) minor tweaks
>
> src/java.base/share/classes/java/lang/VirtualThread.java line 1042:
> 
>> 1040:         if (carrier != null) {
>> 1041:             try {
>> 1042:                 notifyJvmtiDisableSuspend(true);
> 
> this one too.

Thanks. All cases fixed now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1427095561

From joehw at openjdk.org  Thu Dec 14 19:04:41 2023
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 14 Dec 2023 19:04:41 GMT
Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update
In-Reply-To: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
References: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
Message-ID: <dsMlRFjnSPD-o6ihRbzbBI93HYkNtbUONmZPxew9DfM=.3fbc999c-ec8e-454a-92f3-41ee4adbfb2a@github.com>

On Wed, 13 Dec 2023 22:12:48 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Translation drop for JDK22 RDP1

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties line 331:

> 329: 
> 330: # Implementation Property DTD
> 331:         JDK_DTD_DENY = JAXP00010008: DOCTYPE ist nicht zul?ssig, wenn die DTD-Eigenschaft auf "Ablehnen" gesetzt wurde. Weitere Informationen: Eigenschaft jdk.xml.dtd.support in java.xml/module-summary.

This version quoted "Ablehnen" while the other two (ja - "??" and zh_CN - "??") didn't. If we want to be consistent, "deny" would be better since that's the literal value. The English version should have quoted "deny".

The previous translations in these files have not been consistent. Some of the key words were translated. If we want to keep this translation as is, it's probably better to remove the quote in the "de" file.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17096#discussion_r1427152545

From louisb at broadinstitute.org  Thu Dec 14 19:08:48 2023
From: louisb at broadinstitute.org (Louis Bergelson)
Date: Thu, 14 Dec 2023 14:08:48 -0500
Subject: Bug in GZIPInputStream.read() causing data loss
Message-ID: <CALexLmEckXqPSVp3n=7ZizzQVfqVfS_Hmr220C0K00iYEmuW1g@mail.gmail.com>

Hello.  This is my first time posting here so I apologize if this is the
wrong forum.  I wanted to bring up an issue in the GZipInputStream which
was first identified in 2011, confirmed as a bug, and then never resolved.

When reading certain GZIP files from certain types of InputStreams the
GZIPInputStream can misidentify the end of the stream and close early
resulting in silently truncated data.

You can see the bug report which has a detailed description here:
https://bugs.openjdk.org/browse/JDK-7036144

In short it comes down to incorrect use of the (quite confusing)
InputStream.available() method to detect the end of stream.  This typically
works fine with local files, but with network streams that might not have
bytes available at any given moment it fails nondeterministically.

How could I go about getting this fixed?  I can contribute a patch or
additional examples if necessary.

Genomics data is typically encoded as block gzipped files, so this comes up
regularly and causes a lot of confusion.  The workaround is to just not use
the GZIPInput stream.  It seems like a core java class though so it would
be nice if it worked.

Thank you,
Louis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20231214/35025ffd/attachment-0001.htm>

From joehw at openjdk.org  Thu Dec 14 19:24:42 2023
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 14 Dec 2023 19:24:42 GMT
Subject: RFR: 8322027: One XMLStreamException constructor fails to
 initialize cause
In-Reply-To: <xf8pPEe5y0FMqqd49evp9MaMOwcqf7_9WFn40tzoVMU=.60d5f3d1-18f5-4405-aeb6-b953f0b2e68b@github.com>
References: <u7DJBcsIFuCxTDzXam9n5PViiYT-JBphdRh_2MAFVPk=.94e7ef25-1089-41e9-9606-b6820a71527f@github.com>
 <xf8pPEe5y0FMqqd49evp9MaMOwcqf7_9WFn40tzoVMU=.60d5f3d1-18f5-4405-aeb6-b953f0b2e68b@github.com>
Message-ID: <MCdxnzz5RWtmBf-ZvWZRDLZMUQ6wSWMZIjQdLlBgt1Y=.58cbb80d-89d8-422a-9450-b217c04d293a@github.com>

On Wed, 13 Dec 2023 21:25:19 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> After filing this PR, I had some second thoughts and added them to the summary but by then it was too late for the `core-libs-dev` email, so I'll repeat here in case anyone has some comments:
> 
> > It's worth considering if there is any code out there that is working around this problem already by invoking `initCause()` manually. If so, that code would start throwing an `IllegalStateException` after this change.
> > So a more conservative fix would be to just add another constructor taking the same arguments in a different order. But then again that's not much better than just saying "always use `initCause()` with the broken constructor", i.e., don't change anything.
> > Hmm.

Yeah, it may make sense to create a CSR to document the behavior change. My take is that the benefit outweighs the potential drawback. I've seen a case a few days ago where the use of this constructor caused the original cause to be lost. Attempting to work around the issue by invoking 'initCause()" won't necessarily be a good solution given other constructors can be used to avoid the issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17090#issuecomment-1856445263

From bpb at openjdk.org  Thu Dec 14 19:24:58 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 14 Dec 2023 19:24:58 GMT
Subject: RFR: 8297632: InputStream.transferTo() method should specify what
 the return value should be when the number of bytes transfered is
 larger than Long.MAX_VALUE [v7]
In-Reply-To: <9huCKnW7RWabo1GGXTDzXEVpXL3mt31s9BXc5bpQ6_8=.924b4b05-0943-45e0-92d2-fd36042d6495@github.com>
References: <T38kO1hcz3rhpqOOPYmoPl1TlRORJBifQWtXLl10x8Y=.595338d3-df98-4202-95b5-eda88a4ed0a2@github.com>
 <_9WmGHHPiqNaJ2l5vg1qvYvgj9rTKtnYYLt7Gi2x2uQ=.d56479a0-8948-4f76-9e7a-f9661766a281@github.com>
 <9huCKnW7RWabo1GGXTDzXEVpXL3mt31s9BXc5bpQ6_8=.924b4b05-0943-45e0-92d2-fd36042d6495@github.com>
Message-ID: <smBRnTsPYhT6VoOO-M0fwGI9wTjwGhgi6N_hYMslAv0=.1d60c1f4-ccb6-4cdb-932e-a4d0b0c37485@github.com>

On Thu, 14 Dec 2023 06:12:40 GMT, Vladimir Sitnikov <vsitnikov at openjdk.org> wrote:

> What do you think?

I think that you are looking at an obsolete repository:

https://github.com/openjdk/jdk/blob/c328f9589ddc3a981a2c63801bd991f8e593e69f/src/java.base/share/classes/java/io/InputStream.java#L802

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11403#discussion_r1427171307

From naoto at openjdk.org  Thu Dec 14 19:25:41 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 14 Dec 2023 19:25:41 GMT
Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update
In-Reply-To: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
References: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
Message-ID: <L7ojiF0-qtrRJ6kgXJuFd3aHcUafKYpaQTMEc3hKnwg=.60825019-a8b5-4ff6-a74c-94bb7005bced@github.com>

On Wed, 13 Dec 2023 22:12:48 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Translation drop for JDK22 RDP1

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_ja.properties line 111:

> 109: doclet.Factory=?????:
> 110: doclet.UnknownTag=??????????????????
> 111: doclet.UnknownTagWithHint=?????????????@{0}???????????????

Simply appending a question mark may read a bit odd, although it is a straightforward translation from English.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_ja.properties line 88:

> 86: dc.tag.start.unmatched = ??????????: </{0}>
> 87: dc.unknown.javadoc.tag = ??????????????????
> 88: dc.unknown.javadoc.tag.with.hint = ?????????????@{0}???????????????

same here

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17096#discussion_r1427170568
PR Review Comment: https://git.openjdk.org/jdk/pull/17096#discussion_r1427171135

From magnus.eriksson at gmail.com  Thu Dec 14 06:10:02 2023
From: magnus.eriksson at gmail.com (Magnus)
Date: Thu, 14 Dec 2023 07:10:02 +0100
Subject: More support for offset and length in methods operating on byte arrays
Message-ID: <CAP_KEpcmqRhmUVsRHTyV+H6CFPvOpnrSz7OTd3OSL-vqgjyaPA@mail.gmail.com>

In the java libraries there are many methods that operate on byte arrays
that do not allow you to specify offset and length for the relevant data
instead forcing you to copy the relevant part to new arrays before using
the methods reducing performance - I am for instance struggling with this
in java.util.Base64 where the Encoders and Decoders lack a length parameter
(also an offset would have been great even though I don't need that in my
case).

In my system I adds data of unknown length to large buffers that in many
cases only will be partially filled and when I need to BASE64 encode data
in these buffers I now have to create new "right sized" byte arrays and
copy the relevant data from the larger buffer to the new byte array. This
is a waste of CPU time & memory access that I would be happy to avoid.

In this specific case of the Encoders there exists already internal methods
that accepts a length for the source buffer but these are private rather
than protected preventing me from simply creating a subclass that adds such
methods. Making JDK libraries a bit more subclassing friendly would also be
great :-)

As it stands now I have created by own implementation of the Base64 class
(from the JDK sources) that adds a method with the desired "length"
parameter for use in my project but this is obviously not a good solution
as I from now on needs to maintain this class and also misses out on
improvements made to the original JDK library version...

/Trist
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20231214/956a6a31/attachment-0001.htm>

From jlu at openjdk.org  Thu Dec 14 19:46:41 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 14 Dec 2023 19:46:41 GMT
Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update
In-Reply-To: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
References: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
Message-ID: <H5RoLt8IbybQX6PGHDO1nCQMyPO_UpftllwuKLp20E8=.21c243f7-03bf-4667-ba18-d0751fa15b1a@github.com>

On Wed, 13 Dec 2023 22:12:48 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Translation drop for JDK22 RDP1

All around LGTM. From a skim I don't see any of the typical l10n related file mode issues, line ending issues, or values that should not be changed (like _WixLocalization Culture_). Might be worth filing a bug against the translation tool to see if it could support multi line translations for localized versions as @sormuras pointed out.

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties line 2293:

> 2291: compiler.err.underscore.as.identifier=Ab Release 9 ist "_" ein Schl?sselwort und kann nicht als ID verwendet werden
> 2292: 
> 2293: compiler.err.use.of.underscore.not.allowed=Unterstrich ist hier nicht zul?ssig\nAb Release 9 ist ''_'' ein Schl?sselwort und kann nicht als ID verwendet werden\nAb Release 22 kann ''_'' als Name in der Deklaration unbenannter Muster, lokaler Variablen, Ausnahmeparameter oder Lambda-Parameter verwendet werden

Just an observation, but the double quotes were converted to (two) single quotes. Previously, localized de files represented '' '' as " ", as different languages have different l10n rules (according to the translation contact). And this is seen with the other values on this file using "" instead of '' ''.

But here it looks like they updated the value to match the quotes in of the value in the original .properties files. Not sure if they updated the rules and this is intentional, or unintentional.

-------------

PR Review: https://git.openjdk.org/jdk/pull/17096#pullrequestreview-1782404582
PR Review Comment: https://git.openjdk.org/jdk/pull/17096#discussion_r1427080553

From alanb at openjdk.org  Thu Dec 14 19:53:40 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 14 Dec 2023 19:53:40 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v3]
In-Reply-To: <pAUUTvuBz4ZsKwmtGTn35yKj7kw8rFG-FfrMb6hJDIA=.fb59fded-bbf2-47b9-8961-1f2001b67a01@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
 <-3HkgdDQk9480AnHQeIxaNsqK0nVzjaf6UZJ5E9LGHo=.bdff2ed6-db98-4a77-832f-6accad54245f@github.com>
 <iMRU38pTmsjrxRpF1aXV6gMrj5bei0FE325hwzZ8YB4=.68c88f85-f4a2-4e1f-8ba7-22f8ba70be21@github.com>
 <Jq4j4mBXXX5qzG073iJLr8nU2792K6jVJ_CBcbfPG3U=.8765026e-234d-425a-b142-ff098afbf14a@github.com>
 <0IfR_dHcE18gNj1SXT6J0RppMZ2bNU7U51iqi-25bh0=.728701de-31f3-4a6e-a454-a4395f4effe5@github.com>
 <pAUUTvuBz4ZsKwmtGTn35yKj7kw8rFG-FfrMb6hJDIA=.fb59fded-bbf2-47b9-8961-1f2001b67a01@github.com>
Message-ID: <IwWiz01X65vBYii3fm2AZTrNuUZB3q8k2s_Onn6x0Z0=.c3068d9c-9544-446f-a167-de30843a9a1c@github.com>

On Thu, 14 Dec 2023 18:24:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Thank you, Alan. Fixed now. I believe, all your suggestions have been addressed now.

Thanks, it looks much better now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17011#issuecomment-1856485757

From alanb at openjdk.org  Thu Dec 14 19:53:44 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 14 Dec 2023 19:53:44 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v5]
In-Reply-To: <bR2FzlWdDHZ0LcbnsU_f95F1QlA5uMe-JHquxbJpOCg=.f441cf9f-9752-4eb4-a389-0da3c8938427@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
 <bR2FzlWdDHZ0LcbnsU_f95F1QlA5uMe-JHquxbJpOCg=.f441cf9f-9752-4eb4-a389-0da3c8938427@github.com>
Message-ID: <vK7AfcTSTwnVicVwyAeij-1qHzB3YXXmyHVbeR0h9LM=.7d1ee559-18c6-4514-baef-058b4dad8a40@github.com>

On Thu, 14 Dec 2023 18:26:55 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fix is for JDK 23 but the intention is to back port it to 22 in RDP-1 time frame.
>> It is fixing a deadlock issue between `VirtualThread` class critical sections with the `interruptLock` (in methods: `unpark()`, `interrupt()`, `getAndClearInterrupt()`, `threadState()`, `toString()`), `JvmtiVTMSTransitionDisabler` and JVMTI `Suspend/Resume` mechanisms.
>> The deadlocking scenario is well described by Patricio in a bug report comment.
>> In simple words, a virtual thread should not be suspended during 'interruptLock' critical sections.
>> 
>> The fix is to record that a virtual thread is in a critical section (`JavaThread`'s `_in_critical_section` bit) by notifying the VM/JVMTI about begin/end of critical section.
>> This bit is used in `HandshakeState::get_op_for_self()` to filter out any `HandshakeOperation` if a target `JavaThread` is in a critical section.
>> 
>> Some of new notifications with `notifyJvmtiSync()` method is on a performance critical path. It is why this method has been intrincified.
>> 
>> New test was developed by Patricio:
>>  `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
>> The test is very nice as it reliably in 100% reproduces the deadlock without the fix.
>> The test is never failing with this fix.
>> 
>> Testing:
>>  - tested with newly added test: `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: moved notifyJvmtiDisableSuspend(true) out of try-block

src/java.base/share/classes/java/lang/VirtualThread.java line 918:

> 916:                 notifyJvmtiDisableSuspend(true);
> 917:                 try {
> 918:                     // if mounted then return state of carrier thread

Can you move this comment line to before the notifyJvmtiDisableSuspend(true)?

src/java.base/share/classes/java/lang/VirtualThread.java line 1043:

> 1041:             notifyJvmtiDisableSuspend(true);
> 1042:             try {
> 1043:                 // include the carrier thread state and name when mounted

This one too, can you move the comment to before the notifyJvmtiDisableSuspend.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1427198296
PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1427198673

From pavel.rappo at oracle.com  Thu Dec 14 19:57:09 2023
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Thu, 14 Dec 2023 19:57:09 +0000
Subject: More support for offset and length in methods operating on byte
 arrays
In-Reply-To: <CAP_KEpcmqRhmUVsRHTyV+H6CFPvOpnrSz7OTd3OSL-vqgjyaPA@mail.gmail.com>
References: <CAP_KEpcmqRhmUVsRHTyV+H6CFPvOpnrSz7OTd3OSL-vqgjyaPA@mail.gmail.com>
Message-ID: <5C10C2BA-AB39-45C5-B0D6-8679FCACFF56@oracle.com>



> On 14 Dec 2023, at 06:10, Magnus <magnus.eriksson at gmail.com> wrote:
> 
> In the java libraries there are many methods that operate on byte arrays that do not allow you to specify offset and length for the relevant data instead forcing you to copy the relevant part to new arrays before using the methods reducing performance - I am for instance struggling with this in java.util.Base64 where the Encoders and Decoders lack a length parameter (also an offset would have been great even though I don't need that in my case). 

Re: java.util.Base64. Encoder and Decoder also seem to be able to work with ByteBuffer. If you have an array, you can cheaply create a ByteBuffer wrapper around that array. The now-backing array would be read or written though from the specific position and up to the specific limit. Would that help?

-Pavel


From acobbs at openjdk.org  Thu Dec 14 20:10:40 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 14 Dec 2023 20:10:40 GMT
Subject: RFR: 8322027: One XMLStreamException constructor fails to
 initialize cause
In-Reply-To: <u7DJBcsIFuCxTDzXam9n5PViiYT-JBphdRh_2MAFVPk=.94e7ef25-1089-41e9-9606-b6820a71527f@github.com>
References: <u7DJBcsIFuCxTDzXam9n5PViiYT-JBphdRh_2MAFVPk=.94e7ef25-1089-41e9-9606-b6820a71527f@github.com>
Message-ID: <V_z6l6XEVGh4-DAoeY5t-YPFNk36NsZBhaPF_cG_V0U=.b8c5a4be-af8d-42a0-bfc0-8b46129f1ae2@github.com>

On Wed, 13 Dec 2023 20:06:03 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> One of the three `XMLStreamException` constructors that takes a `Throwable` fails to pass it to the superclass constructor.
> 
> This simple patch fixes that omission.
> 
> It's worth considering if there is any code out there that is working around this problem already by invoking `initCause()` manually. If so, that code would start throwing an `IllegalStateException` after this change.
> 
> So a more conservative fix would be to just add another constructor taking the same arguments in a different order. But then again that's not much better than just saying "always use initCause() with the broken constructor", i.e., don't change anything.
> 
> Hmm.

I agree - let's go the CSR route.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17090#issuecomment-1856510107

From archie.cobbs at gmail.com  Thu Dec 14 20:15:57 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 14 Dec 2023 14:15:57 -0600
Subject: Bug in GZIPInputStream.read() causing data loss
In-Reply-To: <CALexLmEckXqPSVp3n=7ZizzQVfqVfS_Hmr220C0K00iYEmuW1g@mail.gmail.com>
References: <CALexLmEckXqPSVp3n=7ZizzQVfqVfS_Hmr220C0K00iYEmuW1g@mail.gmail.com>
Message-ID: <CANSoFxs6vWDtufULUtWN2fbeC84yAZvusiqPuHJZuk1qC0jgKg@mail.gmail.com>

Hi Louis,

On first glance this looks easy to fix. I've filed a draft PR here (pending
tests) https://github.com/openjdk/jdk/pull/17113

-Archie

On Thu, Dec 14, 2023 at 1:10?PM Louis Bergelson <louisb at broadinstitute.org>
wrote:

> Hello.  This is my first time posting here so I apologize if this is the
> wrong forum.  I wanted to bring up an issue in the GZipInputStream which
> was first identified in 2011, confirmed as a bug, and then never resolved.
>
> When reading certain GZIP files from certain types of InputStreams the
> GZIPInputStream can misidentify the end of the stream and close early
> resulting in silently truncated data.
>
> You can see the bug report which has a detailed description here:
> https://bugs.openjdk.org/browse/JDK-7036144
>
> In short it comes down to incorrect use of the (quite confusing)
> InputStream.available() method to detect the end of stream.  This typically
> works fine with local files, but with network streams that might not have
> bytes available at any given moment it fails nondeterministically.
>
> How could I go about getting this fixed?  I can contribute a patch or
> additional examples if necessary.
>
> Genomics data is typically encoded as block gzipped files, so this comes
> up regularly and causes a lot of confusion.  The workaround is to just not
> use the GZIPInput stream.  It seems like a core java class though so it
> would be nice if it worked.
>
> Thank you,
> Louis
>


-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20231214/d6b72f44/attachment.htm>

From vsitnikov at openjdk.org  Thu Dec 14 20:23:56 2023
From: vsitnikov at openjdk.org (Vladimir Sitnikov)
Date: Thu, 14 Dec 2023 20:23:56 GMT
Subject: RFR: 8297632: InputStream.transferTo() method should specify what
 the return value should be when the number of bytes transfered is
 larger than Long.MAX_VALUE [v7]
In-Reply-To: <smBRnTsPYhT6VoOO-M0fwGI9wTjwGhgi6N_hYMslAv0=.1d60c1f4-ccb6-4cdb-932e-a4d0b0c37485@github.com>
References: <T38kO1hcz3rhpqOOPYmoPl1TlRORJBifQWtXLl10x8Y=.595338d3-df98-4202-95b5-eda88a4ed0a2@github.com>
 <_9WmGHHPiqNaJ2l5vg1qvYvgj9rTKtnYYLt7Gi2x2uQ=.d56479a0-8948-4f76-9e7a-f9661766a281@github.com>
 <9huCKnW7RWabo1GGXTDzXEVpXL3mt31s9BXc5bpQ6_8=.924b4b05-0943-45e0-92d2-fd36042d6495@github.com>
 <smBRnTsPYhT6VoOO-M0fwGI9wTjwGhgi6N_hYMslAv0=.1d60c1f4-ccb6-4cdb-932e-a4d0b0c37485@github.com>
Message-ID: <mvUWAuiQVz3jl8PPdcc8CP1wpasHqusn39L4UvgugI0=.77f04ab1-1199-4228-a121-32259e3a096c@github.com>

On Thu, 14 Dec 2023 19:22:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/SequenceInputStream.java line 249:
>> 
>>> 247:                         transferred = Math.addExact(transferred, in.transferTo(out));
>>> 248:                     } catch (ArithmeticException ignore) {
>>> 249:                         return Long.MAX_VALUE;
>> 
>> @bplb , this looks like a bug to me: once `transferred` reaches `Long.MAX_VALUE` the transfer loop will terminate and the transfer will stop even in the case there are more streams available in the sequence.
>> 
>> I think the proper code should be `transferred = Long.MAX_VALUE` instead of `return Long.MAX_VALUE` (and there should be no `if (transferred < Long.MAX_VALUE)` check)
>> 
>> What do you think?
>
>> What do you think?
> 
> I think that you are looking at an obsolete repository:
> 
> https://github.com/openjdk/jdk/blob/c328f9589ddc3a981a2c63801bd991f8e593e69f/src/java.base/share/classes/java/io/InputStream.java#L802

I mean SequenceInputStream, not the base class: https://github.com/openjdk/jdk/blob/c328f9589ddc3a981a2c63801bd991f8e593e69f/src/java.base/share/classes/java/io/SequenceInputStream.java#L249

Could you please double-check?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11403#discussion_r1427231492

From pavel.rappo at oracle.com  Thu Dec 14 20:24:25 2023
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Thu, 14 Dec 2023 20:24:25 +0000
Subject: More support for offset and length in methods operating on byte
 arrays
In-Reply-To: <5C10C2BA-AB39-45C5-B0D6-8679FCACFF56@oracle.com>
References: <CAP_KEpcmqRhmUVsRHTyV+H6CFPvOpnrSz7OTd3OSL-vqgjyaPA@mail.gmail.com>
 <5C10C2BA-AB39-45C5-B0D6-8679FCACFF56@oracle.com>
Message-ID: <379370CD-15FF-4C3B-8F98-8EC6A5F0BF49@oracle.com>

Upon a closer look, switching to ByteBuffer would only get you 50% towards where you want to be: the resulting ByteBuffer, whether encoded or decoded, is *allocated* by the respective methods and then returned as a result rather than accepted by those methods as a parameter.

> On 14 Dec 2023, at 19:57, Pavel Rappo <pavel.rappo at oracle.com> wrote:
> 
> 
> 
>> On 14 Dec 2023, at 06:10, Magnus <magnus.eriksson at gmail.com> wrote:
>> 
>> In the java libraries there are many methods that operate on byte arrays that do not allow you to specify offset and length for the relevant data instead forcing you to copy the relevant part to new arrays before using the methods reducing performance - I am for instance struggling with this in java.util.Base64 where the Encoders and Decoders lack a length parameter (also an offset would have been great even though I don't need that in my case).
> 
> Re: java.util.Base64. Encoder and Decoder also seem to be able to work with ByteBuffer. If you have an array, you can cheaply create a ByteBuffer wrapper around that array. The now-backing array would be read or written though from the specific position and up to the specific limit. Would that help?
> 
> -Pavel
> 


From duke at openjdk.org  Thu Dec 14 20:30:45 2023
From: duke at openjdk.org (Valeh Hajiyev)
Date: Thu, 14 Dec 2023 20:30:45 GMT
Subject: RFR: 6356745: Introduce constructor for PriorityQueue with existing
 collection and custom comparator
Message-ID: <zAcGyJ33ZP0osNg-HMJp4UCtOXYzdqi969ugDhJ7954=.c5f8e2de-cfe8-4224-a98e-70f49da9a7a3@github.com>

This commit addresses the current limitation in the `PriorityQueue` implementation, which lacks a constructor to efficiently create a priority queue with a custom comparator and an existing collection. In order to create such a queue, we currently need to initialize a new queue with custom comparator, and after that populate the queue using `addAll()` method, which in the background calls `add()` method (which takes `O(logn)` time) for each element of the collection (`n` times).  This is resulting in an overall time complexity of `O(nlogn)`. 


PriorityQueue<String> pq = new PriorityQueue<>(customComparator);
pq.addAll(existingCollection);


The pull request introduces a new constructor to streamline this process and reduce the time complexity to `O(n)`.  If you create the queue above using the new constructor, the contents of the collection will be copied (which takes `O(n)` time) and then later  `heapify()` operation (Floyd's algorithm) will be called once (another `O(n)` time). Overall the operation will be reduced from `O(nlogn)` to `O(2n)` -> `O(n)` time.


PriorityQueue<String> pq = new PriorityQueue<>(existingCollection, customComparator);

-------------

Commit messages:
 - fix styling
 - Introduce constructor for PriorityQueue with existing collection and custom comparator

Changes: https://git.openjdk.org/jdk/pull/17045/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17045&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6356745
  Stats: 19 lines in 1 file changed: 19 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17045.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17045/head:pull/17045

PR: https://git.openjdk.org/jdk/pull/17045

From duke at openjdk.org  Thu Dec 14 20:36:50 2023
From: duke at openjdk.org (Valeh Hajiyev)
Date: Thu, 14 Dec 2023 20:36:50 GMT
Subject: RFR: 6356745: Introduce constructor for PriorityQueue with
 existing collection and custom comparator [v2]
In-Reply-To: <zAcGyJ33ZP0osNg-HMJp4UCtOXYzdqi969ugDhJ7954=.c5f8e2de-cfe8-4224-a98e-70f49da9a7a3@github.com>
References: <zAcGyJ33ZP0osNg-HMJp4UCtOXYzdqi969ugDhJ7954=.c5f8e2de-cfe8-4224-a98e-70f49da9a7a3@github.com>
Message-ID: <coAODM-9CtXAmbfpMxBU6wEYu6DXFOJB6OHV_cVo0L4=.978b09e9-1231-4ff3-ac97-e6b40816bc36@github.com>

> This commit addresses the current limitation in the `PriorityQueue` implementation, which lacks a constructor to efficiently create a priority queue with a custom comparator and an existing collection. In order to create such a queue, we currently need to initialize a new queue with custom comparator, and after that populate the queue using `addAll()` method, which in the background calls `add()` method (which takes `O(logn)` time) for each element of the collection (`n` times).  This is resulting in an overall time complexity of `O(nlogn)`. 
> 
> 
> PriorityQueue<String> pq = new PriorityQueue<>(customComparator);
> pq.addAll(existingCollection);
> 
> 
> The pull request introduces a new constructor to streamline this process and reduce the time complexity to `O(n)`.  If you create the queue above using the new constructor, the contents of the collection will be copied (which takes `O(n)` time) and then later  `heapify()` operation (Floyd's algorithm) will be called once (another `O(n)` time). Overall the operation will be reduced from `O(nlogn)` to `O(2n)` -> `O(n)` time.
> 
> 
> PriorityQueue<String> pq = new PriorityQueue<>(existingCollection, customComparator);

Valeh Hajiyev has updated the pull request incrementally with one additional commit since the last revision:

  updated the javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17045/files
  - new: https://git.openjdk.org/jdk/pull/17045/files/8f35fe91..1cce713d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17045&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17045&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17045.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17045/head:pull/17045

PR: https://git.openjdk.org/jdk/pull/17045

From valeh.hajiyev at gmail.com  Thu Dec 14 20:37:08 2023
From: valeh.hajiyev at gmail.com (Valeh Hajiyev)
Date: Thu, 14 Dec 2023 21:37:08 +0100
Subject: [External] : Re: Introduce constructor for PriorityQueue with
 existing collection and custom comparator
In-Reply-To: <CANSoFxsQJSv-LqbyN19+Ai=piLcpvhzR6o7R3E+sbSZ6SbdV5w@mail.gmail.com>
References: <CAJXoXUBjq5GeXoNqdBhspvpsPOvT7EXhz6VuZhZVD5=RLOjg4g@mail.gmail.com>
 <F9804F9F-0726-4E27-AFFC-B05062459AF1@oracle.com>
 <CAJXoXUBzNW94rcOzzOj5x3uxAy1y96=BBRu+OeEcX964DUWcdA@mail.gmail.com>
 <CC225658-D639-4E47-A08C-4DC6D4FA2606@oracle.com>
 <MW4PR10MB5774BD82000BCC031D7B8520FF8CA@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CANSoFxsQJSv-LqbyN19+Ai=piLcpvhzR6o7R3E+sbSZ6SbdV5w@mail.gmail.com>
Message-ID: <CAJXoXUBdU9zeaxPAJQnubose6KdRCTCNwdPGiVdbX7EPAx4odQ@mail.gmail.com>

Yes, there's no such precondition. Thanks for having a look, I updated the
javadoc as you suggested, and linked it to the old existing ticket. It's
now ready for review.

I would appreciate if you could have a look again.

Cheers,
Valeh

On Thu, Dec 14, 2023 at 4:22?PM Archie Cobbs <archie.cobbs at gmail.com> wrote:

> On Thu, Dec 14, 2023 at 4:56?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
>> I presume that the precondition to have the original collection be
>> pre-ordered according to the supplied Comparator can be verified by
>> checking before adding each element in the collection to the PQ that it
>> compareTo equal-or-greater to the previous one?
>>
>
> Hmm...  something is not adding up.
>
> Either (a) there is a precondition that the collection already be sorted
> or (b) there's no such precondition.
>
> In case (a):
>
>    - Why isn't the new constructor invoking initElementsFromCollection()
>    instead of initFromCollection()?
>    - The precondition is not very obvious from the Javadoc description,
>    and moreover what happens when the precondition is not met is not
>    documented at all.
>
> In case (b):
>
>    - The Javadoc is misleading because it (ambiguously) implies there is
>    a precondition with the wording "collection that orders its elements
>    according to the specified comparator" (the referent of "that" is ambiguous
>    - does it refer to the collection or the PriorityQueue?)
>
> From the PR description it seems clear that there is no such precondition.
> So maybe the Javadoc should say this instead:
>
> Creates a {@code PriorityQueue} containing the elements in the specified
>> collection. The {@code PriorityQueue} will order its elements according to
>> the specified comparator.
>>
>
> -Archie
>
> --
> Archie L. Cobbs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20231214/6b259d38/attachment.htm>

From archie.cobbs at gmail.com  Thu Dec 14 20:39:51 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 14 Dec 2023 14:39:51 -0600
Subject: [External] : Re: Introduce constructor for PriorityQueue with
 existing collection and custom comparator
In-Reply-To: <CAJXoXUBdU9zeaxPAJQnubose6KdRCTCNwdPGiVdbX7EPAx4odQ@mail.gmail.com>
References: <CAJXoXUBjq5GeXoNqdBhspvpsPOvT7EXhz6VuZhZVD5=RLOjg4g@mail.gmail.com>
 <F9804F9F-0726-4E27-AFFC-B05062459AF1@oracle.com>
 <CAJXoXUBzNW94rcOzzOj5x3uxAy1y96=BBRu+OeEcX964DUWcdA@mail.gmail.com>
 <CC225658-D639-4E47-A08C-4DC6D4FA2606@oracle.com>
 <MW4PR10MB5774BD82000BCC031D7B8520FF8CA@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CANSoFxsQJSv-LqbyN19+Ai=piLcpvhzR6o7R3E+sbSZ6SbdV5w@mail.gmail.com>
 <CAJXoXUBdU9zeaxPAJQnubose6KdRCTCNwdPGiVdbX7EPAx4odQ@mail.gmail.com>
Message-ID: <CANSoFxvgwFfODoS6fVu3MBCQZi-7Xz5NbFJt9H8_jMNV4iNb6g@mail.gmail.com>

Looks great - thanks (I'm not an official reviewer so I can't approve it
though).

-Archie

On Thu, Dec 14, 2023 at 2:37?PM Valeh Hajiyev <valeh.hajiyev at gmail.com>
wrote:

> Yes, there's no such precondition. Thanks for having a look, I updated the
> javadoc as you suggested, and linked it to the old existing ticket. It's
> now ready for review.
>
> I would appreciate if you could have a look again.
>
> Cheers,
> Valeh
>
> On Thu, Dec 14, 2023 at 4:22?PM Archie Cobbs <archie.cobbs at gmail.com>
> wrote:
>
>> On Thu, Dec 14, 2023 at 4:56?AM Viktor Klang <viktor.klang at oracle.com>
>> wrote:
>>
>>> I presume that the precondition to have the original collection be
>>> pre-ordered according to the supplied Comparator can be verified by
>>> checking before adding each element in the collection to the PQ that it
>>> compareTo equal-or-greater to the previous one?
>>>
>>
>> Hmm...  something is not adding up.
>>
>> Either (a) there is a precondition that the collection already be sorted
>> or (b) there's no such precondition.
>>
>> In case (a):
>>
>>    - Why isn't the new constructor invoking initElementsFromCollection()
>>    instead of initFromCollection()?
>>    - The precondition is not very obvious from the Javadoc description,
>>    and moreover what happens when the precondition is not met is not
>>    documented at all.
>>
>> In case (b):
>>
>>    - The Javadoc is misleading because it (ambiguously) implies there is
>>    a precondition with the wording "collection that orders its elements
>>    according to the specified comparator" (the referent of "that" is ambiguous
>>    - does it refer to the collection or the PriorityQueue?)
>>
>> From the PR description it seems clear that there is no such
>> precondition. So maybe the Javadoc should say this instead:
>>
>> Creates a {@code PriorityQueue} containing the elements in the specified
>>> collection. The {@code PriorityQueue} will order its elements according to
>>> the specified comparator.
>>>
>>
>> -Archie
>>
>> --
>> Archie L. Cobbs
>>
>

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20231214/830cb213/attachment-0001.htm>

From asemenyuk at openjdk.org  Thu Dec 14 20:40:44 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 14 Dec 2023 20:40:44 GMT
Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update
In-Reply-To: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
References: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
Message-ID: <1b8hGFdrVVjDalOWt2pkTGQ_jmudlYiXAeptlQfmbZM=.a08ed560-9472-4a75-ae4d-afab8e93799c@github.com>

On Wed, 13 Dec 2023 22:12:48 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Translation drop for JDK22 RDP1

Marked as reviewed by asemenyuk (Reviewer).

jpackage changes look good

-------------

PR Review: https://git.openjdk.org/jdk/pull/17096#pullrequestreview-1782697421
PR Comment: https://git.openjdk.org/jdk/pull/17096#issuecomment-1856551939

From pavel.rappo at oracle.com  Thu Dec 14 20:46:07 2023
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Thu, 14 Dec 2023 20:46:07 +0000
Subject: More support for offset and length in methods operating on byte
 arrays
In-Reply-To: <379370CD-15FF-4C3B-8F98-8EC6A5F0BF49@oracle.com>
References: <CAP_KEpcmqRhmUVsRHTyV+H6CFPvOpnrSz7OTd3OSL-vqgjyaPA@mail.gmail.com>
 <5C10C2BA-AB39-45C5-B0D6-8679FCACFF56@oracle.com>
 <379370CD-15FF-4C3B-8F98-8EC6A5F0BF49@oracle.com>
Message-ID: <F45FB0CC-96F8-4AD9-9F78-C8AA5E813829@oracle.com>

Yes, overloads that accepted both source and destination ByteBuffer were there at some point, but then were removed:

commit 591834e28d482ea6a375ab215958e1635a7b111d
Author: Xueming Shen <sherman at openjdk.org>
Date:   Tue Dec 3 17:44:31 2013 -0800

    8028397: Undo the lenient MIME BASE64 decoder support change (JDK-8025003) and remove methods de/encode(buf, buf)

    Updated the spec and implementation as requested

    Reviewed-by: alanb

Let me paste the respective JBS description here for readers convenience:

The change set for "lenient mime decoder" support change (JDK-8025003) does not meet the requirement needed by the submitter and there is different understanding and opinion of what the "lenient" should be for the Base64 decoder. Given we are in late stage of the release. The decision is to back out the change and leave the functionality for future releases.

Also during the discussion, it became clear that the decode/encode(ByteBuffer, ByteBuffer) method pair are insufficient to support the requested de/encoding continuation functionality ("underflow" handling, in charset coder's term). Given the the most usage of these pair is for the channel read/writing, it appears it might be more useful/desired to provide a pair of wrap(readable/writableByteChannel) methods stead. While the wrap(channel) methods are under development, it does not appear it will make jdk8. For jdk8 we have decided to remove the decode/encode(Buffer, Buffer).

> On 14 Dec 2023, at 20:24, Pavel Rappo <pavel.rappo at oracle.com> wrote:
> 
> Upon a closer look, switching to ByteBuffer would only get you 50% towards where you want to be: the resulting ByteBuffer, whether encoded or decoded, is *allocated* by the respective methods and then returned as a result rather than accepted by those methods as a parameter.
> 
>> On 14 Dec 2023, at 19:57, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>> 
>> 
>> 
>>> On 14 Dec 2023, at 06:10, Magnus <magnus.eriksson at gmail.com> wrote:
>>> 
>>> In the java libraries there are many methods that operate on byte arrays that do not allow you to specify offset and length for the relevant data instead forcing you to copy the relevant part to new arrays before using the methods reducing performance - I am for instance struggling with this in java.util.Base64 where the Encoders and Decoders lack a length parameter (also an offset would have been great even though I don't need that in my case).
>> 
>> Re: java.util.Base64. Encoder and Decoder also seem to be able to work with ByteBuffer. If you have an array, you can cheaply create a ByteBuffer wrapper around that array. The now-backing array would be read or written though from the specific position and up to the specific limit. Would that help?
>> 
>> -Pavel
>> 
> 


From acobbs at openjdk.org  Thu Dec 14 20:46:03 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 14 Dec 2023 20:46:03 GMT
Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available() test
 for end-of-stream
Message-ID: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>

`GZIPInputStream`, when looking for a concatenated stream, relies on what the underlying `InputStream` says is how many bytes are `available()`. But this is inappropriate because `InputStream.available()` is just an estimate and is allowed (for example) to always return zero.

The fix is to ignore what's `available()` and just proceed and see what happens. If fewer bytes are available than required, the attempt to extend to another stream is canceled just as it was before, e.g., when the next stream header couldn't be read.

-------------

Commit messages:
 - Fix bug in GZIPInputStream when underlying available() returns short.

Changes: https://git.openjdk.org/jdk/pull/17113/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17113&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-7036144
  Stats: 101 lines in 2 files changed: 86 ins; 9 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/17113.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17113/head:pull/17113

PR: https://git.openjdk.org/jdk/pull/17113

From valeh.hajiyev at gmail.com  Thu Dec 14 21:12:31 2023
From: valeh.hajiyev at gmail.com (Valeh Hajiyev)
Date: Thu, 14 Dec 2023 22:12:31 +0100
Subject: [External] : Re: Introduce constructor for PriorityQueue with
 existing collection and custom comparator
In-Reply-To: <CANSoFxvgwFfODoS6fVu3MBCQZi-7Xz5NbFJt9H8_jMNV4iNb6g@mail.gmail.com>
References: <CAJXoXUBjq5GeXoNqdBhspvpsPOvT7EXhz6VuZhZVD5=RLOjg4g@mail.gmail.com>
 <F9804F9F-0726-4E27-AFFC-B05062459AF1@oracle.com>
 <CAJXoXUBzNW94rcOzzOj5x3uxAy1y96=BBRu+OeEcX964DUWcdA@mail.gmail.com>
 <CC225658-D639-4E47-A08C-4DC6D4FA2606@oracle.com>
 <MW4PR10MB5774BD82000BCC031D7B8520FF8CA@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CANSoFxsQJSv-LqbyN19+Ai=piLcpvhzR6o7R3E+sbSZ6SbdV5w@mail.gmail.com>
 <CAJXoXUBdU9zeaxPAJQnubose6KdRCTCNwdPGiVdbX7EPAx4odQ@mail.gmail.com>
 <CANSoFxvgwFfODoS6fVu3MBCQZi-7Xz5NbFJt9H8_jMNV4iNb6g@mail.gmail.com>
Message-ID: <CAJXoXUDGU9idTqv51nhfQTkN4K67R0UXq=L1oR5pPDJDXqofEA@mail.gmail.com>

One more request ? Current PR cannot be merged without CRS. Could someone
please help me to create a CSR request for the issue below?

https://bugs.openjdk.org/browse/JDK-6356745

Unfortunately, I don't have permission to create a CSR request.

-Valeh

On Thu, Dec 14, 2023 at 9:40?PM Archie Cobbs <archie.cobbs at gmail.com> wrote:

> Looks great - thanks (I'm not an official reviewer so I can't approve it
> though).
>
> -Archie
>
> On Thu, Dec 14, 2023 at 2:37?PM Valeh Hajiyev <valeh.hajiyev at gmail.com>
> wrote:
>
>> Yes, there's no such precondition. Thanks for having a look, I updated
>> the javadoc as you suggested, and linked it to the old existing ticket.
>> It's now ready for review.
>>
>> I would appreciate if you could have a look again.
>>
>> Cheers,
>> Valeh
>>
>> On Thu, Dec 14, 2023 at 4:22?PM Archie Cobbs <archie.cobbs at gmail.com>
>> wrote:
>>
>>> On Thu, Dec 14, 2023 at 4:56?AM Viktor Klang <viktor.klang at oracle.com>
>>> wrote:
>>>
>>>> I presume that the precondition to have the original collection be
>>>> pre-ordered according to the supplied Comparator can be verified by
>>>> checking before adding each element in the collection to the PQ that it
>>>> compareTo equal-or-greater to the previous one?
>>>>
>>>
>>> Hmm...  something is not adding up.
>>>
>>> Either (a) there is a precondition that the collection already be sorted
>>> or (b) there's no such precondition.
>>>
>>> In case (a):
>>>
>>>    - Why isn't the new constructor invoking
>>>    initElementsFromCollection() instead of initFromCollection()?
>>>    - The precondition is not very obvious from the Javadoc description,
>>>    and moreover what happens when the precondition is not met is not
>>>    documented at all.
>>>
>>> In case (b):
>>>
>>>    - The Javadoc is misleading because it (ambiguously) implies there
>>>    is a precondition with the wording "collection that orders its elements
>>>    according to the specified comparator" (the referent of "that" is ambiguous
>>>    - does it refer to the collection or the PriorityQueue?)
>>>
>>> From the PR description it seems clear that there is no such
>>> precondition. So maybe the Javadoc should say this instead:
>>>
>>> Creates a {@code PriorityQueue} containing the elements in the specified
>>>> collection. The {@code PriorityQueue} will order its elements according to
>>>> the specified comparator.
>>>>
>>>
>>> -Archie
>>>
>>> --
>>> Archie L. Cobbs
>>>
>>
>
> --
> Archie L. Cobbs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20231214/9c7b5b48/attachment-0001.htm>

From duke at openjdk.org  Thu Dec 14 21:13:43 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 14 Dec 2023 21:13:43 GMT
Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available()
 test for end-of-stream
In-Reply-To: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
References: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
Message-ID: <I_fCJ-jy5RpP9ZcNisDY37xEeVQaDxpLFCA86diyrtk=.925233a1-b768-4398-9a25-e2a5d019a168@github.com>

On Thu, 14 Dec 2023 20:15:39 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> `GZIPInputStream`, when looking for a concatenated stream, relies on what the underlying `InputStream` says is how many bytes are `available()`. But this is inappropriate because `InputStream.available()` is just an estimate and is allowed (for example) to always return zero.
> 
> The fix is to ignore what's `available()` and just proceed and see what happens. If fewer bytes are available than required, the attempt to extend to another stream is canceled just as it was before, e.g., when the next stream header couldn't be read.

The test could benefit from a conversion to JUnit. Not sure I love final local variables, I see the split assignment inside the try/catch makes it useful, but perhaps if you rewrite countBytes as suggested, final will be less useful.

test/jdk/java/util/zip/GZIP/GZIPInputStreamAvailable.java line 54:

> 52:         try (GZIPInputStream in = new GZIPInputStream(new ByteArrayInputStream(gz32))) {
> 53:             count1 = countBytes(in);
> 54:         }

Consider rewriting countBytes to take the ByteArrayInputStream/ZeroAvailableInputStream as a parameter, so you could just do:

 ```suggestion
        long count1 = countBytes(new ByteArrayInputStream(gz32));

test/jdk/java/util/zip/GZIP/GZIPInputStreamAvailable.java line 56:

> 54:         }
> 55: 
> 56:         // (a) Read it from a stream where available() always returns zero

Suggestion:

        // (b) Read it from a stream where available() always returns zero

test/jdk/java/util/zip/GZIP/GZIPInputStreamAvailable.java line 64:

> 62:         // They should be the same
> 63:         if (count2 != count1)
> 64:             throw new AssertionError(count2 + " != " + count1);

Consider converting the test to JUnit, this would allow:
Suggestion:

        asssertEquals(count1, count2);

-------------

PR Review: https://git.openjdk.org/jdk/pull/17113#pullrequestreview-1782746089
PR Review Comment: https://git.openjdk.org/jdk/pull/17113#discussion_r1427283057
PR Review Comment: https://git.openjdk.org/jdk/pull/17113#discussion_r1427283554
PR Review Comment: https://git.openjdk.org/jdk/pull/17113#discussion_r1427285307

From duke at openjdk.org  Thu Dec 14 21:17:38 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 14 Dec 2023 21:17:38 GMT
Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available()
 test for end-of-stream
In-Reply-To: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
References: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
Message-ID: <nO93zs0onuzYVTFTiszJeEr2Ydh2qNgTzP9Gi_1baII=.602de4ea-de3c-40ad-9c03-f854044d3b94@github.com>

On Thu, 14 Dec 2023 20:15:39 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> `GZIPInputStream`, when looking for a concatenated stream, relies on what the underlying `InputStream` says is how many bytes are `available()`. But this is inappropriate because `InputStream.available()` is just an estimate and is allowed (for example) to always return zero.
> 
> The fix is to ignore what's `available()` and just proceed and see what happens. If fewer bytes are available than required, the attempt to extend to another stream is canceled just as it was before, e.g., when the next stream header couldn't be read.

test/jdk/java/util/zip/GZIP/GZIPInputStreamAvailable.java line 37:

> 35:     public static void main(String [] args) throws IOException {
> 36: 
> 37:         // Create gz data

Perhaps expand the comment to explain that you are creating a concatenated stream?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17113#discussion_r1427291799

From jlu at openjdk.org  Thu Dec 14 21:18:47 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 14 Dec 2023 21:18:47 GMT
Subject: Integrated: 8321480: ISO 4217 Amendment 176 Update
In-Reply-To: <kLWpfbMrAiEskU8JqeFoGaEBzx1aTHI_vq5gxjjdoVw=.2b1af423-59c7-44e8-b4d4-deca303ec2a8@github.com>
References: <kLWpfbMrAiEskU8JqeFoGaEBzx1aTHI_vq5gxjjdoVw=.2b1af423-59c7-44e8-b4d4-deca303ec2a8@github.com>
Message-ID: <GQxvCuyxtVgwhjeSm9q5EOP3T-mVEtbLtIrMw6FH5d8=.f60e757a-4b6c-443e-9d6d-cc4dd702d1d9@github.com>

On Thu, 7 Dec 2023 19:43:14 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which incorporates the ISO 4217 Amendment 176 Update. As the replacement of `ANG` to `XCG` won't occur until 2025, this change does not need to go into JDK22. `HR` was also updated to remove the past cutover dates.
> 
> This update also demonstrated that `Currency::getAvailableCurrencies` may return a future currency that should not be returned. _GenerateCurrencyData.java_ was updated to ensure such currencies are not added to the other currency list.
> 
> Additionally, this change also converted a parameterized test to a normal JUnit test, due to output overflow.

This pull request has now been integrated.

Changeset: 8b24851b
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8b24851b9d3619c41c7a6cdb9193ed26a9b732dc
Stats:     43 lines in 5 files changed: 10 ins; 0 del; 33 mod

8321480: ISO 4217 Amendment 176 Update

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/17023

From dholmes at openjdk.org  Thu Dec 14 21:28:47 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 14 Dec 2023 21:28:47 GMT
Subject: Integrated: 8322065: Initial nroff manpage generation for JDK 23
In-Reply-To: <UboOhUcAkH6L4qSOWy_uV5qieIX6IQNBhZxWsIvbLzc=.68cfd313-6718-4a7f-9233-f9fd04269e7a@github.com>
References: <UboOhUcAkH6L4qSOWy_uV5qieIX6IQNBhZxWsIvbLzc=.68cfd313-6718-4a7f-9233-f9fd04269e7a@github.com>
Message-ID: <PburUtgTlWWQUu8FrbTb5opRR6eanF3CGgdcCPJ6sEw=.d9807c9b-f763-4f69-8327-d5e3feb0877d@github.com>

On Thu, 14 Dec 2023 05:46:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Updated the version to 23-ea and year to 2024.
> 
> This initial generation also picks up the unpublished changes from:
> 
> - [JDK-8302233](https://bugs.openjdk.org/browse/JDK-8302233) (keytool & jarsigner)
> - [JDK-8290702](https://bugs.openjdk.org/browse/JDK-8290702) (javadoc) (JDK 23 backport)
> 
> Thanks

This pull request has now been integrated.

Changeset: 692be577
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/692be577385844bf00a01ff10e390e014191569f
Stats:     193 lines in 27 files changed: 36 ins; 51 del; 106 mod

8322065: Initial nroff manpage generation for JDK 23

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/17101

From rriggs at openjdk.org  Thu Dec 14 21:29:41 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 14 Dec 2023 21:29:41 GMT
Subject: RFR: 8320919: Clarify Locale related system properties [v5]
In-Reply-To: <iSzKhtqd-n0z1KroMxDdCGkdyzx-WFpbTnHCkGbdJcY=.48f2574f-1a08-415d-bdab-e699ee6a465d@github.com>
References: <IruGxIK9DXnXFDANt1y4sCMJEGZh1PTOKhOWZZxJEdc=.77092e02-fb4f-4c9e-8d53-0fa0cf3bae7d@github.com>
 <iSzKhtqd-n0z1KroMxDdCGkdyzx-WFpbTnHCkGbdJcY=.48f2574f-1a08-415d-bdab-e699ee6a465d@github.com>
Message-ID: <E8bVek-_Kh7z5bYLXDKsFehdMdPsc8742x1zroWbJnM=.ab6a4b28-aa2b-4947-95b2-741e6f517018@github.com>

On Wed, 13 Dec 2023 19:00:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a doc change to clarify what the `Default Locale` is, and how it is established during the system startup using the system properties. Those locale-related system properties have existed since the early days of Java, but have never been publicly documented before. It is also the intention of this PR to clarify those system properties and how they are overridden. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

src/java.base/share/classes/java/util/Locale.java line 264:

> 262:  * <h3><a id="default_locale">Default Locale</a></h3>
> 263:  *
> 264:  * <p>The default Locale is mainly provided for any locale-sensitive methods if no

The word "mainly" can be omitted, it doesn't add any clarity.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17065#discussion_r1427307955

From naoto at openjdk.org  Thu Dec 14 21:50:01 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 14 Dec 2023 21:50:01 GMT
Subject: RFR: 8320919: Clarify Locale related system properties [v6]
In-Reply-To: <IruGxIK9DXnXFDANt1y4sCMJEGZh1PTOKhOWZZxJEdc=.77092e02-fb4f-4c9e-8d53-0fa0cf3bae7d@github.com>
References: <IruGxIK9DXnXFDANt1y4sCMJEGZh1PTOKhOWZZxJEdc=.77092e02-fb4f-4c9e-8d53-0fa0cf3bae7d@github.com>
Message-ID: <K-unE_fO6QjGn8VZE95YZtm-9SeFm1AMt0jJkWJ5zYo=.1300dae3-ed8d-447d-bee7-36310ad4f055@github.com>

> This is a doc change to clarify what the `Default Locale` is, and how it is established during the system startup using the system properties. Those locale-related system properties have existed since the early days of Java, but have never been publicly documented before. It is also the intention of this PR to clarify those system properties and how they are overridden. A corresponding CSR has been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Reflects review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17065/files
  - new: https://git.openjdk.org/jdk/pull/17065/files/48466817..27195f51

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17065&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17065&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17065.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17065/head:pull/17065

PR: https://git.openjdk.org/jdk/pull/17065

From naoto at openjdk.org  Thu Dec 14 21:50:04 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 14 Dec 2023 21:50:04 GMT
Subject: RFR: 8320919: Clarify Locale related system properties [v5]
In-Reply-To: <E8bVek-_Kh7z5bYLXDKsFehdMdPsc8742x1zroWbJnM=.ab6a4b28-aa2b-4947-95b2-741e6f517018@github.com>
References: <IruGxIK9DXnXFDANt1y4sCMJEGZh1PTOKhOWZZxJEdc=.77092e02-fb4f-4c9e-8d53-0fa0cf3bae7d@github.com>
 <iSzKhtqd-n0z1KroMxDdCGkdyzx-WFpbTnHCkGbdJcY=.48f2574f-1a08-415d-bdab-e699ee6a465d@github.com>
 <E8bVek-_Kh7z5bYLXDKsFehdMdPsc8742x1zroWbJnM=.ab6a4b28-aa2b-4947-95b2-741e6f517018@github.com>
Message-ID: <0h_l_fMH5C_R13S72ISyno8yXdFM6-99vx3WoL02Qoo=.31041cf0-64bf-49a1-974a-bce7ca571531@github.com>

On Thu, 14 Dec 2023 21:27:06 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflects review comments
>
> src/java.base/share/classes/java/util/Locale.java line 264:
> 
>> 262:  * <h3><a id="default_locale">Default Locale</a></h3>
>> 263:  *
>> 264:  * <p>The default Locale is mainly provided for any locale-sensitive methods if no
> 
> The word "mainly" can be omitted, it doesn't add any clarity.

Removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17065#discussion_r1427332501

From duke at openjdk.org  Thu Dec 14 21:57:58 2023
From: duke at openjdk.org (Markus KARG)
Date: Thu, 14 Dec 2023 21:57:58 GMT
Subject: RFR: 8297632: InputStream.transferTo() method should specify what
 the return value should be when the number of bytes transfered is
 larger than Long.MAX_VALUE [v7]
In-Reply-To: <mvUWAuiQVz3jl8PPdcc8CP1wpasHqusn39L4UvgugI0=.77f04ab1-1199-4228-a121-32259e3a096c@github.com>
References: <T38kO1hcz3rhpqOOPYmoPl1TlRORJBifQWtXLl10x8Y=.595338d3-df98-4202-95b5-eda88a4ed0a2@github.com>
 <_9WmGHHPiqNaJ2l5vg1qvYvgj9rTKtnYYLt7Gi2x2uQ=.d56479a0-8948-4f76-9e7a-f9661766a281@github.com>
 <9huCKnW7RWabo1GGXTDzXEVpXL3mt31s9BXc5bpQ6_8=.924b4b05-0943-45e0-92d2-fd36042d6495@github.com>
 <smBRnTsPYhT6VoOO-M0fwGI9wTjwGhgi6N_hYMslAv0=.1d60c1f4-ccb6-4cdb-932e-a4d0b0c37485@github.com>
 <mvUWAuiQVz3jl8PPdcc8CP1wpasHqusn39L4UvgugI0=.77f04ab1-1199-4228-a121-32259e3a096c@github.com>
Message-ID: <RWdxuLb2OFG7CPgviVQewqnlxXbkp3lPvwfcL9Jnrks=.a113678a-fca9-4961-aaa4-d9040761eef3@github.com>

On Thu, 14 Dec 2023 20:21:10 GMT, Vladimir Sitnikov <vsitnikov at openjdk.org> wrote:

>>> What do you think?
>> 
>> I think that you are looking at an obsolete repository:
>> 
>> https://github.com/openjdk/jdk/blob/c328f9589ddc3a981a2c63801bd991f8e593e69f/src/java.base/share/classes/java/io/InputStream.java#L802
>
> I mean SequenceInputStream, not the base class: https://github.com/openjdk/jdk/blob/c328f9589ddc3a981a2c63801bd991f8e593e69f/src/java.base/share/classes/java/io/SequenceInputStream.java#L249
> 
> Could you please double-check?

IMHO @vlsi is right. It is incorrect that we stop the transfer in the overflow case. We should fix it as he suggested. I can do that if you like.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11403#discussion_r1427342442

From achung at openjdk.org  Thu Dec 14 22:01:40 2023
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 14 Dec 2023 22:01:40 GMT
Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update
In-Reply-To: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
References: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
Message-ID: <KURZGxIoW_SgiStcTHzOW8IqokPAPVIYJb7MTvzFWuM=.c274f868-2473-459b-bd3e-290d5fb51324@github.com>

On Wed, 13 Dec 2023 22:12:48 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Translation drop for JDK22 RDP1

mach5 looks green

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17096#issuecomment-1856733375

From achung at openjdk.org  Thu Dec 14 22:17:54 2023
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 14 Dec 2023 22:17:54 GMT
Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update [v2]
In-Reply-To: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
References: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
Message-ID: <Egb10aiw4mPByp-kgJx5KNIR7Rc9SRwemJVG9I1Jp5Y=.d16ce069-7a0e-4ebc-aed4-35ad02aea347@github.com>

> Translation drop for JDK22 RDP1

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  removed quotes around Ablehnen

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17096/files
  - new: https://git.openjdk.org/jdk/pull/17096/files/3c8e871d..0e964a06

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17096&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17096&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17096.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17096/head:pull/17096

PR: https://git.openjdk.org/jdk/pull/17096

From duke at openjdk.org  Thu Dec 14 22:21:37 2023
From: duke at openjdk.org (Valeh Hajiyev)
Date: Thu, 14 Dec 2023 22:21:37 GMT
Subject: RFR: 6356745: Introduce constructor for PriorityQueue with
 existing collection and custom comparator [v2]
In-Reply-To: <coAODM-9CtXAmbfpMxBU6wEYu6DXFOJB6OHV_cVo0L4=.978b09e9-1231-4ff3-ac97-e6b40816bc36@github.com>
References: <zAcGyJ33ZP0osNg-HMJp4UCtOXYzdqi969ugDhJ7954=.c5f8e2de-cfe8-4224-a98e-70f49da9a7a3@github.com>
 <coAODM-9CtXAmbfpMxBU6wEYu6DXFOJB6OHV_cVo0L4=.978b09e9-1231-4ff3-ac97-e6b40816bc36@github.com>
Message-ID: <uPI3xVLtcl5nLvyQktvPt6eItzPGIFLqYKfbHMiHJS4=.cf2f1559-4301-4aca-b3a0-d34e8829f1ce@github.com>

On Thu, 14 Dec 2023 20:36:50 GMT, Valeh Hajiyev <duke at openjdk.org> wrote:

>> This commit addresses the current limitation in the `PriorityQueue` implementation, which lacks a constructor to efficiently create a priority queue with a custom comparator and an existing collection. In order to create such a queue, we currently need to initialize a new queue with custom comparator, and after that populate the queue using `addAll()` method, which in the background calls `add()` method (which takes `O(logn)` time) for each element of the collection (`n` times).  This is resulting in an overall time complexity of `O(nlogn)`. 
>> 
>> 
>> PriorityQueue<String> pq = new PriorityQueue<>(customComparator);
>> pq.addAll(existingCollection);
>> 
>> 
>> The pull request introduces a new constructor to streamline this process and reduce the time complexity to `O(n)`.  If you create the queue above using the new constructor, the contents of the collection will be copied (which takes `O(n)` time) and then later  `heapify()` operation (Floyd's algorithm) will be called once (another `O(n)` time). Overall the operation will be reduced from `O(nlogn)` to `O(2n)` -> `O(n)` time.
>> 
>> 
>> PriorityQueue<String> pq = new PriorityQueue<>(existingCollection, customComparator);
>
> Valeh Hajiyev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated the javadoc

@AlanBateman thanks for having a look. would you be able to create a CRS request as I don't have permission to do so?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17045#issuecomment-1856784903

From sspitsyn at openjdk.org  Thu Dec 14 22:37:42 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 14 Dec 2023 22:37:42 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v5]
In-Reply-To: <vK7AfcTSTwnVicVwyAeij-1qHzB3YXXmyHVbeR0h9LM=.7d1ee559-18c6-4514-baef-058b4dad8a40@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
 <bR2FzlWdDHZ0LcbnsU_f95F1QlA5uMe-JHquxbJpOCg=.f441cf9f-9752-4eb4-a389-0da3c8938427@github.com>
 <vK7AfcTSTwnVicVwyAeij-1qHzB3YXXmyHVbeR0h9LM=.7d1ee559-18c6-4514-baef-058b4dad8a40@github.com>
Message-ID: <aYk0rAFekWG8yhGMgQzxpCOMJbKncBb4faPfu5JArJ4=.bef387da-b251-4dab-bc82-c3aee4c01e49@github.com>

On Thu, 14 Dec 2023 19:50:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: moved notifyJvmtiDisableSuspend(true) out of try-block
>
> src/java.base/share/classes/java/lang/VirtualThread.java line 1043:
> 
>> 1041:             notifyJvmtiDisableSuspend(true);
>> 1042:             try {
>> 1043:                 // include the carrier thread state and name when mounted
> 
> This one too, can you move the comment to before the notifyJvmtiDisableSuspend.

Moved both comments out of try blocks.
What about this one (it seems we would wont to do the same) ? :

                notifyJvmtiDisableSuspend(true);
                try {
                    // unpark carrier thread when pinned
                    synchronized (carrierThreadAccessLock()) {
                        Thread carrier = carrierThread;
                        if (carrier != null && ((s = state()) == PINNED || s == TIMED_PINNED)) {
                            U.unpark(carrier);
                        }
                    }
                } finally {
                    notifyJvmtiDisableSuspend(false);
                }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1427373522

From sspitsyn at openjdk.org  Thu Dec 14 22:57:53 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 14 Dec 2023 22:57:53 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v6]
In-Reply-To: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
Message-ID: <Inldf_8mqmxm0BbsxxpiumpQRxbveclVKwV6HLjtdlQ=.7d300bcb-3628-4c9f-bccf-c2a5633e398f@github.com>

> This fix is for JDK 23 but the intention is to back port it to 22 in RDP-1 time frame.
> It is fixing a deadlock issue between `VirtualThread` class critical sections with the `interruptLock` (in methods: `unpark()`, `interrupt()`, `getAndClearInterrupt()`, `threadState()`, `toString()`), `JvmtiVTMSTransitionDisabler` and JVMTI `Suspend/Resume` mechanisms.
> The deadlocking scenario is well described by Patricio in a bug report comment.
> In simple words, a virtual thread should not be suspended during 'interruptLock' critical sections.
> 
> The fix is to record that a virtual thread is in a critical section (`JavaThread`'s `_in_critical_section` bit) by notifying the VM/JVMTI about begin/end of critical section.
> This bit is used in `HandshakeState::get_op_for_self()` to filter out any `HandshakeOperation` if a target `JavaThread` is in a critical section.
> 
> Some of new notifications with `notifyJvmtiSync()` method is on a performance critical path. It is why this method has been intrincified.
> 
> New test was developed by Patricio:
>  `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
> The test is very nice as it reliably in 100% reproduces the deadlock without the fix.
> The test is never failing with this fix.
> 
> Testing:
>  - tested with newly added test: `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
>  - tested with mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: moved a couple of comments out of try blocks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17011/files
  - new: https://git.openjdk.org/jdk/pull/17011/files/ad990422..917dc724

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17011&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17011&range=04-05

  Stats: 6 lines in 1 file changed: 3 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17011.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17011/head:pull/17011

PR: https://git.openjdk.org/jdk/pull/17011

From sspitsyn at openjdk.org  Thu Dec 14 22:57:55 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 14 Dec 2023 22:57:55 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v5]
In-Reply-To: <aYk0rAFekWG8yhGMgQzxpCOMJbKncBb4faPfu5JArJ4=.bef387da-b251-4dab-bc82-c3aee4c01e49@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
 <bR2FzlWdDHZ0LcbnsU_f95F1QlA5uMe-JHquxbJpOCg=.f441cf9f-9752-4eb4-a389-0da3c8938427@github.com>
 <vK7AfcTSTwnVicVwyAeij-1qHzB3YXXmyHVbeR0h9LM=.7d1ee559-18c6-4514-baef-058b4dad8a40@github.com>
 <aYk0rAFekWG8yhGMgQzxpCOMJbKncBb4faPfu5JArJ4=.bef387da-b251-4dab-bc82-c3aee4c01e49@github.com>
Message-ID: <uA_h7zdsHQEVoulYhB4RkdpEbHqPM7_Gz7v6JF6Ir_E=.e17bbf32-58d0-4d7f-870d-151b42755989@github.com>

On Thu, 14 Dec 2023 22:35:18 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/VirtualThread.java line 1043:
>> 
>>> 1041:             notifyJvmtiDisableSuspend(true);
>>> 1042:             try {
>>> 1043:                 // include the carrier thread state and name when mounted
>> 
>> This one too, can you move the comment to before the notifyJvmtiDisableSuspend.
>
> Moved both comments out of try blocks.
> What about this one (it seems we would wont to do the same) ? :
> 
>                 notifyJvmtiDisableSuspend(true);
>                 try {
>                     // unpark carrier thread when pinned
>                     synchronized (carrierThreadAccessLock()) {
>                         Thread carrier = carrierThread;
>                         if (carrier != null && ((s = state()) == PINNED || s == TIMED_PINNED)) {
>                             U.unpark(carrier);
>                         }
>                     }
>                 } finally {
>                     notifyJvmtiDisableSuspend(false);
>                 }

Moved 3 comments out of try blocks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1427386103

From bpb at openjdk.org  Thu Dec 14 23:06:44 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 14 Dec 2023 23:06:44 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v15]
In-Reply-To: <8SYx9TqaT4rL2o4BZ_Fnu_ZxD3vVMdYJS51dtGMK22I=.4b226895-ec4a-49bc-ab1a-c46a2e290405@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <8SYx9TqaT4rL2o4BZ_Fnu_ZxD3vVMdYJS51dtGMK22I=.4b226895-ec4a-49bc-ab1a-c46a2e290405@github.com>
Message-ID: <dZAa97JgeIWwmAyIMIhBewWJA18a6OSvbjti8NrV0wY=.37ca08b4-6256-44c7-b552-470bb29ed274@github.com>

On Thu, 14 Dec 2023 08:47:03 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`.
>> 
>> See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8320971: Revert irrelevant changes

src/java.base/share/classes/java/io/BufferedInputStream.java line 646:

> 644:             int avail = count - pos;
> 645:             if (avail > 0) {
> 646:                 if (isTrusted(out)) {

It might be cleaner for now to drop `isTrusted()` and just do the class check explicitly here. That still takes care of the main intent of not passing the buffer to an untrustworthy stream. Further cleanup and consolidation can be done later.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1427391530

From mchung at openjdk.org  Thu Dec 14 23:14:44 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 14 Dec 2023 23:14:44 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v13]
In-Reply-To: <1VoNUv8RTXkFcv411pVhC0E3AEZfsp_8EZNXn4IyP5M=.09425f9b-a6b4-4ed0-b659-09cf7aa4adba@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <1VoNUv8RTXkFcv411pVhC0E3AEZfsp_8EZNXn4IyP5M=.09425f9b-a6b4-4ed0-b659-09cf7aa4adba@github.com>
Message-ID: <lN7Bki6CdSqat9b0DdNthypJlqkiRMx6vmf_WDcClGs=.47f5764e-493d-4d8b-9c34-2c0cc0e9066a@github.com>

On Mon, 11 Dec 2023 16:37:38 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Disallow packaged modules and run-time image link
>  - Only check for existing path when not a scratch task
>    
>    When using a run-time image link and the initial build was produced with
>    the --keep-packaged-modules option, we don't need to check existing
>    paths to the location where packaged modules need to be copied. This
>    breaks the --verbose output validation.

Sorry for the delay.   I started the review.   I think there may be better places to make these changes e.g. read `fs_$MODULE_files` and prepare and print out the verbose log.   I am spending time to get familiar with the code and suggest better places to implement this.   Hope I can send something next week.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1856912188

From bpb at openjdk.org  Thu Dec 14 23:20:51 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 14 Dec 2023 23:20:51 GMT
Subject: RFR: 8297632: InputStream.transferTo() method should specify what
 the return value should be when the number of bytes transfered is
 larger than Long.MAX_VALUE [v7]
In-Reply-To: <RWdxuLb2OFG7CPgviVQewqnlxXbkp3lPvwfcL9Jnrks=.a113678a-fca9-4961-aaa4-d9040761eef3@github.com>
References: <T38kO1hcz3rhpqOOPYmoPl1TlRORJBifQWtXLl10x8Y=.595338d3-df98-4202-95b5-eda88a4ed0a2@github.com>
 <_9WmGHHPiqNaJ2l5vg1qvYvgj9rTKtnYYLt7Gi2x2uQ=.d56479a0-8948-4f76-9e7a-f9661766a281@github.com>
 <9huCKnW7RWabo1GGXTDzXEVpXL3mt31s9BXc5bpQ6_8=.924b4b05-0943-45e0-92d2-fd36042d6495@github.com>
 <smBRnTsPYhT6VoOO-M0fwGI9wTjwGhgi6N_hYMslAv0=.1d60c1f4-ccb6-4cdb-932e-a4d0b0c37485@github.com>
 <mvUWAuiQVz3jl8PPdcc8CP1wpasHqusn39L4UvgugI0=.77f04ab1-1199-4228-a121-32259e3a096c@github.com>
 <RWdxuLb2OFG7CPgviVQewqnlxXbkp3lPvwfcL9Jnrks=.a113678a-fca9-4961-aaa4-d9040761eef3@github.com>
Message-ID: <56gPoELnMwnXF5OG9lUTikxzC3O0HYCTxLUlePW3RAI=.e89e1670-a17d-491c-acd2-1d6eeaf16923@github.com>

On Thu, 14 Dec 2023 21:54:53 GMT, Markus KARG <duke at openjdk.org> wrote:

>> I mean SequenceInputStream, not the base class: https://github.com/openjdk/jdk/blob/c328f9589ddc3a981a2c63801bd991f8e593e69f/src/java.base/share/classes/java/io/SequenceInputStream.java#L249
>> 
>> Could you please double-check?
>
> IMHO @vlsi is right. It is incorrect that we stop the transfer in the overflow case. We should fix it as he suggested. I can do that if you like.

Right, the base class. The suggested change was made for `InputStream` in 254d6990bcf75700f1c3aa18e0f8b73b639d9bad. It looks like it should be in `SequenceInputStream` as well. I created [JDK-8322141](https://bugs.openjdk.org/browse/JDK-8322141) to track this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11403#discussion_r1427398726

From achung at openjdk.org  Fri Dec 15 00:11:46 2023
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 15 Dec 2023 00:11:46 GMT
Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update [v2]
In-Reply-To: <dsMlRFjnSPD-o6ihRbzbBI93HYkNtbUONmZPxew9DfM=.3fbc999c-ec8e-454a-92f3-41ee4adbfb2a@github.com>
References: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
 <dsMlRFjnSPD-o6ihRbzbBI93HYkNtbUONmZPxew9DfM=.3fbc999c-ec8e-454a-92f3-41ee4adbfb2a@github.com>
Message-ID: <k3S_M-N-0pmpxnPUpba28kfX9zKVGiZdVkDJdyMOsiM=.e6ceb77e-3fb8-4243-9435-50bf9e306243@github.com>

On Thu, 14 Dec 2023 19:01:22 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed quotes around Ablehnen
>
> src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties line 331:
> 
>> 329: 
>> 330: # Implementation Property DTD
>> 331:         JDK_DTD_DENY = JAXP00010008: DOCTYPE ist nicht zul?ssig, wenn die DTD-Eigenschaft auf "Ablehnen" gesetzt wurde. Weitere Informationen: Eigenschaft jdk.xml.dtd.support in java.xml/module-summary.
> 
> This version quoted "Ablehnen" while the other two (ja - "??" and zh_CN - "??") didn't. If we want to be consistent, "deny" would be better since that's the literal value. The English version should have quoted "deny".
> 
> The previous translations in these files have not been consistent. Some of the key words were translated. If we want to keep this translation as is, it's probably better to remove the quote in the "de" file.

removed quotes around Ablehnen

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17096#discussion_r1427423629

From prappo at openjdk.org  Fri Dec 15 00:14:37 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 15 Dec 2023 00:14:37 GMT
Subject: RFR: 6356745: Introduce constructor for PriorityQueue with
 existing collection and custom comparator [v2]
In-Reply-To: <uPI3xVLtcl5nLvyQktvPt6eItzPGIFLqYKfbHMiHJS4=.cf2f1559-4301-4aca-b3a0-d34e8829f1ce@github.com>
References: <zAcGyJ33ZP0osNg-HMJp4UCtOXYzdqi969ugDhJ7954=.c5f8e2de-cfe8-4224-a98e-70f49da9a7a3@github.com>
 <coAODM-9CtXAmbfpMxBU6wEYu6DXFOJB6OHV_cVo0L4=.978b09e9-1231-4ff3-ac97-e6b40816bc36@github.com>
 <uPI3xVLtcl5nLvyQktvPt6eItzPGIFLqYKfbHMiHJS4=.cf2f1559-4301-4aca-b3a0-d34e8829f1ce@github.com>
Message-ID: <3GIcTNx2rJ2_wuHGHTArXK0bmK0InBNWZpT3KWP6kBc=.5244724b-8ce1-4bfd-ae30-395655803d09@github.com>

On Thu, 14 Dec 2023 22:18:35 GMT, Valeh Hajiyev <duke at openjdk.org> wrote:

> @AlanBateman thanks for having a look. would you be able to create a CRS request as I don't have permission to do so?

You may not be able to create one, but you sure can look at some. If you do so, you'll see that obtaining a permission to create a [CSR](https://wiki.openjdk.org/display/csr/Main) is the least of your concerns. A CSR is a structured essay with elements of a checklist and it takes some effort to compose one. Here are some examples for you (feel free to look at more):

 - https://bugs.openjdk.org/browse/JDK-8189407
 - https://bugs.openjdk.org/browse/JDK-8284377
 - https://bugs.openjdk.org/browse/JDK-8287419
 - https://bugs.openjdk.org/browse/JDK-8266572
 - https://bugs.openjdk.org/browse/JDK-8191517

You've posted your suggestion on core-libs-dev and provided this essentially draft PR. Now simply wait for discussion, if any.

While waiting, though, consider how you would test your proposal. Generally, familiarise yourself with other PRs, both Open and Closed (in OpenJDK PRs are not Merged in GitHub sense). See how changes similar to what you propose are processed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17045#issuecomment-1857046857

From tristpost at hotmail.com  Thu Dec 14 20:17:35 2023
From: tristpost at hotmail.com (Trist Post)
Date: Thu, 14 Dec 2023 21:17:35 +0100
Subject: More support for offset and length in methods operating on byte
 arrays
In-Reply-To: <5C10C2BA-AB39-45C5-B0D6-8679FCACFF56@oracle.com>
References: <CAP_KEpcmqRhmUVsRHTyV+H6CFPvOpnrSz7OTd3OSL-vqgjyaPA@mail.gmail.com>
 <5C10C2BA-AB39-45C5-B0D6-8679FCACFF56@oracle.com>
Message-ID: <PAXP192MB12773455294246BA246762ABBF8CA@PAXP192MB1277.EURP192.PROD.OUTLOOK.COM>

Thanks for the good suggestion Pavel - will look into that - for large
arrays absolutely less costly than copying!

In the general case I would still prefer if the libraries generally
provided offset & length for byte array arguments to allow for "garbage
free" code (i.e. avoiding to frequently create various wrapper objects like
ByteBuffer from heap memory).

Best Regards
Trist

On Thu, Dec 14, 2023 at 8:57?PM Pavel Rappo <pavel.rappo at oracle.com> wrote:

>
>
> > On 14 Dec 2023, at 06:10, Magnus <magnus.eriksson at gmail.com> wrote:
> >
> > In the java libraries there are many methods that operate on byte arrays
> that do not allow you to specify offset and length for the relevant data
> instead forcing you to copy the relevant part to new arrays before using
> the methods reducing performance - I am for instance struggling with this
> in java.util.Base64 where the Encoders and Decoders lack a length parameter
> (also an offset would have been great even though I don't need that in my
> case).
>
> Re: java.util.Base64. Encoder and Decoder also seem to be able to work
> with ByteBuffer. If you have an array, you can cheaply create a ByteBuffer
> wrapper around that array. The now-backing array would be read or written
> though from the specific position and up to the specific limit. Would that
> help?
>
> -Pavel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20231214/b2bdaeb0/attachment-0001.htm>

From duke at openjdk.org  Fri Dec 15 01:22:57 2023
From: duke at openjdk.org (Joshua Cao)
Date: Fri, 15 Dec 2023 01:22:57 GMT
Subject: RFR: 8322149: ConcurrentHashMap copy constructor should not transfer
 from old table on presizing
Message-ID: <7OymBzCIMzM9k2_MrT0qblvshoUQWOL0ifcf0AYbVkU=.548fb86d-6fee-4f10-abc4-be2db275a310@github.com>

ConcurrentHashMap's copy constructor calls `putAll()` -> `tryPresize()` -> `transfer()`. When coming from the copy constructor, the Map is empty, so there is nothing to transfer. But `transfer()` will still copy all the empty nodes from the old table to the new table.

This patch avoids this work by only calling `tryPresize()` if the table is already initialized. If `table` is null, the initialization is deferred to `putVal()`, which calls `initTable()`.

---

### JMH results for testCopyConstructor

before patch:


Result "org.openjdk.bench.java.util.concurrent.Maps.testCopyConstructor":
  937395.686 ?(99.9%) 99074.324 ns/op [Average]
  (min, avg, max) = (825732.550, 937395.686, 1072024.041), stdev = 92674.184
  CI (99.9%): [838321.362, 1036470.010] (assumes normal distribution)


after patch:


Result "org.openjdk.bench.java.util.concurrent.Maps.testCopyConstructor":
  620871.469 ?(99.9%) 59195.406 ns/op [Average]
  (min, avg, max) = (545304.633, 620871.469, 689013.573), stdev = 55371.419
  CI (99.9%): [561676.063, 680066.875] (assumes normal distribution)


Average time is decreased by about 33%.

-------------

Commit messages:
 - 8322149: ConcurrentHashMap copy constructor should not transfer from old table on presizing

Changes: https://git.openjdk.org/jdk/pull/17116/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17116&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322149
  Stats: 22 lines in 2 files changed: 19 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17116.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17116/head:pull/17116

PR: https://git.openjdk.org/jdk/pull/17116

From jpai at openjdk.org  Fri Dec 15 01:33:41 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 15 Dec 2023 01:33:41 GMT
Subject: RFR: 8321958: @param/@return descriptions of
 ZoneRules#isDaylightSavings() are incorrect [v2]
In-Reply-To: <15KaWyH94Qsmj6mnNkgwMVqkSvjVPnlaC6-PlDZZUcU=.e2eed2ca-feb2-4c87-859a-f236a8b7dc8f@github.com>
References: <2150UeprX2CQ34CmEIROihDODlQMKsuPPv3gB-gjChE=.ff26e4a5-48e8-4153-85dc-6f9a7b554116@github.com>
 <15KaWyH94Qsmj6mnNkgwMVqkSvjVPnlaC6-PlDZZUcU=.e2eed2ca-feb2-4c87-859a-f236a8b7dc8f@github.com>
Message-ID: <Z3j3-YeAPfgJOk5z5Jfk695Vg4yZIYeOPllveXqkKqI=.08c137b4-e072-44d3-b504-cd4728f0af06@github.com>

On Thu, 14 Dec 2023 17:08:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Small document correction on a return description.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Corrected @param description

Thank you for the update Naoto. The current change looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17098#pullrequestreview-1782999804

From acobbs at openjdk.org  Fri Dec 15 03:20:01 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 15 Dec 2023 03:20:01 GMT
Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available()
 test for end-of-stream [v2]
In-Reply-To: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
References: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
Message-ID: <AbtLf08Jgc4Eyu3dnOTqkeQE35ZoJiCE0s-iHt7Sa6Q=.f70df457-df2a-4820-9811-4cd8f8beb4e5@github.com>

> `GZIPInputStream`, when looking for a concatenated stream, relies on what the underlying `InputStream` says is how many bytes are `available()`. But this is inappropriate because `InputStream.available()` is just an estimate and is allowed (for example) to always return zero.
> 
> The fix is to ignore what's `available()` and just proceed and see what happens. If fewer bytes are available than required, the attempt to extend to another stream is canceled just as it was before, e.g., when the next stream header couldn't be read.

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17113/files
  - new: https://git.openjdk.org/jdk/pull/17113/files/c07554d0..c7087e55

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17113&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17113&range=00-01

  Stats: 29 lines in 1 file changed: 6 ins; 7 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/17113.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17113/head:pull/17113

PR: https://git.openjdk.org/jdk/pull/17113

From acobbs at openjdk.org  Fri Dec 15 03:20:05 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 15 Dec 2023 03:20:05 GMT
Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available()
 test for end-of-stream [v2]
In-Reply-To: <nO93zs0onuzYVTFTiszJeEr2Ydh2qNgTzP9Gi_1baII=.602de4ea-de3c-40ad-9c03-f854044d3b94@github.com>
References: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
 <nO93zs0onuzYVTFTiszJeEr2Ydh2qNgTzP9Gi_1baII=.602de4ea-de3c-40ad-9c03-f854044d3b94@github.com>
Message-ID: <m3jxoJjuIvv5sGcQ7ePuj5dB1mvSf0QpRQxk_YYLySM=.a1353133-7a95-4ca1-a462-ae127d388b11@github.com>

On Thu, 14 Dec 2023 21:14:33 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments.
>
> test/jdk/java/util/zip/GZIP/GZIPInputStreamAvailable.java line 37:
> 
>> 35:     public static void main(String [] args) throws IOException {
>> 36: 
>> 37:         // Create gz data
> 
> Perhaps expand the comment to explain that you are creating a concatenated stream?

Thanks - should be addressed in c7087e55319.

> test/jdk/java/util/zip/GZIP/GZIPInputStreamAvailable.java line 54:
> 
>> 52:         try (GZIPInputStream in = new GZIPInputStream(new ByteArrayInputStream(gz32))) {
>> 53:             count1 = countBytes(in);
>> 54:         }
> 
> Consider rewriting countBytes to take the ByteArrayInputStream/ZeroAvailableInputStream as a parameter, so you could just do:
> 
>  ```suggestion
>         long count1 = countBytes(new ByteArrayInputStream(gz32));

Thanks - should be addressed in c7087e55319.

> test/jdk/java/util/zip/GZIP/GZIPInputStreamAvailable.java line 56:
> 
>> 54:         }
>> 55: 
>> 56:         // (a) Read it from a stream where available() always returns zero
> 
> Suggestion:
> 
>         // (b) Read it from a stream where available() always returns zero

Thanks - should be addressed in c7087e55319.

> test/jdk/java/util/zip/GZIP/GZIPInputStreamAvailable.java line 64:
> 
>> 62:         // They should be the same
>> 63:         if (count2 != count1)
>> 64:             throw new AssertionError(count2 + " != " + count1);
> 
> Consider converting the test to JUnit, this would allow:
> Suggestion:
> 
>         asssertEquals(count1, count2);

Thanks - should be addressed in c7087e55319.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17113#discussion_r1427507217
PR Review Comment: https://git.openjdk.org/jdk/pull/17113#discussion_r1427507107
PR Review Comment: https://git.openjdk.org/jdk/pull/17113#discussion_r1427507154
PR Review Comment: https://git.openjdk.org/jdk/pull/17113#discussion_r1427507189

From dholmes at openjdk.org  Fri Dec 15 05:17:50 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 15 Dec 2023 05:17:50 GMT
Subject: RFR: 8321400: java/foreign/TestStubAllocFailure.java fails with
 code cache exhaustion
In-Reply-To: <wlohswVQSIo7JBcsZBP4yS93SVEj8Ic78Hgvzy_I-d8=.06fd69b0-d059-4b5e-aee5-77c015a2ad17@github.com>
References: <GzvkhIYT0Bz6jHuS5o-q_DvNTRCKfj5hqDRHPvN2MxY=.8ce04894-a4e6-4339-9dfb-26a1933d3e59@github.com>
 <Qu9R1yyh7SkP0VwxYDVFjFCRRY-xE-lRlyFNMG750d8=.915f6560-81fe-4efe-b98b-06054b31c591@github.com>
 <wlohswVQSIo7JBcsZBP4yS93SVEj8Ic78Hgvzy_I-d8=.06fd69b0-d059-4b5e-aee5-77c015a2ad17@github.com>
Message-ID: <2VfTsCAQQHpaGwE0K9qXxSrqjXJjYABEkcrA_idjNw0=.14606b1a-bd21-4d8e-8d36-0a2d08950f48@github.com>

On Wed, 13 Dec 2023 13:29:43 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> test/jdk/java/foreign/TestStubAllocFailure.java line 51:
>> 
>>> 49:         runInNewProcess(UpcallRunner.class, true, List.of("-XX:ReservedCodeCacheSize=3M"), List.of())
>>> 50:                 .shouldNotHaveExitValue(0)
>>> 51:                 .shouldNotHaveFatalError();
>> 
>> Just curious what non-zero exit value is actually expected here and below?
>
> Any non-zero exit value is acceptable. The intent here is to check that the process didn't complete normally.

A non-zero non-crashing value. Just wondering what that actually would be?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17056#discussion_r1427557140

From joehw at openjdk.org  Fri Dec 15 05:26:41 2023
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 15 Dec 2023 05:26:41 GMT
Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update [v2]
In-Reply-To: <Egb10aiw4mPByp-kgJx5KNIR7Rc9SRwemJVG9I1Jp5Y=.d16ce069-7a0e-4ebc-aed4-35ad02aea347@github.com>
References: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
 <Egb10aiw4mPByp-kgJx5KNIR7Rc9SRwemJVG9I1Jp5Y=.d16ce069-7a0e-4ebc-aed4-35ad02aea347@github.com>
Message-ID: <z8aKUf41rLHle3HwH5xn7EiUtS_iKARKC6S_zujxzAQ=.657eb893-0fa3-4aca-9393-a47e6f0fcc1c@github.com>

On Thu, 14 Dec 2023 22:17:54 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Translation drop for JDK22 RDP1
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed quotes around Ablehnen

The java.xml changes look good.

-------------

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17096#pullrequestreview-1783142189

From alanb at openjdk.org  Fri Dec 15 08:19:02 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 15 Dec 2023 08:19:02 GMT
Subject: RFR: 8297632: InputStream.transferTo() method should specify what
 the return value should be when the number of bytes transfered is
 larger than Long.MAX_VALUE [v7]
In-Reply-To: <56gPoELnMwnXF5OG9lUTikxzC3O0HYCTxLUlePW3RAI=.e89e1670-a17d-491c-acd2-1d6eeaf16923@github.com>
References: <T38kO1hcz3rhpqOOPYmoPl1TlRORJBifQWtXLl10x8Y=.595338d3-df98-4202-95b5-eda88a4ed0a2@github.com>
 <_9WmGHHPiqNaJ2l5vg1qvYvgj9rTKtnYYLt7Gi2x2uQ=.d56479a0-8948-4f76-9e7a-f9661766a281@github.com>
 <9huCKnW7RWabo1GGXTDzXEVpXL3mt31s9BXc5bpQ6_8=.924b4b05-0943-45e0-92d2-fd36042d6495@github.com>
 <smBRnTsPYhT6VoOO-M0fwGI9wTjwGhgi6N_hYMslAv0=.1d60c1f4-ccb6-4cdb-932e-a4d0b0c37485@github.com>
 <mvUWAuiQVz3jl8PPdcc8CP1wpasHqusn39L4UvgugI0=.77f04ab1-1199-4228-a121-32259e3a096c@github.com>
 <RWdxuLb2OFG7CPgviVQewqnlxXbkp3lPvwfcL9Jnrks=.a113678a-fca9-4961-aaa4-d9040761eef3@github.com>
 <56gPoELnMwnXF5OG9lUTikxzC3O0HYCTxLUlePW3RAI=.e89e1670-a17d-491c-acd2-1d6eeaf16923@github.com>
Message-ID: <LcSTAVwKzNVqfkZtsbo-9sNCVIal8aoxSNSWTrw79xU=.c38f36dc-058f-43c2-af42-187206ac6dd7@github.com>

On Thu, 14 Dec 2023 23:17:41 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> IMHO @vlsi is right. It is incorrect that we stop the transfer in the overflow case. We should fix it as he suggested. I can do that if you like.
>
> Right, the base class. The suggested change was made for `InputStream` in 254d6990bcf75700f1c3aa18e0f8b73b639d9bad. It looks like it should be in `SequenceInputStream` as well. I created [JDK-8322141](https://bugs.openjdk.org/browse/JDK-8322141) to track this.

We don't have any tests to check the behavior of the transferTo overrides when they transfer more than nine quintillion bytes so dependent on catching issues like this during code review.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11403#discussion_r1427679131

From duke at openjdk.org  Fri Dec 15 08:31:02 2023
From: duke at openjdk.org (Markus KARG)
Date: Fri, 15 Dec 2023 08:31:02 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return as
 soon as Long.MAX_VALUE bytes have been transferred
Message-ID: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>

Fixes JDK-8322141

As suggested by @vlsi and documented by @bplb this PR does not return, but only sets the maximum result value.

-------------

Commit messages:
 - Fixes JDK-8322141

Changes: https://git.openjdk.org/jdk/pull/17119/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17119&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322141
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17119.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17119/head:pull/17119

PR: https://git.openjdk.org/jdk/pull/17119

From duke at openjdk.org  Fri Dec 15 08:31:02 2023
From: duke at openjdk.org (Markus KARG)
Date: Fri, 15 Dec 2023 08:31:02 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred
In-Reply-To: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
Message-ID: <OJOelD6qxTukYh1ERbvN5obUybS3P4cDBEkWc8gRs4g=.d62552e2-9dd2-4f9a-8ccf-90062caf5fd4@github.com>

On Fri, 15 Dec 2023 08:23:58 GMT, Markus KARG <duke at openjdk.org> wrote:

> Fixes JDK-8322141
> 
> As suggested by @vlsi and documented by @bplb this PR does not return, but only sets the maximum result value.

@bplb Kindly requesting your review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17119#issuecomment-1857471406

From duke at openjdk.org  Fri Dec 15 08:31:55 2023
From: duke at openjdk.org (Markus KARG)
Date: Fri, 15 Dec 2023 08:31:55 GMT
Subject: RFR: 8297632: InputStream.transferTo() method should specify what
 the return value should be when the number of bytes transfered is
 larger than Long.MAX_VALUE [v7]
In-Reply-To: <mvUWAuiQVz3jl8PPdcc8CP1wpasHqusn39L4UvgugI0=.77f04ab1-1199-4228-a121-32259e3a096c@github.com>
References: <T38kO1hcz3rhpqOOPYmoPl1TlRORJBifQWtXLl10x8Y=.595338d3-df98-4202-95b5-eda88a4ed0a2@github.com>
 <_9WmGHHPiqNaJ2l5vg1qvYvgj9rTKtnYYLt7Gi2x2uQ=.d56479a0-8948-4f76-9e7a-f9661766a281@github.com>
 <9huCKnW7RWabo1GGXTDzXEVpXL3mt31s9BXc5bpQ6_8=.924b4b05-0943-45e0-92d2-fd36042d6495@github.com>
 <smBRnTsPYhT6VoOO-M0fwGI9wTjwGhgi6N_hYMslAv0=.1d60c1f4-ccb6-4cdb-932e-a4d0b0c37485@github.com>
 <mvUWAuiQVz3jl8PPdcc8CP1wpasHqusn39L4UvgugI0=.77f04ab1-1199-4228-a121-32259e3a096c@github.com>
Message-ID: <AqLAR1I0Rm9DmkO0FqgNXkyL7o9D2NR9i6cwB1g2PQs=.468e737d-00da-47a8-9d81-c9277506ea9c@github.com>

On Thu, 14 Dec 2023 20:21:10 GMT, Vladimir Sitnikov <vsitnikov at openjdk.org> wrote:

>>> What do you think?
>> 
>> I think that you are looking at an obsolete repository:
>> 
>> https://github.com/openjdk/jdk/blob/c328f9589ddc3a981a2c63801bd991f8e593e69f/src/java.base/share/classes/java/io/InputStream.java#L802
>
> I mean SequenceInputStream, not the base class: https://github.com/openjdk/jdk/blob/c328f9589ddc3a981a2c63801bd991f8e593e69f/src/java.base/share/classes/java/io/SequenceInputStream.java#L249
> 
> Could you please double-check?

The solution proposed by @vlsi and outlined by @bplb in [JDK-8322141](https://bugs.openjdk.org/browse/JDK-8322141) now can be reviewed in https://github.com/openjdk/jdk/pull/17119. I suggest to continue the discussion *there*.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11403#discussion_r1427692263

From vsitnikov at openjdk.org  Fri Dec 15 08:37:37 2023
From: vsitnikov at openjdk.org (Vladimir Sitnikov)
Date: Fri, 15 Dec 2023 08:37:37 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred
In-Reply-To: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
Message-ID: <PXYI1krPvbf-MYprDbd8aeRMw3Y6jRlmTSFGujfyWEg=.14b38971-e873-4039-8d73-a01ac8123cf6@github.com>

On Fri, 15 Dec 2023 08:23:58 GMT, Markus KARG <duke at openjdk.org> wrote:

> Fixes JDK-8322141
> 
> As suggested by @vlsi and documented by @bplb this PR does not return, but only sets the maximum result value.

Marked as reviewed by vsitnikov (no project role).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17119#pullrequestreview-1783356424

From alanb at openjdk.org  Fri Dec 15 08:41:40 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 15 Dec 2023 08:41:40 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred
In-Reply-To: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
Message-ID: <KRiCBUIIEmZch1YwfM3UU-YVBMehmWUV6TJds5-VKHE=.8056e58a-2be5-495d-88df-28712ac6edd3@github.com>

On Fri, 15 Dec 2023 08:23:58 GMT, Markus KARG <duke at openjdk.org> wrote:

> Fixes JDK-8322141
> 
> As suggested by @vlsi and documented by @bplb this PR does not return, but only sets the maximum result value.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17119#pullrequestreview-1783361621

From jvernee at openjdk.org  Fri Dec 15 08:45:47 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 15 Dec 2023 08:45:47 GMT
Subject: RFR: 8321400: java/foreign/TestStubAllocFailure.java fails with
 code cache exhaustion
In-Reply-To: <2VfTsCAQQHpaGwE0K9qXxSrqjXJjYABEkcrA_idjNw0=.14606b1a-bd21-4d8e-8d36-0a2d08950f48@github.com>
References: <GzvkhIYT0Bz6jHuS5o-q_DvNTRCKfj5hqDRHPvN2MxY=.8ce04894-a4e6-4339-9dfb-26a1933d3e59@github.com>
 <Qu9R1yyh7SkP0VwxYDVFjFCRRY-xE-lRlyFNMG750d8=.915f6560-81fe-4efe-b98b-06054b31c591@github.com>
 <wlohswVQSIo7JBcsZBP4yS93SVEj8Ic78Hgvzy_I-d8=.06fd69b0-d059-4b5e-aee5-77c015a2ad17@github.com>
 <2VfTsCAQQHpaGwE0K9qXxSrqjXJjYABEkcrA_idjNw0=.14606b1a-bd21-4d8e-8d36-0a2d08950f48@github.com>
Message-ID: <DanCUgai-a4kevG0-ZIrheed877nX3Y0K_veayx-gvs=.91f3125b-ddfa-4647-87b1-f884b4ad6944@github.com>

On Fri, 15 Dec 2023 05:15:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Any non-zero exit value is acceptable. The intent here is to check that the process didn't complete normally.
>
> A non-zero non-crashing value. Just wondering what that actually would be?

For instance, when we exit due to an uncaught exception, the exit value is 1.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17056#discussion_r1427705400

From duke at openjdk.org  Fri Dec 15 08:47:40 2023
From: duke at openjdk.org (Markus KARG)
Date: Fri, 15 Dec 2023 08:47:40 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred
In-Reply-To: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
Message-ID: <L7vpYn_0zybg9bBtrXHl68lInPDB0kz-0DnvfZJykBo=.5fc3af84-a862-45fe-a8da-72a35a9d07d0@github.com>

On Fri, 15 Dec 2023 08:23:58 GMT, Markus KARG <duke at openjdk.org> wrote:

> Fixes JDK-8322141
> 
> As suggested by @vlsi and documented by @bplb this PR does not return, but only sets the maximum result value.

@bplb Kindly requesting your sponsoring. :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17119#issuecomment-1857497876

From kbarrett at openjdk.org  Fri Dec 15 08:51:37 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 15 Dec 2023 08:51:37 GMT
Subject: RFR: 8321688: Build on linux with GCC 7.5.0 fails after 8319577
In-Reply-To: <vIByQ06ftSU9o1Rb4YOWXPrry1LkYSj-vJqLXaMXQ5g=.d5a0ea33-f57a-4549-addf-b7a9c5eaa67d@github.com>
References: <vIByQ06ftSU9o1Rb4YOWXPrry1LkYSj-vJqLXaMXQ5g=.d5a0ea33-f57a-4549-addf-b7a9c5eaa67d@github.com>
Message-ID: <93jYEROn5yAyMamzLQOfGF3rRIq_kB2hdKcLeqMGa7s=.8f2f3ea5-3ecf-4f5f-afcf-02eecdd14cd9@github.com>

On Mon, 11 Dec 2023 02:36:30 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch fixes the building failure introduced by [JDK-8319577](https://bugs.openjdk.org/browse/JDK-8319577) in old GCC version (linux & GCC 7.5.0 locally).
> 
> Thanks for the review.
> 
>  Best Regards,
> -- Guoxiong

The files being proposed for change are cloned copies of a 3rd-party library.
We may want to take updates from that library in the future. Having local
modifications makes that more difficult.

Also, this library uses C++17.  GCC support for C++17 was experimental until
GCC 9.  As such, it shouldn't be entirely surprising if an earlier version of
GCC might run into problems with it.

We've been discussing switching to using C++17 JDK-wide for some time, and I
think that may happen soon.  At that point the minimum supported version of
GCC will be changed to at least GCC 9.

So I think the answer here is that building this lbrary with GCC 7.5 is not
supported and a newer version should be used. So the change should be here:
https://github.com/openjdk/jdk/blob/b31454e36234091c3827c3b4d07f62345cb0cee4/src/java.base/linux/native/libsimdsort/simdsort-support.hpp#L34-L37
to require a later GCC version. That way, if building with an older version of
GCC then the code in the library won't be built and the library won't be used
by the JDK (because the relevant symbols won't be found).

But GCC 7.5 will probably not be supported for building the JDK for much longer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17047#issuecomment-1857502174

From alanb at openjdk.org  Fri Dec 15 09:00:43 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 15 Dec 2023 09:00:43 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v6]
In-Reply-To: <Inldf_8mqmxm0BbsxxpiumpQRxbveclVKwV6HLjtdlQ=.7d300bcb-3628-4c9f-bccf-c2a5633e398f@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
 <Inldf_8mqmxm0BbsxxpiumpQRxbveclVKwV6HLjtdlQ=.7d300bcb-3628-4c9f-bccf-c2a5633e398f@github.com>
Message-ID: <xTnvAkjAUo2NKPeEqCtOdfGXO0DxrUQ5NzgOCuAlvrQ=.fd2edefd-a45e-44a3-a618-3036eb35b33e@github.com>

On Thu, 14 Dec 2023 22:57:53 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fix is for JDK 23 but the intention is to back port it to 22 in RDP-1 time frame.
>> It is fixing a deadlock issue between `VirtualThread` class critical sections with the `interruptLock` (in methods: `unpark()`, `interrupt()`, `getAndClearInterrupt()`, `threadState()`, `toString()`), `JvmtiVTMSTransitionDisabler` and JVMTI `Suspend/Resume` mechanisms.
>> The deadlocking scenario is well described by Patricio in a bug report comment.
>> In simple words, a virtual thread should not be suspended during 'interruptLock' critical sections.
>> 
>> The fix is to record that a virtual thread is in a critical section (`JavaThread`'s `_in_critical_section` bit) by notifying the VM/JVMTI about begin/end of critical section.
>> This bit is used in `HandshakeState::get_op_for_self()` to filter out any `HandshakeOperation` if a target `JavaThread` is in a critical section.
>> 
>> Some of new notifications with `notifyJvmtiSync()` method is on a performance critical path. It is why this method has been intrincified.
>> 
>> New test was developed by Patricio:
>>  `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
>> The test is very nice as it reliably in 100% reproduces the deadlock without the fix.
>> The test is never failing with this fix.
>> 
>> Testing:
>>  - tested with newly added test: `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: moved a couple of comments out of try blocks

src/hotspot/share/prims/jvm.cpp line 4019:

> 4017:     return;
> 4018:   }
> 4019:   assert(thread->is_disable_suspend() != (bool)enter, "recursive disable suspend is not allowed");

This is an important assert, the message should probably say nested or unbalanced enter/exit not allowed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1427719197

From stsypanov at openjdk.org  Fri Dec 15 09:27:51 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 15 Dec 2023 09:27:51 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v15]
In-Reply-To: <dZAa97JgeIWwmAyIMIhBewWJA18a6OSvbjti8NrV0wY=.37ca08b4-6256-44c7-b552-470bb29ed274@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <8SYx9TqaT4rL2o4BZ_Fnu_ZxD3vVMdYJS51dtGMK22I=.4b226895-ec4a-49bc-ab1a-c46a2e290405@github.com>
 <dZAa97JgeIWwmAyIMIhBewWJA18a6OSvbjti8NrV0wY=.37ca08b4-6256-44c7-b552-470bb29ed274@github.com>
Message-ID: <0L9QJXEAc014B6fWGCh3W5CK822Vw1O9Ze-B-W3m2SY=.2322e284-d896-4b2a-9fc9-c375cf5ac9ca@github.com>

On Thu, 14 Dec 2023 23:04:25 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8320971: Revert irrelevant changes
>
> src/java.base/share/classes/java/io/BufferedInputStream.java line 646:
> 
>> 644:             int avail = count - pos;
>> 645:             if (avail > 0) {
>> 646:                 if (isTrusted(out)) {
> 
> It might be cleaner for now to drop `isTrusted()` and just do the class check explicitly here. That still takes care of the main intent of not passing the buffer to an untrustworthy stream. Further cleanup and consolidation can be done later.

I think this would be doing double job, wouldn't it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1427749255

From alanb at openjdk.org  Fri Dec 15 09:29:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 15 Dec 2023 09:29:41 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v6]
In-Reply-To: <Inldf_8mqmxm0BbsxxpiumpQRxbveclVKwV6HLjtdlQ=.7d300bcb-3628-4c9f-bccf-c2a5633e398f@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
 <Inldf_8mqmxm0BbsxxpiumpQRxbveclVKwV6HLjtdlQ=.7d300bcb-3628-4c9f-bccf-c2a5633e398f@github.com>
Message-ID: <iraqjBUP8iU1mKkm_PgCAtP2psxtnwt2EQLGGJ_1kUs=.a68ac691-6e05-4b86-b07b-702f88023099@github.com>

On Thu, 14 Dec 2023 22:57:53 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fix is for JDK 23 but the intention is to back port it to 22 in RDP-1 time frame.
>> It is fixing a deadlock issue between `VirtualThread` class critical sections with the `interruptLock` (in methods: `unpark()`, `interrupt()`, `getAndClearInterrupt()`, `threadState()`, `toString()`), `JvmtiVTMSTransitionDisabler` and JVMTI `Suspend/Resume` mechanisms.
>> The deadlocking scenario is well described by Patricio in a bug report comment.
>> In simple words, a virtual thread should not be suspended during 'interruptLock' critical sections.
>> 
>> The fix is to record that a virtual thread is in a critical section (`JavaThread`'s `_in_critical_section` bit) by notifying the VM/JVMTI about begin/end of critical section.
>> This bit is used in `HandshakeState::get_op_for_self()` to filter out any `HandshakeOperation` if a target `JavaThread` is in a critical section.
>> 
>> Some of new notifications with `notifyJvmtiSync()` method is on a performance critical path. It is why this method has been intrincified.
>> 
>> New test was developed by Patricio:
>>  `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
>> The test is very nice as it reliably in 100% reproduces the deadlock without the fix.
>> The test is never failing with this fix.
>> 
>> Testing:
>>  - tested with newly added test: `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: moved a couple of comments out of try blocks

I think okay, I don't have any other comments.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17011#pullrequestreview-1783445183

From jpai at openjdk.org  Fri Dec 15 09:44:40 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 15 Dec 2023 09:44:40 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred
In-Reply-To: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
Message-ID: <0BeAIbQUChFnNZmUoHncwAkq_pSzC5JnsI99VA8SSaA=.9e6a1022-1e35-4c79-92b6-18b0dabef842@github.com>

On Fri, 15 Dec 2023 08:23:58 GMT, Markus KARG <duke at openjdk.org> wrote:

> Fixes JDK-8322141
> 
> As suggested by @vlsi and documented by @bplb this PR does not return, but only sets the maximum result value.

src/java.base/share/classes/java/io/SequenceInputStream.java line 249:

> 247:                         transferred = Math.addExact(transferred, in.transferTo(out));
> 248:                     } catch (ArithmeticException ignore) {
> 249:                         transferred = Long.MAX_VALUE;

Hello Markus, looking at this code, even with this change, I think we still have a bug here. Once the `transferred` becomes `Long.MAX_VALUE`, if there is a `nextStream()` available, then when we continue in this `while` loop, then this check:

if (transferred < Long.MAX_VALUE) {

will prevent it from transfering to the output stream, the next input stream's content and thus ignoring the next stream's content.

I think what we might want here is something like:



diff --git a/src/java.base/share/classes/java/io/SequenceInputStream.java b/src/java.base/share/classes/java/io/SequenceInputStream.java
index de3fafc884d..b89d9ca80b0 100644
--- a/src/java.base/share/classes/java/io/SequenceInputStream.java
+++ b/src/java.base/share/classes/java/io/SequenceInputStream.java
@@ -242,11 +242,14 @@ public long transferTo(OutputStream out) throws IOException {
         if (getClass() == SequenceInputStream.class) {
             long transferred = 0;
             while (in != null) {
+                long numTransferred = in.transferTo(out);
+                // increment the total transferred byte count
+                // only if we haven't already reached the Long.MAX_VALUE
                 if (transferred < Long.MAX_VALUE) {
                     try {
-                        transferred = Math.addExact(transferred, in.transferTo(out));
+                        transferred = Math.addExact(transferred, numTransferred);
                     } catch (ArithmeticException ignore) {
-                        return Long.MAX_VALUE;
+                        transferred = Long.MAX_VALUE;
                     }
                 }
                 nextStream();

(I haven't tested it)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17119#discussion_r1427766162

From alanb at openjdk.org  Fri Dec 15 09:58:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 15 Dec 2023 09:58:41 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred
In-Reply-To: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
Message-ID: <0p0DR3d5Tz1Kq3pQQzyjwSYKzZEV5665_vv5LXmaA7Y=.6bc1a26c-d118-4911-90e8-5772f83937f9@github.com>

On Fri, 15 Dec 2023 08:23:58 GMT, Markus KARG <duke at openjdk.org> wrote:

> Fixes JDK-8322141
> 
> As suggested by @vlsi and documented by @bplb this PR does not return, but only sets the maximum result value.

I think Jai is right, maybe we need to come up with tests that quickly check the handling at this limit.

-------------

Changes requested by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17119#pullrequestreview-1783490622

From sgehwolf at openjdk.org  Fri Dec 15 10:05:46 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 15 Dec 2023 10:05:46 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v13]
In-Reply-To: <1VoNUv8RTXkFcv411pVhC0E3AEZfsp_8EZNXn4IyP5M=.09425f9b-a6b4-4ed0-b659-09cf7aa4adba@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <1VoNUv8RTXkFcv411pVhC0E3AEZfsp_8EZNXn4IyP5M=.09425f9b-a6b4-4ed0-b659-09cf7aa4adba@github.com>
Message-ID: <nwIS8DM4bg1KqmwxqY0btCqmlxhZ2DXtozgRKU9pqiA=.533711cd-da43-4850-9675-02ba2da81f11@github.com>

On Mon, 11 Dec 2023 16:37:38 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Disallow packaged modules and run-time image link
>  - Only check for existing path when not a scratch task
>    
>    When using a run-time image link and the initial build was produced with
>    the --keep-packaged-modules option, we don't need to check existing
>    paths to the location where packaged modules need to be copied. This
>    breaks the --verbose output validation.

Thanks. I'm not super happy with it either (yet). I'll do some pondering myself to try to clean this up. Basically it would be good to know if the functionality so far would be complete as far as you're concerned as I could then focus on a cleaner patch without needing to add more bits.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1857598537

From sspitsyn at openjdk.org  Fri Dec 15 10:49:56 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 15 Dec 2023 10:49:56 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v7]
In-Reply-To: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
Message-ID: <4iSULgKTef_C2q4AJpEKB64tZh_QDIB77Ov2rwZ78nY=.39d3c708-4175-42b5-8eb9-58684e131ccf@github.com>

> This fix is for JDK 23 but the intention is to back port it to 22 in RDP-1 time frame.
> It is fixing a deadlock issue between `VirtualThread` class critical sections with the `interruptLock` (in methods: `unpark()`, `interrupt()`, `getAndClearInterrupt()`, `threadState()`, `toString()`), `JvmtiVTMSTransitionDisabler` and JVMTI `Suspend/Resume` mechanisms.
> The deadlocking scenario is well described by Patricio in a bug report comment.
> In simple words, a virtual thread should not be suspended during 'interruptLock' critical sections.
> 
> The fix is to record that a virtual thread is in a critical section (`JavaThread`'s `_in_critical_section` bit) by notifying the VM/JVMTI about begin/end of critical section.
> This bit is used in `HandshakeState::get_op_for_self()` to filter out any `HandshakeOperation` if a target `JavaThread` is in a critical section.
> 
> Some of new notifications with `notifyJvmtiSync()` method is on a performance critical path. It is why this method has been intrincified.
> 
> New test was developed by Patricio:
>  `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
> The test is very nice as it reliably in 100% reproduces the deadlock without the fix.
> The test is never failing with this fix.
> 
> Testing:
>  - tested with newly added test: `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
>  - tested with mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: improve an assert message

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17011/files
  - new: https://git.openjdk.org/jdk/pull/17011/files/917dc724..6f8cdf06

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17011&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17011&range=05-06

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17011.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17011/head:pull/17011

PR: https://git.openjdk.org/jdk/pull/17011

From sspitsyn at openjdk.org  Fri Dec 15 10:50:01 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 15 Dec 2023 10:50:01 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v6]
In-Reply-To: <xTnvAkjAUo2NKPeEqCtOdfGXO0DxrUQ5NzgOCuAlvrQ=.fd2edefd-a45e-44a3-a618-3036eb35b33e@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
 <Inldf_8mqmxm0BbsxxpiumpQRxbveclVKwV6HLjtdlQ=.7d300bcb-3628-4c9f-bccf-c2a5633e398f@github.com>
 <xTnvAkjAUo2NKPeEqCtOdfGXO0DxrUQ5NzgOCuAlvrQ=.fd2edefd-a45e-44a3-a618-3036eb35b33e@github.com>
Message-ID: <FVrpOHQfuJ570LgQjmy8Tus_v1G-89QCMkzHNBBfqQ8=.69fed58e-6a3e-4c7e-bb13-3bc771ad90d7@github.com>

On Fri, 15 Dec 2023 08:57:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: moved a couple of comments out of try blocks
>
> src/hotspot/share/prims/jvm.cpp line 4019:
> 
>> 4017:     return;
>> 4018:   }
>> 4019:   assert(thread->is_disable_suspend() != (bool)enter, "recursive disable suspend is not allowed");
> 
> This is an important assert, the message should probably say nested or unbalanced enter/exit not allowed.

Thanks. Updated the assert message as suggested.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1427830694

From lancea at openjdk.org  Fri Dec 15 11:18:39 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 15 Dec 2023 11:18:39 GMT
Subject: RFR: 8321616: Retire binary test vectors in
 test/jdk/java/util/zip/ZipFile [v7]
In-Reply-To: <VOfG5f4fta1usmRtqkepWj4KSnN8BZ73QeRdxo02lDI=.f2905bde-0c3a-4833-b421-8c18068e356b@github.com>
References: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
 <ip6qd-bohoWPTglfA3IVTBU7c46aNspVpVGAsvf_Na0=.b0ea34ea-2b18-430e-80eb-5d90df67a5b3@github.com>
 <VOfG5f4fta1usmRtqkepWj4KSnN8BZ73QeRdxo02lDI=.f2905bde-0c3a-4833-b421-8c18068e356b@github.com>
Message-ID: <PuEqYTbKQV88c-f6tcR3zG5RqvHJ6elwfHADf-CnnvQ=.5607e70a-8aaf-4125-97dd-2f3543760b64@github.com>

On Thu, 14 Dec 2023 15:00:15 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Seeing that `ReadAfterClose.java` uses a binary test vector `crash.jar`, I think it makes sense to include it in this PR, convert it to JUnit and move it into `ReadZip.readAfterClose`.
> 
> This removes the last remaining binary test vector ZIP in the `ZipFile/` directory.

These are on my list to review, thank you for the update.

One comment, for the tests that we are removing/retiring, we probably want to include the bug numbers and/or the name of the original test class in the new home for the tests to  make it easier for future maintainers to chase back the history in the unlikely event that an issue arises...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17038#issuecomment-1857706931

From duke at openjdk.org  Fri Dec 15 11:54:56 2023
From: duke at openjdk.org (Markus KARG)
Date: Fri, 15 Dec 2023 11:54:56 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred [v2]
In-Reply-To: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
Message-ID: <RRYuMB9HA07h17rfEWqta5nWc-pfi0VizmMIF3dfyp8=.f80e8dd6-4e52-47b7-b7ab-8e2aff185451@github.com>

> Fixes JDK-8322141
> 
> As suggested by @vlsi and documented by @bplb this PR does not return, but only sets the maximum result value.

Markus KARG has updated the pull request incrementally with one additional commit since the last revision:

  Keep transferring beyond MAX_VALUE bytes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17119/files
  - new: https://git.openjdk.org/jdk/pull/17119/files/2b175c07..8181dccd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17119&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17119&range=00-01

  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17119.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17119/head:pull/17119

PR: https://git.openjdk.org/jdk/pull/17119

From duke at openjdk.org  Fri Dec 15 11:54:57 2023
From: duke at openjdk.org (Markus KARG)
Date: Fri, 15 Dec 2023 11:54:57 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred [v2]
In-Reply-To: <0BeAIbQUChFnNZmUoHncwAkq_pSzC5JnsI99VA8SSaA=.9e6a1022-1e35-4c79-92b6-18b0dabef842@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
 <0BeAIbQUChFnNZmUoHncwAkq_pSzC5JnsI99VA8SSaA=.9e6a1022-1e35-4c79-92b6-18b0dabef842@github.com>
Message-ID: <47EcTg5AZjIG2ZhhznmHx65hRj9nH3DUTEz07o0xTUI=.ebd6cd76-c8f8-4434-9dac-d0b5ffabb587@github.com>

On Fri, 15 Dec 2023 09:41:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Keep transferring beyond MAX_VALUE bytes
>
> src/java.base/share/classes/java/io/SequenceInputStream.java line 249:
> 
>> 247:                         transferred = Math.addExact(transferred, in.transferTo(out));
>> 248:                     } catch (ArithmeticException ignore) {
>> 249:                         transferred = Long.MAX_VALUE;
> 
> Hello Markus, looking at this code, even with this change, I think we still have a bug here. Once the `transferred` becomes `Long.MAX_VALUE`, if there is a `nextStream()` available, then when we continue in this `while` loop, then this check:
> 
> if (transferred < Long.MAX_VALUE) {
> 
> will prevent it from transfering to the output stream, the next input stream's content and thus ignoring the next stream's content.
> 
> I think what we might want here is something like:
> 
> 
> 
> diff --git a/src/java.base/share/classes/java/io/SequenceInputStream.java b/src/java.base/share/classes/java/io/SequenceInputStream.java
> index de3fafc884d..b89d9ca80b0 100644
> --- a/src/java.base/share/classes/java/io/SequenceInputStream.java
> +++ b/src/java.base/share/classes/java/io/SequenceInputStream.java
> @@ -242,11 +242,14 @@ public long transferTo(OutputStream out) throws IOException {
>          if (getClass() == SequenceInputStream.class) {
>              long transferred = 0;
>              while (in != null) {
> +                long numTransferred = in.transferTo(out);
> +                // increment the total transferred byte count
> +                // only if we haven't already reached the Long.MAX_VALUE
>                  if (transferred < Long.MAX_VALUE) {
>                      try {
> -                        transferred = Math.addExact(transferred, in.transferTo(out));
> +                        transferred = Math.addExact(transferred, numTransferred);
>                      } catch (ArithmeticException ignore) {
> -                        return Long.MAX_VALUE;
> +                        transferred = Long.MAX_VALUE;
>                      }
>                  }
>                  nextStream();
> 
> (I haven't tested it)

@jaikiran Good catch! I have added your proposed solution in https://github.com/openjdk/jdk/pull/17119/commits/8181dccd9217aa5d57b2df0888373904510183df.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17119#discussion_r1427890488

From Alan.Bateman at oracle.com  Fri Dec 15 11:59:03 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 15 Dec 2023 11:59:03 +0000
Subject: [External] : Re: Introduce constructor for PriorityQueue with
 existing collection and custom comparator
In-Reply-To: <MW4PR10MB5774BD82000BCC031D7B8520FF8CA@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAJXoXUBjq5GeXoNqdBhspvpsPOvT7EXhz6VuZhZVD5=RLOjg4g@mail.gmail.com>
 <F9804F9F-0726-4E27-AFFC-B05062459AF1@oracle.com>
 <CAJXoXUBzNW94rcOzzOj5x3uxAy1y96=BBRu+OeEcX964DUWcdA@mail.gmail.com>
 <CC225658-D639-4E47-A08C-4DC6D4FA2606@oracle.com>
 <MW4PR10MB5774BD82000BCC031D7B8520FF8CA@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <a61a630d-f018-461d-b95a-1bc12400a891@oracle.com>

On 14/12/2023 10:55, Viktor Klang wrote:
> I presume that the precondition to have the original collection be 
> pre-ordered according to the supplied Comparator can be verified by 
> checking before adding each element in the collection to the PQ that 
> it compareTo equal-or-greater to the previous one?
>
It's not a precondition. If a PQ is created from an existing collection, 
or is deserialized (shudder!), then it has to copy and re-sort using the 
Comparator.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20231215/f3e810aa/attachment.htm>

From asotona at openjdk.org  Fri Dec 15 12:11:59 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 15 Dec 2023 12:11:59 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use the
 Classfile API to generate lambdas and method handles
Message-ID: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>

java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.

This patch converts ASM calls to Classfile API.

This PR is continuation of https://github.com/openjdk/jdk/pull/12945

Any comments and suggestions are welcome.

Please review.

Thank you,
Adam

-------------

Commit messages:
 - fixed InnerClassLambdaMetafactory for hidden caller classes
 - performance improvements
 - consolidation of descriptors handling
 - InvokerBytecodeGenerator::emit... improvements
 - 8294960: Convert java.base/java.lang.invoke package to use the Classfile API to generate lambdas and method handlers

Changes: https://git.openjdk.org/jdk/pull/17108/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294960
  Stats: 2142 lines in 13 files changed: 443 ins; 859 del; 840 mod
  Patch: https://git.openjdk.org/jdk/pull/17108.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17108/head:pull/17108

PR: https://git.openjdk.org/jdk/pull/17108

From duke at openjdk.org  Fri Dec 15 12:12:00 2023
From: duke at openjdk.org (ExE Boss)
Date: Fri, 15 Dec 2023 12:12:00 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles
In-Reply-To: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
Message-ID: <BZRERAbUazW6XxUifOwg32NDQJcOznC6IGsn6yfmpT8=.86bb0c37-60a6-4cca-ab9b-bac21b50550b@github.com>

On Thu, 14 Dec 2023 12:39:52 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
> 
> This patch converts ASM calls to Classfile API.
> 
> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
> 
> Any comments and suggestions are welcome.
> 
> Please review.
> 
> Thank you,
> Adam

The?title of?this?PR is?wrong, it?should?be:

8294960: Convert java.base/java.lang.invoke package to use the Classfile API to generate lambdas and method handles


diff:

-8294960: Convert java.base/java.lang.invoke package to use the Classfile API to generate lambdas and method handlers
+8294960: Convert java.base/java.lang.invoke package to use the Classfile API to generate lambdas and method handles

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17108#issuecomment-1857623966

From jlahoda at openjdk.org  Fri Dec 15 12:13:38 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 15 Dec 2023 12:13:38 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 [v10]
In-Reply-To: <dlqD_1CkX1z3xkuRCTaXPWBbeMx5Ey1l5GsHIC36sEY=.086ee49b-8506-41e0-b4db-c988eb4f91a7@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
 <dlqD_1CkX1z3xkuRCTaXPWBbeMx5Ey1l5GsHIC36sEY=.086ee49b-8506-41e0-b4db-c988eb4f91a7@github.com>
Message-ID: <nqeXpO1Dkv4UVgqPapXIY1WMMAWTfpHuLn69WXC59Rw=.371986a9-11e9-478e-bb4c-d2f11e9b7790@github.com>

On Thu, 14 Dec 2023 04:00:58 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding comment to jcod file

As the patch is flipping the iteration order, it may be useful to have tests for other cases, especially capturing local (and maybe anonymous) classes (in static and non-static contexts?), maybe even using classfile before and after [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275). Not sure if such tests exist, but it would help to make sure we don't regress. Note that captured variables for local/anonymous classes are appended to the end of the "explicit" parameters, so the change in iteration order could affect that.

I was experimenting with such local and anonymous classfiles, and didn't see an error, so it is probably OK, and it is probably only about the tests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17070#issuecomment-1857786430

From asotona at openjdk.org  Fri Dec 15 12:26:50 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 15 Dec 2023 12:26:50 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v2]
In-Reply-To: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
Message-ID: <ryPVgRWbldkLMNq2GOZZqYLydDKWgixV910y7KY01qw=.63e9f740-66db-4529-a211-e8db04e6bfe4@github.com>

> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
> 
> This patch converts ASM calls to Classfile API.
> 
> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
> 
> Any comments and suggestions are welcome.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  added missing comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17108/files
  - new: https://git.openjdk.org/jdk/pull/17108/files/dc53d750..0f356eb3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17108.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17108/head:pull/17108

PR: https://git.openjdk.org/jdk/pull/17108

From duke at openjdk.org  Fri Dec 15 12:29:41 2023
From: duke at openjdk.org (ExE Boss)
Date: Fri, 15 Dec 2023 12:29:41 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v2]
In-Reply-To: <ryPVgRWbldkLMNq2GOZZqYLydDKWgixV910y7KY01qw=.63e9f740-66db-4529-a211-e8db04e6bfe4@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <ryPVgRWbldkLMNq2GOZZqYLydDKWgixV910y7KY01qw=.63e9f740-66db-4529-a211-e8db04e6bfe4@github.com>
Message-ID: <LI_8ssl-DBK-OBVmMArWlfGuvSnpiQYlc2lIeGrhNaU=.b98524ba-01c4-4191-b4b9-a15c6297b360@github.com>

On Fri, 15 Dec 2023 12:26:50 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
>> 
>> This patch converts ASM calls to Classfile API.
>> 
>> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
>> 
>> Any comments and suggestions are welcome.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added missing comment

src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 548:

> 546:     static ClassDesc classDesc(Class<?> cls) {
> 547:         return cls.isHidden() ? ClassDesc.ofInternalName(cls.getName().replace('.', '/'))
> 548:                               : ClassDesc.ofDescriptor(cls.descriptorString());

This?still isn?t?correct, as?[`Class::getName()`] includes?the?trailing `/<suffix>` for?a?hidden?class.
Suggestion:

        if (cls.isHidden()) {
            var name = cls.getName();
            return ClassDesc.of(name.substring(0, name.indexOf('/'));
        }
        return ClassDesc.ofDescriptor(cls.descriptorString());


[`Class::getName()`]: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Class.html#getName()

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1427921269

From asotona at openjdk.org  Fri Dec 15 13:05:40 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 15 Dec 2023 13:05:40 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v2]
In-Reply-To: <LI_8ssl-DBK-OBVmMArWlfGuvSnpiQYlc2lIeGrhNaU=.b98524ba-01c4-4191-b4b9-a15c6297b360@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <ryPVgRWbldkLMNq2GOZZqYLydDKWgixV910y7KY01qw=.63e9f740-66db-4529-a211-e8db04e6bfe4@github.com>
 <LI_8ssl-DBK-OBVmMArWlfGuvSnpiQYlc2lIeGrhNaU=.b98524ba-01c4-4191-b4b9-a15c6297b360@github.com>
Message-ID: <Ddu9digMR_byFeipDo0VsLs0oPac4DOZDa8quvDufbM=.e6e1b2ac-b8fc-44e1-9fb9-0a1da08757d3@github.com>

On Fri, 15 Dec 2023 12:27:16 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added missing comment
>
> src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 548:
> 
>> 546:     static ClassDesc classDesc(Class<?> cls) {
>> 547:         return cls.isHidden() ? ClassDesc.ofInternalName(cls.getName().replace('.', '/'))
>> 548:                               : ClassDesc.ofDescriptor(cls.descriptorString());
> 
> This?still isn?t?correct, as?[`Class::getName()`] includes?the?trailing `/<suffix>` for?a?hidden?class.
> Suggestion:
> 
>         if (cls.isHidden()) {
>             var name = cls.getName();
>             return ClassDesc.of(name.substring(0, name.indexOf('/'));
>         }
>         return ClassDesc.ofDescriptor(cls.descriptorString());
> 
> 
> [`Class::getName()`]: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Class.html#getName()

This is fix of `runtime/cds/appcds/dynamicArchive/LambdaProxyCallerIsHidden.java` test.
It is based on the original code way of getting the class name.
Cutting of the class name behind the first slash will remove important suffix.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1427953577

From duke at openjdk.org  Fri Dec 15 14:19:44 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 15 Dec 2023 14:19:44 GMT
Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available()
 test for end-of-stream [v2]
In-Reply-To: <AbtLf08Jgc4Eyu3dnOTqkeQE35ZoJiCE0s-iHt7Sa6Q=.f70df457-df2a-4820-9811-4cd8f8beb4e5@github.com>
References: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
 <AbtLf08Jgc4Eyu3dnOTqkeQE35ZoJiCE0s-iHt7Sa6Q=.f70df457-df2a-4820-9811-4cd8f8beb4e5@github.com>
Message-ID: <CXYQc22TCp43Ypik_rFHAhAchVpAzEgt8KkOliP_AEs=.17d1e60a-08e8-4969-aca3-c6a8dda7cff8@github.com>

On Fri, 15 Dec 2023 03:20:01 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> `GZIPInputStream`, when looking for a concatenated stream, relies on what the underlying `InputStream` says is how many bytes are `available()`. But this is inappropriate because `InputStream.available()` is just an estimate and is allowed (for example) to always return zero.
>> 
>> The fix is to ignore what's `available()` and just proceed and see what happens. If fewer bytes are available than required, the attempt to extend to another stream is canceled just as it was before, e.g., when the next stream header couldn't be read.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments.

A few minor suggestions.

test/jdk/java/util/zip/GZIP/GZIPInputStreamAvailable.java line 52:

> 50:         buf.reset();
> 51:         for(int i = 0; i < 100; i++)
> 52:             buf.write(gz);

Whitespace after `for`, braces are recommended even when optional in the language:

Suggestion:

        for (int i = 0; i < 100; i++) {
            buf.write(gz);
        }

test/jdk/java/util/zip/GZIP/GZIPInputStreamAvailable.java line 53:

> 51:         for(int i = 0; i < 100; i++)
> 52:             buf.write(gz);
> 53:         final byte[] gz32 = buf.toByteArray();

Drop final, consider finding a more expressive name:

Suggestion:

        byte[] concatenatedGz = buf.toByteArray();

test/jdk/java/util/zip/GZIP/GZIPInputStreamAvailable.java line 56:

> 54: 
> 55:         // (a) Read it back from a stream where available() is accurate
> 56:         long count1 = countBytes(new GZIPInputStream(new ByteArrayInputStream(gz32)));

This is the expected number of bytes to be read. This could be calculated directly from the uncompressed data. At least the name should express that this is the expected number of bytes:

Suggestion:

        long expectedBytes = countBytes(new GZIPInputStream(new ByteArrayInputStream(gz32)));

test/jdk/java/util/zip/GZIP/GZIPInputStreamAvailable.java line 62:

> 60: 
> 61:         // They should be the same
> 62:         Assert.assertEquals(count2, count1);

This could be a static import. And for the assertion failure message to be correct, the expected value must come first:

Suggestion:

        assertEquals(expectedBytes, actualBytes);


An alternative here could be to store the original uncompressed data and compare that to the full inflated  data read from GZIPInputStream using assertArrayEquals. The length alone is a bit of a weak proxy for equality.

-------------

PR Review: https://git.openjdk.org/jdk/pull/17113#pullrequestreview-1784136773
PR Review Comment: https://git.openjdk.org/jdk/pull/17113#discussion_r1428015571
PR Review Comment: https://git.openjdk.org/jdk/pull/17113#discussion_r1428017078
PR Review Comment: https://git.openjdk.org/jdk/pull/17113#discussion_r1428019017
PR Review Comment: https://git.openjdk.org/jdk/pull/17113#discussion_r1428020568

From asotona at openjdk.org  Fri Dec 15 14:30:55 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 15 Dec 2023 14:30:55 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator to
 use the Classfile API to generate proxy classes
Message-ID: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>

java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes.

This patch converts it to use Classfile API.

It is continuation of https://github.com/openjdk/jdk/pull/10991

Any comments and suggestions are welcome.

Please review.

Thank you,
Adam

-------------

Commit messages:
 - 8294961: Convert java.base/java.lang.reflect.ProxyGenerator to use the Classfile API to generate proxy classes

Changes: https://git.openjdk.org/jdk/pull/17121/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17121&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294961
  Stats: 444 lines in 2 files changed: 19 ins; 191 del; 234 mod
  Patch: https://git.openjdk.org/jdk/pull/17121.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17121/head:pull/17121

PR: https://git.openjdk.org/jdk/pull/17121

From rriggs at openjdk.org  Fri Dec 15 16:16:48 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 15 Dec 2023 16:16:48 GMT
Subject: Integrated: 8322018: Test
 java/lang/String/CompactString/MaxSizeUTF16String.java fails with -Xcomp
In-Reply-To: <7qbrvSGT9oZvj9tjokk17uxT5_032AY_GjyrD_QGa_g=.e6a674ea-f4f6-49b0-8ece-2910c4531bc4@github.com>
References: <7qbrvSGT9oZvj9tjokk17uxT5_032AY_GjyrD_QGa_g=.e6a674ea-f4f6-49b0-8ece-2910c4531bc4@github.com>
Message-ID: <kR6CwnPlsThuLUm0qJbnayddZiTASIp8JRS3Ccvp2sI=.e002eb23-1ae2-4e48-bb14-c687bd159446@github.com>

On Wed, 13 Dec 2023 21:38:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The test java/lang/String/CompactString/MaxSizeUTF16String.java fails when run with -Xcomp.
> 
> Both the java implementation and the intrinsic for StringUTF16.toBytes() allocate memory for a copy of the string.
> The java implementation of `toBytes()` throws an exception with a message in terms of length of the string.
> The intrinsic uses a generic message when allocating a byte array that is too large for the implementation.
> 
> Test should accept either message on the OOME exception, the message is an implementation detail and should reflect the cause of the error and not be confused with a general out of java heap message.

This pull request has now been integrated.

Changeset: 6311dabe
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6311dabe68762749e4317cfa5e13005318bdceac
Stats:     19 lines in 1 file changed: 14 ins; 0 del; 5 mod

8322018: Test java/lang/String/CompactString/MaxSizeUTF16String.java fails with -Xcomp

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/17095

From acobbs at openjdk.org  Fri Dec 15 16:30:01 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 15 Dec 2023 16:30:01 GMT
Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available()
 test for end-of-stream [v3]
In-Reply-To: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
References: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
Message-ID: <vIbIGoGMaNRDNzqArUyg51FckKiQiRBofvxte7DvP4g=.9bc2e0fc-0a38-487b-8d55-d7090fb4efcf@github.com>

> `GZIPInputStream`, when looking for a concatenated stream, relies on what the underlying `InputStream` says is how many bytes are `available()`. But this is inappropriate because `InputStream.available()` is just an estimate and is allowed (for example) to always return zero.
> 
> The fix is to ignore what's `available()` and just proceed and see what happens. If fewer bytes are available than required, the attempt to extend to another stream is canceled just as it was before, e.g., when the next stream header couldn't be read.

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Address second round of review comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17113/files
  - new: https://git.openjdk.org/jdk/pull/17113/files/c7087e55..074b8455

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17113&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17113&range=01-02

  Stats: 40 lines in 1 file changed: 13 ins; 6 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/17113.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17113/head:pull/17113

PR: https://git.openjdk.org/jdk/pull/17113

From acobbs at openjdk.org  Fri Dec 15 16:30:05 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 15 Dec 2023 16:30:05 GMT
Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available()
 test for end-of-stream [v2]
In-Reply-To: <CXYQc22TCp43Ypik_rFHAhAchVpAzEgt8KkOliP_AEs=.17d1e60a-08e8-4969-aca3-c6a8dda7cff8@github.com>
References: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
 <AbtLf08Jgc4Eyu3dnOTqkeQE35ZoJiCE0s-iHt7Sa6Q=.f70df457-df2a-4820-9811-4cd8f8beb4e5@github.com>
 <CXYQc22TCp43Ypik_rFHAhAchVpAzEgt8KkOliP_AEs=.17d1e60a-08e8-4969-aca3-c6a8dda7cff8@github.com>
Message-ID: <w6xCr9ZmaH4U1Y05vs_Ws5myVXsk22dEkOuPvqwyoM0=.b1f35f97-64b0-46df-a056-139d246425d8@github.com>

On Fri, 15 Dec 2023 14:09:12 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments.
>
> test/jdk/java/util/zip/GZIP/GZIPInputStreamAvailable.java line 52:
> 
>> 50:         buf.reset();
>> 51:         for(int i = 0; i < 100; i++)
>> 52:             buf.write(gz);
> 
> Whitespace after `for`, braces are recommended even when optional in the language:
> 
> Suggestion:
> 
>         for (int i = 0; i < 100; i++) {
>             buf.write(gz);
>         }

Thanks - should be addressed in 074b8455b11.

> test/jdk/java/util/zip/GZIP/GZIPInputStreamAvailable.java line 53:
> 
>> 51:         for(int i = 0; i < 100; i++)
>> 52:             buf.write(gz);
>> 53:         final byte[] gz32 = buf.toByteArray();
> 
> Drop final, consider finding a more expressive name:
> 
> Suggestion:
> 
>         byte[] concatenatedGz = buf.toByteArray();

Thanks - should be addressed in 074b8455b11.

> test/jdk/java/util/zip/GZIP/GZIPInputStreamAvailable.java line 56:
> 
>> 54: 
>> 55:         // (a) Read it back from a stream where available() is accurate
>> 56:         long count1 = countBytes(new GZIPInputStream(new ByteArrayInputStream(gz32)));
> 
> This is the expected number of bytes to be read. This could be calculated directly from the uncompressed data. At least the name should express that this is the expected number of bytes:
> 
> Suggestion:
> 
>         long expectedBytes = countBytes(new GZIPInputStream(new ByteArrayInputStream(gz32)));
> 
> 
> Similarly, `count2` could be renamed `actualBytes`

Thanks - should be addressed in 074b8455b11.

> test/jdk/java/util/zip/GZIP/GZIPInputStreamAvailable.java line 62:
> 
>> 60: 
>> 61:         // They should be the same
>> 62:         Assert.assertEquals(count2, count1);
> 
> This could be a static import. And for the assertion failure message to be correct, the expected value must come first:
> 
> Suggestion:
> 
>         assertEquals(expectedBytes, actualBytes);
> 
> 
> An alternative here could be to store the original uncompressed data and compare that to the full inflated  data read from GZIPInputStream using assertArrayEquals. The length alone is a bit of a weak proxy for equality.

Thanks - should be addressed in 074b8455b11.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17113#discussion_r1428174716
PR Review Comment: https://git.openjdk.org/jdk/pull/17113#discussion_r1428175505
PR Review Comment: https://git.openjdk.org/jdk/pull/17113#discussion_r1428174894
PR Review Comment: https://git.openjdk.org/jdk/pull/17113#discussion_r1428175182

From bpb at openjdk.org  Fri Dec 15 17:24:43 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 15 Dec 2023 17:24:43 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v15]
In-Reply-To: <0L9QJXEAc014B6fWGCh3W5CK822Vw1O9Ze-B-W3m2SY=.2322e284-d896-4b2a-9fc9-c375cf5ac9ca@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <8SYx9TqaT4rL2o4BZ_Fnu_ZxD3vVMdYJS51dtGMK22I=.4b226895-ec4a-49bc-ab1a-c46a2e290405@github.com>
 <dZAa97JgeIWwmAyIMIhBewWJA18a6OSvbjti8NrV0wY=.37ca08b4-6256-44c7-b552-470bb29ed274@github.com>
 <0L9QJXEAc014B6fWGCh3W5CK822Vw1O9Ze-B-W3m2SY=.2322e284-d896-4b2a-9fc9-c375cf5ac9ca@github.com>
Message-ID: <euNCdTLCMfLfmISnyqzbRV-XX9pdrSoVjdptGI8dCoM=.705c2d5f-f408-480e-87e8-b4b60fc763cf@github.com>

On Fri, 15 Dec 2023 09:25:00 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> I think this would be doing double job, wouldn't it?

Sorry, I don't understand.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1428236374

From naoto at openjdk.org  Fri Dec 15 17:36:47 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 15 Dec 2023 17:36:47 GMT
Subject: RFR: 8321958: @param/@return descriptions of
 ZoneRules#isDaylightSavings() are incorrect [v2]
In-Reply-To: <15KaWyH94Qsmj6mnNkgwMVqkSvjVPnlaC6-PlDZZUcU=.e2eed2ca-feb2-4c87-859a-f236a8b7dc8f@github.com>
References: <2150UeprX2CQ34CmEIROihDODlQMKsuPPv3gB-gjChE=.ff26e4a5-48e8-4153-85dc-6f9a7b554116@github.com>
 <15KaWyH94Qsmj6mnNkgwMVqkSvjVPnlaC6-PlDZZUcU=.e2eed2ca-feb2-4c87-859a-f236a8b7dc8f@github.com>
Message-ID: <aPhsRdKRAbSteQcDdV3JDS26aTh7Gv_k32tqDb_I_9A=.8e60cd5b-33cd-4b8d-9c01-2c43aa228feb@github.com>

On Thu, 14 Dec 2023 17:08:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Small document correction on a return description.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Corrected @param description

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17098#issuecomment-1858238897

From naoto at openjdk.org  Fri Dec 15 17:36:48 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 15 Dec 2023 17:36:48 GMT
Subject: Integrated: 8321958: @param/@return descriptions of
 ZoneRules#isDaylightSavings() are incorrect
In-Reply-To: <2150UeprX2CQ34CmEIROihDODlQMKsuPPv3gB-gjChE=.ff26e4a5-48e8-4153-85dc-6f9a7b554116@github.com>
References: <2150UeprX2CQ34CmEIROihDODlQMKsuPPv3gB-gjChE=.ff26e4a5-48e8-4153-85dc-6f9a7b554116@github.com>
Message-ID: <lwbMv6OmnDzMXCsV7jWmggVo7biVZlD9-kBEdpcYFGQ=.c0a5c801-1ef9-4c82-ae87-88835e19fbc0@github.com>

On Wed, 13 Dec 2023 23:10:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Small document correction on a return description.

This pull request has now been integrated.

Changeset: 87ef7332
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/87ef73329f66e898d85eecea94a4104a13b3a2db
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8321958: @param/@return descriptions of ZoneRules#isDaylightSavings() are incorrect

Reviewed-by: jlu, joehw, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/17098

From rgiulietti at openjdk.org  Fri Dec 15 17:39:52 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 15 Dec 2023 17:39:52 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
Message-ID: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>

Adds serialization misdeclaration events to JFR.

-------------

Commit messages:
 - Make use of EventNames.
 - Merge branch 'master' into 8275338
 - 8275338: Add JFR events for notable serialization situations

Changes: https://git.openjdk.org/jdk/pull/17129/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8275338
  Stats: 769 lines in 10 files changed: 769 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17129.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17129/head:pull/17129

PR: https://git.openjdk.org/jdk/pull/17129

From rgiulietti at openjdk.org  Fri Dec 15 17:43:39 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 15 Dec 2023 17:43:39 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
In-Reply-To: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
Message-ID: <F2KeBbIgw_xOnFD7ICZE5fFnQF_LBzqHXgmkLiPB1-k=.87b0aaca-a9d3-4ce3-a221-32eba492f4d8@github.com>

On Fri, 15 Dec 2023 17:34:53 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Adds serialization misdeclaration events to JFR.

A serialization misdeclaration on one of the following fields or methods means that they are not declared according to the Java Object Serialization Specification (JOSS) or in the Java SE specification.

Depending on the exact circumstances, a misdeclared member can be _ineffective_ for serialization, or can still be effective but does not adhere to the conventions stated in the specs.

serialVersionUID
serialPersistentFields

writeObject()
readObject()
readObjectNoData()
writeReplace()
readResolve()

This PR adds JFR events to detect such misdeclarations at runtime, when a serializable class is about to be used for serialization purposes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17129#issuecomment-1858247455

From naoto at openjdk.org  Fri Dec 15 17:46:53 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 15 Dec 2023 17:46:53 GMT
Subject: [jdk22] RFR: 8321958: @param/@return descriptions of
 ZoneRules#isDaylightSavings() are incorrect
Message-ID: <c8Un-3GGhN7zRwnLX2BXgp49nldYIidUrmDo5BQOgBo=.8319d284-297e-45ed-a2c2-b80c1f73adb3@github.com>

8321958: @param/@return descriptions of ZoneRules#isDaylightSavings() are incorrect

-------------

Commit messages:
 - Backport 87ef73329f66e898d85eecea94a4104a13b3a2db

Changes: https://git.openjdk.org/jdk22/pull/16/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=16&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321958
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk22/pull/16.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/16/head:pull/16

PR: https://git.openjdk.org/jdk22/pull/16

From bpb at openjdk.org  Fri Dec 15 18:04:44 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 15 Dec 2023 18:04:44 GMT
Subject: [jdk22] RFR: 8321958: @param/@return descriptions of
 ZoneRules#isDaylightSavings() are incorrect
In-Reply-To: <c8Un-3GGhN7zRwnLX2BXgp49nldYIidUrmDo5BQOgBo=.8319d284-297e-45ed-a2c2-b80c1f73adb3@github.com>
References: <c8Un-3GGhN7zRwnLX2BXgp49nldYIidUrmDo5BQOgBo=.8319d284-297e-45ed-a2c2-b80c1f73adb3@github.com>
Message-ID: <knIdiJPhI_fQP91UZSmRepitPMuJ7hWDy3CHwmGvK1Q=.1bdec232-d54a-43e2-904e-b89c963acea6@github.com>

On Fri, 15 Dec 2023 17:41:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> 8321958: @param/@return descriptions of ZoneRules#isDaylightSavings() are incorrect

Marked as reviewed by bpb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk22/pull/16#pullrequestreview-1784673248

From naoto at openjdk.org  Fri Dec 15 18:15:44 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 15 Dec 2023 18:15:44 GMT
Subject: [jdk22] Integrated: 8321958: @param/@return descriptions of
 ZoneRules#isDaylightSavings() are incorrect
In-Reply-To: <c8Un-3GGhN7zRwnLX2BXgp49nldYIidUrmDo5BQOgBo=.8319d284-297e-45ed-a2c2-b80c1f73adb3@github.com>
References: <c8Un-3GGhN7zRwnLX2BXgp49nldYIidUrmDo5BQOgBo=.8319d284-297e-45ed-a2c2-b80c1f73adb3@github.com>
Message-ID: <CJQmTIiPukYwewXhG2V5a2oGCNKNtN0FJVThltI5x_U=.5c540ab5-b144-428b-a402-961edca82296@github.com>

On Fri, 15 Dec 2023 17:41:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> 8321958: @param/@return descriptions of ZoneRules#isDaylightSavings() are incorrect

This pull request has now been integrated.

Changeset: 57d97b52
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/57d97b52c9d3e92318c9f74cb257efb95bafa3ed
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8321958: @param/@return descriptions of ZoneRules#isDaylightSavings() are incorrect

Reviewed-by: bpb
Backport-of: 87ef73329f66e898d85eecea94a4104a13b3a2db

-------------

PR: https://git.openjdk.org/jdk22/pull/16

From bpb at openjdk.org  Fri Dec 15 18:23:40 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 15 Dec 2023 18:23:40 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred [v2]
In-Reply-To: <0p0DR3d5Tz1Kq3pQQzyjwSYKzZEV5665_vv5LXmaA7Y=.6bc1a26c-d118-4911-90e8-5772f83937f9@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
 <0p0DR3d5Tz1Kq3pQQzyjwSYKzZEV5665_vv5LXmaA7Y=.6bc1a26c-d118-4911-90e8-5772f83937f9@github.com>
Message-ID: <3EEoX01kuX8voRMrJaZia9OaEmY0VkN-vpBH8PXN71o=.fe29a665-e1b8-4c7e-96c1-62d7d4a8d059@github.com>

On Fri, 15 Dec 2023 09:55:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> [...] maybe we need to come up with tests that quickly check the handling at this limit.

@mkarg Do you intend to provide any such test as part of this request?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17119#issuecomment-1858308908

From duke at openjdk.org  Fri Dec 15 18:37:53 2023
From: duke at openjdk.org (Markus KARG)
Date: Fri, 15 Dec 2023 18:37:53 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred [v3]
In-Reply-To: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
Message-ID: <or3XL6VncTjPJX8eTKqk4-ylMborJWXylXZcIBzWDGA=.86149b61-aed0-45df-a93c-76952478708f@github.com>

> Fixes JDK-8322141
> 
> As suggested by @vlsi and documented by @bplb this PR does not return, but only sets the maximum result value.

Markus KARG has updated the pull request incrementally with one additional commit since the last revision:

  New test asserts subsequent input stream is read when preceding stream already was MAX_VALUE long.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17119/files
  - new: https://git.openjdk.org/jdk/pull/17119/files/8181dccd..2aaac630

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17119&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17119&range=01-02

  Stats: 35 lines in 1 file changed: 35 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17119.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17119/head:pull/17119

PR: https://git.openjdk.org/jdk/pull/17119

From duke at openjdk.org  Fri Dec 15 18:37:54 2023
From: duke at openjdk.org (Markus KARG)
Date: Fri, 15 Dec 2023 18:37:54 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred [v3]
In-Reply-To: <3EEoX01kuX8voRMrJaZia9OaEmY0VkN-vpBH8PXN71o=.fe29a665-e1b8-4c7e-96c1-62d7d4a8d059@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
 <0p0DR3d5Tz1Kq3pQQzyjwSYKzZEV5665_vv5LXmaA7Y=.6bc1a26c-d118-4911-90e8-5772f83937f9@github.com>
 <3EEoX01kuX8voRMrJaZia9OaEmY0VkN-vpBH8PXN71o=.fe29a665-e1b8-4c7e-96c1-62d7d4a8d059@github.com>
Message-ID: <rRlsHGXonfniXeRoPkhwu_zcx5KTWg6v1vdveBgaW6U=.df37c481-ceb5-4c04-94ff-a871602c0ee9@github.com>

On Fri, 15 Dec 2023 18:21:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> > [...] maybe we need to come up with tests that quickly check the handling at this limit.

> @mkarg Do you intend to provide any such test as part of this request?

@bplb I quickly drafted an absolute minimal test for this in [2aaac63](https://github.com/openjdk/jdk/pull/17119/commits/2aaac630a3e6d1df0fd77f6b34c0f0d3a3b50292). IMHO this is sufficient for the current case.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17119#issuecomment-1858324061

From stefan at selessia.com  Fri Dec 15 19:07:03 2023
From: stefan at selessia.com (Stefan Norberg)
Date: Fri, 15 Dec 2023 20:07:03 +0100
Subject: Regexp with word-boundary followed by unicode character doesn't work
 in 19, 21
Message-ID: <CAC4ea0FwxqVY5+O2CGR7NvTEEsLJbGAVX5ky=B7j7arWyMj+9g@mail.gmail.com>

The following test works in 17 but fails in 19.0.2, and 21.0.1 on the last
assertion. Bug or feature?

import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;

import java.util.ArrayList;
import java.util.regex.Matcher;
import java.util.regex.Pattern;

/**
* Tests passes in JDK 17 but fails in JDK 19, 21.
*
* The combination of a \b "word boundary" and a unicode char doesn't seem
to work in 19, 21.
*
*/
public class UnicodeTest {
@Test
public void testRegexp() throws Exception {
var text = "En sak som ?kas och sedan minskas. Bra va!";
var word = "?kas";
Assertions.assertTrue(text.contains(word));

Pattern p = Pattern.compile("(\\b" + word + "\\b)");
Matcher m = p.matcher(text);
var matches = new ArrayList<>();

while (m.find()) {
String matchString = m.group();
System.out.println(matchString);
matches.add(matchString);
}
Assertions.assertEquals(1, matches.size());
}
}



openjdk version "21.0.1" 2023-10-17 LTS

OpenJDK Runtime Environment Corretto-21.0.1.12.1 (build 21.0.1+12-LTS)

OpenJDK 64-Bit Server VM Corretto-21.0.1.12.1 (build 21.0.1+12-LTS, mixed
mode, sharing)


System Version: macOS 14.2 (23C64)

Kernel Version: Darwin 23.2.0

Thanks!


/Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20231215/438a63ec/attachment.htm>

From raffaello.giulietti at oracle.com  Fri Dec 15 19:24:28 2023
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Fri, 15 Dec 2023 20:24:28 +0100
Subject: Regexp with word-boundary followed by unicode character doesn't
 work in 19, 21
In-Reply-To: <CAC4ea0FwxqVY5+O2CGR7NvTEEsLJbGAVX5ky=B7j7arWyMj+9g@mail.gmail.com>
References: <CAC4ea0FwxqVY5+O2CGR7NvTEEsLJbGAVX5ky=B7j7arWyMj+9g@mail.gmail.com>
Message-ID: <465d733a-f050-4beb-b8aa-e71f19af9be7@oracle.com>

By default, a word boundary only considers ASCII letters and digits. See 
"Predefined character classes" in the documentation.

To add Unicode support, you have a choice between adding a flag as a 2nd 
argument to the compile() method

Pattern p = Pattern.compile("(\\b" + word + "\\b)", 
Pattern.UNICODE_CHARACTER_CLASS);

or add a flag in the regex pattern, as documented in "Special constructs 
(named-capturing and non-capturing)"

Pattern p = Pattern.compile("(?U)(\\b" + word + "\\b)");


Greetings
Raffaello


On 2023-12-15 20:07, Stefan Norberg wrote:
> The following test works in 17 but fails in 19.0.2, and 21.0.1 on the 
> last assertion. Bug or feature?
> 
> import org.junit.jupiter.api.Assertions;
> import org.junit.jupiter.api.Test;
> 
> import java.util.ArrayList;
> import java.util.regex.Matcher;
> import java.util.regex.Pattern;
> 
> /**
> * Tests passes in JDK 17 but fails in JDK 19, 21.
> *
> * The combination of a \b "word boundary" and a unicode char doesn't 
> seem to work in 19, 21.
> *
> */
> public class UnicodeTest {
> @Test
> public void testRegexp() throws Exception {
> var text = "En sak som ?kas och sedan minskas. Bra va!";
> var word = "?kas";
> Assertions.assertTrue(text.contains(word));
> 
> Pattern p = Pattern.compile("(\\b" + word + "\\b)");
> Matcher m = p.matcher(text);
> var matches = new ArrayList<>();
> 
> while (m.find()) {
> String matchString = m.group();
> System.out.println(matchString);
> matches.add(matchString);
> }
> Assertions.assertEquals(1, matches.size());
> }
> }
> 
> 
> 
> openjdk version "21.0.1" 2023-10-17 LTS
> 
> OpenJDK Runtime Environment Corretto-21.0.1.12.1 (build 21.0.1+12-LTS)
> 
> OpenJDK 64-Bit Server VM Corretto-21.0.1.12.1 (build 21.0.1+12-LTS, 
> mixed mode, sharing)
> 
> 
> System Version: macOS 14.2 (23C64)
> 
> Kernel Version: Darwin 23.2.0
> 
> 
> Thanks!
> 
> 
> /Stefan
> 

From stefan at selessia.com  Fri Dec 15 19:29:21 2023
From: stefan at selessia.com (Stefan Norberg)
Date: Fri, 15 Dec 2023 20:29:21 +0100
Subject: Regexp with word-boundary followed by unicode character doesn't
 work in 19, 21
In-Reply-To: <465d733a-f050-4beb-b8aa-e71f19af9be7@oracle.com>
References: <CAC4ea0FwxqVY5+O2CGR7NvTEEsLJbGAVX5ky=B7j7arWyMj+9g@mail.gmail.com>
 <465d733a-f050-4beb-b8aa-e71f19af9be7@oracle.com>
Message-ID: <CAC4ea0Hite5YLxmtAMuUWE1EjG3BhLNDgfD+rs+pCcS7NZB_jQ@mail.gmail.com>

Thanks Raffaello,
Ah, thanks! Found https://bugs.openjdk.org/browse/JDK-8264160 in the
release notes for 19 just now.
Have a great weekend!

/Stefan

On Fri, Dec 15, 2023 at 8:24?PM Raffaello Giulietti <
raffaello.giulietti at oracle.com> wrote:

> By default, a word boundary only considers ASCII letters and digits. See
> "Predefined character classes" in the documentation.
>
> To add Unicode support, you have a choice between adding a flag as a 2nd
> argument to the compile() method
>
> Pattern p = Pattern.compile("(\\b" + word + "\\b)",
> Pattern.UNICODE_CHARACTER_CLASS);
>
> or add a flag in the regex pattern, as documented in "Special constructs
> (named-capturing and non-capturing)"
>
> Pattern p = Pattern.compile("(?U)(\\b" + word + "\\b)");
>
>
> Greetings
> Raffaello
>
>
> On 2023-12-15 20:07, Stefan Norberg wrote:
> > The following test works in 17 but fails in 19.0.2, and 21.0.1 on the
> > last assertion. Bug or feature?
> >
> > import org.junit.jupiter.api.Assertions;
> > import org.junit.jupiter.api.Test;
> >
> > import java.util.ArrayList;
> > import java.util.regex.Matcher;
> > import java.util.regex.Pattern;
> >
> > /**
> > * Tests passes in JDK 17 but fails in JDK 19, 21.
> > *
> > * The combination of a \b "word boundary" and a unicode char doesn't
> > seem to work in 19, 21.
> > *
> > */
> > public class UnicodeTest {
> > @Test
> > public void testRegexp() throws Exception {
> > var text = "En sak som ?kas och sedan minskas. Bra va!";
> > var word = "?kas";
> > Assertions.assertTrue(text.contains(word));
> >
> > Pattern p = Pattern.compile("(\\b" + word + "\\b)");
> > Matcher m = p.matcher(text);
> > var matches = new ArrayList<>();
> >
> > while (m.find()) {
> > String matchString = m.group();
> > System.out.println(matchString);
> > matches.add(matchString);
> > }
> > Assertions.assertEquals(1, matches.size());
> > }
> > }
> >
> >
> >
> > openjdk version "21.0.1" 2023-10-17 LTS
> >
> > OpenJDK Runtime Environment Corretto-21.0.1.12.1 (build 21.0.1+12-LTS)
> >
> > OpenJDK 64-Bit Server VM Corretto-21.0.1.12.1 (build 21.0.1+12-LTS,
> > mixed mode, sharing)
> >
> >
> > System Version: macOS 14.2 (23C64)
> >
> > Kernel Version: Darwin 23.2.0
> >
> >
> > Thanks!
> >
> >
> > /Stefan
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20231215/7985b85b/attachment-0001.htm>

From stsypanov at openjdk.org  Fri Dec 15 19:37:43 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 15 Dec 2023 19:37:43 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v15]
In-Reply-To: <euNCdTLCMfLfmISnyqzbRV-XX9pdrSoVjdptGI8dCoM=.705c2d5f-f408-480e-87e8-b4b60fc763cf@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <8SYx9TqaT4rL2o4BZ_Fnu_ZxD3vVMdYJS51dtGMK22I=.4b226895-ec4a-49bc-ab1a-c46a2e290405@github.com>
 <dZAa97JgeIWwmAyIMIhBewWJA18a6OSvbjti8NrV0wY=.37ca08b4-6256-44c7-b552-470bb29ed274@github.com>
 <0L9QJXEAc014B6fWGCh3W5CK822Vw1O9Ze-B-W3m2SY=.2322e284-d896-4b2a-9fc9-c375cf5ac9ca@github.com>
 <euNCdTLCMfLfmISnyqzbRV-XX9pdrSoVjdptGI8dCoM=.705c2d5f-f408-480e-87e8-b4b60fc763cf@github.com>
Message-ID: <TsiPmav5k6DExDU6OV_I06YvbSxO0KrjkRcfYaxzHdQ=.e422ae7c-f5b7-4c56-8fc2-bca44bec1393@github.com>

On Fri, 15 Dec 2023 17:21:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I think this would be doing double job, wouldn't it?
>
>> I think this would be doing double job, wouldn't it?
> 
> Sorry, I don't understand.

If we drop the method for now I have to write it later again, I guess

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1428403398

From duke at openjdk.org  Fri Dec 15 20:40:46 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 15 Dec 2023 20:40:46 GMT
Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available()
 test for end-of-stream [v3]
In-Reply-To: <vIbIGoGMaNRDNzqArUyg51FckKiQiRBofvxte7DvP4g=.9bc2e0fc-0a38-487b-8d55-d7090fb4efcf@github.com>
References: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
 <vIbIGoGMaNRDNzqArUyg51FckKiQiRBofvxte7DvP4g=.9bc2e0fc-0a38-487b-8d55-d7090fb4efcf@github.com>
Message-ID: <HbxnVrkNA8z_9BYU_SwzdRFMPed46UZwszPLOeMnZro=.87265577-95d5-4577-a76f-fa834ffbbaf0@github.com>

On Fri, 15 Dec 2023 16:30:01 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> `GZIPInputStream`, when looking for a concatenated stream, relies on what the underlying `InputStream` says is how many bytes are `available()`. But this is inappropriate because `InputStream.available()` is just an estimate and is allowed (for example) to always return zero.
>> 
>> The fix is to ignore what's `available()` and just proceed and see what happens. If fewer bytes are available than required, the attempt to extend to another stream is canceled just as it was before, e.g., when the next stream header couldn't be read.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address second round of review comments.

The test is shaping up nicely. Since it's a new test it should use JUnit 5.

Also included a couple suggestions, I'll stop now, promise! :)

test/jdk/java/util/zip/GZIP/GZIPInputStreamAvailable.java line 30:

> 28:  */
> 29: 
> 30: import org.junit.Test;

Let's use JUnit 5:
Suggestion:

import org.junit.jupiter.api.Test;

test/jdk/java/util/zip/GZIP/GZIPInputStreamAvailable.java line 36:

> 34: import java.util.zip.*;
> 35: 
> 36: import static org.junit.Assert.assertArrayEquals;

Let's use JUnit 5:

Suggestion:

import static org.junit.jupiter.api.Assertions.assertArrayEquals;

test/jdk/java/util/zip/GZIP/GZIPInputStreamAvailable.java line 53:

> 51:         byte[] compressedN = repeat(compressed1, NUM_COPIES);
> 52: 
> 53:         // (a) Read back copied compressed data from a stream where available() is accurate and verify

Suggestion:

        // (a) Read back inflated data from a stream where available() is accurate and verify

test/jdk/java/util/zip/GZIP/GZIPInputStreamAvailable.java line 54:

> 52: 
> 53:         // (a) Read back copied compressed data from a stream where available() is accurate and verify
> 54:         byte[] readback1 = new GZIPInputStream(new ByteArrayInputStream(compressedN)).readAllBytes();

These readback lines got rather long. Perhaps consider extracting the GZIP reading into a method taking the source InputStream as a parameter?

Suggestion:

        byte[] readback1 = inflateFrom(new ByteArrayInputStream(compressedN));

test/jdk/java/util/zip/GZIP/GZIPInputStreamAvailable.java line 57:

> 55:         assertArrayEquals(uncompressedN, readback1);
> 56: 
> 57:         // (b) Read back copied compressed data from a stream where available() always returns zero and verify

Suggestion:

        // (b) Read back inflated data from a stream where available() always returns zero and verify

test/jdk/java/util/zip/GZIP/GZIPInputStreamAvailable.java line 58:

> 56: 
> 57:         // (b) Read back copied compressed data from a stream where available() always returns zero and verify
> 58:         byte[] readback2 = new GZIPInputStream(new ZeroAvailableStream(new ByteArrayInputStream(compressedN))).readAllBytes();

Suggestion:

        byte[] readback2 = inflateFrom(new ZeroAvailableStream(new ByteArrayInputStream(compressedN)));

-------------

PR Review: https://git.openjdk.org/jdk/pull/17113#pullrequestreview-1784857282
PR Review Comment: https://git.openjdk.org/jdk/pull/17113#discussion_r1428434843
PR Review Comment: https://git.openjdk.org/jdk/pull/17113#discussion_r1428435461
PR Review Comment: https://git.openjdk.org/jdk/pull/17113#discussion_r1428452384
PR Review Comment: https://git.openjdk.org/jdk/pull/17113#discussion_r1428455030
PR Review Comment: https://git.openjdk.org/jdk/pull/17113#discussion_r1428452815
PR Review Comment: https://git.openjdk.org/jdk/pull/17113#discussion_r1428456971

From bchristi at openjdk.org  Fri Dec 15 20:42:41 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 15 Dec 2023 20:42:41 GMT
Subject: RFR: 8320919: Clarify Locale related system properties [v6]
In-Reply-To: <K-unE_fO6QjGn8VZE95YZtm-9SeFm1AMt0jJkWJ5zYo=.1300dae3-ed8d-447d-bee7-36310ad4f055@github.com>
References: <IruGxIK9DXnXFDANt1y4sCMJEGZh1PTOKhOWZZxJEdc=.77092e02-fb4f-4c9e-8d53-0fa0cf3bae7d@github.com>
 <K-unE_fO6QjGn8VZE95YZtm-9SeFm1AMt0jJkWJ5zYo=.1300dae3-ed8d-447d-bee7-36310ad4f055@github.com>
Message-ID: <zvYBz_MI7jnQF61V1kFDKH3XtLcARmuPQ6XGnG6X_84=.cc3455d6-f208-44ab-a24f-a1472a9070d8@github.com>

On Thu, 14 Dec 2023 21:50:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a doc change to clarify what the `Default Locale` is, and how it is established during the system startup using the system properties. Those locale-related system properties have existed since the early days of Java, but have never been publicly documented before. It is also the intention of this PR to clarify those system properties and how they are overridden. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

src/java.base/share/classes/java/util/Locale.java line 327:

> 325:  * the value of the {@code user.language.display} system property will be used in the
> 326:  * {@code language} part of the default Locale for {@link Locale.Category#DISPLAY}
> 327:  * category. In the absence of category specific system properties, the "category-less"

"...part of the default Locale for **_the_** Locale.Category#DISPLAY category."
?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17065#discussion_r1428459997

From naoto at openjdk.org  Fri Dec 15 21:02:54 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 15 Dec 2023 21:02:54 GMT
Subject: RFR: 8320919: Clarify Locale related system properties [v6]
In-Reply-To: <zvYBz_MI7jnQF61V1kFDKH3XtLcARmuPQ6XGnG6X_84=.cc3455d6-f208-44ab-a24f-a1472a9070d8@github.com>
References: <IruGxIK9DXnXFDANt1y4sCMJEGZh1PTOKhOWZZxJEdc=.77092e02-fb4f-4c9e-8d53-0fa0cf3bae7d@github.com>
 <K-unE_fO6QjGn8VZE95YZtm-9SeFm1AMt0jJkWJ5zYo=.1300dae3-ed8d-447d-bee7-36310ad4f055@github.com>
 <zvYBz_MI7jnQF61V1kFDKH3XtLcARmuPQ6XGnG6X_84=.cc3455d6-f208-44ab-a24f-a1472a9070d8@github.com>
Message-ID: <pf_PY5Sad9R6mbETpLgXnm31VkXI-kCqbglGJUvSxwM=.871041ef-eccf-4e6d-865c-2b1f820982d3@github.com>

On Fri, 15 Dec 2023 20:39:47 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflects review comments
>
> src/java.base/share/classes/java/util/Locale.java line 327:
> 
>> 325:  * the value of the {@code user.language.display} system property will be used in the
>> 326:  * {@code language} part of the default Locale for {@link Locale.Category#DISPLAY}
>> 327:  * category. In the absence of category specific system properties, the "category-less"
> 
> "...part of the default Locale for **_the_** Locale.Category#DISPLAY category."
> ?

Thanks, Brent. Inserted `the`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17065#discussion_r1428479238

From naoto at openjdk.org  Fri Dec 15 21:02:51 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 15 Dec 2023 21:02:51 GMT
Subject: RFR: 8320919: Clarify Locale related system properties [v7]
In-Reply-To: <IruGxIK9DXnXFDANt1y4sCMJEGZh1PTOKhOWZZxJEdc=.77092e02-fb4f-4c9e-8d53-0fa0cf3bae7d@github.com>
References: <IruGxIK9DXnXFDANt1y4sCMJEGZh1PTOKhOWZZxJEdc=.77092e02-fb4f-4c9e-8d53-0fa0cf3bae7d@github.com>
Message-ID: <q1IKIjNOG4mf-XMMNQL1d7rNYKuwFsP_1kQP3dMrNkk=.b4c7cd8d-0ecc-4afb-ba29-208577108a1b@github.com>

> This is a doc change to clarify what the `Default Locale` is, and how it is established during the system startup using the system properties. Those locale-related system properties have existed since the early days of Java, but have never been publicly documented before. It is also the intention of this PR to clarify those system properties and how they are overridden. A corresponding CSR has been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Reflects review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17065/files
  - new: https://git.openjdk.org/jdk/pull/17065/files/27195f51..e67585e0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17065&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17065&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17065.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17065/head:pull/17065

PR: https://git.openjdk.org/jdk/pull/17065

From acobbs at openjdk.org  Fri Dec 15 21:13:07 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 15 Dec 2023 21:13:07 GMT
Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available()
 test for end-of-stream [v4]
In-Reply-To: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
References: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
Message-ID: <TJ8loA9R1Kf_GxXw9lR-XLW-xqjrkPhdCnZFwFExG1A=.e3d52b42-d008-4841-b979-88d88f04b525@github.com>

> `GZIPInputStream`, when looking for a concatenated stream, relies on what the underlying `InputStream` says is how many bytes are `available()`. But this is inappropriate because `InputStream.available()` is just an estimate and is allowed (for example) to always return zero.
> 
> The fix is to ignore what's `available()` and just proceed and see what happens. If fewer bytes are available than required, the attempt to extend to another stream is canceled just as it was before, e.g., when the next stream header couldn't be read.

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Address third round of review comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17113/files
  - new: https://git.openjdk.org/jdk/pull/17113/files/074b8455..cf457eff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17113&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17113&range=02-03

  Stats: 12 lines in 1 file changed: 4 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/17113.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17113/head:pull/17113

PR: https://git.openjdk.org/jdk/pull/17113

From acobbs at openjdk.org  Fri Dec 15 21:13:08 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 15 Dec 2023 21:13:08 GMT
Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available()
 test for end-of-stream [v3]
In-Reply-To: <HbxnVrkNA8z_9BYU_SwzdRFMPed46UZwszPLOeMnZro=.87265577-95d5-4577-a76f-fa834ffbbaf0@github.com>
References: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
 <vIbIGoGMaNRDNzqArUyg51FckKiQiRBofvxte7DvP4g=.9bc2e0fc-0a38-487b-8d55-d7090fb4efcf@github.com>
 <HbxnVrkNA8z_9BYU_SwzdRFMPed46UZwszPLOeMnZro=.87265577-95d5-4577-a76f-fa834ffbbaf0@github.com>
Message-ID: <MhhlaFQ8MIJneatyMeagiq-EXHGdswZtRyF165kuPV0=.38c049d1-7aae-4b2a-a10d-7e86bed45d9a@github.com>

On Fri, 15 Dec 2023 20:38:19 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> The test is shaping up nicely. Since it's a new test it should use JUnit 5.
> 
> Also included a couple suggestions, I'll stop now, promise! :)

No prob - they're all reasonable suggestions :)

> test/jdk/java/util/zip/GZIP/GZIPInputStreamAvailable.java line 30:
> 
>> 28:  */
>> 29: 
>> 30: import org.junit.Test;
> 
> Let's use JUnit 5:
> Suggestion:
> 
> import org.junit.jupiter.api.Test;

Should be fixed in cf457eff38c.

> test/jdk/java/util/zip/GZIP/GZIPInputStreamAvailable.java line 36:
> 
>> 34: import java.util.zip.*;
>> 35: 
>> 36: import static org.junit.Assert.assertArrayEquals;
> 
> Let's use JUnit 5:
> 
> Suggestion:
> 
> import static org.junit.jupiter.api.Assertions.assertArrayEquals;

Should be fixed in cf457eff38c.

> test/jdk/java/util/zip/GZIP/GZIPInputStreamAvailable.java line 53:
> 
>> 51:         byte[] compressedN = repeat(compressed1, NUM_COPIES);
>> 52: 
>> 53:         // (a) Read back copied compressed data from a stream where available() is accurate and verify
> 
> Suggestion:
> 
>         // (a) Read back inflated data from a stream where available() is accurate and verify

Should be fixed in cf457eff38c.

> test/jdk/java/util/zip/GZIP/GZIPInputStreamAvailable.java line 54:
> 
>> 52: 
>> 53:         // (a) Read back copied compressed data from a stream where available() is accurate and verify
>> 54:         byte[] readback1 = new GZIPInputStream(new ByteArrayInputStream(compressedN)).readAllBytes();
> 
> These readback lines got rather long. Perhaps consider extracting the GZIP reading into a method taking the source InputStream as a parameter?
> 
> Suggestion:
> 
>         byte[] readback1 = inflateFrom(new ByteArrayInputStream(compressedN));

Should be fixed in cf457eff38c.

> test/jdk/java/util/zip/GZIP/GZIPInputStreamAvailable.java line 57:
> 
>> 55:         assertArrayEquals(uncompressedN, readback1);
>> 56: 
>> 57:         // (b) Read back copied compressed data from a stream where available() always returns zero and verify
> 
> Suggestion:
> 
>         // (b) Read back inflated data from a stream where available() always returns zero and verify

Should be fixed in cf457eff38c.

> test/jdk/java/util/zip/GZIP/GZIPInputStreamAvailable.java line 58:
> 
>> 56: 
>> 57:         // (b) Read back copied compressed data from a stream where available() always returns zero and verify
>> 58:         byte[] readback2 = new GZIPInputStream(new ZeroAvailableStream(new ByteArrayInputStream(compressedN))).readAllBytes();
> 
> Suggestion:
> 
>         byte[] readback2 = inflateFrom(new ZeroAvailableStream(new ByteArrayInputStream(compressedN)));

Should be fixed in cf457eff38c.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17113#issuecomment-1858489270
PR Review Comment: https://git.openjdk.org/jdk/pull/17113#discussion_r1428486646
PR Review Comment: https://git.openjdk.org/jdk/pull/17113#discussion_r1428487198
PR Review Comment: https://git.openjdk.org/jdk/pull/17113#discussion_r1428486708
PR Review Comment: https://git.openjdk.org/jdk/pull/17113#discussion_r1428487465
PR Review Comment: https://git.openjdk.org/jdk/pull/17113#discussion_r1428486783
PR Review Comment: https://git.openjdk.org/jdk/pull/17113#discussion_r1428486924

From rgiulietti at openjdk.org  Fri Dec 15 22:26:04 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 15 Dec 2023 22:26:04 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v2]
In-Reply-To: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
Message-ID: <ETA8uKzeRwTYkvSRjpzeBDCLzM21yUyz5tHhn5TS3RM=.b4c80ae2-0d64-413e-9ad9-6a50214fc8b0@github.com>

> Adds serialization misdeclaration events to JFR.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Restrict accessibility of nested classes.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17129/files
  - new: https://git.openjdk.org/jdk/pull/17129/files/f0b96e97..629e8f23

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=00-01

  Stats: 22 lines in 2 files changed: 3 ins; 2 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/17129.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17129/head:pull/17129

PR: https://git.openjdk.org/jdk/pull/17129

From bpb at openjdk.org  Fri Dec 15 22:42:39 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 15 Dec 2023 22:42:39 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred [v3]
In-Reply-To: <rRlsHGXonfniXeRoPkhwu_zcx5KTWg6v1vdveBgaW6U=.df37c481-ceb5-4c04-94ff-a871602c0ee9@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
 <0p0DR3d5Tz1Kq3pQQzyjwSYKzZEV5665_vv5LXmaA7Y=.6bc1a26c-d118-4911-90e8-5772f83937f9@github.com>
 <3EEoX01kuX8voRMrJaZia9OaEmY0VkN-vpBH8PXN71o=.fe29a665-e1b8-4c7e-96c1-62d7d4a8d059@github.com>
 <rRlsHGXonfniXeRoPkhwu_zcx5KTWg6v1vdveBgaW6U=.df37c481-ceb5-4c04-94ff-a871602c0ee9@github.com>
Message-ID: <xdCqn82wCMGKpBPnaO1rTqQUL1JiojVi4cQNRGVAmdg=.f05ca1f9-5ee9-486d-b0d9-87dfd3b1badd@github.com>

On Fri, 15 Dec 2023 18:34:42 GMT, Markus KARG <duke at openjdk.org> wrote:

> I quickly drafted an absolute minimal test for this in [2aaac63] [...].

This test does not fail for me when run against my local build of the current mainline. Usually, unless randomness is involved, a test should fail before the proposed patch is applied but succeed thereafter.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17119#issuecomment-1858574102

From duke at openjdk.org  Fri Dec 15 23:07:38 2023
From: duke at openjdk.org (Markus KARG)
Date: Fri, 15 Dec 2023 23:07:38 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred [v3]
In-Reply-To: <xdCqn82wCMGKpBPnaO1rTqQUL1JiojVi4cQNRGVAmdg=.f05ca1f9-5ee9-486d-b0d9-87dfd3b1badd@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
 <0p0DR3d5Tz1Kq3pQQzyjwSYKzZEV5665_vv5LXmaA7Y=.6bc1a26c-d118-4911-90e8-5772f83937f9@github.com>
 <3EEoX01kuX8voRMrJaZia9OaEmY0VkN-vpBH8PXN71o=.fe29a665-e1b8-4c7e-96c1-62d7d4a8d059@github.com>
 <rRlsHGXonfniXeRoPkhwu_zcx5KTWg6v1vdveBgaW6U=.df37c481-ceb5-4c04-94ff-a871602c0ee9@github.com>
 <xdCqn82wCMGKpBPnaO1rTqQUL1JiojVi4cQNRGVAmdg=.f05ca1f9-5ee9-486d-b0d9-87dfd3b1badd@github.com>
Message-ID: <u4pVP-imISZ0GQYymN0IbKBDKjGePQ6b0Ncgzh-t7NI=.8791b0c7-e651-4d25-9920-c2d0caf6c2cf@github.com>

On Fri, 15 Dec 2023 22:40:17 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> This test does not fail for me when run against my local build of the current mainline. Usually, unless randomness is involved, a test should fail before the proposed patch is applied but succeed thereafter.

This is weird. How could that code ever pass without the patch?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17119#issuecomment-1858590771

From naoto.sato at oracle.com  Fri Dec 15 23:25:29 2023
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 15 Dec 2023 15:25:29 -0800
Subject: Regexp with word-boundary followed by unicode character doesn't
 work in 19, 21
In-Reply-To: <CAC4ea0Hite5YLxmtAMuUWE1EjG3BhLNDgfD+rs+pCcS7NZB_jQ@mail.gmail.com>
References: <CAC4ea0FwxqVY5+O2CGR7NvTEEsLJbGAVX5ky=B7j7arWyMj+9g@mail.gmail.com>
 <465d733a-f050-4beb-b8aa-e71f19af9be7@oracle.com>
 <CAC4ea0Hite5YLxmtAMuUWE1EjG3BhLNDgfD+rs+pCcS7NZB_jQ@mail.gmail.com>
Message-ID: <423391f1-cd9f-4c9c-8a30-ec0fb1b6082c@oracle.com>

Or use extended Grapheme Cluster boundary "\\b{g}" instead of "\\b". 
This will correctly search emoji sequences such as ???????, while 
"\\b" with Unicode option won't.

HTH,
Naoto

On 12/15/23 11:29 AM, Stefan Norberg wrote:
> Thanks?Raffaello,
> Ah, thanks! Found https://bugs.openjdk.org/browse/JDK-8264160 
> <https://bugs.openjdk.org/browse/JDK-8264160> in the release notes for 
> 19 just now.
> Have a great weekend!
> 
> /Stefan
> 
> On Fri, Dec 15, 2023 at 8:24?PM Raffaello Giulietti 
> <raffaello.giulietti at oracle.com <mailto:raffaello.giulietti at oracle.com>> 
> wrote:
> 
>     By default, a word boundary only considers ASCII letters and digits.
>     See
>     "Predefined character classes" in the documentation.
> 
>     To add Unicode support, you have a choice between adding a flag as a
>     2nd
>     argument to the compile() method
> 
>     Pattern p = Pattern.compile("(\\b" + word + "\\b)",
>     Pattern.UNICODE_CHARACTER_CLASS);
> 
>     or add a flag in the regex pattern, as documented in "Special
>     constructs
>     (named-capturing and non-capturing)"
> 
>     Pattern p = Pattern.compile("(?U)(\\b" + word + "\\b)");
> 
> 
>     Greetings
>     Raffaello
> 
> 
>     On 2023-12-15 20:07, Stefan Norberg wrote:
>      > The following test works in 17 but fails in 19.0.2, and 21.0.1 on
>     the
>      > last assertion. Bug or feature?
>      >
>      > import org.junit.jupiter.api.Assertions;
>      > import org.junit.jupiter.api.Test;
>      >
>      > import java.util.ArrayList;
>      > import java.util.regex.Matcher;
>      > import java.util.regex.Pattern;
>      >
>      > /**
>      > * Tests passes in JDK 17 but fails in JDK 19, 21.
>      > *
>      > * The combination of a \b "word boundary" and a unicode char doesn't
>      > seem to work in 19, 21.
>      > *
>      > */
>      > public class UnicodeTest {
>      > @Test
>      > public void testRegexp() throws Exception {
>      > var text = "En sak som ?kas och sedan minskas. Bra va!";
>      > var word = "?kas";
>      > Assertions.assertTrue(text.contains(word));
>      >
>      > Pattern p = Pattern.compile("(\\b" + word + "\\b)");
>      > Matcher m = p.matcher(text);
>      > var matches = new ArrayList<>();
>      >
>      > while (m.find()) {
>      > String matchString = m.group();
>      > System.out.println(matchString);
>      > matches.add(matchString);
>      > }
>      > Assertions.assertEquals(1, matches.size());
>      > }
>      > }
>      >
>      >
>      >
>      > openjdk version "21.0.1" 2023-10-17 LTS
>      >
>      > OpenJDK Runtime Environment Corretto-21.0.1.12.1 (build
>     21.0.1+12-LTS)
>      >
>      > OpenJDK 64-Bit Server VM Corretto-21.0.1.12.1 (build 21.0.1+12-LTS,
>      > mixed mode, sharing)
>      >
>      >
>      > System Version: macOS 14.2 (23C64)
>      >
>      > Kernel Version: Darwin 23.2.0
>      >
>      >
>      > Thanks!
>      >
>      >
>      > /Stefan
>      >
> 

From bpb at openjdk.org  Sat Dec 16 00:13:41 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Sat, 16 Dec 2023 00:13:41 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v15]
In-Reply-To: <TsiPmav5k6DExDU6OV_I06YvbSxO0KrjkRcfYaxzHdQ=.e422ae7c-f5b7-4c56-8fc2-bca44bec1393@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <8SYx9TqaT4rL2o4BZ_Fnu_ZxD3vVMdYJS51dtGMK22I=.4b226895-ec4a-49bc-ab1a-c46a2e290405@github.com>
 <dZAa97JgeIWwmAyIMIhBewWJA18a6OSvbjti8NrV0wY=.37ca08b4-6256-44c7-b552-470bb29ed274@github.com>
 <0L9QJXEAc014B6fWGCh3W5CK822Vw1O9Ze-B-W3m2SY=.2322e284-d896-4b2a-9fc9-c375cf5ac9ca@github.com>
 <euNCdTLCMfLfmISnyqzbRV-XX9pdrSoVjdptGI8dCoM=.705c2d5f-f408-480e-87e8-b4b60fc763cf@github.com>
 <TsiPmav5k6DExDU6OV_I06YvbSxO0KrjkRcfYaxzHdQ=.e422ae7c-f5b7-4c56-8fc2-bca44bec1393@github.com>
Message-ID: <P0ndNW257XHjZnSbh6tgKvTk2xGJmMjVJVdEU7n1vrg=.8ac0aa39-aab2-4120-aa10-649b8128226c@github.com>

On Fri, 15 Dec 2023 19:35:18 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> If we drop the method for now I have to write it later again, I guess

Maybe, but it's archived so it's easy enough.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1428601842

From jjg at openjdk.org  Sat Dec 16 00:30:43 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Sat, 16 Dec 2023 00:30:43 GMT
Subject: RFR: 8322041: JDK 22 RDP1 L10n resource files update [v2]
In-Reply-To: <Egb10aiw4mPByp-kgJx5KNIR7Rc9SRwemJVG9I1Jp5Y=.d16ce069-7a0e-4ebc-aed4-35ad02aea347@github.com>
References: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
 <Egb10aiw4mPByp-kgJx5KNIR7Rc9SRwemJVG9I1Jp5Y=.d16ce069-7a0e-4ebc-aed4-35ad02aea347@github.com>
Message-ID: <vui2bQ07IKPZlxU0kxYYremw50nCWrLQg4_aLtOkqyA=.2f07249e-dc8b-4578-93ce-7c4ed32c4a1b@github.com>

On Thu, 14 Dec 2023 22:17:54 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Translation drop for JDK22 RDP1
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed quotes around Ablehnen

The diffs are more conveniently available here:
https://cr.openjdk.org/~jjg/jdk-l10n-diffs--15dec23/

The compiler and javadoc diffs look "ok" but I cannot read most other languages, and cannot comment on the quality of the translations. I do see that there are places where a translation has been edited where the English original has not. I also see issues with some of the English messages, but that is not for here. 

My "approval" is just for `jdk.compiler` and `jdk.javadoc` files.

-------------

Marked as reviewed by jjg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17096#pullrequestreview-1785076089

From achung at openjdk.org  Sat Dec 16 01:05:46 2023
From: achung at openjdk.org (Alisen Chung)
Date: Sat, 16 Dec 2023 01:05:46 GMT
Subject: Integrated: 8322041: JDK 22 RDP1 L10n resource files update
In-Reply-To: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
References: <hxXaP5joY_NTYBPMMLVwR_KtMkEHKDgzl3BRYxp5Hu8=.36351034-b1d8-4535-92d0-efe9aae47480@github.com>
Message-ID: <NFpfs0qdRUOnXNf5GJOgxCzucmZQK0fg1Vwia3ZOwKU=.281411ad-914c-471c-835a-f99a1f9e2d06@github.com>

On Wed, 13 Dec 2023 22:12:48 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Translation drop for JDK22 RDP1

This pull request has now been integrated.

Changeset: b061b667
Author:    Alisen Chung <achung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b061b6678fde891974d5b58cec963b3481099a8d
Stats:     290 lines in 36 files changed: 166 ins; 15 del; 109 mod

8322041: JDK 22 RDP1 L10n resource files update

Reviewed-by: almatvee, cstein, asemenyuk, joehw, jjg

-------------

PR: https://git.openjdk.org/jdk/pull/17096

From egahlin at openjdk.org  Sat Dec 16 01:30:38 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sat, 16 Dec 2023 01:30:38 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v2]
In-Reply-To: <ETA8uKzeRwTYkvSRjpzeBDCLzM21yUyz5tHhn5TS3RM=.b4c80ae2-0d64-413e-9ad9-6a50214fc8b0@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <ETA8uKzeRwTYkvSRjpzeBDCLzM21yUyz5tHhn5TS3RM=.b4c80ae2-0d64-413e-9ad9-6a50214fc8b0@github.com>
Message-ID: <fmdSrcdXS-1mrnFZfef_gpjuVCcddZCHpj9MzeVLXIw=.1c3c494a-0399-4c72-a870-e8b43fcb70dc@github.com>

On Fri, 15 Dec 2023 22:26:04 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restrict accessibility of nested classes.

It seems correct to have the event disabled in both configurations. It's not hard to imagine pathological cases where millions of stream objects are created, which would create overhead and flood event buffers, making JFR not usable.

That said, I wonder how many will actually use, or find out about the event, if they need to edit the .jfc file or specify -XX:StartFlightRecording:jdk.SerializationMisdeclaration#enabled=true on command line? 

How important is the stack trace when diagnosing serialization misdeclarations?

We faced a similar situation with the Finalization event a couple of years ago, but we were able to make the event periodic and enabled by default with some VM magic. An event that is enabled by default will probably be seen by 10 000 times as many users, so it might be worth considering other approaches, even if they are harder to implement, or we lose some of the information.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17129#issuecomment-1858665731

From duke at openjdk.org  Sat Dec 16 05:56:40 2023
From: duke at openjdk.org (Bernd)
Date: Sat, 16 Dec 2023 05:56:40 GMT
Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available()
 test for end-of-stream [v4]
In-Reply-To: <TJ8loA9R1Kf_GxXw9lR-XLW-xqjrkPhdCnZFwFExG1A=.e3d52b42-d008-4841-b979-88d88f04b525@github.com>
References: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
 <TJ8loA9R1Kf_GxXw9lR-XLW-xqjrkPhdCnZFwFExG1A=.e3d52b42-d008-4841-b979-88d88f04b525@github.com>
Message-ID: <HXXiM-MGVLXh3gv7Abs4dd3ipgQqsWdCzPjfK-fG8CI=.584a80cc-9f8f-45f8-817c-54e3eaf468fc@github.com>

On Fri, 15 Dec 2023 21:13:07 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> `GZIPInputStream`, when looking for a concatenated stream, relies on what the underlying `InputStream` says is how many bytes are `available()`. But this is inappropriate because `InputStream.available()` is just an estimate and is allowed (for example) to always return zero.
>> 
>> The fix is to ignore what's `available()` and just proceed and see what happens. If fewer bytes are available than required, the attempt to extend to another stream is canceled just as it was before, e.g., when the next stream header couldn't be read.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address third round of review comments.

Misuse of available() is a petpeave of mine, so I am happy to see that change and test. I wonder: if the stream does no longer depend on this available() condition to be true, does that mean it?s no longer (indirectly) verified? That behavior might not be guaranteed, but it?s still often relied upon. (I guess injecting a return 0 into the current implementation and running the tests would tell us if another test catches it?)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17113#issuecomment-1858731583

From vsitnikov at openjdk.org  Sat Dec 16 07:27:43 2023
From: vsitnikov at openjdk.org (Vladimir Sitnikov)
Date: Sat, 16 Dec 2023 07:27:43 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v15]
In-Reply-To: <8Nndvje8ODVuIPgPEx9sqzj19OQNs18BGwTwtlSaMWQ=.c7f39ccd-6b12-4019-a212-8b3fc3e98df0@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <vrdFV2cgL_pMuQWhcgLiV5STWcrxjahjiMq86qghuwM=.a2da54b7-0c22-4608-9857-d48bb207d7d4@github.com>
 <06dpAmRUHn4PyHDz2vZLZ9FyzF6u81qj_39hbqP7PnE=.2924f568-9021-46e7-b1fb-0c7a4d5f9c4d@github.com>
 <TRdmt9bEfMyCOTFYsvxvZSdfFPvnk0H_0SMPX5rqO0s=.028e96eb-52e0-4960-b955-1f12202978c9@github.com>
 <6IitbefHaaKPhCkB_FRZnBxTyZJi0i8jjh8Pr32jsb8=.956ea224-3aff-4c86-9e28-6399172bfc92@github.com>
 <NXUxb-lZvWnXhc0tuyHN4acnl24E0p6N9tjR6SRjocI=.feb4f5cc-b1ac-4b3f-bee2-c57e5fe101bf@github.com>
 <h3gsRz_Q935JguupcZqwssUazi6miz6k4RMFCULNPwg=.d1fe182b-1b04-4e19-803a-ce166ded27f4@github.com>
 <5PkUvozvjQnOZ40SBRcdabaHwJFhHPl0I5UniEE_C3s=.9269db2b-e3cc-4487-b540-b8f90cbe6df7@github.com>
 <7JHnl4QcbKEDH4V6rxX33WHoeTuyBGQG1z5a6jhNjjs=.45301468-a6c2-46bc-9c96-570ec8bdc887@github.com>
 <0NmifS49RKzaRhohbMSEck5cW62UUnTTQGZc5L-2EL8=.1cba3343-1cab-4a31-873d-09356653391a@github.com>
 <8Nndvje8ODVuIPgPEx9sqzj19OQNs18BGwT
 wtlSaMWQ=.c7f39ccd-6b12-4019-a212-8b3fc3e98df0@github.com>
Message-ID: <yBoEF0c_bD0OOuxvKZxbNLHSLN2wa1jVSEcrCD1r25k=.80bbfefe-226b-4bc5-9839-cb78323cc316@github.com>

On Mon, 4 Dec 2023 14:05:14 GMT, Vladimir Sitnikov <vsitnikov at openjdk.org> wrote:

>>> > it doesn't solve the second part of the concern which is read-only view on the internal buffer.
>>> 
>>> I think `ByteBuffer.asReadOnlyBuffer()` should resolve the issues regarding naked byte access. At least `ByteBuffer#array()` returns `null` for read-only buffers, and `ByteBuffer#hasArray()` returns `false`. Am I missing something?
>> 
>> The backing array is not frozen so a read-only view doesn't address the second part of the concern where the target keeps a reference.
>
>>The backing array is not frozen so a read-only view doesn't address the second part of the concern where the target keeps a reference.
> 
> The users outside of OpenJDK would not have a reference to `byte[]`.
> Do you mean a reference to `ByteBuffer`?
> What if there was a `ByteBuffer#forbidReads()` method that would permanently forbid subsequent reads from the `ByteBuffer`?

I've created a draft change for `OutputStream#write(ByteBuffer)`, and I have benchmarked several cases including `ByteArrayInputStream.transferTo(BufferedOutputStream(ByteArrayOutputStream))`, `ByteArrayInputStream.transferTo(DataOutputStream(FileOutputStream))`.

Benchmarks show there's improvement in both allocation rate and latency.

Read-only `ByteBuffers` can address poisoning concerns as non-jdk code can't peek into read-only arrays.

The `write(ByteBuffer)` approach supports cases like `CheckedOutputStream`, `DataOutputStream` which would be hard or impossible to optimize when passing naked byte arrays.

Here are the results: https://gist.github.com/vlsi/7f4411515a4f2dbb0925fffde92ccb1d
Here is the diff: https://github.com/vlsi/jdk/compare/ce108446ca1fe604ecc24bbefb0bf1c6318271c7...write_bytebuffer

@mkarg , @bplb , @AlanBateman , could you please review `OutputStream.write(ByteBuffer)` approach?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1428725435

From duke at openjdk.org  Sat Dec 16 14:07:52 2023
From: duke at openjdk.org (Markus KARG)
Date: Sat, 16 Dec 2023 14:07:52 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred [v4]
In-Reply-To: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
Message-ID: <MgqxdnIJbR-Kan1rvnLN0M63R5zLUcThXNHvdJDGCP4=.77f9b25a-12fa-4edb-935b-eb19196da8da@github.com>

> Fixes JDK-8322141
> 
> As suggested by @vlsi and documented by @bplb this PR does not return, but only sets the maximum result value.

Markus KARG has updated the pull request incrementally with one additional commit since the last revision:

  Test was using Integer but must use Long

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17119/files
  - new: https://git.openjdk.org/jdk/pull/17119/files/2aaac630..556a8dc4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17119&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17119&range=02-03

  Stats: 18 lines in 1 file changed: 10 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/17119.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17119/head:pull/17119

PR: https://git.openjdk.org/jdk/pull/17119

From duke at openjdk.org  Sat Dec 16 14:07:53 2023
From: duke at openjdk.org (Markus KARG)
Date: Sat, 16 Dec 2023 14:07:53 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred [v4]
In-Reply-To: <xdCqn82wCMGKpBPnaO1rTqQUL1JiojVi4cQNRGVAmdg=.f05ca1f9-5ee9-486d-b0d9-87dfd3b1badd@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
 <0p0DR3d5Tz1Kq3pQQzyjwSYKzZEV5665_vv5LXmaA7Y=.6bc1a26c-d118-4911-90e8-5772f83937f9@github.com>
 <3EEoX01kuX8voRMrJaZia9OaEmY0VkN-vpBH8PXN71o=.fe29a665-e1b8-4c7e-96c1-62d7d4a8d059@github.com>
 <rRlsHGXonfniXeRoPkhwu_zcx5KTWg6v1vdveBgaW6U=.df37c481-ceb5-4c04-94ff-a871602c0ee9@github.com>
 <xdCqn82wCMGKpBPnaO1rTqQUL1JiojVi4cQNRGVAmdg=.f05ca1f9-5ee9-486d-b0d9-87dfd3b1badd@github.com>
Message-ID: <SsiJ5rOSFcba9KvghEc_YEeRt_9EDr_NQYef7GusaM0=.18c480cb-c412-45c0-93fa-9381d6639b53@github.com>

On Fri, 15 Dec 2023 22:40:17 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>>> > [...] maybe we need to come up with tests that quickly check the handling at this limit.
>> 
>>> @mkarg Do you intend to provide any such test as part of this request?
>> 
>> @bplb I quickly drafted an absolute minimal test for this in [2aaac63](https://github.com/openjdk/jdk/pull/17119/commits/2aaac630a3e6d1df0fd77f6b34c0f0d3a3b50292). IMHO this is sufficient for the current case.
>
>> I quickly drafted an absolute minimal test for this in [2aaac63] [...].
> 
> This test does not fail for me when run against my local build of the current mainline. Usually, unless randomness is involved, a test should fail before the proposed patch is applied but succeed thereafter.

@bplb Test is fixed now. Sorry for the delay. I have updated the test (contained in https://github.com/openjdk/jdk/pull/17119/commits/556a8dc4d3d8ff157e8374625eb129a08926e0dd) and successfully tried it with the original code (test fails) and the fixed code (test succeeds). IMHO this should do the job.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17119#issuecomment-1858826626

From vsitnikov at openjdk.org  Sat Dec 16 14:07:56 2023
From: vsitnikov at openjdk.org (Vladimir Sitnikov)
Date: Sat, 16 Dec 2023 14:07:56 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred [v3]
In-Reply-To: <or3XL6VncTjPJX8eTKqk4-ylMborJWXylXZcIBzWDGA=.86149b61-aed0-45df-a93c-76952478708f@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
 <or3XL6VncTjPJX8eTKqk4-ylMborJWXylXZcIBzWDGA=.86149b61-aed0-45df-a93c-76952478708f@github.com>
Message-ID: <di9VA40qo-dfmWf-bSTsYxdAb0k0c_pUC1W2hvlGn0o=.54a03fda-6778-45f6-9429-d2be7015a93c@github.com>

On Fri, 15 Dec 2023 18:37:53 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Fixes JDK-8322141
>> 
>> As suggested by @vlsi and documented by @bplb this PR does not return, but only sets the maximum result value.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   New test asserts subsequent input stream is read when preceding stream already was MAX_VALUE long.

test/jdk/java/io/SequenceInputStream/TransferTo.java line 160:

> 158:                 pos++;
> 159:                 return b;
> 160:             }

To trigger the problematic case, we need to transfer more than `Long.MAX_VALUE`. `Integer.MAX_VALUE` is not enough, and we need nearly `Integer.MAX_VALUE * Integer.MAX_VALUE` bytes to trigger the problematic case which might take noticeable time.

I think the easiest way would be overriding `transferTo(...)` in a mock `InputStream` so it returns `Long.MAX_VALUE`, and adding that stream in a sequence.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17119#discussion_r1428720731

From duke at openjdk.org  Sat Dec 16 14:07:56 2023
From: duke at openjdk.org (Markus KARG)
Date: Sat, 16 Dec 2023 14:07:56 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred [v3]
In-Reply-To: <di9VA40qo-dfmWf-bSTsYxdAb0k0c_pUC1W2hvlGn0o=.54a03fda-6778-45f6-9429-d2be7015a93c@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
 <or3XL6VncTjPJX8eTKqk4-ylMborJWXylXZcIBzWDGA=.86149b61-aed0-45df-a93c-76952478708f@github.com>
 <di9VA40qo-dfmWf-bSTsYxdAb0k0c_pUC1W2hvlGn0o=.54a03fda-6778-45f6-9429-d2be7015a93c@github.com>
Message-ID: <WE9lidknEyu8fyCVr_7Udu39IacMEgho59zpX0C12KQ=.476b99dc-3b43-4338-bd19-226eb7d320dc@github.com>

On Sat, 16 Dec 2023 07:02:57 GMT, Vladimir Sitnikov <vsitnikov at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   New test asserts subsequent input stream is read when preceding stream already was MAX_VALUE long.
>
> test/jdk/java/io/SequenceInputStream/TransferTo.java line 160:
> 
>> 158:                 pos++;
>> 159:                 return b;
>> 160:             }
> 
> To trigger the problematic case, we need to transfer more than `Long.MAX_VALUE`. `Integer.MAX_VALUE` is not enough, and we need nearly `Integer.MAX_VALUE * Integer.MAX_VALUE` bytes to trigger the problematic case which might take noticeable time.
> 
> I think the easiest way would be overriding `transferTo(...)` in a mock `InputStream` so it returns `Long.MAX_VALUE`, and adding that stream in a sequence.

I know and the solution is already in progress (see my last comment from yesterday). Stay tuned.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17119#discussion_r1428746194

From duke at openjdk.org  Sat Dec 16 14:07:56 2023
From: duke at openjdk.org (Markus KARG)
Date: Sat, 16 Dec 2023 14:07:56 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred [v3]
In-Reply-To: <WE9lidknEyu8fyCVr_7Udu39IacMEgho59zpX0C12KQ=.476b99dc-3b43-4338-bd19-226eb7d320dc@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
 <or3XL6VncTjPJX8eTKqk4-ylMborJWXylXZcIBzWDGA=.86149b61-aed0-45df-a93c-76952478708f@github.com>
 <di9VA40qo-dfmWf-bSTsYxdAb0k0c_pUC1W2hvlGn0o=.54a03fda-6778-45f6-9429-d2be7015a93c@github.com>
 <WE9lidknEyu8fyCVr_7Udu39IacMEgho59zpX0C12KQ=.476b99dc-3b43-4338-bd19-226eb7d320dc@github.com>
Message-ID: <Ohny50CgQvvNpFi8VITJ4T2QF4vSZIBijBsq8KzkutQ=.240c52a1-ef0b-413a-b4d8-a487f4f21535@github.com>

On Sat, 16 Dec 2023 08:56:16 GMT, Markus KARG <duke at openjdk.org> wrote:

>> test/jdk/java/io/SequenceInputStream/TransferTo.java line 160:
>> 
>>> 158:                 pos++;
>>> 159:                 return b;
>>> 160:             }
>> 
>> To trigger the problematic case, we need to transfer more than `Long.MAX_VALUE`. `Integer.MAX_VALUE` is not enough, and we need nearly `Integer.MAX_VALUE * Integer.MAX_VALUE` bytes to trigger the problematic case which might take noticeable time.
>> 
>> I think the easiest way would be overriding `transferTo(...)` in a mock `InputStream` so it returns `Long.MAX_VALUE`, and adding that stream in a sequence.
>
> I know and the solution is already in progress (see my last comment from yesterday). Stay tuned.

Done, see https://github.com/openjdk/jdk/pull/17119/commits/556a8dc4d3d8ff157e8374625eb129a08926e0dd. :-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17119#discussion_r1428818440

From duke at openjdk.org  Sat Dec 16 14:55:42 2023
From: duke at openjdk.org (Markus KARG)
Date: Sat, 16 Dec 2023 14:55:42 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v15]
In-Reply-To: <yBoEF0c_bD0OOuxvKZxbNLHSLN2wa1jVSEcrCD1r25k=.80bbfefe-226b-4bc5-9839-cb78323cc316@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <vrdFV2cgL_pMuQWhcgLiV5STWcrxjahjiMq86qghuwM=.a2da54b7-0c22-4608-9857-d48bb207d7d4@github.com>
 <06dpAmRUHn4PyHDz2vZLZ9FyzF6u81qj_39hbqP7PnE=.2924f568-9021-46e7-b1fb-0c7a4d5f9c4d@github.com>
 <TRdmt9bEfMyCOTFYsvxvZSdfFPvnk0H_0SMPX5rqO0s=.028e96eb-52e0-4960-b955-1f12202978c9@github.com>
 <6IitbefHaaKPhCkB_FRZnBxTyZJi0i8jjh8Pr32jsb8=.956ea224-3aff-4c86-9e28-6399172bfc92@github.com>
 <NXUxb-lZvWnXhc0tuyHN4acnl24E0p6N9tjR6SRjocI=.feb4f5cc-b1ac-4b3f-bee2-c57e5fe101bf@github.com>
 <h3gsRz_Q935JguupcZqwssUazi6miz6k4RMFCULNPwg=.d1fe182b-1b04-4e19-803a-ce166ded27f4@github.com>
 <5PkUvozvjQnOZ40SBRcdabaHwJFhHPl0I5UniEE_C3s=.9269db2b-e3cc-4487-b540-b8f90cbe6df7@github.com>
 <7JHnl4QcbKEDH4V6rxX33WHoeTuyBGQG1z5a6jhNjjs=.45301468-a6c2-46bc-9c96-570ec8bdc887@github.com>
 <0NmifS49RKzaRhohbMSEck5cW62UUnTTQGZc5L-2EL8=.1cba3343-1cab-4a31-873d-09356653391a@github.com>
 <8Nndvje8ODVuIPgPEx9sqzj19OQNs18BGwT
 wtlSaMWQ=.c7f39ccd-6b12-4019-a212-8b3fc3e98df0@github.com>
 <yBoEF0c_bD0OOuxvKZxbNLHSLN2wa1jVSEcrCD1r25k=.80bbfefe-226b-4bc5-9839-cb78323cc316@github.com>
Message-ID: <bTceBQzcMUyh5z2-ohM89Wimodf2GHRDInRdOYqJxkw=.3990dd0d-51e5-49a1-8a23-768f2c01ff6b@github.com>

On Sat, 16 Dec 2023 07:24:59 GMT, Vladimir Sitnikov <vsitnikov at openjdk.org> wrote:

>>>The backing array is not frozen so a read-only view doesn't address the second part of the concern where the target keeps a reference.
>> 
>> The users outside of OpenJDK would not have a reference to `byte[]`.
>> Do you mean a reference to `ByteBuffer`?
>> What if there was a `ByteBuffer#forbidReads()` method that would permanently forbid subsequent reads from the `ByteBuffer`?
>
> I've created a draft change for `OutputStream#write(ByteBuffer)`, and I have benchmarked several cases including `ByteArrayInputStream.transferTo(BufferedOutputStream(ByteArrayOutputStream))`, `ByteArrayInputStream.transferTo(DataOutputStream(FileOutputStream))`.
> 
> Benchmarks show there's improvement in both allocation rate and latency.
> 
> Read-only `ByteBuffers` can address poisoning concerns as non-jdk code can't peek into read-only arrays.
> 
> The `write(ByteBuffer)` approach supports cases like `CheckedOutputStream`, `DataOutputStream` which would be hard or impossible to optimize when passing naked byte arrays.
> 
> Here are the results: https://gist.github.com/vlsi/7f4411515a4f2dbb0925fffde92ccb1d
> Here is the diff: https://github.com/vlsi/jdk/compare/ce108446ca1fe604ecc24bbefb0bf1c6318271c7...write_bytebuffer
> 
> @mkarg , @bplb , @AlanBateman , could you please review `OutputStream.write(ByteBuffer)` approach?

@vlsi This is a very interesting solution ?, but it opens a number of questions! ? As a start, here are mine:
* You propose a new public method (`OutputStream.write(ByteBuffer)`) as part of your solution. We need to discuss whether this is worth the effort to change all implementations (and to perceive acceptable performance, all custom authors need to optimize their custom classes, too). We also need to discuss whether we like the design choice that de facto the public API (not just the implementation) of the legacy IO domain (`OutputStream`) is now linked to the NIO domain (`ByteBuffer`) (which, IMHO, feels some kind of scary beyond `ChannelOutputStream`).
* Just thinking loudly: I wonder if we could simplify the solution, or if we could turn parts of it into some generic `byte[] readOnly(byte[])` utility.
* I would like to know how much faster the solution with `ByteBuffer` is compared to `Arrays.copyOfRange()`: Is it really so huge that it is worth the additional trouble?
* I would like to know how much slower the solution with `ByteBuffer` is compared to *skipping* `Arrays.copyOfRange()` for trusted cases (as you removed the skipping).
* I would like to know the performance of custom streams, because your default implementation is filling a temporary byte array with a Java-implemented byte-by-byte loop, which IMHO would be rather painful compared to hardware-supported `copyOrRange()`, and it does that even in case of *trusted* targets.
* @briangoetz Wouldn't we rather teach the Java language some day to provide native read-only arrays? That would be much faster, much better to read and implies less complex code for the end user.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1428830013

From liangchenblue at gmail.com  Sat Dec 16 15:07:39 2023
From: liangchenblue at gmail.com (-)
Date: Sat, 16 Dec 2023 09:07:39 -0600
Subject: Should Class.name field be @Stable?
Message-ID: <CABe8uE0+5Te8yvZgUrkHn3miY9QF6Z_Cv6=O-+HQ_78SM8C1ww@mail.gmail.com>

Hello,
I just noticed the Class.name field is mutable but not @Stable, meaning
`Class.getName()` calls are not eligible for constant folding.

The last update to this field is in 2019 in JDK-8216302 when the field
initialization was done directly by a write from hotspot code (for the
class name is interned anyways, though interning limits scalability of
hidden classes)

Would it be a good idea to submit a patch to mark this field @Stable? Given
class names may be frequently used to quickly identify a class, to create
descriptors.

Chen Liang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20231216/2f2e00ed/attachment-0001.htm>

From liach at openjdk.org  Sat Dec 16 15:20:38 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 16 Dec 2023 15:20:38 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v2]
In-Reply-To: <Ddu9digMR_byFeipDo0VsLs0oPac4DOZDa8quvDufbM=.e6e1b2ac-b8fc-44e1-9fb9-0a1da08757d3@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <ryPVgRWbldkLMNq2GOZZqYLydDKWgixV910y7KY01qw=.63e9f740-66db-4529-a211-e8db04e6bfe4@github.com>
 <LI_8ssl-DBK-OBVmMArWlfGuvSnpiQYlc2lIeGrhNaU=.b98524ba-01c4-4191-b4b9-a15c6297b360@github.com>
 <Ddu9digMR_byFeipDo0VsLs0oPac4DOZDa8quvDufbM=.e6e1b2ac-b8fc-44e1-9fb9-0a1da08757d3@github.com>
Message-ID: <BesXaKS1HbmJxG5xppWl82vZAqR3HVzLSXVLkyjb9zs=.13698173-8dc7-4e9f-ac63-3738b592466a@github.com>

On Fri, 15 Dec 2023 13:02:57 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 548:
>> 
>>> 546:     static ClassDesc classDesc(Class<?> cls) {
>>> 547:         return cls.isHidden() ? ClassDesc.ofInternalName(cls.getName().replace('.', '/'))
>>> 548:                               : ClassDesc.ofDescriptor(cls.descriptorString());
>> 
>> This?still isn?t?correct, as?[`Class::getName()`] includes?the?trailing `/<suffix>` for?a?hidden?class.
>> Suggestion:
>> 
>>         if (cls.isHidden()) {
>>             var name = cls.getName();
>>             return ClassDesc.of(name.substring(0, name.indexOf('/'));
>>         }
>>         return ClassDesc.ofDescriptor(cls.descriptorString());
>> 
>> 
>> [`Class::getName()`]: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Class.html#getName()
>
> This is fix of `runtime/cds/appcds/dynamicArchive/LambdaProxyCallerIsHidden.java` test.
> It is based on the original code way of getting the class name.
> Cutting of the class name behind the first slash will remove important suffix.

Notice that hidden classes can be created by providing a javac-produced class file, and is frequently used to redefine the same class multiple times (distinguished by their random suffix) in tests. Thus hidden classes may totally use bootstrap methods like lambda or enhanced switch and their secondary hidden classes must be distinguished from each other.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1428836408

From liach at openjdk.org  Sat Dec 16 15:20:41 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 16 Dec 2023 15:20:41 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v2]
In-Reply-To: <ryPVgRWbldkLMNq2GOZZqYLydDKWgixV910y7KY01qw=.63e9f740-66db-4529-a211-e8db04e6bfe4@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <ryPVgRWbldkLMNq2GOZZqYLydDKWgixV910y7KY01qw=.63e9f740-66db-4529-a211-e8db04e6bfe4@github.com>
Message-ID: <G3jIWYtmtgn75d5y0ebI5D9-tn1ZvvcSuehhlO3rziM=.01d0f628-a53a-4c39-849a-e993b2205a47@github.com>

On Fri, 15 Dec 2023 12:26:50 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
>> 
>> This patch converts ASM calls to Classfile API.
>> 
>> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
>> 
>> Any comments and suggestions are welcome.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added missing comment

src/java.base/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java line 67:

> 65: 
> 66:     static private TypeKind primitiveTypeKindFromClass(Class<?> type) {
> 67:         return switch (type.getName().length()) {

We can probably just use an if-chain like that in `sun.invoke.util.Wrapper`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1428834792

From vsitnikov at openjdk.org  Sat Dec 16 15:43:40 2023
From: vsitnikov at openjdk.org (Vladimir Sitnikov)
Date: Sat, 16 Dec 2023 15:43:40 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v15]
In-Reply-To: <bTceBQzcMUyh5z2-ohM89Wimodf2GHRDInRdOYqJxkw=.3990dd0d-51e5-49a1-8a23-768f2c01ff6b@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <vrdFV2cgL_pMuQWhcgLiV5STWcrxjahjiMq86qghuwM=.a2da54b7-0c22-4608-9857-d48bb207d7d4@github.com>
 <06dpAmRUHn4PyHDz2vZLZ9FyzF6u81qj_39hbqP7PnE=.2924f568-9021-46e7-b1fb-0c7a4d5f9c4d@github.com>
 <TRdmt9bEfMyCOTFYsvxvZSdfFPvnk0H_0SMPX5rqO0s=.028e96eb-52e0-4960-b955-1f12202978c9@github.com>
 <6IitbefHaaKPhCkB_FRZnBxTyZJi0i8jjh8Pr32jsb8=.956ea224-3aff-4c86-9e28-6399172bfc92@github.com>
 <NXUxb-lZvWnXhc0tuyHN4acnl24E0p6N9tjR6SRjocI=.feb4f5cc-b1ac-4b3f-bee2-c57e5fe101bf@github.com>
 <h3gsRz_Q935JguupcZqwssUazi6miz6k4RMFCULNPwg=.d1fe182b-1b04-4e19-803a-ce166ded27f4@github.com>
 <5PkUvozvjQnOZ40SBRcdabaHwJFhHPl0I5UniEE_C3s=.9269db2b-e3cc-4487-b540-b8f90cbe6df7@github.com>
 <7JHnl4QcbKEDH4V6rxX33WHoeTuyBGQG1z5a6jhNjjs=.45301468-a6c2-46bc-9c96-570ec8bdc887@github.com>
 <0NmifS49RKzaRhohbMSEck5cW62UUnTTQGZc5L-2EL8=.1cba3343-1cab-4a31-873d-09356653391a@github.com>
 <8Nndvje8ODVuIPgPEx9sqzj19OQNs18BGwT
 wtlSaMWQ=.c7f39ccd-6b12-4019-a212-8b3fc3e98df0@github.com>
 <yBoEF0c_bD0OOuxvKZxbNLHSLN2wa1jVSEcrCD1r25k=.80bbfefe-226b-4bc5-9839-cb78323cc316@github.com>
 <bTceBQzcMUyh5z2-ohM89Wimodf2GHRDInRdOYqJxkw=.3990dd0d-51e5-49a1-8a23-768f2c01ff6b@github.com>
Message-ID: <qL0IlTSylqz2uHwqDJjHq_sdQua6Pi7-qqop831C1G4=.9664525a-85e0-4271-bd62-ca28eb3d0502@github.com>

On Sat, 16 Dec 2023 14:52:42 GMT, Markus KARG <duke at openjdk.org> wrote:

>> I've created a draft change for `OutputStream#write(ByteBuffer)`, and I have benchmarked several cases including `ByteArrayInputStream.transferTo(BufferedOutputStream(ByteArrayOutputStream))`, `ByteArrayInputStream.transferTo(DataOutputStream(FileOutputStream))`.
>> 
>> Benchmarks show there's improvement in both allocation rate and latency.
>> 
>> Read-only `ByteBuffers` can address poisoning concerns as non-jdk code can't peek into read-only arrays.
>> 
>> The `write(ByteBuffer)` approach supports cases like `CheckedOutputStream`, `DataOutputStream` which would be hard or impossible to optimize when passing naked byte arrays.
>> 
>> Here are the results: https://gist.github.com/vlsi/7f4411515a4f2dbb0925fffde92ccb1d
>> Here is the diff: https://github.com/vlsi/jdk/compare/ce108446ca1fe604ecc24bbefb0bf1c6318271c7...write_bytebuffer
>> 
>> @mkarg , @bplb , @AlanBateman , could you please review `OutputStream.write(ByteBuffer)` approach?
>
> @vlsi This is a very interesting solution ?, but it opens a number of questions! ? As a start, here are mine:
> * You propose a new public method (`OutputStream.write(ByteBuffer)`) as part of your solution. We need to discuss whether this is worth the effort to change all implementations (and to perceive acceptable performance, all custom authors need to optimize their custom classes, too). We also need to discuss whether we like the design choice that de facto the public API (not just the implementation) of the legacy IO domain (`OutputStream`) is now linked to the NIO domain (`ByteBuffer`) (which, IMHO, feels some kind of scary beyond `ChannelOutputStream`).
> * Just thinking loudly: I wonder if we could simplify the solution, or if we could turn parts of it into some generic `byte[] readOnly(byte[])` utility.
> * I would like to know how much faster the solution with `ByteBuffer` is compared to `Arrays.copyOfRange()`: Is it really so huge that it is worth the additional trouble?
> * I would like to know how much slower the solution with `ByteBuffer` is compared to *skipping* `Arrays.copyOfRange()` for trusted cases (as you removed the skipping).
> * I would like to know the performance of custom streams, because your default implementation is filling a temporary byte array with a Java-implemented byte-by-byte loop, which IMHO would be rather painful compared to hardware-supported `copyOrRange()`, and it does that even in case of *trusted* targets.
> * @briangoetz Wouldn't we rather teach the Java language some day to provide native read-only arrays? That would be much faster, much better to read and implies less complex code for the end user.

@mkarg , thank you for the review, I replied in JIRA to avoid mixing comments across different issues: https://bugs.openjdk.org/browse/JDK-8321271?focusedId=14634794&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14634794

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1428842060

From briangoetz at openjdk.org  Sat Dec 16 15:58:41 2023
From: briangoetz at openjdk.org (Brian Goetz)
Date: Sat, 16 Dec 2023 15:58:41 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v15]
In-Reply-To: <qL0IlTSylqz2uHwqDJjHq_sdQua6Pi7-qqop831C1G4=.9664525a-85e0-4271-bd62-ca28eb3d0502@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <vrdFV2cgL_pMuQWhcgLiV5STWcrxjahjiMq86qghuwM=.a2da54b7-0c22-4608-9857-d48bb207d7d4@github.com>
 <06dpAmRUHn4PyHDz2vZLZ9FyzF6u81qj_39hbqP7PnE=.2924f568-9021-46e7-b1fb-0c7a4d5f9c4d@github.com>
 <TRdmt9bEfMyCOTFYsvxvZSdfFPvnk0H_0SMPX5rqO0s=.028e96eb-52e0-4960-b955-1f12202978c9@github.com>
 <6IitbefHaaKPhCkB_FRZnBxTyZJi0i8jjh8Pr32jsb8=.956ea224-3aff-4c86-9e28-6399172bfc92@github.com>
 <NXUxb-lZvWnXhc0tuyHN4acnl24E0p6N9tjR6SRjocI=.feb4f5cc-b1ac-4b3f-bee2-c57e5fe101bf@github.com>
 <h3gsRz_Q935JguupcZqwssUazi6miz6k4RMFCULNPwg=.d1fe182b-1b04-4e19-803a-ce166ded27f4@github.com>
 <5PkUvozvjQnOZ40SBRcdabaHwJFhHPl0I5UniEE_C3s=.9269db2b-e3cc-4487-b540-b8f90cbe6df7@github.com>
 <7JHnl4QcbKEDH4V6rxX33WHoeTuyBGQG1z5a6jhNjjs=.45301468-a6c2-46bc-9c96-570ec8bdc887@github.com>
 <0NmifS49RKzaRhohbMSEck5cW62UUnTTQGZc5L-2EL8=.1cba3343-1cab-4a31-873d-09356653391a@github.com>
 <8Nndvje8ODVuIPgPEx9sqzj19OQNs18BGwT
 wtlSaMWQ=.c7f39ccd-6b12-4019-a212-8b3fc3e98df0@github.com>
 <yBoEF0c_bD0OOuxvKZxbNLHSLN2wa1jVSEcrCD1r25k=.80bbfefe-226b-4bc5-9839-cb78323cc316@github.com>
 <bTceBQzcMUyh5z2-ohM89Wimodf2GHRDInRdOYqJxkw=.3990dd0d-51e5-49a1-8a23-768f2c01ff6b@github.com>
 <qL0IlTSylqz2uHwqDJjHq_sdQua6Pi7-qqop831C1G4=.9664525a-85e0-4271-bd62-ca28eb3d0502@github.com>
Message-ID: <KcTPZ_jdMGsMQeNuHzUNPxxXUXomjwhLEvtmNg2GvGo=.3dd8ae7a-8428-4ead-929e-cb6985b93dad@github.com>

On Sat, 16 Dec 2023 15:40:50 GMT, Vladimir Sitnikov <vsitnikov at openjdk.org> wrote:

>> @vlsi This is a very interesting solution ?, but it opens a number of questions! ? As a start, here are mine:
>> * You propose a new public method (`OutputStream.write(ByteBuffer)`) as part of your solution. We need to discuss whether this is worth the effort to change all implementations (and to perceive acceptable performance, all custom authors need to optimize their custom classes, too). We also need to discuss whether we like the design choice that de facto the public API (not just the implementation) of the legacy IO domain (`OutputStream`) is now linked to the NIO domain (`ByteBuffer`) (which, IMHO, feels some kind of scary beyond `ChannelOutputStream`).
>> * Just thinking loudly: I wonder if we could simplify the solution, or if we could turn parts of it into some generic `byte[] readOnly(byte[])` utility.
>> * I would like to know how much faster the solution with `ByteBuffer` is compared to `Arrays.copyOfRange()`: Is it really so huge that it is worth the additional trouble?
>> * I would like to know how much slower the solution with `ByteBuffer` is compared to *skipping* `Arrays.copyOfRange()` for trusted cases (as you removed the skipping).
>> * I would like to know the performance of custom streams, because your default implementation is filling a temporary byte array with a Java-implemented byte-by-byte loop, which IMHO would be rather painful compared to hardware-supported `copyOrRange()`, and it does that even in case of *trusted* targets.
>> * @briangoetz Wouldn't we rather teach the Java language some day to provide native read-only arrays? That would be much faster, much better to read and implies less complex code for the end user.
>
> @mkarg , thank you for the review, I replied in JIRA to avoid mixing comments across different issues: https://bugs.openjdk.org/browse/JDK-8321271?focusedId=14634794&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14634794

While frozen arrays are on our radar, this is a significant lift, so unlikely to be coming all that soon.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1428846145

From liach at openjdk.org  Sat Dec 16 17:12:50 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 16 Dec 2023 17:12:50 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v2]
In-Reply-To: <ryPVgRWbldkLMNq2GOZZqYLydDKWgixV910y7KY01qw=.63e9f740-66db-4529-a211-e8db04e6bfe4@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <ryPVgRWbldkLMNq2GOZZqYLydDKWgixV910y7KY01qw=.63e9f740-66db-4529-a211-e8db04e6bfe4@github.com>
Message-ID: <JPxIdiqmGMXIQOtKKI4ZbT9P4eTK3QBubhMXS5B1bWM=.1b74cf4e-1d39-4207-8ed8-a6f1d4878467@github.com>

On Fri, 15 Dec 2023 12:26:50 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
>> 
>> This patch converts ASM calls to Classfile API.
>> 
>> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
>> 
>> Any comments and suggestions are welcome.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added missing comment

src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 318:

> 316:                 accidentallySerializable |= !isSerializable && Serializable.class.isAssignableFrom(i);
> 317:             }
> 318:             interfaces = new ArrayList<>(itfs);

Suggestion:

            interfaces = List.copyOf(itfs);

src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 406:

> 404:                     public void accept(CodeBuilder cob) {
> 405:                         cob.aload(0)
> 406:                            .invokespecial(CD_Object, INIT_NAME, MethodTypeDesc.of(CD_void));

Suggestion:

                           .invokespecial(CD_Object, INIT_NAME, MTD_void);

src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 548:

> 546:     static ClassDesc classDesc(Class<?> cls) {
> 547:         return cls.isHidden() ? ClassDesc.ofInternalName(cls.getName().replace('.', '/'))
> 548:                               : ClassDesc.ofDescriptor(cls.descriptorString());

That said, all the usages already anticipate a valid `ClassDesc` that can be encoded in bytecode except `implClass`. You should make 2 versions of `classDesc()`, one that eagerly throws for all other usages, and another special version that handles hidden class conversion (with the same code as existing method) for https://github.com/openjdk/jdk/pull/17108/files#diff-76236a0dd20022f749d95ad5890e2bece0c4ac212d1b2ffab90ca86875f14282R173

src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 468:

> 466:     }
> 467: 
> 468:     private void emitStoreInsn(BasicType type, int index) {

If we are going to use `localsMap` in every removed `emitStoreInsn`, perhaps we should restore it instead? Will also make it easier to move away from localsMap to CodeBuilder's tracking system.

src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 529:

> 527:         // Expects MethodHandle on the stack and actual receiver MethodHandle in slot #0
> 528:         cob.dup()
> 529:            .aload(0)

Note for other reviewers: localsMap[0] is 0 in constructor

src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 990:

> 988:         cob.invokevirtual(MRE_Class_isInstance);
> 989:         Label L_rethrow = cob.newLabel();
> 990:         cob.branchInstruction(Opcode.IFEQ, L_rethrow);

Suggestion:

        cob.ifeq(L_rethrow);

src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 1002:

> 1000: 
> 1001:         cob.labelBinding(L_rethrow);
> 1002:         cob.throwInstruction();

Suggestion:

        cob.athrow();

src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 1131:

> 1129:             emitPopInsn(cob, basicReturnType);
> 1130:         }
> 1131:         cob.throwInstruction();

Suggestion:

        cob.athrow();

src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 1145:

> 1143:     private static Opcode popInsnOpcode(BasicType type) {
> 1144:         switch (type) {
> 1145:             case I_TYPE:

Should restore the enhanced switch syntax

src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 1171:

> 1169:         cob.getfield(ClassDesc.ofInternalName("java/lang/invoke/MethodHandleImpl$CasesHolder"), "cases",
> 1170:                 CD_MethodHandle.arrayType());
> 1171:         int casesLocal = extendLocalsMap(new Class<?>[] { MethodHandle[].class });

We should look into replacing the local map with `CodeBuilder.allocateLocal` etc. in the future.

src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 1519:

> 1517:         //      double      -     d2i,i2b   d2i,i2s  d2i,i2c    d2i      d2l      d2f      <->
> 1518:         if (from != to && from != TypeKind.BooleanType && to != TypeKind.BooleanType) try {
> 1519:             cob.convertInstruction(from, to);

Need an intermediate int if you are converting from long/float/double to byte/short/char.

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 2290:

> 2288:                 int accessFlags;
> 2289:                 try {
> 2290:                     ClassModel cm = java.lang.classfile.ClassFile.of().parse(bytes);

No need for fully-qualified name.

src/java.base/share/classes/java/lang/invoke/MethodType.java line 1295:

> 1293:     public Optional<MethodTypeDesc> describeConstable() {
> 1294:         try {
> 1295:             var params = new ClassDesc[parameterCount()];

We can probably handle like this:

var retDesc = returnType().describeConstable();
if (retDesc.isEmpty())
    return Optional.empty();

if (parameterCount() == 0)
    return Optional.of(MethodTypeDesc.of(retDesc.get()));

var params = new ClassDesc[parameterCount()];
for (int i = 0; i < params.length; i++) {
    var paramDesc = parameterType(i).describeConstable();
    if (paramDesc.isEmpty())
        return Optional.empty();
    params[i] = paramDesc.get();
}
return Optional.of(MethodTypeDesc.of(returnType().get(), params));


To avoid creating exceptions and allocating array when the params array is empty.

src/java.base/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java line 162:

> 160:         } else {
> 161:             Class<?> src;
> 162:             if (arg == functional || functional.isPrimitive()) {

`arg == functional` avoids a cast, though it's not in parity with the older code. Should probably restore the old cast that takes a source argument to avoid adding `==` checks to avoid casts.

src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java line 379:

> 377:     @Override
> 378:     public ClassEntry classEntry(ClassDesc classDesc) {
> 379:         if (classDesc == ConstantDescs.CD_Object) {

What causes the slow lookup of Object CE? If it's because that hashing needs to compute the substring first, I recommend changing the hashing algorithm if that's the case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1428838012
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1428838938
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1428845878
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1428856469
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1428851052
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1428853927
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1428854077
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1428854309
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1428855265
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1428850744
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1428857603
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1428859242
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1428860067
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1428862861
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1428863415

From liach at openjdk.org  Sat Dec 16 17:17:42 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 16 Dec 2023 17:17:42 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v15]
In-Reply-To: <P0ndNW257XHjZnSbh6tgKvTk2xGJmMjVJVdEU7n1vrg=.8ac0aa39-aab2-4120-aa10-649b8128226c@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <8SYx9TqaT4rL2o4BZ_Fnu_ZxD3vVMdYJS51dtGMK22I=.4b226895-ec4a-49bc-ab1a-c46a2e290405@github.com>
 <dZAa97JgeIWwmAyIMIhBewWJA18a6OSvbjti8NrV0wY=.37ca08b4-6256-44c7-b552-470bb29ed274@github.com>
 <0L9QJXEAc014B6fWGCh3W5CK822Vw1O9Ze-B-W3m2SY=.2322e284-d896-4b2a-9fc9-c375cf5ac9ca@github.com>
 <euNCdTLCMfLfmISnyqzbRV-XX9pdrSoVjdptGI8dCoM=.705c2d5f-f408-480e-87e8-b4b60fc763cf@github.com>
 <TsiPmav5k6DExDU6OV_I06YvbSxO0KrjkRcfYaxzHdQ=.e422ae7c-f5b7-4c56-8fc2-bca44bec1393@github.com>
 <P0ndNW257XHjZnSbh6tgKvTk2xGJmMjVJVdEU7n1vrg=.8ac0aa39-aab2-4120-aa10-649b8128226c@github.com>
Message-ID: <ygBFvyFtGX_ucxCbdy_YWjgVC2b3YHMZ0YUKlfwBVgs=.7e81ce36-cb48-43b4-a142-70ef2ff6084e@github.com>

On Sat, 16 Dec 2023 00:11:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> If we drop the method for now I have to write it later again, I guess
>
>> If we drop the method for now I have to write it later again, I guess
> 
> Maybe, but it's archived so it's easy enough.

If this is only used after Module system is ready, we can use something like:
https://github.com/openjdk/jdk/blob/34351b7a7950a3b563748f40f2619374f62f9b16/src/java.base/share/classes/java/nio/file/Files.java#L3352


if (out.getClass().getModule() == Object.class.getModule())

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1428864626

From duke at openjdk.org  Sat Dec 16 17:32:40 2023
From: duke at openjdk.org (ExE Boss)
Date: Sat, 16 Dec 2023 17:32:40 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v2]
In-Reply-To: <ryPVgRWbldkLMNq2GOZZqYLydDKWgixV910y7KY01qw=.63e9f740-66db-4529-a211-e8db04e6bfe4@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <ryPVgRWbldkLMNq2GOZZqYLydDKWgixV910y7KY01qw=.63e9f740-66db-4529-a211-e8db04e6bfe4@github.com>
Message-ID: <aM8Sgna07i1Xo1Q4_g8D6BMwxM12cVM-FTDBp7okIr4=.abadae69-d620-4097-9fb9-3f135a031562@github.com>

On Fri, 15 Dec 2023 12:26:50 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
>> 
>> This patch converts ASM calls to Classfile API.
>> 
>> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
>> 
>> Any comments and suggestions are welcome.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added missing comment

src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 187:

> 185:         // generating bridges in the target class)
> 186:         useImplMethodHandle = (Modifier.isProtected(implInfo.getModifiers()) &&
> 187:                                !VerifyAccess.isSamePackage(targetClass, implInfo.getDeclaringClass())) ||

If?the?`implClass` is?hidden, then?it?s not?possible to?generate?bytecode which?correctly?refers to?`implMethod`, so?the?only?way is?to?use the?method?handle in?that?case:
Suggestion:

        useImplMethodHandle = (Modifier.isProtected(implInfo.getModifiers()) &&
                               !VerifyAccess.isSamePackage(targetClass, implInfo.getDeclaringClass())) ||
                               implClass.isHidden() ||

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1428867973

From duke at openjdk.org  Sat Dec 16 17:42:39 2023
From: duke at openjdk.org (Markus KARG)
Date: Sat, 16 Dec 2023 17:42:39 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred [v4]
In-Reply-To: <MgqxdnIJbR-Kan1rvnLN0M63R5zLUcThXNHvdJDGCP4=.77f9b25a-12fa-4edb-935b-eb19196da8da@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
 <MgqxdnIJbR-Kan1rvnLN0M63R5zLUcThXNHvdJDGCP4=.77f9b25a-12fa-4edb-935b-eb19196da8da@github.com>
Message-ID: <dSCvYZZCDnKyW4mzNaXOBrRde27ng2a8AUSuoy11yoo=.32a13c37-6830-4807-b613-35cf4c06a74e@github.com>

On Sat, 16 Dec 2023 14:07:52 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Fixes JDK-8322141
>> 
>> As suggested by @vlsi and documented by @bplb this PR does not return, but only sets the maximum result value.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test was using Integer but must use Long

Kindly asking for review. :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17119#issuecomment-1858879606

From duke at openjdk.org  Sat Dec 16 17:49:43 2023
From: duke at openjdk.org (Markus KARG)
Date: Sat, 16 Dec 2023 17:49:43 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v15]
In-Reply-To: <KcTPZ_jdMGsMQeNuHzUNPxxXUXomjwhLEvtmNg2GvGo=.3dd8ae7a-8428-4ead-929e-cb6985b93dad@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <vrdFV2cgL_pMuQWhcgLiV5STWcrxjahjiMq86qghuwM=.a2da54b7-0c22-4608-9857-d48bb207d7d4@github.com>
 <06dpAmRUHn4PyHDz2vZLZ9FyzF6u81qj_39hbqP7PnE=.2924f568-9021-46e7-b1fb-0c7a4d5f9c4d@github.com>
 <TRdmt9bEfMyCOTFYsvxvZSdfFPvnk0H_0SMPX5rqO0s=.028e96eb-52e0-4960-b955-1f12202978c9@github.com>
 <6IitbefHaaKPhCkB_FRZnBxTyZJi0i8jjh8Pr32jsb8=.956ea224-3aff-4c86-9e28-6399172bfc92@github.com>
 <NXUxb-lZvWnXhc0tuyHN4acnl24E0p6N9tjR6SRjocI=.feb4f5cc-b1ac-4b3f-bee2-c57e5fe101bf@github.com>
 <h3gsRz_Q935JguupcZqwssUazi6miz6k4RMFCULNPwg=.d1fe182b-1b04-4e19-803a-ce166ded27f4@github.com>
 <5PkUvozvjQnOZ40SBRcdabaHwJFhHPl0I5UniEE_C3s=.9269db2b-e3cc-4487-b540-b8f90cbe6df7@github.com>
 <7JHnl4QcbKEDH4V6rxX33WHoeTuyBGQG1z5a6jhNjjs=.45301468-a6c2-46bc-9c96-570ec8bdc887@github.com>
 <0NmifS49RKzaRhohbMSEck5cW62UUnTTQGZc5L-2EL8=.1cba3343-1cab-4a31-873d-09356653391a@github.com>
 <8Nndvje8ODVuIPgPEx9sqzj19OQNs18BGwT
 wtlSaMWQ=.c7f39ccd-6b12-4019-a212-8b3fc3e98df0@github.com>
 <yBoEF0c_bD0OOuxvKZxbNLHSLN2wa1jVSEcrCD1r25k=.80bbfefe-226b-4bc5-9839-cb78323cc316@github.com>
 <bTceBQzcMUyh5z2-ohM89Wimodf2GHRDInRdOYqJxkw=.3990dd0d-51e5-49a1-8a23-768f2c01ff6b@github.com>
 <qL0IlTSylqz2uHwqDJjHq_sdQua6Pi7-qqop831C1G4=.9664525a-85e0-4271-bd62-ca28eb3d0502@github.com>
 <KcTPZ_jdMGsMQeNuHzUNPxxXUXomjwhLEvtmNg2GvGo=.3dd8ae7a-8428-4ead-929e-cb6985b93dad@github.com>
Message-ID: <gJPrfJPps_TkLvyMtDf6LfJPuonBo4cMeMR6kz-n2CY=.b8c4dbdc-7cff-4604-b5a6-0d679e0472be@github.com>

On Sat, 16 Dec 2023 15:55:48 GMT, Brian Goetz <briangoetz at openjdk.org> wrote:

>> @mkarg , thank you for the review, I replied in JIRA to avoid mixing comments across different issues: https://bugs.openjdk.org/browse/JDK-8321271?focusedId=14634794&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14634794
>
> While frozen arrays are on our radar, this is a significant lift, so unlikely to be coming all that soon.

I propose to separate this PR from Vladimir's proposal, so we can merge *this* PR first, and if we later see that Vladimir's changes are accepted, we can merge them *ontop*. Agreed everybody?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1428872271

From acobbs at openjdk.org  Sat Dec 16 17:51:36 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 16 Dec 2023 17:51:36 GMT
Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available()
 test for end-of-stream [v4]
In-Reply-To: <HXXiM-MGVLXh3gv7Abs4dd3ipgQqsWdCzPjfK-fG8CI=.584a80cc-9f8f-45f8-817c-54e3eaf468fc@github.com>
References: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
 <TJ8loA9R1Kf_GxXw9lR-XLW-xqjrkPhdCnZFwFExG1A=.e3d52b42-d008-4841-b979-88d88f04b525@github.com>
 <HXXiM-MGVLXh3gv7Abs4dd3ipgQqsWdCzPjfK-fG8CI=.584a80cc-9f8f-45f8-817c-54e3eaf468fc@github.com>
Message-ID: <DnjQ9xoaQdr5XloN4Ayr6uBvuMdmUL_iUhYPrilPMbk=.dad11855-f2b1-434f-8c56-fdde644ee9ad@github.com>

On Sat, 16 Dec 2023 05:53:34 GMT, Bernd <duke at openjdk.org> wrote:

> I wonder: if the stream does no longer depend on this `available()` condition to be true, does that mean it?s no longer (indirectly) verified?

I'm not sure I understand ... what do you mean by "verified"?

If what you're saying is "Previously we were implicitly verifying that the data reported by `available()` was actually there, and now we're no longer verifying that" then that's not correct. The code that was previously conditional on an `available()` check was just catching and discarding `IOException`, so even if `available()` was lying before, that would not have ever been detected.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17113#issuecomment-1858883789

From duke at openjdk.org  Sat Dec 16 17:54:43 2023
From: duke at openjdk.org (Markus KARG)
Date: Sat, 16 Dec 2023 17:54:43 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v15]
In-Reply-To: <8SYx9TqaT4rL2o4BZ_Fnu_ZxD3vVMdYJS51dtGMK22I=.4b226895-ec4a-49bc-ab1a-c46a2e290405@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <8SYx9TqaT4rL2o4BZ_Fnu_ZxD3vVMdYJS51dtGMK22I=.4b226895-ec4a-49bc-ab1a-c46a2e290405@github.com>
Message-ID: <mOFTUALYYY7dLlbzIL7BqI0RsmohLvlNCtEcZ7k_pzk=.b043a248-54bb-4368-9480-e6e3fe510b14@github.com>

On Thu, 14 Dec 2023 08:47:03 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`.
>> 
>> See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8320971: Revert irrelevant changes

I know it is a bit disappointing to undo the nice changes you did just days ago, but to get this PR merged quickly it is best to follow Alan's proposal.

src/java.base/share/classes/java/io/BufferedInputStream.java line 677:

> 675:      * @see java.io.BufferedInputStream#implTransferTo(OutputStream)
> 676:      */
> 677:     private static boolean isTrusted(OutputStream os) {

Let's follow Alan's proposal and simply inline this. The solution is in sync with BAIS then, and we can merge it quickly.

test/jdk/java/io/BufferedInputStream/TransferToTrusted.java line 85:

> 83:     }
> 84: 
> 85:     private static void byteArrayOutputStream(BufferedInputStream bis, byte[] buf) throws IOException {

As we agreed that this PR shall only cover BIS, we can remove the additional classes' tests again.

-------------

Changes requested by mkarg at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/16879#pullrequestreview-1785245773
PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1428872958
PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1428873231

From duke at openjdk.org  Sat Dec 16 17:54:45 2023
From: duke at openjdk.org (Markus KARG)
Date: Sat, 16 Dec 2023 17:54:45 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v15]
In-Reply-To: <ygBFvyFtGX_ucxCbdy_YWjgVC2b3YHMZ0YUKlfwBVgs=.7e81ce36-cb48-43b4-a142-70ef2ff6084e@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <8SYx9TqaT4rL2o4BZ_Fnu_ZxD3vVMdYJS51dtGMK22I=.4b226895-ec4a-49bc-ab1a-c46a2e290405@github.com>
 <dZAa97JgeIWwmAyIMIhBewWJA18a6OSvbjti8NrV0wY=.37ca08b4-6256-44c7-b552-470bb29ed274@github.com>
 <0L9QJXEAc014B6fWGCh3W5CK822Vw1O9Ze-B-W3m2SY=.2322e284-d896-4b2a-9fc9-c375cf5ac9ca@github.com>
 <euNCdTLCMfLfmISnyqzbRV-XX9pdrSoVjdptGI8dCoM=.705c2d5f-f408-480e-87e8-b4b60fc763cf@github.com>
 <TsiPmav5k6DExDU6OV_I06YvbSxO0KrjkRcfYaxzHdQ=.e422ae7c-f5b7-4c56-8fc2-bca44bec1393@github.com>
 <P0ndNW257XHjZnSbh6tgKvTk2xGJmMjVJVdEU7n1vrg=.8ac0aa39-aab2-4120-aa10-649b8128226c@github.com>
 <ygBFvyFtGX_ucxCbdy_YWjgVC2b3YHMZ0YUKlfwBVgs=.7e81ce36-cb48-43b4-a142-70ef2ff6084e@github.com>
Message-ID: <fHfgEU1BKWVzcmamcYU5yplE8RfCxhKsais1rS8vGjU=.4765166c-d1de-4564-8643-265574f96c98@github.com>

On Sat, 16 Dec 2023 17:13:17 GMT, Chen Liang <liach at openjdk.org> wrote:

>>> If we drop the method for now I have to write it later again, I guess
>> 
>> Maybe, but it's archived so it's easy enough.
>
> If this is only used after Module system is ready, we can use something like:
> https://github.com/openjdk/jdk/blob/34351b7a7950a3b563748f40f2619374f62f9b16/src/java.base/share/classes/java/nio/file/Files.java#L3352
> 
> 
> if (out.getClass().getModule() == Object.class.getModule())

I propose we simply go with the original solution, so we stay sync with BAIS.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1428872747

From duke at openjdk.org  Sat Dec 16 17:54:47 2023
From: duke at openjdk.org (Markus KARG)
Date: Sat, 16 Dec 2023 17:54:47 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v13]
In-Reply-To: <iR1U-YCF5xWqPgMo2y_mtGy_bgR142DY992awqsdzVM=.23721c0f-aac6-4590-b1ae-3a3e404e3f44@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <9dHae2TsRpC75QWWLwT8zj5wgU3sNE9BruMOsO9-lGg=.2425bed0-13f8-496d-903c-702953337207@github.com>
 <iR1U-YCF5xWqPgMo2y_mtGy_bgR142DY992awqsdzVM=.23721c0f-aac6-4590-b1ae-3a3e404e3f44@github.com>
Message-ID: <hJ7IOVhrH2nt1yCbhwekNeX1lUIkvUx9CmCr0a5xECU=.8a309772-14d2-4506-a030-e74a71e4c0cd@github.com>

On Wed, 13 Dec 2023 08:41:37 GMT, Vladimir Sitnikov <vsitnikov at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8320971: Fix JavaDoc
>
> test/jdk/java/io/BufferedInputStream/TransferToTrusted.java line 52:
> 
>> 50:             byte[] tmp = new byte[len];
>> 51:             RND.nextBytes(tmp);
>> 52:             System.arraycopy(tmp, 0, b, off, len);
> 
> It is sad there's no `Random#nextBytes(byte[] buf, int offs, int len)`

@vlsi Will you?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1428873024

From liach at openjdk.org  Sat Dec 16 18:05:40 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 16 Dec 2023 18:05:40 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v2]
In-Reply-To: <aM8Sgna07i1Xo1Q4_g8D6BMwxM12cVM-FTDBp7okIr4=.abadae69-d620-4097-9fb9-3f135a031562@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <ryPVgRWbldkLMNq2GOZZqYLydDKWgixV910y7KY01qw=.63e9f740-66db-4529-a211-e8db04e6bfe4@github.com>
 <aM8Sgna07i1Xo1Q4_g8D6BMwxM12cVM-FTDBp7okIr4=.abadae69-d620-4097-9fb9-3f135a031562@github.com>
Message-ID: <9LZAzg09HflnE69Iq0Bs0HKp-yUoJOrOXCvPzzuRiVI=.9f41f2f7-c954-411c-b287-f2b07e9f5b60@github.com>

On Sat, 16 Dec 2023 17:28:13 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added missing comment
>
> src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 187:
> 
>> 185:         // generating bridges in the target class)
>> 186:         useImplMethodHandle = (Modifier.isProtected(implInfo.getModifiers()) &&
>> 187:                                !VerifyAccess.isSamePackage(targetClass, implInfo.getDeclaringClass())) ||
> 
> If?the?`implClass` is?hidden, then?it?s not?possible to?generate?bytecode which?correctly?refers to?`implMethod`, so?the?only?way is?to?use the?method?handle in?that?case:
> Suggestion:
> 
>         useImplMethodHandle = (Modifier.isProtected(implInfo.getModifiers()) &&
>                                !VerifyAccess.isSamePackage(targetClass, implInfo.getDeclaringClass())) ||
>                                implClass.isHidden() ||

I think this belongs to another RFE and is out of scope of this one. In addition, we need extra tests to invoke the hidden class's lambda to assert its behavioral correctness. Currently, the previously failing test [`LambdaProxyCaller`](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/test-classes/LambdaProxyCallerIsHiddenApp.java) only creates the hidden class for CDS testing; it doesn't actually invoke the lambda to test its implementation correctness.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1428875697

From vsitnikov at openjdk.org  Sat Dec 16 19:05:40 2023
From: vsitnikov at openjdk.org (Vladimir Sitnikov)
Date: Sat, 16 Dec 2023 19:05:40 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred [v4]
In-Reply-To: <MgqxdnIJbR-Kan1rvnLN0M63R5zLUcThXNHvdJDGCP4=.77f9b25a-12fa-4edb-935b-eb19196da8da@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
 <MgqxdnIJbR-Kan1rvnLN0M63R5zLUcThXNHvdJDGCP4=.77f9b25a-12fa-4edb-935b-eb19196da8da@github.com>
Message-ID: <Zho8TuPcR4VIbdhHukt08uDLADDVZx2CmsOvOcnkllo=.28057586-87a5-4c35-8ddc-b280fa7c4b03@github.com>

On Sat, 16 Dec 2023 14:07:52 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Fixes JDK-8322141
>> 
>> As suggested by @vlsi and documented by @bplb this PR does not return, but only sets the maximum result value.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test was using Integer but must use Long

test/jdk/java/io/SequenceInputStream/TransferTo.java line 154:

> 152:      * but fails with any other operation.
> 153:      */
> 154:     private static InputStream repeat(int b, long count) {

`b` parameter seems to be unused. Wdyt of removing it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17119#discussion_r1428889592

From vsitnikov at openjdk.org  Sat Dec 16 19:13:41 2023
From: vsitnikov at openjdk.org (Vladimir Sitnikov)
Date: Sat, 16 Dec 2023 19:13:41 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred [v4]
In-Reply-To: <MgqxdnIJbR-Kan1rvnLN0M63R5zLUcThXNHvdJDGCP4=.77f9b25a-12fa-4edb-935b-eb19196da8da@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
 <MgqxdnIJbR-Kan1rvnLN0M63R5zLUcThXNHvdJDGCP4=.77f9b25a-12fa-4edb-935b-eb19196da8da@github.com>
Message-ID: <_6MPgEioxhFJAk0oPdS4oNBg42JSl0B6YfafYvEUAB8=.d11b1ac8-6d45-4403-a213-87d201e24d09@github.com>

On Sat, 16 Dec 2023 14:07:52 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Fixes JDK-8322141
>> 
>> As suggested by @vlsi and documented by @bplb this PR does not return, but only sets the maximum result value.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test was using Integer but must use Long

test/jdk/java/io/SequenceInputStream/TransferTo.java line 139:

> 137:         InputStream is1 = repeat(0, Long.MAX_VALUE);
> 138:         InputStream is2 = repeat(0, 1);
> 139:         assertNotEquals(is1.available(), 0);

Wdyt of asserting the expected value with assertEquals or removing the assertions before .transferTo altogether?
Suggestion:

        assertEquals(is1.available(), Integer.MAX_VALUE, "The stream should have Long.MAX_VALUE bytes .available() before .transferTo (.available returns int)");

test/jdk/java/io/SequenceInputStream/TransferTo.java line 143:

> 141:         SequenceInputStream sis = new SequenceInputStream(is1, is2);
> 142:         OutputStream nos = OutputStream.nullOutputStream();
> 143:         sis.transferTo(nos);

Suggestion:

        assertEquals(sis.transferTo(nos), Long.MAX_VALUE, ".transferTo should return Long.MAX_VALUE when transferring more than that amount of bytes");

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17119#discussion_r1428890685
PR Review Comment: https://git.openjdk.org/jdk/pull/17119#discussion_r1428891013

From duke at openjdk.org  Sat Dec 16 20:03:38 2023
From: duke at openjdk.org (ExE Boss)
Date: Sat, 16 Dec 2023 20:03:38 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes
In-Reply-To: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
Message-ID: <vZ0JZO-LntuIELlOiR_rg9VJwdbzYYatl0yee_101fU=.99d7c1f1-8ace-4325-b3e6-0e59721445ba@github.com>

On Fri, 15 Dec 2023 12:54:27 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes.
> 
> This patch converts it to use Classfile API.
> 
> It is continuation of https://github.com/openjdk/jdk/pull/10991
> 
> Any comments and suggestions are welcome.
> 
> Please review.
> 
> Thank you,
> Adam

src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 748:

> 746:                 if (parameterTypes[i].isPrimitive()) {
> 747:                     PrimitiveTypeInfo prim = PrimitiveTypeInfo.get(parameterTypes[i]);
> 748:                     cob.getstatic(prim.wrapperClass, "TYPE", CD_Class);

These?can?use a?condy?via [`ConstantBootstraps?::primitiveClass?(MethodHandles.Lookup, String,?Class<?>)`], although?that?s?probably gonna?need [JDK?8283739].

[`ConstantBootstraps?::primitiveClass?(MethodHandles.Lookup, String,?Class<?>)`]: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/invoke/ConstantBootstraps.html#primitiveClass(java.lang.invoke.MethodHandles.Lookup,java.lang.String,java.lang.Class)
[JDK?8283739]: https://bugs.openjdk.org/browse/JDK-8283739 "[JDK?8283739] Support compiling `<primitive>.class` to a CONSTANT_Dynamic"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17121#discussion_r1428898926

From liach at openjdk.org  Sun Dec 17 04:53:43 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 17 Dec 2023 04:53:43 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes
In-Reply-To: <vZ0JZO-LntuIELlOiR_rg9VJwdbzYYatl0yee_101fU=.99d7c1f1-8ace-4325-b3e6-0e59721445ba@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
 <vZ0JZO-LntuIELlOiR_rg9VJwdbzYYatl0yee_101fU=.99d7c1f1-8ace-4325-b3e6-0e59721445ba@github.com>
Message-ID: <ShYZeOSZIxe8saL--w8DGWWK6_5ExzIz-Oi7Glrk-NQ=.8c6d7cff-2a68-4aa1-81bf-a471bb411c50@github.com>

On Sat, 16 Dec 2023 19:49:12 GMT, ExE Boss <duke at openjdk.org> wrote:

>> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes.
>> 
>> This patch converts it to use Classfile API.
>> 
>> It is continuation of https://github.com/openjdk/jdk/pull/10991
>> 
>> Any comments and suggestions are welcome.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 748:
> 
>> 746:                 if (parameterTypes[i].isPrimitive()) {
>> 747:                     PrimitiveTypeInfo prim = PrimitiveTypeInfo.get(parameterTypes[i]);
>> 748:                     cob.getstatic(prim.wrapperClass, "TYPE", CD_Class);
> 
> These?can?use a?condy?via [`ConstantBootstraps?::primitiveClass?(MethodHandles.Lookup, String,?Class<?>)`], although?that?s?probably gonna?need [JDK?8283739].
> 
> [`ConstantBootstraps?::primitiveClass?(MethodHandles.Lookup, String,?Class<?>)`]: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/invoke/ConstantBootstraps.html#primitiveClass(java.lang.invoke.MethodHandles.Lookup,java.lang.String,java.lang.Class)
> [JDK?8283739]: https://bugs.openjdk.org/browse/JDK-8283739 "[JDK?8283739] Support compiling `<primitive>.class` to a CONSTANT_Dynamic"

I recommend optimizing in another patch, as this patch aims to preserve code parity.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17121#discussion_r1429016197

From alanb at openjdk.org  Sun Dec 17 07:38:05 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 17 Dec 2023 07:38:05 GMT
Subject: RFR: 8320707: Virtual thread test updates
Message-ID: <rNS3FjC-lrCkDaS7D4upOdiVZcqXrtHhzc41R2pOXgM=.8240aa70-7226-4c88-8234-fe7e54a088bf@github.com>

A lot of test changes have accumulated in the loom repo, this includes both new tests and updates to existing tests. Some of these updates can be brought to the main line. This update brings over:

- The existing tests for pinning use synchronized blocks. In preparation for changes to allow carrier thread be released when a virtual thread parks holding a monitor or blocks on monitorenter, these tests are changed to pin by having a native frame on the stack. This part includes test infrastructure to make it easy to add more tests that do operations while pinned. The tests still test what they were originally created to test of course.

- The test for the JFR jdk.VirtualThreadPinned event is refactored to allow for additional cases where the event may be reported.

- ThreadAPI is expanded to cover test for uncaught exception handling.

- GetStackTraceWhenRunnable is refactored to not use a Selector, otherwise this test will be invalidated when blocking selection operations release the carrier.

- StressStackOverflow is dialed down to run for 1m instead of 2mins.

- The use of CountDownLatch in a number of tests that poll thread state has been dropped to keep the tests as simple as possible.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/17136/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17136&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8320707
  Stats: 572 lines in 12 files changed: 381 ins; 48 del; 143 mod
  Patch: https://git.openjdk.org/jdk/pull/17136.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17136/head:pull/17136

PR: https://git.openjdk.org/jdk/pull/17136

From alanb at openjdk.org  Sun Dec 17 07:51:44 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 17 Dec 2023 07:51:44 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v15]
In-Reply-To: <mOFTUALYYY7dLlbzIL7BqI0RsmohLvlNCtEcZ7k_pzk=.b043a248-54bb-4368-9480-e6e3fe510b14@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <8SYx9TqaT4rL2o4BZ_Fnu_ZxD3vVMdYJS51dtGMK22I=.4b226895-ec4a-49bc-ab1a-c46a2e290405@github.com>
 <mOFTUALYYY7dLlbzIL7BqI0RsmohLvlNCtEcZ7k_pzk=.b043a248-54bb-4368-9480-e6e3fe510b14@github.com>
Message-ID: <cY1eDOFP0kH54rTWFToD9rzmndVsSBW20IjIAtCRVAQ=.21764086-deed-4587-8ed5-a8ab30140e9b@github.com>

On Sat, 16 Dec 2023 17:50:07 GMT, Markus KARG <duke at openjdk.org> wrote:

> Let's follow Alan's proposal and simply inline this. 

I didn't suggest inlining this. I just asked not to add a new package com.sun.io with a single method class. Also as the concerns with BAIS and BIS are not the same (they do overlap but they are not the same), I think it's best to keep the changes as local as possible. It can be made more widely useful in the future but great care must be taken.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1429051646

From alanb at openjdk.org  Sun Dec 17 08:58:38 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 17 Dec 2023 08:58:38 GMT
Subject: RFR: 8259637: java.io.File.getCanonicalPath() returns different
 values for same path
In-Reply-To: <uClvCZ0hgjGS7z2k81iXiC5PJ1VbvzJwvvnlPd-nkxE=.da23f584-9126-41c7-b8ab-e86e1680127f@github.com>
References: <uClvCZ0hgjGS7z2k81iXiC5PJ1VbvzJwvvnlPd-nkxE=.da23f584-9126-41c7-b8ab-e86e1680127f@github.com>
Message-ID: <QLM859C7J6HZkGSFIZBYbIJvfN5Xr7CIGknst3Y5T3Q=.ed6b9d63-8796-4fb6-a33a-cb79862356e3@github.com>

On Wed, 13 Dec 2023 19:37:15 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify the `collapse()` function to remove each instance of ".." when the path is absolute and there is no preceding name.

The change looks okay, the canonical path of a file that does not exist has always been hard to reason about.

test/jdk/java/io/File/GetCanonicalPath.java line 98:

> 96:                               "/b/c"));
> 97: 
> 98:         return list.stream();

You could use Stream.of here, e.g.


        return Stream.of(
            Arguments.of("/../../../../../a/b/c", "/a/b/c"),
            Arguments.of("/../../../../../a/../b/c", "/b/c"),
            Arguments.of("/../../../../../a/../../b/c", "/b/c"),
            Arguments.of("/../../../../../a/../../../b/c", "/b/c"),
            Arguments.of("/../../../../../a/../../../../b/c", "/b/c")
        );

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17089#pullrequestreview-1785402494
PR Review Comment: https://git.openjdk.org/jdk/pull/17089#discussion_r1429079490

From alanb at openjdk.org  Sun Dec 17 09:09:43 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 17 Dec 2023 09:09:43 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v15]
In-Reply-To: <8SYx9TqaT4rL2o4BZ_Fnu_ZxD3vVMdYJS51dtGMK22I=.4b226895-ec4a-49bc-ab1a-c46a2e290405@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <8SYx9TqaT4rL2o4BZ_Fnu_ZxD3vVMdYJS51dtGMK22I=.4b226895-ec4a-49bc-ab1a-c46a2e290405@github.com>
Message-ID: <YID5BtIoNcMdaMFfv1duC75kuOp9VI1AHDQCJiRCihU=.e6578ed3-a4f6-4312-b6da-5e9e1da254c0@github.com>

On Thu, 14 Dec 2023 08:47:03 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`.
>> 
>> See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8320971: Revert irrelevant changes

For the method description, I think you can expand it to:

- does not retain a reference to the byte[]
- does not leak a reference to the byte[] to non-trusted classes
- does not modify the contents of the byte[]
- its 3-arg write does not read the contents outside of the offset/length bounds

In passing, this class uses "out" for the target OutputStream in the other methods, you can keep that consistent. Also I assume the `@see` are left over from a previous iteration.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16879#issuecomment-1859080164

From alanb at openjdk.org  Sun Dec 17 09:27:43 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 17 Dec 2023 09:27:43 GMT
Subject: RFR: 8321802: (zipfs) Add validation of incorrect LOC signature in
 ZipFileSystem [v2]
In-Reply-To: <4tMOaFRnlcSLhVgiBj9eDfRI0u9mOVQpx6kCAvpVgS0=.3dbe700c-2f7e-40ed-a644-4175d41bb69c@github.com>
References: <9OyZCEKEcOKOhnzSo8Ls4EfxijWzTVhp1H_SBaisYY8=.b82a211b-b98a-451d-8ce2-47b53314c492@github.com>
 <4tMOaFRnlcSLhVgiBj9eDfRI0u9mOVQpx6kCAvpVgS0=.3dbe700c-2f7e-40ed-a644-4175d41bb69c@github.com>
Message-ID: <8cxgLJ5LPAoaRCME7HWOPrR1Gj4uYPNQ3hzCl_YpRjw=.8499a2eb-e01d-45e2-be7a-01548c8a0037@github.com>

On Tue, 12 Dec 2023 11:59:36 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Please review this PR which adds validation of incorrect LOC signatures in `ZipFileSystem`.
>> 
>> `ZipFile` already rejects the case where the  offset pointed to from the CEN header does not start with the expected LOC signature. It makes sense to add this check to `ZipFileSystem` as well.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use uppercase LOC in ZipException messages

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17059#pullrequestreview-1785407026

From alanb at openjdk.org  Sun Dec 17 09:32:36 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 17 Dec 2023 09:32:36 GMT
Subject: RFR: 8318971 : Better Error Handling for Jar Tool Processing of
 @File
In-Reply-To: <xht1jEn-KP8Fhz4Xa4MBxlhsvlxk3mdAkpdv9dF77oQ=.3fdc9a36-e7da-4230-9b26-40dacb8e92b6@github.com>
References: <xht1jEn-KP8Fhz4Xa4MBxlhsvlxk3mdAkpdv9dF77oQ=.3fdc9a36-e7da-4230-9b26-40dacb8e92b6@github.com>
Message-ID: <URBh2Fx0GcLS7pRbkcThSOzfHPc6LKWufgbX1VOuBLs=.be0b4b46-daf1-4001-9099-85b9f866eee7@github.com>

On Wed, 13 Dec 2023 18:16:56 GMT, Weibing Xiao <duke at openjdk.org> wrote:

> Better Error Handling for Jar Tool Processing of "@File" <br>
> 
> This is a new PR for this PR since the original developer left the team. See all of the review history at https://github.com/openjdk/jdk/pull/16423.
> 
> Thank you.

The implementation change looks okay, I think we mostly agreed that in the previous PR.

I don't have cycles to look at the test right now so I hope you can get another reviewer for the test update.

The other part to this is the man page. I chatted briefly with Ryan about this a few weeks ago as something that needs to updated (not this PR of course).

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17088#pullrequestreview-1785407802

From alanb at openjdk.org  Sun Dec 17 09:45:39 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 17 Dec 2023 09:45:39 GMT
Subject: RFR: 6356745: Introduce constructor for PriorityQueue with
 existing collection and custom comparator [v2]
In-Reply-To: <coAODM-9CtXAmbfpMxBU6wEYu6DXFOJB6OHV_cVo0L4=.978b09e9-1231-4ff3-ac97-e6b40816bc36@github.com>
References: <zAcGyJ33ZP0osNg-HMJp4UCtOXYzdqi969ugDhJ7954=.c5f8e2de-cfe8-4224-a98e-70f49da9a7a3@github.com>
 <coAODM-9CtXAmbfpMxBU6wEYu6DXFOJB6OHV_cVo0L4=.978b09e9-1231-4ff3-ac97-e6b40816bc36@github.com>
Message-ID: <tWAU74ffW_SCH-sc1TOKUwR7M30tej2O0UydQSKNvdI=.7cac8560-fe7f-44e1-b513-1c08da06cd5a@github.com>

On Thu, 14 Dec 2023 20:36:50 GMT, Valeh Hajiyev <duke at openjdk.org> wrote:

>> This commit addresses the current limitation in the `PriorityQueue` implementation, which lacks a constructor to efficiently create a priority queue with a custom comparator and an existing collection. In order to create such a queue, we currently need to initialize a new queue with custom comparator, and after that populate the queue using `addAll()` method, which in the background calls `add()` method (which takes `O(logn)` time) for each element of the collection (`n` times).  This is resulting in an overall time complexity of `O(nlogn)`. 
>> 
>> 
>> PriorityQueue<String> pq = new PriorityQueue<>(customComparator);
>> pq.addAll(existingCollection);
>> 
>> 
>> The pull request introduces a new constructor to streamline this process and reduce the time complexity to `O(n)`.  If you create the queue above using the new constructor, the contents of the collection will be copied (which takes `O(n)` time) and then later  `heapify()` operation (Floyd's algorithm) will be called once (another `O(n)` time). Overall the operation will be reduced from `O(nlogn)` to `O(2n)` -> `O(n)` time.
>> 
>> 
>> PriorityQueue<String> pq = new PriorityQueue<>(existingCollection, customComparator);
>
> Valeh Hajiyev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated the javadoc

src/java.base/share/classes/java/util/PriorityQueue.java line 215:

> 213:      * Creates a {@code PriorityQueue} containing the elements in the
> 214:      * specified collection. The {@code PriorityQueue} will order its
> 215:      * elements according to the specified comparator.

The wording "will order its elements" is consistent with the other constructors but I wonder if "its" might be mis-read to mean the collection rather than the queue. If you change it to "will order the priority queue's elements" will avoid that.

You'll need to add `@since 23`. Also new tests will need to be added for this constructor.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17045#discussion_r1429103333

From alanb at openjdk.org  Sun Dec 17 09:49:44 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 17 Dec 2023 09:49:44 GMT
Subject: RFR: JDK-8319626: Override toString() for ZipFile [v8]
In-Reply-To: <EEHjubpyde8VF6w4shuUjROZWwIabcGCI9DYMva_gy8=.afba4e81-0f88-4530-8e32-23ca7f949157@github.com>
References: <UEVJDXC8Cs_RSBUEsWgmq8SPvI-T4LSydbPKr8u29iA=.fdce7d47-87a8-42ba-9cd4-119bf9023ad9@github.com>
 <EEHjubpyde8VF6w4shuUjROZWwIabcGCI9DYMva_gy8=.afba4e81-0f88-4530-8e32-23ca7f949157@github.com>
Message-ID: <smeRBQHV52MOdPEJYGX0BgC9jPplDR_vF-0XcOQ4vLA=.5370c4a6-c5fe-4bf5-8964-cec7cc35573b@github.com>

On Mon, 11 Dec 2023 05:47:33 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319982) which overrides and provides an implementation of `toString()` in _java.util.zip.ZipFile_ (and by extension, _java.util.jar.JarFile_).
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8319626
>  - break line
>  - reflect review: change impl to store field name
>  - drop additional specification
>  - drop 2nd paragraph
>  - return base name, not full path
>  - shorten wording
>  - reflect review: use separator, clarify spec
>  - reflect review: change string value and drop spec
>  - init

The description looks fine, there is similar "for debugging" in several other APIs.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16643#pullrequestreview-1785410175

From gli at openjdk.org  Sun Dec 17 13:25:00 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Sun, 17 Dec 2023 13:25:00 GMT
Subject: RFR: 8321688: Build on linux with GCC 7.5.0 fails after 8319577
 [v2]
In-Reply-To: <vIByQ06ftSU9o1Rb4YOWXPrry1LkYSj-vJqLXaMXQ5g=.d5a0ea33-f57a-4549-addf-b7a9c5eaa67d@github.com>
References: <vIByQ06ftSU9o1Rb4YOWXPrry1LkYSj-vJqLXaMXQ5g=.d5a0ea33-f57a-4549-addf-b7a9c5eaa67d@github.com>
Message-ID: <IgVsEyruca5jYomg5OTMjFXt9kBhDS3KTp2prBY9sbQ=.8e140145-a9ed-494b-a10d-f5ffeb2bc142@github.com>

> Hi all,
> 
> This patch fixes the building failure introduced by [JDK-8319577](https://bugs.openjdk.org/browse/JDK-8319577) in old GCC version (linux & GCC 7.5.0 locally).
> 
> Thanks for the review.
> 
>  Best Regards,
> -- Guoxiong

Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Bump the needed version of GCC.
 - Revert previous change.
 - Merge branch 'master' into JDK-8321688
 - JDK-8321688

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17047/files
  - new: https://git.openjdk.org/jdk/pull/17047/files/46858210..f04bcd55

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17047&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17047&range=00-01

  Stats: 876 lines in 56 files changed: 520 ins; 166 del; 190 mod
  Patch: https://git.openjdk.org/jdk/pull/17047.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17047/head:pull/17047

PR: https://git.openjdk.org/jdk/pull/17047

From gli at openjdk.org  Sun Dec 17 13:28:36 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Sun, 17 Dec 2023 13:28:36 GMT
Subject: RFR: 8321688: Build on linux with GCC 7.5.0 fails after 8319577
In-Reply-To: <93jYEROn5yAyMamzLQOfGF3rRIq_kB2hdKcLeqMGa7s=.8f2f3ea5-3ecf-4f5f-afcf-02eecdd14cd9@github.com>
References: <vIByQ06ftSU9o1Rb4YOWXPrry1LkYSj-vJqLXaMXQ5g=.d5a0ea33-f57a-4549-addf-b7a9c5eaa67d@github.com>
 <93jYEROn5yAyMamzLQOfGF3rRIq_kB2hdKcLeqMGa7s=.8f2f3ea5-3ecf-4f5f-afcf-02eecdd14cd9@github.com>
Message-ID: <IizNtxdhblRM3JftzTns1zYFtKjHE4DO13brb-k47Z8=.e189a62c-5eba-406c-b031-b9ebd4986172@github.com>

On Fri, 15 Dec 2023 08:48:59 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch fixes the building failure introduced by [JDK-8319577](https://bugs.openjdk.org/browse/JDK-8319577) in old GCC version (linux & GCC 7.5.0 locally).
>> 
>> Thanks for the review.
>> 
>>  Best Regards,
>> -- Guoxiong
>
> The files being proposed for change are cloned copies of a 3rd-party library.
> We may want to take updates from that library in the future. Having local
> modifications makes that more difficult.
> 
> Also, this library uses C++17.  GCC support for C++17 was experimental until
> GCC 9.  As such, it shouldn't be entirely surprising if an earlier version of
> GCC might run into problems with it.
> 
> We've been discussing switching to using C++17 JDK-wide for some time, and I
> think that may happen soon.  At that point the minimum supported version of
> GCC will be changed to at least GCC 9.
> 
> So I think the answer here is that building this lbrary with GCC 7.5 is not
> supported and a newer version should be used. So the change should be here:
> https://github.com/openjdk/jdk/blob/b31454e36234091c3827c3b4d07f62345cb0cee4/src/java.base/linux/native/libsimdsort/simdsort-support.hpp#L34-L37
> to require a later GCC version. That way, if building with an older version of
> GCC then the code in the library won't be built and the library won't be used
> by the JDK (because the relevant symbols won't be found).
> 
> But GCC 7.5 will probably not be supported for building the JDK for much longer.

@kimbarrett Thanks for the guide. I updated the code just now. All the `release`, `fastdebug` and `slowdebug` builds succeeded locally with GCC7.5.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17047#issuecomment-1859172217

From duke at openjdk.org  Sun Dec 17 13:51:45 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sun, 17 Dec 2023 13:51:45 GMT
Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available()
 test for end-of-stream [v4]
In-Reply-To: <TJ8loA9R1Kf_GxXw9lR-XLW-xqjrkPhdCnZFwFExG1A=.e3d52b42-d008-4841-b979-88d88f04b525@github.com>
References: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
 <TJ8loA9R1Kf_GxXw9lR-XLW-xqjrkPhdCnZFwFExG1A=.e3d52b42-d008-4841-b979-88d88f04b525@github.com>
Message-ID: <16wj4o26YNMV2UEJT_kL-r92WQB0CRf8OZpN35SZbb0=.9313a35b-69fb-4349-9620-ed2a8f06e9a5@github.com>

On Fri, 15 Dec 2023 21:13:07 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> `GZIPInputStream`, when looking for a concatenated stream, relies on what the underlying `InputStream` says is how many bytes are `available()`. But this is inappropriate because `InputStream.available()` is just an estimate and is allowed (for example) to always return zero.
>> 
>> The fix is to ignore what's `available()` and just proceed and see what happens. If fewer bytes are available than required, the attempt to extend to another stream is canceled just as it was before, e.g., when the next stream header couldn't be read.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address third round of review comments.

The current behavior of allowing/ignoring trailing malformed data seems to have a complicated history:

- GZipInputStream was updated to throw ZipExeption instead of IOException on malformed GZIP data in [4263582](https://bugs.openjdk.org/browse/JDK-4263582)
- The ability to read concatenated GZ files was added in [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425) This change interestingly also introduced the current behavior of ignoring any trailing malformed data in the stream. 
- [7021870](https://bugs.openjdk.org/browse/JDK-7021870) fixed a bug where GZipInputStream closed the underlying input stream. The change also introduced the test GZIPInZip which verified that reads from a wrapped ZipInputStream does not close the stream
- Some months later GZIPInZip was updated in fix a test failure, but the change also modified the test to verifiy that malformed trailing data was ignored. The JBS issue is not available to me: [JDK-8023431](https://bugs.openjdk.org/browse/JDK-8023431)
- Soon after this, GZIPInZip was again updated to fix test failure, this time removing the use of piped streams and threads. The JBS issue is not available to me: [JDK-8026756](https://bugs.openjdk.org/browse/JDK-8026756)

The current behavior of ignoring trailing malformed data does not seem to be specified in the API. On the contrary, the read methods are specified to throw ZipException for corrupt input data:


     * @throws    ZipException if the compressed input data is corrupt.
     * @throws    IOException if an I/O error has occurred.
     *
     */
    public int read(byte[] buf, int off, int len) throws IOException {


Not sure whether it is worthwhile to change this long-standing behavior of GZIpInputStream.  But it could perhaps be noted somehow in the API documentation? (To be clear, that would be for a different PR/issue/CSR)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17113#issuecomment-1859177655

From duke at openjdk.org  Sun Dec 17 13:53:42 2023
From: duke at openjdk.org (Markus KARG)
Date: Sun, 17 Dec 2023 13:53:42 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v15]
In-Reply-To: <cY1eDOFP0kH54rTWFToD9rzmndVsSBW20IjIAtCRVAQ=.21764086-deed-4587-8ed5-a8ab30140e9b@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <8SYx9TqaT4rL2o4BZ_Fnu_ZxD3vVMdYJS51dtGMK22I=.4b226895-ec4a-49bc-ab1a-c46a2e290405@github.com>
 <mOFTUALYYY7dLlbzIL7BqI0RsmohLvlNCtEcZ7k_pzk=.b043a248-54bb-4368-9480-e6e3fe510b14@github.com>
 <cY1eDOFP0kH54rTWFToD9rzmndVsSBW20IjIAtCRVAQ=.21764086-deed-4587-8ed5-a8ab30140e9b@github.com>
Message-ID: <lQeYMyDpIQREf4VhxyY7-pmxvQcSgSHVcuBDwRCrX5M=.3c7b02c5-5eb4-4ce2-b155-c3bc99d8fbfb@github.com>

On Sun, 17 Dec 2023 07:49:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Let's follow Alan's proposal and simply inline this.
> 
> I didn't suggest inlining this. I just asked not to add a new package com.sun.io with a single method class. Also as the concerns with BAIS and BIS are not the same (they do overlap but they are not the same), I think it's best to keep the changes as local as possible. It can be made more widely useful in the future but great care must be taken.

Well, effectively inlining is the *ultimate* locality. ;-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1429166857

From duke at openjdk.org  Sun Dec 17 13:59:42 2023
From: duke at openjdk.org (Markus KARG)
Date: Sun, 17 Dec 2023 13:59:42 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred [v4]
In-Reply-To: <Zho8TuPcR4VIbdhHukt08uDLADDVZx2CmsOvOcnkllo=.28057586-87a5-4c35-8ddc-b280fa7c4b03@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
 <MgqxdnIJbR-Kan1rvnLN0M63R5zLUcThXNHvdJDGCP4=.77f9b25a-12fa-4edb-935b-eb19196da8da@github.com>
 <Zho8TuPcR4VIbdhHukt08uDLADDVZx2CmsOvOcnkllo=.28057586-87a5-4c35-8ddc-b280fa7c4b03@github.com>
Message-ID: <1c9Puqk2Y21hKGqgHXMqWaO1J_bqVfBa2KWSWf3qLTI=.c461100f-9ad4-4a44-bbb9-0123c71271d1@github.com>

On Sat, 16 Dec 2023 19:03:26 GMT, Vladimir Sitnikov <vsitnikov at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test was using Integer but must use Long
>
> test/jdk/java/io/SequenceInputStream/TransferTo.java line 154:
> 
>> 152:      * but fails with any other operation.
>> 153:      */
>> 154:     private static InputStream repeat(int b, long count) {
> 
> `b` parameter seems to be unused. Wdyt of removing it?

Kept it for future use: If in future we like to add `write(b)` in `transferTo` then we do not have to rework the call sites.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17119#discussion_r1429168196

From duke at openjdk.org  Sun Dec 17 14:05:41 2023
From: duke at openjdk.org (Markus KARG)
Date: Sun, 17 Dec 2023 14:05:41 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred [v4]
In-Reply-To: <_6MPgEioxhFJAk0oPdS4oNBg42JSl0B6YfafYvEUAB8=.d11b1ac8-6d45-4403-a213-87d201e24d09@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
 <MgqxdnIJbR-Kan1rvnLN0M63R5zLUcThXNHvdJDGCP4=.77f9b25a-12fa-4edb-935b-eb19196da8da@github.com>
 <_6MPgEioxhFJAk0oPdS4oNBg42JSl0B6YfafYvEUAB8=.d11b1ac8-6d45-4403-a213-87d201e24d09@github.com>
Message-ID: <B1CqpuAqs10_4NfzP25omz7gBOjIjvmrUXku39kCgWI=.4ec7a548-e54a-4a02-a90d-0bcb87300d92@github.com>

On Sat, 16 Dec 2023 19:09:05 GMT, Vladimir Sitnikov <vsitnikov at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test was using Integer but must use Long
>
> test/jdk/java/io/SequenceInputStream/TransferTo.java line 139:
> 
>> 137:         InputStream is1 = repeat(0, Long.MAX_VALUE);
>> 138:         InputStream is2 = repeat(0, 1);
>> 139:         assertNotEquals(is1.available(), 0);
> 
> Wdyt of asserting the expected value with assertEquals or removing the assertions before .transferTo altogether?
> Suggestion:
> 
>         assertEquals(is1.available(), Integer.MAX_VALUE, "The stream should have Long.MAX_VALUE bytes .available() before .transferTo (.available returns int)");

The reader shall understand what the test is good for and what it works like. There is no benefit in checking the *actual* value (there is no need to explicitly fail if `available` returns something *else*, as long as it is *not zero*), so this would confuse the reader more than it helps. I kept the before-assertations solely to proof that the before-value of `available()` is *not the default value* of `InputStream`, hence to proof that the source code of this test is actually able to detect a *change*. We can remove this, it is not needed, but it makes it easier *to understand* what this test actually expects *to change*.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17119#discussion_r1429169709

From duke at openjdk.org  Sun Dec 17 14:09:41 2023
From: duke at openjdk.org (Markus KARG)
Date: Sun, 17 Dec 2023 14:09:41 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred [v4]
In-Reply-To: <_6MPgEioxhFJAk0oPdS4oNBg42JSl0B6YfafYvEUAB8=.d11b1ac8-6d45-4403-a213-87d201e24d09@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
 <MgqxdnIJbR-Kan1rvnLN0M63R5zLUcThXNHvdJDGCP4=.77f9b25a-12fa-4edb-935b-eb19196da8da@github.com>
 <_6MPgEioxhFJAk0oPdS4oNBg42JSl0B6YfafYvEUAB8=.d11b1ac8-6d45-4403-a213-87d201e24d09@github.com>
Message-ID: <d4buPNbqRBYVj-FaoysUYNjaKT8sRIq9oziCww0rqfQ=.3c845d47-265e-4c4d-b2be-06cf2ad4e970@github.com>

On Sat, 16 Dec 2023 19:10:49 GMT, Vladimir Sitnikov <vsitnikov at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test was using Integer but must use Long
>
> test/jdk/java/io/SequenceInputStream/TransferTo.java line 143:
> 
>> 141:         SequenceInputStream sis = new SequenceInputStream(is1, is2);
>> 142:         OutputStream nos = OutputStream.nullOutputStream();
>> 143:         sis.transferTo(nos);
> 
> Suggestion:
> 
>         assertEquals(sis.transferTo(nos), Long.MAX_VALUE, ".transferTo should return Long.MAX_VALUE when transferring more than that amount of bytes");

The intention is not to fully test the complete functionality of `transferTo` but solely to test what *this* PR is fixing. It was never broken that transferTo returned the correct value (that bug never existed), and there is already a test for transferTo contents across streams in place.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17119#discussion_r1429170643

From liach at openjdk.org  Sun Dec 17 15:23:38 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 17 Dec 2023 15:23:38 GMT
Subject: RFR: 6356745: Introduce constructor for PriorityQueue with
 existing collection and custom comparator [v2]
In-Reply-To: <coAODM-9CtXAmbfpMxBU6wEYu6DXFOJB6OHV_cVo0L4=.978b09e9-1231-4ff3-ac97-e6b40816bc36@github.com>
References: <zAcGyJ33ZP0osNg-HMJp4UCtOXYzdqi969ugDhJ7954=.c5f8e2de-cfe8-4224-a98e-70f49da9a7a3@github.com>
 <coAODM-9CtXAmbfpMxBU6wEYu6DXFOJB6OHV_cVo0L4=.978b09e9-1231-4ff3-ac97-e6b40816bc36@github.com>
Message-ID: <Hrv4ZAhQ0Rtc6jGWLOqKH_TjHPdJ7yrE8Jx1vSbbaBU=.12b0179d-6fed-4f28-b12c-a2b7564cf8cc@github.com>

On Thu, 14 Dec 2023 20:36:50 GMT, Valeh Hajiyev <duke at openjdk.org> wrote:

>> This commit addresses the current limitation in the `PriorityQueue` implementation, which lacks a constructor to efficiently create a priority queue with a custom comparator and an existing collection. In order to create such a queue, we currently need to initialize a new queue with custom comparator, and after that populate the queue using `addAll()` method, which in the background calls `add()` method (which takes `O(logn)` time) for each element of the collection (`n` times).  This is resulting in an overall time complexity of `O(nlogn)`. 
>> 
>> 
>> PriorityQueue<String> pq = new PriorityQueue<>(customComparator);
>> pq.addAll(existingCollection);
>> 
>> 
>> The pull request introduces a new constructor to streamline this process and reduce the time complexity to `O(n)`.  If you create the queue above using the new constructor, the contents of the collection will be copied (which takes `O(n)` time) and then later  `heapify()` operation (Floyd's algorithm) will be called once (another `O(n)` time). Overall the operation will be reduced from `O(nlogn)` to `O(2n)` -> `O(n)` time.
>> 
>> 
>> PriorityQueue<String> pq = new PriorityQueue<>(existingCollection, customComparator);
>
> Valeh Hajiyev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated the javadoc

You should update the GitHub PR title to `6356745: (coll) Add PriorityQueue(Collection, Comparator)` to match the JBS issue title.

In addition, you will need a [CSR](https://wiki.openjdk.org/display/csr) as the bot tells you. Its prompt is like:

Summary
A concise description of the proposed change. The description should be one to two sentences long and written to be reusable in documents aggregating changes for a release.

Problem
A brief description of the problem, optionally including the motivation for developing a solution.

Solution
An overview of the solution. Alternative solutions may be discussed; links to rationale documents or review threads welcome to provide additional background to reviewers.

Specification
The detailed changes. Acceptable normative formats include inline patches, attached webrevs, and attached specdiffs. The names of attached files are recommended to include a bug id. References to external webservers, such as http://cr.openjdk.java.net/, can be provided as informative supplements for the convenience of reviewers, but must be accompanied by a normative form of the specification directly associated with the CSR issue to satisfy archival purposes.


I can create one for you, and here's my proposed CSR content:

Summary
Add a new constructor to PriorityQueue that takes a Collection and a Comparator.

Problem
Creating a PriorityQueue with an existing Collection and a custom Comparator is inefficient; it can use heapify which is `O(N)` in time complexity, but it currently has to be done via `addAll`, which has `O(N log N)` time complexity.

Solution
Add a new constructor `PriorityQueue(Collection, Comparator)` to explicitly allow the heapify process when a custom comparator is given. This constructor would be in pair with `PriorityQueue(Collection)`, as all other PriorityQueue constructors come in natural-order and comparator pairs (`()` and `(Comparator)`, `(int)` and `(int, Comparator)` ones)

An alternative solution would be to override `addAll(Collection)` to call `initFromCollection` when the PriorityQueue is empty. This would have the same effect as the new constructor and is applicable to all empty PriorityQueues, but doesn't solve the parity issue mentioned above.

Specification
    --- a/src/java.base/share/classes/java/util/PriorityQueue.java
    +++ b/src/java.base/share/classes/java/util/PriorityQueue.java
    @@ -209,6 +209,25 @@ else if (c instanceof PriorityQueue<?>) {
             }
         }
     
    +    /**
    +     * Creates a {@code PriorityQueue} containing the elements in the
    +     * specified collection. The {@code PriorityQueue} will order its
    +     * elements according to the specified comparator.
    +     *
    +     * @param  c the collection whose elements are to be placed
    +     *         into this priority queue
    +     * @param  comparator the comparator that will be used to order this
    +     *         priority queue.  If {@code null}, the {@linkplain Comparable
    +     *         natural ordering} of the elements will be used.
    +     * @throws NullPointerException if the specified collection or any
    +     *         of its elements are null
    +     * @since 23
    +     */
    +    public PriorityQueue(Collection<? extends E> c,
    +                         Comparator<? super E> comparator) {
    +        this.comparator = comparator;
    +        initFromCollection(c);
    +    }
    +
         /**
          * Creates a {@code PriorityQueue} containing the elements in the
          * specified priority queue.  This priority queue will be


Also extra fields:
 - Scope: SE
 - Compatibility Risk: Minimal
 - Compatibility Risk Description: Adding a new constructor to an existing class is a compatible change.

You can upload the CSR content you propose in the comments, and I will create a CSR for you.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17045#issuecomment-1859200431

From acobbs at openjdk.org  Sun Dec 17 16:03:37 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sun, 17 Dec 2023 16:03:37 GMT
Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available()
 test for end-of-stream [v4]
In-Reply-To: <16wj4o26YNMV2UEJT_kL-r92WQB0CRf8OZpN35SZbb0=.9313a35b-69fb-4349-9620-ed2a8f06e9a5@github.com>
References: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
 <TJ8loA9R1Kf_GxXw9lR-XLW-xqjrkPhdCnZFwFExG1A=.e3d52b42-d008-4841-b979-88d88f04b525@github.com>
 <16wj4o26YNMV2UEJT_kL-r92WQB0CRf8OZpN35SZbb0=.9313a35b-69fb-4349-9620-ed2a8f06e9a5@github.com>
Message-ID: <ov_iibVSO-WiXW5jig7KVPWX9RVllyvzpWdgYoq37Ms=.70547559-f332-4059-aed2-5b7aedf08701@github.com>

On Sun, 17 Dec 2023 13:47:00 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> The current behavior of allowing/ignoring trailing malformed data seems to have a complicated history...

Thanks for researching all of that. I agree this should be cleaned up and have created [JDK-8322256](https://bugs.openjdk.org/browse/JDK-8322256) to that end.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17113#issuecomment-1859210088

From jbhateja at openjdk.org  Sun Dec 17 17:55:11 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 17 Dec 2023 17:55:11 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v8]
In-Reply-To: <bFMGfbhJS6iecd1-od-Irw1400eZAD7MVMYFZyIXLRc=.e78b0dc8-1942-44d5-ba03-23519d717767@github.com>
References: <bFMGfbhJS6iecd1-od-Irw1400eZAD7MVMYFZyIXLRc=.e78b0dc8-1942-44d5-ba03-23519d717767@github.com>
Message-ID: <1-fZiP70dJ9idc-DmdVVQggxLvDuP2zeb3wt9l-R1dA=.265f4701-8feb-400b-a3e2-272b6d96fe7a@github.com>

> Hi All,
> 
> This patch optimizes sub-word gather operation for x86 targets with AVX2 and AVX512 features.
> 
> Following is the summary of changes:-
> 
> 1) Intrinsify sub-word gather using hybrid algorithm which initially partially unrolls scalar loop to accumulates values from gather indices into a quadword(64bit) slice followed by vector permutation to place the slice into appropriate vector lanes, it prevents code bloating and generates compact
> JIT sequence. This coupled with savings from expansive array allocation in existing java implementation translates into significant performance of 1.3-5x gains with included micro.
> 
> 
> ![image](https://github.com/openjdk/jdk/assets/59989778/e25ba4ad-6a61-42fa-9566-452f741a9c6d)
> 
> 
> 2) Patch was also compared against modified java fallback implementation by replacing temporary array allocation with zero initialized vector and a scalar loops which inserts gathered values into vector. But, vector insert operation in higher vector lanes is a three step process which first extracts the upper vector 128 bit lane, updates it with gather subword value and then inserts the lane back to its original position. This makes inserts into higher order lanes costly w.r.t to proposed solution. In addition generated JIT code for modified fallback implementation was very bulky. This may impact in-lining decisions into caller contexts.
> 
> 3) Some minor adjustments in existing gather instruction pattens for double/quad words.
> 
> 
> Kindly review and share your feedback.
> 
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request with a new target base 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:

 - Refined AVX3 implementation with integral gather.
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8318650
 - Fix incorrect comment
 - Review comments resolutions.
 - Review comments resolutions.
 - Review comments resolutions.
 - Restricting masked sub-word gather to AVX512 target to align with integral gather support.
 - Review comments resolution.
 - 8318650: Optimized subword gather for x86 targets.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16354/files
  - new: https://git.openjdk.org/jdk/pull/16354/files/328b2217..a6f0f8cf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16354&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16354&range=06-07

  Stats: 842039 lines in 5288 files changed: 204894 ins; 551932 del; 85213 mod
  Patch: https://git.openjdk.org/jdk/pull/16354.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16354/head:pull/16354

PR: https://git.openjdk.org/jdk/pull/16354

From jbhateja at openjdk.org  Sun Dec 17 17:55:12 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 17 Dec 2023 17:55:12 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v7]
In-Reply-To: <6trfINWUmYQ7emAfsQAeLPzXSWZGRubI7v8s-wWcGn4=.91ef2dc5-dc4b-4fdd-aa0d-1e7f809cd060@github.com>
References: <bFMGfbhJS6iecd1-od-Irw1400eZAD7MVMYFZyIXLRc=.e78b0dc8-1942-44d5-ba03-23519d717767@github.com>
 <6trfINWUmYQ7emAfsQAeLPzXSWZGRubI7v8s-wWcGn4=.91ef2dc5-dc4b-4fdd-aa0d-1e7f809cd060@github.com>
Message-ID: <heyMCmSiqGCkGrzljwxfqnN0hTsh6i44sJ4iUXfO7xk=.7db85dac-ceba-4711-9c9a-7763f0dec19a@github.com>

On Wed, 15 Nov 2023 02:17:58 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> This patch optimizes sub-word gather operation for x86 targets with AVX2 and AVX512 features.
>> 
>> Following is the summary of changes:-
>> 
>> 1) Intrinsify sub-word gather using hybrid algorithm which initially partially unrolls scalar loop to accumulates values from gather indices into a quadword(64bit) slice followed by vector permutation to place the slice into appropriate vector lanes, it prevents code bloating and generates compact
>> JIT sequence. This coupled with savings from expansive array allocation in existing java implementation translates into significant performance of 1.3-5x gains with included micro.
>> 
>> 
>> ![image](https://github.com/openjdk/jdk/assets/59989778/e25ba4ad-6a61-42fa-9566-452f741a9c6d)
>> 
>> 
>> 2) Patch was also compared against modified java fallback implementation by replacing temporary array allocation with zero initialized vector and a scalar loops which inserts gathered values into vector. But, vector insert operation in higher vector lanes is a three step process which first extracts the upper vector 128 bit lane, updates it with gather subword value and then inserts the lane back to its original position. This makes inserts into higher order lanes costly w.r.t to proposed solution. In addition generated JIT code for modified fallback implementation was very bulky. This may impact in-lining decisions into caller contexts.
>> 
>> 3) Some minor adjustments in existing gather instruction pattens for double/quad words.
>> 
>> 
>> Kindly review and share your feedback.
>> 
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix incorrect comment

Refined implementation using integral gather operation for AVX512 targets. As per Intel Optimization manual section 4.8.1.6 gather are micro coded atom with 50+ cycles latency, existing hybrid algorithm is performant for Intel Atom family CPUs and with runtime flag UseAVX=2.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16354#issuecomment-1859235516

From jbhateja at openjdk.org  Sun Dec 17 18:08:45 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 17 Dec 2023 18:08:45 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v8]
In-Reply-To: <1-fZiP70dJ9idc-DmdVVQggxLvDuP2zeb3wt9l-R1dA=.265f4701-8feb-400b-a3e2-272b6d96fe7a@github.com>
References: <bFMGfbhJS6iecd1-od-Irw1400eZAD7MVMYFZyIXLRc=.e78b0dc8-1942-44d5-ba03-23519d717767@github.com>
 <1-fZiP70dJ9idc-DmdVVQggxLvDuP2zeb3wt9l-R1dA=.265f4701-8feb-400b-a3e2-272b6d96fe7a@github.com>
Message-ID: <HvfRDyJXboEnx7CbWIfnA3LGh57Zgj_Nt7fLv3lJLUI=.a920958b-7cf2-4517-a371-fc2b4470c087@github.com>

On Sun, 17 Dec 2023 17:55:11 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> This patch optimizes sub-word gather operation for x86 targets with AVX2 and AVX512 features.
>> 
>> Following is the summary of changes:-
>> 
>> 1) Intrinsify sub-word gather using hybrid algorithm which initially partially unrolls scalar loop to accumulates values from gather indices into a quadword(64bit) slice followed by vector permutation to place the slice into appropriate vector lanes, it prevents code bloating and generates compact
>> JIT sequence. This coupled with savings from expansive array allocation in existing java implementation translates into significant performance of 1.3-5x gains with included micro.
>> 
>> 
>> ![image](https://github.com/openjdk/jdk/assets/59989778/e25ba4ad-6a61-42fa-9566-452f741a9c6d)
>> 
>> 
>> 2) Patch was also compared against modified java fallback implementation by replacing temporary array allocation with zero initialized vector and a scalar loops which inserts gathered values into vector. But, vector insert operation in higher vector lanes is a three step process which first extracts the upper vector 128 bit lane, updates it with gather subword value and then inserts the lane back to its original position. This makes inserts into higher order lanes costly w.r.t to proposed solution. In addition generated JIT code for modified fallback implementation was very bulky. This may impact in-lining decisions into caller contexts.
>> 
>> 3) Some minor adjustments in existing gather instruction pattens for double/quad words.
>> 
>> 
>> Kindly review and share your feedback.
>> 
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request with a new target base 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:
> 
>  - Refined AVX3 implementation with integral gather.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8318650
>  - Fix incorrect comment
>  - Review comments resolutions.
>  - Review comments resolutions.
>  - Review comments resolutions.
>  - Restricting masked sub-word gather to AVX512 target to align with integral gather support.
>  - Review comments resolution.
>  - 8318650: Optimized subword gather for x86 targets.

Latest performance number for E-Core and P-Core targets.

![image](https://github.com/openjdk/jdk/assets/59989778/34390500-44dd-425b-84d7-a1f59827397e)

![image](https://github.com/openjdk/jdk/assets/59989778/08c4c119-95d7-4466-868c-a2103d652f4c)

![image](https://github.com/openjdk/jdk/assets/59989778/5220fbbc-b8bb-4ca1-8670-26c190e0168d)

![image](https://github.com/openjdk/jdk/assets/59989778/bfee7e5e-f07b-4da6-b98d-d6dca9668ec0)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16354#issuecomment-1859238889

From liach at openjdk.org  Sun Dec 17 19:22:06 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 17 Dec 2023 19:22:06 GMT
Subject: RFR: 8294977: Convert test/jdk/java tests from ASM library to
 Classfile API [v10]
In-Reply-To: <ZNm0kG5HiHCfixYeCz0EGjsT7ejmvPsXxN36-vAwQsU=.3eec9170-96da-444e-ad10-0095597b4fef@github.com>
References: <ZNm0kG5HiHCfixYeCz0EGjsT7ejmvPsXxN36-vAwQsU=.3eec9170-96da-444e-ad10-0095597b4fef@github.com>
Message-ID: <j3-9ojlgeERCm-x8_pIuhbJgCJZcXWtyIpaE40-0V7M=.96cdb3c1-ef04-4c41-95a8-47da81002e64@github.com>

> Summaries:
> 1. A few recommendations about updating the constant API is made at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html and I may update this patch shall the API changes be integrated before
> 2. One ASM library-specific test, `LambdaAsm` is removed. Others have their code generation infrastructure upgraded from ASM to Classfile API.
> 3. Most tests are included in tier1, but some are not:
> In `:jdk_io`: (tier2, part 2)
> 
> test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java
> test/jdk/java/io/Serializable/records/ProhibitedMethods.java
> test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java
> 
> In `:jdk_instrument`: (tier 3)
> 
> test/jdk/java/lang/instrument/RetransformAgent.java
> test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java
> test/jdk/java/lang/instrument/asmlib/Instrumentor.java
> 
> 
> @asotona Would you mind reviewing?

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Some tests don't work well with previews
 - Update tests to Class-File API
 - Merge branch 'master' into invoke-test-classfile
 - Classfile object update
 - Merge branch 'master' into invoke-test-classfile
 - Merge branch 'master' into invoke-test-classfile
 - Switch to ConstantDescs for <init> <clinit> and void constants
 - Merge AnnotationsTest, remove ModuleTargetAttribute call
 - Merge branch 'invoke-test-classfile' of https://github.com/liachmodded/jdk into invoke-test-classfile
 - Update test/jdk/java/lang/invoke/8022701/MHIllegalAccess.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - ... and 7 more: https://git.openjdk.org/jdk/compare/34351b7a...7f15d2d7

-------------

Changes: https://git.openjdk.org/jdk/pull/13009/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13009&range=09
  Stats: 1832 lines in 31 files changed: 361 ins; 713 del; 758 mod
  Patch: https://git.openjdk.org/jdk/pull/13009.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13009/head:pull/13009

PR: https://git.openjdk.org/jdk/pull/13009

From lmesnik at openjdk.org  Sun Dec 17 20:30:39 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sun, 17 Dec 2023 20:30:39 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v7]
In-Reply-To: <4iSULgKTef_C2q4AJpEKB64tZh_QDIB77Ov2rwZ78nY=.39d3c708-4175-42b5-8eb9-58684e131ccf@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
 <4iSULgKTef_C2q4AJpEKB64tZh_QDIB77Ov2rwZ78nY=.39d3c708-4175-42b5-8eb9-58684e131ccf@github.com>
Message-ID: <bJ5fZHynWBd4dWcssxNBSuL8It1pwm5_G0KJREnJYDI=.4636ffa7-53d0-4c49-a1c4-d39d344cd743@github.com>

On Fri, 15 Dec 2023 10:49:56 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fix is for JDK 23 but the intention is to back port it to 22 in RDP-1 time frame.
>> It is fixing a deadlock issue between `VirtualThread` class critical sections with the `interruptLock` (in methods: `unpark()`, `interrupt()`, `getAndClearInterrupt()`, `threadState()`, `toString()`), `JvmtiVTMSTransitionDisabler` and JVMTI `Suspend/Resume` mechanisms.
>> The deadlocking scenario is well described by Patricio in a bug report comment.
>> In simple words, a virtual thread should not be suspended during 'interruptLock' critical sections.
>> 
>> The fix is to record that a virtual thread is in a critical section (`JavaThread`'s `_in_critical_section` bit) by notifying the VM/JVMTI about begin/end of critical section.
>> This bit is used in `HandshakeState::get_op_for_self()` to filter out any `HandshakeOperation` if a target `JavaThread` is in a critical section.
>> 
>> Some of new notifications with `notifyJvmtiSync()` method is on a performance critical path. It is why this method has been intrincified.
>> 
>> New test was developed by Patricio:
>>  `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
>> The test is very nice as it reliably in 100% reproduces the deadlock without the fix.
>> The test is never failing with this fix.
>> 
>> Testing:
>>  - tested with newly added test: `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: improve an assert message

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17011#pullrequestreview-1785514646

From liach at openjdk.org  Sun Dec 17 23:11:10 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 17 Dec 2023 23:11:10 GMT
Subject: RFR: 8294977: Convert test/jdk/java tests from ASM library to
 Classfile API [v11]
In-Reply-To: <ZNm0kG5HiHCfixYeCz0EGjsT7ejmvPsXxN36-vAwQsU=.3eec9170-96da-444e-ad10-0095597b4fef@github.com>
References: <ZNm0kG5HiHCfixYeCz0EGjsT7ejmvPsXxN36-vAwQsU=.3eec9170-96da-444e-ad10-0095597b4fef@github.com>
Message-ID: <A323ixd32QcT5_Vjdjd0_2DkYVyCEdDQbh0mpXbqGS0=.77b21938-215d-4752-ba87-f428d75cac2c@github.com>

> Summaries:
> 1. A few recommendations about updating the constant API is made at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html and I may update this patch shall the API changes be integrated before
> 2. One ASM library-specific test, `LambdaAsm` is removed. Others have their code generation infrastructure upgraded from ASM to Classfile API.
> 3. Most tests are included in tier1, but some are not:
> In `:jdk_io`: (tier2, part 2)
> 
> test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java
> test/jdk/java/io/Serializable/records/ProhibitedMethods.java
> test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java
> 
> In `:jdk_instrument`: (tier 3)
> 
> test/jdk/java/lang/instrument/RetransformAgent.java
> test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java
> test/jdk/java/lang/instrument/asmlib/Instrumentor.java
> 
> 
> @asotona Would you mind reviewing?

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Fix the 2 failing tests and add notes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13009/files
  - new: https://git.openjdk.org/jdk/pull/13009/files/7f15d2d7..eb4851fd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13009&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13009&range=09-10

  Stats: 30 lines in 2 files changed: 4 ins; 19 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/13009.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13009/head:pull/13009

PR: https://git.openjdk.org/jdk/pull/13009

From liach at openjdk.org  Mon Dec 18 00:39:39 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Dec 2023 00:39:39 GMT
Subject: RFR: 8294977: Convert test/jdk/java tests from ASM library to
 Classfile API [v11]
In-Reply-To: <A323ixd32QcT5_Vjdjd0_2DkYVyCEdDQbh0mpXbqGS0=.77b21938-215d-4752-ba87-f428d75cac2c@github.com>
References: <ZNm0kG5HiHCfixYeCz0EGjsT7ejmvPsXxN36-vAwQsU=.3eec9170-96da-444e-ad10-0095597b4fef@github.com>
 <A323ixd32QcT5_Vjdjd0_2DkYVyCEdDQbh0mpXbqGS0=.77b21938-215d-4752-ba87-f428d75cac2c@github.com>
Message-ID: <jC6ICCTdHCS4KCX4G8tQW3hOq9djVln7yRwzjys-020=.becedc18-fd2c-468d-851c-17a957ab705c@github.com>

On Sun, 17 Dec 2023 23:11:10 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Summaries:
>> 1. A few recommendations about updating the constant API is made at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html and I may update this patch shall the API changes be integrated before
>> 2. One ASM library-specific test, `LambdaAsm` is removed. Others have their code generation infrastructure upgraded from ASM to Classfile API.
>> 3. Most tests are included in tier1, but some are not:
>> In `:jdk_io`: (tier2, part 2)
>> 
>> test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java
>> test/jdk/java/io/Serializable/records/ProhibitedMethods.java
>> test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java
>> 
>> In `:jdk_instrument`: (tier 3)
>> 
>> test/jdk/java/lang/instrument/RetransformAgent.java
>> test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java
>> test/jdk/java/lang/instrument/asmlib/Instrumentor.java
>> 
>> 
>> @asotona Would you mind reviewing?
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the 2 failing tests and add notes

I have migrated the tests to Preview Class-File API and fixed a few issues related to preview status that broke the tests. All tests now pass.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13009#issuecomment-1859351576

From jbhateja at openjdk.org  Mon Dec 18 06:01:12 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 18 Dec 2023 06:01:12 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v9]
In-Reply-To: <bFMGfbhJS6iecd1-od-Irw1400eZAD7MVMYFZyIXLRc=.e78b0dc8-1942-44d5-ba03-23519d717767@github.com>
References: <bFMGfbhJS6iecd1-od-Irw1400eZAD7MVMYFZyIXLRc=.e78b0dc8-1942-44d5-ba03-23519d717767@github.com>
Message-ID: <To0NCL91ie44n7T_7-BRi6fJuXKYLPo0RtjcgkKeb-A=.056d602b-d6ff-4bc6-9319-c200a74175b0@github.com>

> Hi All,
> 
> This patch optimizes sub-word gather operation for x86 targets with AVX2 and AVX512 features.
> 
> Following is the summary of changes:-
> 
> 1) Intrinsify sub-word gather using hybrid algorithm which initially partially unrolls scalar loop to accumulates values from gather indices into a quadword(64bit) slice followed by vector permutation to place the slice into appropriate vector lanes, it prevents code bloating and generates compact JIT sequence. This coupled with savings from expansive array allocation in existing java implementation translates into significant performance of 1.5-10x gains with included micro on Intel Atom family CPUs and with JVM option UseAVX=2.
> 
> ![image](https://github.com/openjdk/jdk/assets/59989778/e25ba4ad-6a61-42fa-9566-452f741a9c6d)
> 
> 
> 2) For AVX512 targets algorithm uses integral gather instructions to load values from normalized indices which are multiple of integer size, followed by shuffling and packing exact sub-word values from integral lanes. 
> 
> 3) Patch was also compared against modified java fallback implementation by replacing temporary array allocation with zero initialized vector and a scalar loops which inserts gathered values into vector. But, vector insert operation in higher vector lanes is a three step process which first extracts the upper vector 128 bit lane, updates it with gather subword value and then inserts the lane back to its original position. This makes inserts into higher order lanes costly w.r.t to proposed solution. In addition generated JIT code for modified fallback implementation was very bulky. This may impact in-lining decisions into caller contexts.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Removing JDK-8321648 related changes.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16354/files
  - new: https://git.openjdk.org/jdk/pull/16354/files/a6f0f8cf..4af776e8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16354&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16354&range=07-08

  Stats: 16 lines in 1 file changed: 14 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16354.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16354/head:pull/16354

PR: https://git.openjdk.org/jdk/pull/16354

From asotona at openjdk.org  Mon Dec 18 08:35:51 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 18 Dec 2023 08:35:51 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v3]
In-Reply-To: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
Message-ID: <aPNrxPtIvYKmYHbToXPOSuUP4xrlJH_yPpSxwV_FxmU=.c9927b9b-acdd-429c-845d-236739609a01@github.com>

> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
> 
> This patch converts ASM calls to Classfile API.
> 
> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
> 
> Any comments and suggestions are welcome.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: liach <7806504+liach at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17108/files
  - new: https://git.openjdk.org/jdk/pull/17108/files/0f356eb3..8fee4564

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=01-02

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/17108.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17108/head:pull/17108

PR: https://git.openjdk.org/jdk/pull/17108

From asotona at openjdk.org  Mon Dec 18 09:16:45 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 18 Dec 2023 09:16:45 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v2]
In-Reply-To: <JPxIdiqmGMXIQOtKKI4ZbT9P4eTK3QBubhMXS5B1bWM=.1b74cf4e-1d39-4207-8ed8-a6f1d4878467@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <ryPVgRWbldkLMNq2GOZZqYLydDKWgixV910y7KY01qw=.63e9f740-66db-4529-a211-e8db04e6bfe4@github.com>
 <JPxIdiqmGMXIQOtKKI4ZbT9P4eTK3QBubhMXS5B1bWM=.1b74cf4e-1d39-4207-8ed8-a6f1d4878467@github.com>
Message-ID: <_YhN936BNbmIKI_GfmN3IGch2xBAezQKU18RUwy1Mzk=.8da9587f-fc23-4bb4-8400-e7519f272eb8@github.com>

On Sat, 16 Dec 2023 16:12:05 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added missing comment
>
> src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 1171:
> 
>> 1169:         cob.getfield(ClassDesc.ofInternalName("java/lang/invoke/MethodHandleImpl$CasesHolder"), "cases",
>> 1170:                 CD_MethodHandle.arrayType());
>> 1171:         int casesLocal = extendLocalsMap(new Class<?>[] { MethodHandle[].class });
> 
> We should look into replacing the local map with `CodeBuilder.allocateLocal` etc. in the future.

Yes, however actual API does not match directly.
It would require an extension of the API or more significant refactoring of InvokerBytecodeGenerator.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1429746763

From asotona at openjdk.org  Mon Dec 18 09:20:45 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 18 Dec 2023 09:20:45 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v2]
In-Reply-To: <JPxIdiqmGMXIQOtKKI4ZbT9P4eTK3QBubhMXS5B1bWM=.1b74cf4e-1d39-4207-8ed8-a6f1d4878467@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <ryPVgRWbldkLMNq2GOZZqYLydDKWgixV910y7KY01qw=.63e9f740-66db-4529-a211-e8db04e6bfe4@github.com>
 <JPxIdiqmGMXIQOtKKI4ZbT9P4eTK3QBubhMXS5B1bWM=.1b74cf4e-1d39-4207-8ed8-a6f1d4878467@github.com>
Message-ID: <k7dtrgT5Z9d61m-ROjdr6xWnXMGFQuaVENOB4XJN2ZY=.40223018-6b28-4628-aa33-4d7d1778898f@github.com>

On Sat, 16 Dec 2023 16:32:23 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added missing comment
>
> src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 1145:
> 
>> 1143:     private static Opcode popInsnOpcode(BasicType type) {
>> 1144:         switch (type) {
>> 1145:             case I_TYPE:
> 
> Should restore the enhanced switch syntax

Will fix, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1429753608

From asotona at openjdk.org  Mon Dec 18 09:42:43 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 18 Dec 2023 09:42:43 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v3]
In-Reply-To: <JPxIdiqmGMXIQOtKKI4ZbT9P4eTK3QBubhMXS5B1bWM=.1b74cf4e-1d39-4207-8ed8-a6f1d4878467@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <ryPVgRWbldkLMNq2GOZZqYLydDKWgixV910y7KY01qw=.63e9f740-66db-4529-a211-e8db04e6bfe4@github.com>
 <JPxIdiqmGMXIQOtKKI4ZbT9P4eTK3QBubhMXS5B1bWM=.1b74cf4e-1d39-4207-8ed8-a6f1d4878467@github.com>
Message-ID: <EEu2MSBVLfqdl4mhmw6J48_gG9Jm7qyTFyFk4a3Uyj0=.fdda6332-9228-44e0-8ae3-f9a585198f7f@github.com>

On Sat, 16 Dec 2023 16:37:16 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply suggestions from code review
>>   
>>   Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>
> src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 468:
> 
>> 466:     }
>> 467: 
>> 468:     private void emitStoreInsn(BasicType type, int index) {
> 
> If we are going to use `localsMap` in every removed `emitStoreInsn`, perhaps we should restore it instead? Will also make it easier to move away from localsMap to CodeBuilder's tracking system.

Right, I'll restore emitLoadInsn and emitStoreInsn

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1429791664

From asotona at openjdk.org  Mon Dec 18 09:42:47 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 18 Dec 2023 09:42:47 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v2]
In-Reply-To: <JPxIdiqmGMXIQOtKKI4ZbT9P4eTK3QBubhMXS5B1bWM=.1b74cf4e-1d39-4207-8ed8-a6f1d4878467@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <ryPVgRWbldkLMNq2GOZZqYLydDKWgixV910y7KY01qw=.63e9f740-66db-4529-a211-e8db04e6bfe4@github.com>
 <JPxIdiqmGMXIQOtKKI4ZbT9P4eTK3QBubhMXS5B1bWM=.1b74cf4e-1d39-4207-8ed8-a6f1d4878467@github.com>
Message-ID: <LExTbXvJgpWzFPniPAwkqkbTBEBMUIBfSQXvMQ3YVrg=.49ac19c4-a271-4e8a-b9fa-6c7d46f38401@github.com>

On Sat, 16 Dec 2023 16:42:09 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added missing comment
>
> src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 1519:
> 
>> 1517:         //      double      -     d2i,i2b   d2i,i2s  d2i,i2c    d2i      d2l      d2f      <->
>> 1518:         if (from != to && from != TypeKind.BooleanType && to != TypeKind.BooleanType) try {
>> 1519:             cob.convertInstruction(from, to);
> 
> Need an intermediate int if you are converting from long/float/double to byte/short/char.

Will fix, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1429794214

From asotona at openjdk.org  Mon Dec 18 10:14:41 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 18 Dec 2023 10:14:41 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v2]
In-Reply-To: <JPxIdiqmGMXIQOtKKI4ZbT9P4eTK3QBubhMXS5B1bWM=.1b74cf4e-1d39-4207-8ed8-a6f1d4878467@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <ryPVgRWbldkLMNq2GOZZqYLydDKWgixV910y7KY01qw=.63e9f740-66db-4529-a211-e8db04e6bfe4@github.com>
 <JPxIdiqmGMXIQOtKKI4ZbT9P4eTK3QBubhMXS5B1bWM=.1b74cf4e-1d39-4207-8ed8-a6f1d4878467@github.com>
Message-ID: <bwdIPuuH4SgvJsyvunGLuBwpYH1OdgvtACCDutp-aiI=.3cc07480-c81f-4d90-846e-4926197c8132@github.com>

On Sat, 16 Dec 2023 16:49:26 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added missing comment
>
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 2290:
> 
>> 2288:                 int accessFlags;
>> 2289:                 try {
>> 2290:                     ClassModel cm = java.lang.classfile.ClassFile.of().parse(bytes);
> 
> No need for fully-qualified name.

Unfortunately there is conflict with MethodHandles.Lookup.ClassFile

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1429855148

From asotona at openjdk.org  Mon Dec 18 10:24:45 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 18 Dec 2023 10:24:45 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v2]
In-Reply-To: <JPxIdiqmGMXIQOtKKI4ZbT9P4eTK3QBubhMXS5B1bWM=.1b74cf4e-1d39-4207-8ed8-a6f1d4878467@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <ryPVgRWbldkLMNq2GOZZqYLydDKWgixV910y7KY01qw=.63e9f740-66db-4529-a211-e8db04e6bfe4@github.com>
 <JPxIdiqmGMXIQOtKKI4ZbT9P4eTK3QBubhMXS5B1bWM=.1b74cf4e-1d39-4207-8ed8-a6f1d4878467@github.com>
Message-ID: <n6LQvHm-btGjXHJfDfuQEFvJILPOcTRn34It5GitWDk=.25dcccae-9604-47e2-9073-909974f4a9de@github.com>

On Sat, 16 Dec 2023 16:53:26 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added missing comment
>
> src/java.base/share/classes/java/lang/invoke/MethodType.java line 1295:
> 
>> 1293:     public Optional<MethodTypeDesc> describeConstable() {
>> 1294:         try {
>> 1295:             var params = new ClassDesc[parameterCount()];
> 
> We can probably handle like this:
> 
> var retDesc = returnType().describeConstable();
> if (retDesc.isEmpty())
>     return Optional.empty();
> 
> if (parameterCount() == 0)
>     return Optional.of(MethodTypeDesc.of(retDesc.get()));
> 
> var params = new ClassDesc[parameterCount()];
> for (int i = 0; i < params.length; i++) {
>     var paramDesc = parameterType(i).describeConstable();
>     if (paramDesc.isEmpty())
>         return Optional.empty();
>     params[i] = paramDesc.get();
> }
> return Optional.of(MethodTypeDesc.of(returnType().get(), params));
> 
> 
> To avoid creating exceptions and allocating array when the params array is empty.

yes, it looks better, thanks.

> src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java line 379:
> 
>> 377:     @Override
>> 378:     public ClassEntry classEntry(ClassDesc classDesc) {
>> 379:         if (classDesc == ConstantDescs.CD_Object) {
> 
> What causes the slow lookup of Object CE? If it's because that hashing needs to compute the substring first, I recommend changing the hashing algorithm if that's the case.

Right, I'll take this specific shortcut back and will think about more generic performance improvement.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1429863879
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1429866344

From asotona at openjdk.org  Mon Dec 18 11:03:10 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 18 Dec 2023 11:03:10 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v4]
In-Reply-To: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
Message-ID: <e3svw09clM3QZVdC3shb8DcJdvSkubsQv7-u1YFcRqk=.b4996354-c254-4cce-9b3f-d72347f81fde@github.com>

> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
> 
> This patch converts ASM calls to Classfile API.
> 
> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
> 
> Any comments and suggestions are welcome.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: liach <7806504+liach at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17108/files
  - new: https://git.openjdk.org/jdk/pull/17108/files/8fee4564..098df109

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=02-03

  Stats: 145 lines in 7 files changed: 51 ins; 55 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/17108.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17108/head:pull/17108

PR: https://git.openjdk.org/jdk/pull/17108

From asotona at openjdk.org  Mon Dec 18 11:03:15 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 18 Dec 2023 11:03:15 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v2]
In-Reply-To: <JPxIdiqmGMXIQOtKKI4ZbT9P4eTK3QBubhMXS5B1bWM=.1b74cf4e-1d39-4207-8ed8-a6f1d4878467@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <ryPVgRWbldkLMNq2GOZZqYLydDKWgixV910y7KY01qw=.63e9f740-66db-4529-a211-e8db04e6bfe4@github.com>
 <JPxIdiqmGMXIQOtKKI4ZbT9P4eTK3QBubhMXS5B1bWM=.1b74cf4e-1d39-4207-8ed8-a6f1d4878467@github.com>
Message-ID: <FiRp2hMxH1vEaNKkzebC2m3L2340P3rJIhXhjcfvFJM=.e68a3227-c36a-4d13-ac92-2568e4a3bba4@github.com>

On Sat, 16 Dec 2023 15:54:57 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added missing comment
>
> src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 548:
> 
>> 546:     static ClassDesc classDesc(Class<?> cls) {
>> 547:         return cls.isHidden() ? ClassDesc.ofInternalName(cls.getName().replace('.', '/'))
>> 548:                               : ClassDesc.ofDescriptor(cls.descriptorString());
> 
> That said, all the usages already anticipate a valid `ClassDesc` that can be encoded in bytecode except `implClass`. You should make 2 versions of `classDesc()`, one that eagerly throws for all other usages, and another special version that handles hidden class conversion (with the same code as existing method) for https://github.com/openjdk/jdk/pull/17108/files#diff-76236a0dd20022f749d95ad5890e2bece0c4ac212d1b2ffab90ca86875f14282R173

Split, thank you.

> src/java.base/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java line 162:
> 
>> 160:         } else {
>> 161:             Class<?> src;
>> 162:             if (arg == functional || functional.isPrimitive()) {
> 
> `arg == functional` avoids a cast, though it's not in parity with the older code. Should probably restore the old cast that takes a source argument to avoid adding `==` checks to avoid casts.

Original cast is avoided when class names (derived from descriptors, derived from classes) are equal.
Correct me, please, but I think that this simple `arg == functional` check does the same job, without unnecessary String conversions and comparisons.
Or is there a case, where the cast is missing or added incorrectly?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1429931780
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1429919564

From avoitylov at openjdk.org  Mon Dec 18 12:02:06 2023
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Mon, 18 Dec 2023 12:02:06 GMT
Subject: [jdk22] RFR: 8321514: UTF16 string gets constructed incorrectly from
 codepoints if CompactStrings is not enabled
Message-ID: <qYnMiDf6o6CjptzNwcIKfI9JJY-9wVn5gFonPB2_Aos=.4b4690ad-95da-4443-afd8-7e0cd473e33f@github.com>

Hi all,

This pull request contains a backport of commit [fde5b168](https://github.com/openjdk/jdk/commit/fde5b16817c3263236993f2e8c2d2469610d99bd) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Aleksei Voitylov on 14 Dec 2023 and was reviewed by Roger Riggs.

Thanks!

-------------

Commit messages:
 - Backport fde5b16817c3263236993f2e8c2d2469610d99bd

Changes: https://git.openjdk.org/jdk22/pull/18/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=18&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321514
  Stats: 27 lines in 2 files changed: 25 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk22/pull/18.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/18/head:pull/18

PR: https://git.openjdk.org/jdk22/pull/18

From rgiulietti at openjdk.org  Mon Dec 18 14:34:37 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 18 Dec 2023 14:34:37 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v2]
In-Reply-To: <fmdSrcdXS-1mrnFZfef_gpjuVCcddZCHpj9MzeVLXIw=.1c3c494a-0399-4c72-a870-e8b43fcb70dc@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <ETA8uKzeRwTYkvSRjpzeBDCLzM21yUyz5tHhn5TS3RM=.b4c80ae2-0d64-413e-9ad9-6a50214fc8b0@github.com>
 <fmdSrcdXS-1mrnFZfef_gpjuVCcddZCHpj9MzeVLXIw=.1c3c494a-0399-4c72-a870-e8b43fcb70dc@github.com>
Message-ID: <FXjooWz3eHO2fiQkWYLapE4NztCFpJf7MSgSaMaKn1M=.d81c6187-7989-47e2-ae0f-26db60461af0@github.com>

On Sat, 16 Dec 2023 01:27:17 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restrict accessibility of nested classes.
>
> It seems correct to have the event disabled in both configurations. It's not hard to imagine pathological cases where millions of stream objects are created, which would create overhead and flood event buffers, making JFR not usable.
> 
> That said, I wonder how many will actually use, or find out about the event, if they need to edit the .jfc file or specify -XX:StartFlightRecording:jdk.SerializationMisdeclaration#enabled=true on command line? 
> 
> How important is the stack trace when diagnosing serialization misdeclarations?
> 
> We faced a similar situation with the Finalization event a couple of years ago, but we were able to make the event periodic and enabled by default with some VM magic. An event that is enabled by default will probably be seen by 10 000 times as many users, so it might be worth considering other approaches, even if they are harder to implement, or we lose some of the information.

@egahlin Yes, disabled by default means less overhead in the usual case.

On the other hand, the checks and the events generation are done for serializable classes that actually actively participate in serialization, lazily, and just once per class, so maybe they are not as invasive and might be "always enabled". Pathological cases with millions of serializable classes might indeed lead to problems with "always enable", although they should be quite rare.

I don't think that stack traces are that useful for this kind of event, since they are mostly related to the static class structure rather than to runtime characteristics. Looking at the event itself should help in locating the problem quickly: it reports the class, the member, and what's questionable with it.

Or am I misunderstanding your points?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17129#issuecomment-1860655448

From jjiang at openjdk.org  Mon Dec 18 15:01:38 2023
From: jjiang at openjdk.org (John Jiang)
Date: Mon, 18 Dec 2023 15:01:38 GMT
Subject: RFR: 8321637: Simplify if statement in ArraysSupport::hugeLength
In-Reply-To: <oMBdVUIKUu5OL4z0RHVOiogWAejQ6Ef7wfsTgKGI6wM=.a7b472b2-7b0a-4066-adfe-bdb00bc91d34@github.com>
References: <oMBdVUIKUu5OL4z0RHVOiogWAejQ6Ef7wfsTgKGI6wM=.a7b472b2-7b0a-4066-adfe-bdb00bc91d34@github.com>
Message-ID: <rtuoV0ktFWEp1-ZRJncheuGyWhRl1s49MhlD7D55Qig=.2a61cc9d-6dd3-4677-a975-c122fb33bc91@github.com>

On Sat, 9 Dec 2023 23:19:52 GMT, John Jiang <jjiang at openjdk.org> wrote:

> It looks the `else-if` and `else` clauses in method `ArraysSupport::hugeLength` could be simplified by `Math::max`.

Could this simple PR be reviewed?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17043#issuecomment-1860729032

From egahlin at openjdk.org  Mon Dec 18 15:15:40 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 18 Dec 2023 15:15:40 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v2]
In-Reply-To: <fmdSrcdXS-1mrnFZfef_gpjuVCcddZCHpj9MzeVLXIw=.1c3c494a-0399-4c72-a870-e8b43fcb70dc@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <ETA8uKzeRwTYkvSRjpzeBDCLzM21yUyz5tHhn5TS3RM=.b4c80ae2-0d64-413e-9ad9-6a50214fc8b0@github.com>
 <fmdSrcdXS-1mrnFZfef_gpjuVCcddZCHpj9MzeVLXIw=.1c3c494a-0399-4c72-a870-e8b43fcb70dc@github.com>
Message-ID: <btYr8U90yi9h9ghzvm06xFzVG1VLxK8pqZHnLjlUbJI=.4ad3995e-b5b8-45ca-a81e-5576ddab17b9@github.com>

On Sat, 16 Dec 2023 01:27:17 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restrict accessibility of nested classes.
>
> It seems correct to have the event disabled in both configurations. It's not hard to imagine pathological cases where millions of stream objects are created, which would create overhead and flood event buffers, making JFR not usable.
> 
> That said, I wonder how many will actually use, or find out about the event, if they need to edit the .jfc file or specify -XX:StartFlightRecording:jdk.SerializationMisdeclaration#enabled=true on command line? 
> 
> How important is the stack trace when diagnosing serialization misdeclarations?
> 
> We faced a similar situation with the Finalization event a couple of years ago, but we were able to make the event periodic and enabled by default with some VM magic. An event that is enabled by default will probably be seen by 10 000 times as many users, so it might be worth considering other approaches, even if they are harder to implement, or we lose some of the information.

> @egahlin Yes, disabled by default means less overhead in the usual case.
> 
> On the other hand, the checks and the events generation are done for serializable classes that actually actively participate in serialization, lazily, and just once per class, so maybe they are not as invasive and might be "always enabled". Pathological cases with millions of serializable classes might indeed lead to problems with "always enable", although they should be quite rare.
> 

If it's once per class per JVM, I think it's fine to enable it in profile.jfc. It's meant to have low overhead (around 1%) for the typical application, but OK with higher in pathological cases. Loading/initiating a class has a cost, so it will likely dominate.

> I don't think that stack traces are that useful for this kind of event, since they are mostly related to the static class structure rather than to runtime characteristics. Looking at the event itself should help in locating the problem quickly: it reports the class, the member, and what's questionable with it.
> 

If we were to make the event periodic, it's hard to keep the stack trace around, at least in Java, so I wanted to know how important it is. Now if we can have it in profile.jfc, I think it's fine to keep it. If you think the stack trace has no use at all, then you could remove it and perhaps also the thread using the RemoveFields annotation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17129#issuecomment-1860765344

From kbarrett at openjdk.org  Mon Dec 18 15:31:41 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 18 Dec 2023 15:31:41 GMT
Subject: RFR: 8321688: Build on linux with GCC 7.5.0 fails after 8319577
 [v2]
In-Reply-To: <IgVsEyruca5jYomg5OTMjFXt9kBhDS3KTp2prBY9sbQ=.8e140145-a9ed-494b-a10d-f5ffeb2bc142@github.com>
References: <vIByQ06ftSU9o1Rb4YOWXPrry1LkYSj-vJqLXaMXQ5g=.d5a0ea33-f57a-4549-addf-b7a9c5eaa67d@github.com>
 <IgVsEyruca5jYomg5OTMjFXt9kBhDS3KTp2prBY9sbQ=.8e140145-a9ed-494b-a10d-f5ffeb2bc142@github.com>
Message-ID: <J8AypHrlp4XgE4ZNNTPTwxecHyWzG_d10N34vo7P8Yk=.cb069cf4-3e7a-492d-b2bb-6ddac371facc@github.com>

On Sun, 17 Dec 2023 13:25:00 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch fixes the building failure introduced by [JDK-8319577](https://bugs.openjdk.org/browse/JDK-8319577) in old GCC version (linux & GCC 7.5.0 locally).
>> 
>> Thanks for the review.
>> 
>>  Best Regards,
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Bump the needed version of GCC.
>  - Revert previous change.
>  - Merge branch 'master' into JDK-8321688
>  - JDK-8321688

src/java.base/linux/native/libsimdsort/simdsort-support.hpp line 35:

> 33: 
> 34: // GCC >= 9.1 is needed to build AVX2 portions of libsimdsort using C++17 features
> 35: #if defined(_LP64) && (defined(__GNUC__) && ((__GNUC__ > 9) || ((__GNUC__ == 9) && (__GNUC_MINOR__ >= 1))))

Have you tested with gcc 9?  Or is this just supposition based on gcc9 having removed the experimental
status for C++17?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17047#discussion_r1430308457

From sspitsyn at openjdk.org  Mon Dec 18 16:35:40 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 18 Dec 2023 16:35:40 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v7]
In-Reply-To: <4iSULgKTef_C2q4AJpEKB64tZh_QDIB77Ov2rwZ78nY=.39d3c708-4175-42b5-8eb9-58684e131ccf@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
 <4iSULgKTef_C2q4AJpEKB64tZh_QDIB77Ov2rwZ78nY=.39d3c708-4175-42b5-8eb9-58684e131ccf@github.com>
Message-ID: <JF84k4MMI9B6_F2qQdbRAoiAzVsfNxC6OtPGJRRNjW8=.dce2dbca-421c-433e-9e7c-af6ca983dfeb@github.com>

On Fri, 15 Dec 2023 10:49:56 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fix is for JDK 23 but the intention is to back port it to 22 in RDP-1 time frame.
>> It is fixing a deadlock issue between `VirtualThread` class critical sections with the `interruptLock` (in methods: `unpark()`, `interrupt()`, `getAndClearInterrupt()`, `threadState()`, `toString()`), `JvmtiVTMSTransitionDisabler` and JVMTI `Suspend/Resume` mechanisms.
>> The deadlocking scenario is well described by Patricio in a bug report comment.
>> In simple words, a virtual thread should not be suspended during 'interruptLock' critical sections.
>> 
>> The fix is to record that a virtual thread is in a critical section (`JavaThread`'s `_in_critical_section` bit) by notifying the VM/JVMTI about begin/end of critical section.
>> This bit is used in `HandshakeState::get_op_for_self()` to filter out any `HandshakeOperation` if a target `JavaThread` is in a critical section.
>> 
>> Some of new notifications with `notifyJvmtiSync()` method is on a performance critical path. It is why this method has been intrincified.
>> 
>> New test was developed by Patricio:
>>  `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
>> The test is very nice as it reliably in 100% reproduces the deadlock without the fix.
>> The test is never failing with this fix.
>> 
>> Testing:
>>  - tested with newly added test: `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: improve an assert message

Alan and Leonid, thank you for review!
Will push after the final mach5 testing is completed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17011#issuecomment-1860980377

From bpb at openjdk.org  Mon Dec 18 16:41:07 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 18 Dec 2023 16:41:07 GMT
Subject: RFR: 8259637: java.io.File.getCanonicalPath() returns different
 values for same path [v2]
In-Reply-To: <uClvCZ0hgjGS7z2k81iXiC5PJ1VbvzJwvvnlPd-nkxE=.da23f584-9126-41c7-b8ab-e86e1680127f@github.com>
References: <uClvCZ0hgjGS7z2k81iXiC5PJ1VbvzJwvvnlPd-nkxE=.da23f584-9126-41c7-b8ab-e86e1680127f@github.com>
Message-ID: <IzhSQ9q4HLoohlfWpfpgs0pevqCS8qM6fRQ-ufuV2PE=.77fa73c5-d348-4338-8ea6-041e4cabd113@github.com>

> Modify the `collapse()` function to remove each instance of ".." when the path is absolute and there is no preceding name.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8259637: Use Stream.of in test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17089/files
  - new: https://git.openjdk.org/jdk/pull/17089/files/d2f755b0..cd2b3776

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17089&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17089&range=00-01

  Stats: 14 lines in 1 file changed: 0 ins; 7 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/17089.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17089/head:pull/17089

PR: https://git.openjdk.org/jdk/pull/17089

From bpb at openjdk.org  Mon Dec 18 16:41:10 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 18 Dec 2023 16:41:10 GMT
Subject: RFR: 8259637: java.io.File.getCanonicalPath() returns different
 values for same path [v2]
In-Reply-To: <QLM859C7J6HZkGSFIZBYbIJvfN5Xr7CIGknst3Y5T3Q=.ed6b9d63-8796-4fb6-a33a-cb79862356e3@github.com>
References: <uClvCZ0hgjGS7z2k81iXiC5PJ1VbvzJwvvnlPd-nkxE=.da23f584-9126-41c7-b8ab-e86e1680127f@github.com>
 <QLM859C7J6HZkGSFIZBYbIJvfN5Xr7CIGknst3Y5T3Q=.ed6b9d63-8796-4fb6-a33a-cb79862356e3@github.com>
Message-ID: <QZjLfP29x-fqZGw9f9pVmiXfXqqK2DgDMY1HS6VYuvM=.c9b69a00-c5c4-4749-aae8-0342c51f68d1@github.com>

On Sun, 17 Dec 2023 08:53:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8259637: Use Stream.of in test
>
> test/jdk/java/io/File/GetCanonicalPath.java line 98:
> 
>> 96:                               "/b/c"));
>> 97: 
>> 98:         return list.stream();
> 
> You could use Stream.of here, e.g.
> 
> 
>         return Stream.of(
>             Arguments.of("/../../../../../a/b/c", "/a/b/c"),
>             Arguments.of("/../../../../../a/../b/c", "/b/c"),
>             Arguments.of("/../../../../../a/../../b/c", "/b/c"),
>             Arguments.of("/../../../../../a/../../../b/c", "/b/c"),
>             Arguments.of("/../../../../../a/../../../../b/c", "/b/c")
>         );

So changed in cd2b3776463ddc95b36f7b65be12da7ac2686c53.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17089#discussion_r1430388844

From sspitsyn at openjdk.org  Mon Dec 18 17:09:59 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 18 Dec 2023 17:09:59 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v8]
In-Reply-To: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
Message-ID: <EwkIDbTs7wG5q6lcikgo0ycMFRpu5VXxvMbR3tOPAM8=.40c169b6-57df-4dc7-8726-fd6d8439c541@github.com>

> This fix is for JDK 23 but the intention is to back port it to 22 in RDP-1 time frame.
> It is fixing a deadlock issue between `VirtualThread` class critical sections with the `interruptLock` (in methods: `unpark()`, `interrupt()`, `getAndClearInterrupt()`, `threadState()`, `toString()`), `JvmtiVTMSTransitionDisabler` and JVMTI `Suspend/Resume` mechanisms.
> The deadlocking scenario is well described by Patricio in a bug report comment.
> In simple words, a virtual thread should not be suspended during 'interruptLock' critical sections.
> 
> The fix is to record that a virtual thread is in a critical section (`JavaThread`'s `_in_critical_section` bit) by notifying the VM/JVMTI about begin/end of critical section.
> This bit is used in `HandshakeState::get_op_for_self()` to filter out any `HandshakeOperation` if a target `JavaThread` is in a critical section.
> 
> Some of new notifications with `notifyJvmtiSync()` method is on a performance critical path. It is why this method has been intrincified.
> 
> New test was developed by Patricio:
>  `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
> The test is very nice as it reliably in 100% reproduces the deadlock without the fix.
> The test is never failing with this fix.
> 
> Testing:
>  - tested with newly added test: `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
>  - tested with mach5 tiers 1-6

Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge
 - review: improve an assert message
 - review: moved a couple of comments out of try blocks
 - review: moved notifyJvmtiDisableSuspend(true) out of try-block
 - review: 1) replace CriticalLock with DisableSuspend; 2) minor tweaks
 - review: (1) rename notifyJvmti method; (2) add try-final statements to VirtualThread methods
 - Resolved merge conflict in VirtualThread.java
 - added @summary to new test SuspendWithInterruptLock.java
 - add new test SuspendWithInterruptLock.java
 - 8311218: fatal error: stuck in JvmtiVTMSTransitionDisabler::VTMS_transition_disable

-------------

Changes: https://git.openjdk.org/jdk/pull/17011/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17011&range=07
  Stats: 229 lines in 15 files changed: 196 ins; 0 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/17011.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17011/head:pull/17011

PR: https://git.openjdk.org/jdk/pull/17011

From naoto at openjdk.org  Mon Dec 18 17:45:48 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 18 Dec 2023 17:45:48 GMT
Subject: RFR: 8320919: Clarify Locale related system properties [v8]
In-Reply-To: <IruGxIK9DXnXFDANt1y4sCMJEGZh1PTOKhOWZZxJEdc=.77092e02-fb4f-4c9e-8d53-0fa0cf3bae7d@github.com>
References: <IruGxIK9DXnXFDANt1y4sCMJEGZh1PTOKhOWZZxJEdc=.77092e02-fb4f-4c9e-8d53-0fa0cf3bae7d@github.com>
Message-ID: <DuCeW7gG9Bv6j8pwYVtF-0-RT5xnwoy2WLH2eYHYJ6E=.004d7067-eaf3-4d8e-8a2e-b4f9b6a8a747@github.com>

> This is a doc change to clarify what the `Default Locale` is, and how it is established during the system startup using the system properties. Those locale-related system properties have existed since the early days of Java, but have never been publicly documented before. It is also the intention of this PR to clarify those system properties and how they are overridden. A corresponding CSR has been drafted.

Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Reflects review comments
 - Reflects review comments
 - Reflects review comments
 - Reflects review comments
 - Review comments
 - Update src/java.base/share/classes/java/util/Locale.java
   
   Co-authored-by: Justin Lu <Justin.lu at oracle.com>
 - Update src/java.base/share/classes/java/util/Locale.java
   
   Co-authored-by: Justin Lu <Justin.lu at oracle.com>
 - Update src/java.base/share/classes/java/util/Locale.java
   
   Co-authored-by: Justin Lu <Justin.lu at oracle.com>
 - Update src/java.base/share/classes/java/util/Locale.java
   
   Co-authored-by: Justin Lu <Justin.lu at oracle.com>
 - 6th draft
 - ... and 5 more: https://git.openjdk.org/jdk/compare/1fde8b86...4a76c89c

-------------

Changes: https://git.openjdk.org/jdk/pull/17065/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17065&range=07
  Stats: 81 lines in 1 file changed: 71 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/17065.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17065/head:pull/17065

PR: https://git.openjdk.org/jdk/pull/17065

From rgiulietti at openjdk.org  Mon Dec 18 17:49:04 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 18 Dec 2023 17:49:04 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v3]
In-Reply-To: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
Message-ID: <_8M6KPN0UJHeW1cx31IW0mIfaXG5ls5nUfZ0TwxMdAs=.fd4facc4-91d4-4117-9b1f-a2cc1806d2b7@github.com>

> Adds serialization misdeclaration events to JFR.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Event enabled on profile.jfc but disabled on default.jfc.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17129/files
  - new: https://git.openjdk.org/jdk/pull/17129/files/629e8f23..8534d7af

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=01-02

  Stats: 37 lines in 5 files changed: 27 ins; 6 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/17129.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17129/head:pull/17129

PR: https://git.openjdk.org/jdk/pull/17129

From stsypanov at openjdk.org  Mon Dec 18 17:53:57 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 18 Dec 2023 17:53:57 GMT
Subject: RFR: 8322292: Rearrange comparison of fields in Record.equals()
Message-ID: <eNySqrZ9HgZrjF61lHA_6YecuPT7RB9xxz82U3zIjog=.f8b68ce5-3fab-4cfa-8709-17e51d77a958@github.com>

Currently if we create a record it's fields are compared in their declaration order. This might be ineffective in cases when two objects have "heavy" fields equals to each other, but different "lightweight" fields (heavy and lightweight in terms of comparison) e.g. primitives, enums, nullable/non-nulls etc.

If we have declared a record like

public record MyRecord(String field1, int field2) {}

It's equals() looks like:

  public final equals(Ljava/lang/Object;)Z
   L0
    LINENUMBER 3 L0
    ALOAD 0
    ALOAD 1
    INVOKEDYNAMIC equals(Lcom/caspianone/openbanking/productservice/controller/MyRecord;Ljava/lang/Object;)Z [
      // handle kind 0x6 : INVOKESTATIC
      java/lang/runtime/ObjectMethods.bootstrap(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/TypeDescriptor;Ljava/lang/Class;Ljava/lang/String;[Ljava/lang/invoke/MethodHandle;)Ljava/lang/Object;
      // arguments:
      com.caspianone.openbanking.productservice.controller.MyRecord.class,
      "field1;field2",
      // handle kind 0x1 : GETFIELD
      com/caspianone/openbanking/productservice/controller/MyRecord.field1(Ljava/lang/String;),
      // handle kind 0x1 : GETFIELD
      com/caspianone/openbanking/productservice/controller/MyRecord.field2(I)
    ]
    IRETURN
   L1
    LOCALVARIABLE this Lcom/caspianone/openbanking/productservice/controller/MyRecord; L0 L1 0
    LOCALVARIABLE o Ljava/lang/Object; L0 L1 1
    MAXSTACK = 2
    MAXLOCALS = 2

This can be improved by rearranging the comparison order of the fields moving enums and primitives upper, and collections/arrays lower.

-------------

Commit messages:
 - 8322292: Update copyright
 - 8322292: Shift arrays and Iterables down
 - Improve Record.equals()

Changes: https://git.openjdk.org/jdk/pull/17143/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17143&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322292
  Stats: 12 lines in 1 file changed: 9 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17143/head:pull/17143

PR: https://git.openjdk.org/jdk/pull/17143

From bpb at openjdk.org  Mon Dec 18 18:13:47 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 18 Dec 2023 18:13:47 GMT
Subject: Integrated: 8259637: java.io.File.getCanonicalPath() returns different
 values for same path
In-Reply-To: <uClvCZ0hgjGS7z2k81iXiC5PJ1VbvzJwvvnlPd-nkxE=.da23f584-9126-41c7-b8ab-e86e1680127f@github.com>
References: <uClvCZ0hgjGS7z2k81iXiC5PJ1VbvzJwvvnlPd-nkxE=.da23f584-9126-41c7-b8ab-e86e1680127f@github.com>
Message-ID: <oIuFZEo1wHuLoBiy25VKjVVRWr3mqWJaLAKtHEtLoJo=.b3ea9bd0-f7b2-4dfe-849b-17265b0af9a4@github.com>

On Wed, 13 Dec 2023 19:37:15 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify the `collapse()` function to remove each instance of ".." when the path is absolute and there is no preceding name.

This pull request has now been integrated.

Changeset: b98d13fc
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b98d13fc3c7f6747d9201eb884cf9d3181671ccb
Stats:     37 lines in 2 files changed: 30 ins; 1 del; 6 mod

8259637: java.io.File.getCanonicalPath() returns different values for same path

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/17089

From cjplummer at openjdk.org  Mon Dec 18 20:40:39 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 18 Dec 2023 20:40:39 GMT
Subject: RFR: 8320707: Virtual thread test updates
In-Reply-To: <rNS3FjC-lrCkDaS7D4upOdiVZcqXrtHhzc41R2pOXgM=.8240aa70-7226-4c88-8234-fe7e54a088bf@github.com>
References: <rNS3FjC-lrCkDaS7D4upOdiVZcqXrtHhzc41R2pOXgM=.8240aa70-7226-4c88-8234-fe7e54a088bf@github.com>
Message-ID: <he7bxkLAkieXc-zUTz9P3K6Oc_spp358G4PyTmHJ7iE=.bb607344-087f-4dff-9fbf-03824794bfc7@github.com>

On Sat, 16 Dec 2023 17:25:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> A lot of test changes have accumulated in the loom repo, this includes both new tests and updates to existing tests. Some of these updates can be brought to the main line. This update brings over:
> 
> - The existing tests for pinning use synchronized blocks. In preparation for changes to allow carrier thread be released when a virtual thread parks holding a monitor or blocks on monitorenter, these tests are changed to pin by having a native frame on the stack. This part includes test infrastructure to make it easy to add more tests that do operations while pinned. The tests still test what they were originally created to test of course.
> 
> - The test for the JFR jdk.VirtualThreadPinned event is refactored to allow for additional cases where the event may be reported.
> 
> - ThreadAPI is expanded to cover test for uncaught exception handling.
> 
> - GetStackTraceWhenRunnable is refactored to not use a Selector, otherwise this test will be invalidated when blocking selection operations release the carrier.
> 
> - StressStackOverflow is dialed down to run for 1m instead of 2mins.
> 
> - The use of CountDownLatch in a number of tests that poll thread state has been dropped to keep the tests as simple as possible.

Can you explain your motivation for using AtomicBoolean with a polling loop rather than CountDownLatch(1)? I'm working on a test where I just added a CountDownLatch(1) and am wondering if I should do the same, but I'm not sure if there is something about these tests that is motivating the change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17136#issuecomment-1861578806

From duke at openjdk.org  Mon Dec 18 22:23:55 2023
From: duke at openjdk.org (duke)
Date: Mon, 18 Dec 2023 22:23:55 GMT
Subject: Withdrawn: 8310901: Convert String::newStringNoRepl with Latin-1 to
 String::newStringLatin1NoRepl
In-Reply-To: <GhtOigwdW3GRuBl_ij2FwElObi3JdrvVfe3O6TFYYyY=.98d1da72-d869-4f05-a048-c50950823d18@github.com>
References: <GhtOigwdW3GRuBl_ij2FwElObi3JdrvVfe3O6TFYYyY=.98d1da72-d869-4f05-a048-c50950823d18@github.com>
Message-ID: <l9-XZIS4AYXV1-yXW4JbtDJN8ejSKHEmQsf1ArYtkeA=.6f613997-d386-4818-80a4-f517fc4f8b13@github.com>

On Mon, 26 Jun 2023 15:25:08 GMT, Glavo <duke at openjdk.org> wrote:

> Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`.
> 
> Reasons:
> 
> * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, creating a new shortcut can make writing shorter;
> * Since all possible values of `byte` are legal Latin-1 characters, `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so users can make the compiler happy without using useless try-catch statements.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/14655

From sviswanathan at openjdk.org  Tue Dec 19 00:11:40 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 19 Dec 2023 00:11:40 GMT
Subject: RFR: 8321688: Build on linux with GCC 7.5.0 fails after 8319577
 [v2]
In-Reply-To: <IgVsEyruca5jYomg5OTMjFXt9kBhDS3KTp2prBY9sbQ=.8e140145-a9ed-494b-a10d-f5ffeb2bc142@github.com>
References: <vIByQ06ftSU9o1Rb4YOWXPrry1LkYSj-vJqLXaMXQ5g=.d5a0ea33-f57a-4549-addf-b7a9c5eaa67d@github.com>
 <IgVsEyruca5jYomg5OTMjFXt9kBhDS3KTp2prBY9sbQ=.8e140145-a9ed-494b-a10d-f5ffeb2bc142@github.com>
Message-ID: <s80tBTS2G82fveDiAHU8X2OjxPmXDYp8V0ZB6ShkJN8=.9b7f4c1b-593a-4bf0-8724-2eb5c25b164b@github.com>

On Sun, 17 Dec 2023 13:25:00 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch fixes the building failure introduced by [JDK-8319577](https://bugs.openjdk.org/browse/JDK-8319577) in old GCC version (linux & GCC 7.5.0 locally).
>> 
>> Thanks for the review.
>> 
>>  Best Regards,
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Bump the needed version of GCC.
>  - Revert previous change.
>  - Merge branch 'master' into JDK-8321688
>  - JDK-8321688

Let us restrict the libsimdsort.so build to GCC 8.4.0 with the following change:
`diff --git a/src/java.base/linux/native/libsimdsort/simdsort-support.hpp b/src/java.base/linux/native/libsimdsort/simdsort-support.hpp
index c73fd7920d8..2a2946cff82 100644
--- a/src/java.base/linux/native/libsimdsort/simdsort-support.hpp
+++ b/src/java.base/linux/native/libsimdsort/simdsort-support.hpp
@@ -31,9 +31,9 @@
 #define assert(cond, msg) { if (!(cond)) { fprintf(stderr, "assert fails %s %d: %s\n", __FILE__, __LINE__, msg); abort(); }}


-// GCC >= 7.5 is needed to build AVX2 portions of libsimdsort using C++17 features
-#if defined(_LP64) && (defined(__GNUC__) && ((__GNUC__ > 7) || ((__GNUC__ == 7) && (__GNUC_MINOR__ >= 5))))
+// GCC >= 8.4 is needed to build AVX2 portions of libsimdsort using C++17 features
+#if defined(_LP64) && (defined(__GNUC__) && ((__GNUC__ > 8) || ((__GNUC__ == 8) && (__GNUC_MINOR__ >= 4))))
 #define __SIMDSORT_SUPPORTED_LINUX
 #endif

-#endif //SIMDSORT_SUPPORT_HPP
\ No newline at end of file
+#endif //SIMDSORT_SUPPORT_HPP`
I have verified that with the above change the builds (release, fastdebug, slowdebug) all succeed with GCC 8.4.0 as well as prior GCC like GCC7.5.0 and the test/jdk/java/util/Arrays/Sorting.java passes successfully with these builds.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17047#issuecomment-1861889879

From gli at openjdk.org  Tue Dec 19 02:24:41 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 19 Dec 2023 02:24:41 GMT
Subject: RFR: 8321688: Build on linux with GCC 7.5.0 fails after 8319577
 [v2]
In-Reply-To: <IgVsEyruca5jYomg5OTMjFXt9kBhDS3KTp2prBY9sbQ=.8e140145-a9ed-494b-a10d-f5ffeb2bc142@github.com>
References: <vIByQ06ftSU9o1Rb4YOWXPrry1LkYSj-vJqLXaMXQ5g=.d5a0ea33-f57a-4549-addf-b7a9c5eaa67d@github.com>
 <IgVsEyruca5jYomg5OTMjFXt9kBhDS3KTp2prBY9sbQ=.8e140145-a9ed-494b-a10d-f5ffeb2bc142@github.com>
Message-ID: <u1nX9_G34LVzhPfmQo1w7eTUR5DLF23SBmDKFXeKEGg=.26464d0a-7549-4794-8a5c-c0bd33be6597@github.com>

On Sun, 17 Dec 2023 13:25:00 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch fixes the building failure introduced by [JDK-8319577](https://bugs.openjdk.org/browse/JDK-8319577) in old GCC version (linux & GCC 7.5.0 locally).
>> 
>> Thanks for the review.
>> 
>>  Best Regards,
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Bump the needed version of GCC.
>  - Revert previous change.
>  - Merge branch 'master' into JDK-8321688
>  - JDK-8321688

> Have you tested with gcc 9? Or is this just supposition based on gcc9 having removed the experimental
status for C++17?

I have not tested GCC 8 and 9. @sviswa7 seems to test them.

> I have verified that with the above change the builds (release, fastdebug, slowdebug) all succeed with GCC 8.4.0 as well as prior GCC like GCC7.5.0 and the test/jdk/java/util/Arrays/Sorting.java passes successfully with these builds.

Thanks for your tests. But from the description of the [GCC document](https://gcc.gnu.org/projects/cxx-status.html), shown below, it may be good to skip GCC 8 and use GCC 9 directly if we want to switch to C++17.

>  Some C++17 features are available since GCC 5, but support was experimental and the ABI of C++17 features was not stable until GCC 9.

What do you think about it?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17047#issuecomment-1861998852

From smarks at openjdk.org  Tue Dec 19 03:46:36 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 19 Dec 2023 03:46:36 GMT
Subject: RFR: 8321637: Simplify if statement in ArraysSupport::hugeLength
In-Reply-To: <oMBdVUIKUu5OL4z0RHVOiogWAejQ6Ef7wfsTgKGI6wM=.a7b472b2-7b0a-4066-adfe-bdb00bc91d34@github.com>
References: <oMBdVUIKUu5OL4z0RHVOiogWAejQ6Ef7wfsTgKGI6wM=.a7b472b2-7b0a-4066-adfe-bdb00bc91d34@github.com>
Message-ID: <fAUCu6CenmCUjIUL56IkAc5-6w32AuuyNDDhjfsHjTg=.72d765fb-0d49-484a-9ad1-c503411b88b1@github.com>

On Sat, 9 Dec 2023 23:19:52 GMT, John Jiang <jjiang at openjdk.org> wrote:

> It looks the `else-if` and `else` clauses in method `ArraysSupport::hugeLength` could be simplified by `Math::max`.

This change would make the code shorter, but in my opinion, it obscures what's going on. This code tries to be very careful about avoiding problems caused by integer overflow/wraparound, and in order to do that, it needs to make sure that the full range of int values is handled properly. With the explicit if/else code, this is clear. Using Math.max() instead tends to make this obscure.

This came up previously; see

https://github.com/openjdk/jdk/pull/1617#discussion_r536260884

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17043#issuecomment-1862068604

From jjiang at openjdk.org  Tue Dec 19 03:57:44 2023
From: jjiang at openjdk.org (John Jiang)
Date: Tue, 19 Dec 2023 03:57:44 GMT
Subject: RFR: 8321637: Simplify if statement in ArraysSupport::hugeLength
In-Reply-To: <fAUCu6CenmCUjIUL56IkAc5-6w32AuuyNDDhjfsHjTg=.72d765fb-0d49-484a-9ad1-c503411b88b1@github.com>
References: <oMBdVUIKUu5OL4z0RHVOiogWAejQ6Ef7wfsTgKGI6wM=.a7b472b2-7b0a-4066-adfe-bdb00bc91d34@github.com>
 <fAUCu6CenmCUjIUL56IkAc5-6w32AuuyNDDhjfsHjTg=.72d765fb-0d49-484a-9ad1-c503411b88b1@github.com>
Message-ID: <P1jGaMppyZPg1-C8ndKNop6F8Vv-D6XXsh3obgKX6Ts=.b2baba70-7098-4857-883c-56bceaaa04d8@github.com>

On Tue, 19 Dec 2023 03:44:26 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> It looks the `else-if` and `else` clauses in method `ArraysSupport::hugeLength` could be simplified by `Math::max`.
>
> This change would make the code shorter, but in my opinion, it obscures what's going on. This code tries to be very careful about avoiding problems caused by integer overflow/wraparound, and in order to do that, it needs to make sure that the full range of int values is handled properly. With the explicit if/else code, this is clear. Using Math.max() instead tends to make this obscure.
> 
> This came up previously; see
> 
> https://github.com/openjdk/jdk/pull/1617#discussion_r536260884

@stuart-marks 
Thanks for your clarification!

Just closed this PR and JBS.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17043#issuecomment-1862076153

From jjiang at openjdk.org  Tue Dec 19 03:57:46 2023
From: jjiang at openjdk.org (John Jiang)
Date: Tue, 19 Dec 2023 03:57:46 GMT
Subject: Withdrawn: 8321637: Simplify if statement in ArraysSupport::hugeLength
In-Reply-To: <oMBdVUIKUu5OL4z0RHVOiogWAejQ6Ef7wfsTgKGI6wM=.a7b472b2-7b0a-4066-adfe-bdb00bc91d34@github.com>
References: <oMBdVUIKUu5OL4z0RHVOiogWAejQ6Ef7wfsTgKGI6wM=.a7b472b2-7b0a-4066-adfe-bdb00bc91d34@github.com>
Message-ID: <WR3ESYMc4SvSprUzkyzkl5R4dUKkMfJlw7KI8isPNc8=.4534824d-62f3-495f-8367-7ad08d5a2364@github.com>

On Sat, 9 Dec 2023 23:19:52 GMT, John Jiang <jjiang at openjdk.org> wrote:

> It looks the `else-if` and `else` clauses in method `ArraysSupport::hugeLength` could be simplified by `Math::max`.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/17043

From stuart.marks at oracle.com  Tue Dec 19 04:39:03 2023
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 18 Dec 2023 20:39:03 -0800
Subject: Omission in javadoc Stream.toArray(): Safe array contract
 stipulation
In-Reply-To: <CAK6PxWMmLWkBWemO2E529TDwc1gGiPq6WUK2n+4v0kuP-_f_YQ@mail.gmail.com>
References: <CAK6PxWMmLWkBWemO2E529TDwc1gGiPq6WUK2n+4v0kuP-_f_YQ@mail.gmail.com>
Message-ID: <a6349a1c-c6de-7cc6-a6e2-85a7cd579794@oracle.com>

Hi Reinier,

I see you asked this here as well as on Stack Overflow. I'll repeat my answer from 
Stack Overflow here and then continue with some additional discussion.

Quick recap: Collection::toArray has a requirement that the returned array be 
"safe", whereas Stream::toArray has no such requirement. In my earlier Stack 
Overflow answer (which you quoted) I mentioned something like "if [Stream.toArray] 
were to violate its spec", and you asked, what spec?

My answer:

> I probably mistakenly assumed that the Stream::toArray spec had the same "safety" 
> requirements as Collection::toArray. That was our intent, as I recall, but it 
> didn't make it into the spec. 

Now to your questions in this email.

The second question, where to report this, is right here! We can discuss this and 
file bugs/PRs etc. if necessary depending on the outcome of the discussion.

The first question has some subtlety to it. Should we not update the specification 
for Stream::toArray to have the same "safety" requirement as Collection::toArray?

I guess a change would serve to clarify the specification. The developer of a 
clean-room implementation of streams might reasonably think that, if the stream 
source is an array, that this array can simply be returned from toArray(). However, 
that violates the intent (which is pretty clear in my memory) that the returned 
array be freshly created. Usually, adding assertions to interfaces creates a danger 
of invalidating existing implementations. However, I don't think returning an 
existing array, especially one that might be aliased, was ever considered to be 
valid behavior. Thus, a spec change would be more like filling a gap that shouldn't 
have been there in the first place, not adding a new semantic requirement.

As a practical matter, there are few third-party implementations, this requirement 
is almost impossible to test, and any callers of toArray() won't change. That is, if 
they're currently using the returned array, they'll continue using it; but if they 
want 100% assurance the array isn't aliased, they'll continue to make a defensive 
copy. So, it doesn't seem like changing the spec will have any practical impact.

Have I answered your questions?

s'marks


On 12/14/23 5:46 AM, Reinier Zwitserloot wrote:
> Hi core libs team,
>
> I think I found a rather inconsequential and esoteric bug, though the term is 
> somewhat less objectively defined when the problem exists solely in how complete 
> some method?s javadoc is.
>
> Two questions: Is there a plausible argument that the javadoc as is, shouldn?t be 
> updated? If not, what?s the right place to report this javadoc ?bug??
>
> The issue:
>
> A snippet of the javadoc of Collection.toArray, from current HEAD jdk22u:
>
> ? ? <p>The returned array will be "safe" in that no references to it are
> ? ? ?* maintained by this collection. ?(In other words, this method must
> ? ? ?* allocate a new array even if this collection is backed by an array).
> ? ? ?* The caller is thus free to modify the returned array.
>
> The javadoc of Stream.toArray, from current HEAD jdk22u - has no such rider 
> anywhere in its documentation nor on the javadoc of the Stream interface, nor on 
> the package javadoc. The javadoc is quite short; the complete docs on toArray():
>
> ? ? ?/**
> ? ? ?* Returns an array containing the elements of this stream.
> ? ? ?*
> ? ? ?* <p>This is a <a href="package-summary.html#StreamOps">terminal
> ? ? ?* operation</a>.
> ? ? ?*
> ? ? ?* @return an array, whose {@linkplain Class#getComponentType runtime component
> ? ? ?* type} is {@code Object}, containing the elements of this stream
> ? ? ?*/
>
> The more usually used variant taking a function that makes the array has slightly 
> longer javadoc, but it similarly makes no mention whatsoever about the contract 
> stipulation that any implementors must not keep a reference.
>
> A snippet from Stuart Marks on a stack overflow question about a to the asker 
> weird choice about stream?s toList()?s default implementation 
> (https://stackoverflow.com/questions/77473755/is-it-necessary-to-copy-a-list-to-be-safe/77474199?noredirect=1#comment136909551_77474199):
>
> @Holger The extra step in the default implementation is there to force a defensive 
> copy if |this.toArray|?were to violate its spec and keep a reference to the 
> returned array. Without the defensive copy, it would be possible to modify the 
> list returned from the default |toList|?implementation.
>
>
> Which leads to the obvious question: Where is that ?spec? that Stuart is referring 
> to? Either the javadoc is the spec and therefore the javadoc is buggy, in that it 
> fails to mention this stipulation, or the spec is elsewhere, in which case surely 
> the javadoc should link to it or copy it.
>
> Possibly this is jus filed away as: ?Unlike with Collection, Stream instances are 
> disposable; after a terminal operation (and toArray is terminal) has been invoked 
> on it, that stream object has ceased being useful. Therefore, there is no 
> perceived value to caching any created array, therefore, it doesn?t need mentioning".
>
> Except, as per Stuart?s comment, actual OpenJDK code is written partly to deal 
> with any violators of this invisible spec, and the discrepancy (where 
> Collection.toArray explicitly mentions the contract stipulation that toArray() 
> must make safe arrays, but Stream?s toArray() does not) suggests a fundamental 
> difference where none exists (in fact, literally: Apparently its a spec violation 
> if your Stream implementation return a non-safe array from toArray!)
>
> ?--Reinier Zwitserloot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20231218/0ed8f846/attachment-0001.htm>

From hgreule at openjdk.org  Tue Dec 19 06:10:37 2023
From: hgreule at openjdk.org (Hannes Greule)
Date: Tue, 19 Dec 2023 06:10:37 GMT
Subject: RFR: 8322292: Rearrange comparison of fields in Record.equals()
In-Reply-To: <eNySqrZ9HgZrjF61lHA_6YecuPT7RB9xxz82U3zIjog=.f8b68ce5-3fab-4cfa-8709-17e51d77a958@github.com>
References: <eNySqrZ9HgZrjF61lHA_6YecuPT7RB9xxz82U3zIjog=.f8b68ce5-3fab-4cfa-8709-17e51d77a958@github.com>
Message-ID: <eqkuO0tHexUhpYZIwZjJMqT8JQzU8nXFwQ9sWvqj0gQ=.01df9224-992c-4e40-ba51-33c6f4ff7eec@github.com>

On Mon, 18 Dec 2023 13:42:35 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Currently if we create a record it's fields are compared in their declaration order. This might be ineffective in cases when two objects have "heavy" fields equals to each other, but different "lightweight" fields (heavy and lightweight in terms of comparison) e.g. primitives, enums, nullable/non-nulls etc.
> 
> If we have declared a record like
> 
> public record MyRecord(String field1, int field2) {}
> 
> It's equals() looks like:
> 
>   public final equals(Ljava/lang/Object;)Z
>    L0
>     LINENUMBER 3 L0
>     ALOAD 0
>     ALOAD 1
>     INVOKEDYNAMIC equals(Lcom/caspianone/openbanking/productservice/controller/MyRecord;Ljava/lang/Object;)Z [
>       // handle kind 0x6 : INVOKESTATIC
>       java/lang/runtime/ObjectMethods.bootstrap(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/TypeDescriptor;Ljava/lang/Class;Ljava/lang/String;[Ljava/lang/invoke/MethodHandle;)Ljava/lang/Object;
>       // arguments:
>       com.caspianone.openbanking.productservice.controller.MyRecord.class,
>       "field1;field2",
>       // handle kind 0x1 : GETFIELD
>       com/caspianone/openbanking/productservice/controller/MyRecord.field1(Ljava/lang/String;),
>       // handle kind 0x1 : GETFIELD
>       com/caspianone/openbanking/productservice/controller/MyRecord.field2(I)
>     ]
>     IRETURN
>    L1
>     LOCALVARIABLE this Lcom/caspianone/openbanking/productservice/controller/MyRecord; L0 L1 0
>     LOCALVARIABLE o Ljava/lang/Object; L0 L1 1
>     MAXSTACK = 2
>     MAXLOCALS = 2
> 
> This can be improved by rearranging the comparison order of the fields moving enums and primitives upper, and collections/arrays lower.

Generally, this is a good idea. A few comments:

1. Arrays are compared by reference rather than element-wise, so they should/could be at the beginning similar to enums, not at the end.
2. You are sorting the array passed to the bootstrap method. This might be observable to callers, potentially causing problems, especially when e.g. creating the method handle for equals first, and then for toString with the same array.
3. What's the test situation here? Is there enough coverage for things like that already?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17143#issuecomment-1862179369

From duke at openjdk.org  Tue Dec 19 08:14:38 2023
From: duke at openjdk.org (Bernd)
Date: Tue, 19 Dec 2023 08:14:38 GMT
Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available()
 test for end-of-stream [v4]
In-Reply-To: <DnjQ9xoaQdr5XloN4Ayr6uBvuMdmUL_iUhYPrilPMbk=.dad11855-f2b1-434f-8c56-fdde644ee9ad@github.com>
References: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
 <TJ8loA9R1Kf_GxXw9lR-XLW-xqjrkPhdCnZFwFExG1A=.e3d52b42-d008-4841-b979-88d88f04b525@github.com>
 <HXXiM-MGVLXh3gv7Abs4dd3ipgQqsWdCzPjfK-fG8CI=.584a80cc-9f8f-45f8-817c-54e3eaf468fc@github.com>
 <DnjQ9xoaQdr5XloN4Ayr6uBvuMdmUL_iUhYPrilPMbk=.dad11855-f2b1-434f-8c56-fdde644ee9ad@github.com>
Message-ID: <W9j_Me4qREmkU9yuC7XTC59gESkiF0rOsUKy8vvrwyI=.7abc9827-b987-4bff-8f5c-ce5ce1a758f0@github.com>

On Sat, 16 Dec 2023 17:48:39 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> If what you're saying is "Previously we were implicitly verifying that the data reported by `available()` was actually there, and now we're no longer verifying that" then that's not correct.

I mean it verified the non-zero behavior, not that the data length was correct. Not sure if that is somewhere tested now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17113#issuecomment-1862300414

From alanb at openjdk.org  Tue Dec 19 09:18:39 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 19 Dec 2023 09:18:39 GMT
Subject: RFR: 8320707: Virtual thread test updates
In-Reply-To: <he7bxkLAkieXc-zUTz9P3K6Oc_spp358G4PyTmHJ7iE=.bb607344-087f-4dff-9fbf-03824794bfc7@github.com>
References: <rNS3FjC-lrCkDaS7D4upOdiVZcqXrtHhzc41R2pOXgM=.8240aa70-7226-4c88-8234-fe7e54a088bf@github.com>
 <he7bxkLAkieXc-zUTz9P3K6Oc_spp358G4PyTmHJ7iE=.bb607344-087f-4dff-9fbf-03824794bfc7@github.com>
Message-ID: <-J_DKfk6g-qoYrPZcs-mdUUAG_wnsMzle2aZQhdXps4=.53d1ae20-503b-4b01-94c8-a10421e5405d@github.com>

On Mon, 18 Dec 2023 20:37:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I'm working on a test where I just added a CountDownLatch(1) and am wondering if I should do the same, but I'm not sure if there is something about these tests that is motivating the change.

CountDownLatch is great for many tests. It's not as powerful as a Phaser of course but good enough and usually easy to understand quickly what is going on. However, for tests that are testing thread state then you often want to have as few dependencies as possible. In the case of CountDownlatch, the await method may park. The countDown method may have to unpark waiters for for virtual threads it means potentially parking (to queue a task) when unparking, so temporary transitions that JVMTI has to be concerned with. The other thing is keeping tests simple/consistent, it can be hard to maintain tests where one test method coordinates with one approach, another test method does something different.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17136#issuecomment-1862390382

From jai.forums2013 at gmail.com  Tue Dec 19 09:40:30 2023
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Tue, 19 Dec 2023 15:10:30 +0530
Subject: Should Class.name field be @Stable?
In-Reply-To: <CABe8uE0+5Te8yvZgUrkHn3miY9QF6Z_Cv6=O-+HQ_78SM8C1ww@mail.gmail.com>
References: <CABe8uE0+5Te8yvZgUrkHn3miY9QF6Z_Cv6=O-+HQ_78SM8C1ww@mail.gmail.com>
Message-ID: <3e19a48a-940a-4625-909f-f446304b70b5@gmail.com>

Hello Chen,

Looking at the implementation of java.lang.Class.getName(), which then 
triggers the hotspot code to initialize this "name" field, I suspect 
there will be a (harmless) race in the hotspot implementation where more 
than one thread could end up writing the "name" field (with the same 
value of course) 
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/classfile/javaClasses.cpp#L1237. 
I don't know how the JVM would then react if such a field is marked 
@Stable (the javadoc of @Stable states that the behaviour is such cases 
is undefined).

-Jaikiran

On 16/12/23 8:37 pm, - wrote:
> Hello,
> I just noticed the Class.name field is mutable but not @Stable, 
> meaning `Class.getName()` calls are not eligible for constant folding.
>
> The last update to this field is in 2019 in JDK-8216302 when the field 
> initialization was done directly by a write from hotspot code (for the 
> class name is interned anyways, though interning limits scalability of 
> hidden classes)
>
> Would it be a good idea to submit a patch to mark this field?@Stable? 
> Given class names may be?frequently used to quickly identify a class, 
> to create descriptors.
>
> Chen Liang
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20231219/fd893068/attachment-0001.htm>

From stsypanov at openjdk.org  Tue Dec 19 09:44:49 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 19 Dec 2023 09:44:49 GMT
Subject: RFR: 8322292: Rearrange comparison of fields in Record.equals()
 [v2]
In-Reply-To: <eNySqrZ9HgZrjF61lHA_6YecuPT7RB9xxz82U3zIjog=.f8b68ce5-3fab-4cfa-8709-17e51d77a958@github.com>
References: <eNySqrZ9HgZrjF61lHA_6YecuPT7RB9xxz82U3zIjog=.f8b68ce5-3fab-4cfa-8709-17e51d77a958@github.com>
Message-ID: <6yZOiX1Kc-ZyO0embh4OSa5lHpVCRLH6EOL5X14suFA=.48a5a97c-a04b-4ab7-82ed-66e3565778e7@github.com>

> Currently if we create a record it's fields are compared in their declaration order. This might be ineffective in cases when two objects have "heavy" fields equals to each other, but different "lightweight" fields (heavy and lightweight in terms of comparison) e.g. primitives, enums, nullable/non-nulls etc.
> 
> If we have declared a record like
> 
> public record MyRecord(String field1, int field2) {}
> 
> It's equals() looks like:
> 
>   public final equals(Ljava/lang/Object;)Z
>    L0
>     LINENUMBER 3 L0
>     ALOAD 0
>     ALOAD 1
>     INVOKEDYNAMIC equals(Lcom/caspianone/openbanking/productservice/controller/MyRecord;Ljava/lang/Object;)Z [
>       // handle kind 0x6 : INVOKESTATIC
>       java/lang/runtime/ObjectMethods.bootstrap(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/TypeDescriptor;Ljava/lang/Class;Ljava/lang/String;[Ljava/lang/invoke/MethodHandle;)Ljava/lang/Object;
>       // arguments:
>       com.caspianone.openbanking.productservice.controller.MyRecord.class,
>       "field1;field2",
>       // handle kind 0x1 : GETFIELD
>       com/caspianone/openbanking/productservice/controller/MyRecord.field1(Ljava/lang/String;),
>       // handle kind 0x1 : GETFIELD
>       com/caspianone/openbanking/productservice/controller/MyRecord.field2(I)
>     ]
>     IRETURN
>    L1
>     LOCALVARIABLE this Lcom/caspianone/openbanking/productservice/controller/MyRecord; L0 L1 0
>     LOCALVARIABLE o Ljava/lang/Object; L0 L1 1
>     MAXSTACK = 2
>     MAXLOCALS = 2
> 
> This can be improved by rearranging the comparison order of the fields moving enums and primitives upper, and collections/arrays lower.

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  8322292: Use copy

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17143/files
  - new: https://git.openjdk.org/jdk/pull/17143/files/26c4428c..988601b3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17143&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17143&range=00-01

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17143/head:pull/17143

PR: https://git.openjdk.org/jdk/pull/17143

From stsypanov at openjdk.org  Tue Dec 19 09:44:50 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 19 Dec 2023 09:44:50 GMT
Subject: RFR: 8322292: Rearrange comparison of fields in Record.equals()
In-Reply-To: <eqkuO0tHexUhpYZIwZjJMqT8JQzU8nXFwQ9sWvqj0gQ=.01df9224-992c-4e40-ba51-33c6f4ff7eec@github.com>
References: <eNySqrZ9HgZrjF61lHA_6YecuPT7RB9xxz82U3zIjog=.f8b68ce5-3fab-4cfa-8709-17e51d77a958@github.com>
 <eqkuO0tHexUhpYZIwZjJMqT8JQzU8nXFwQ9sWvqj0gQ=.01df9224-992c-4e40-ba51-33c6f4ff7eec@github.com>
Message-ID: <EvBE54cgMGXSXuRwZ0cdP8et1XDQOLE7Ml4DrVwVQL4=.72de2396-1c17-4363-9c75-1b3534d319df@github.com>

On Tue, 19 Dec 2023 06:07:31 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

> Arrays are compared by reference

Isn't `Arrays.equals()` used under the hood?

> You are sorting the array passed to the bootstrap method

Good point, fixed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17143#issuecomment-1862429275

From stsypanov at openjdk.org  Tue Dec 19 10:18:13 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 19 Dec 2023 10:18:13 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v15]
In-Reply-To: <mOFTUALYYY7dLlbzIL7BqI0RsmohLvlNCtEcZ7k_pzk=.b043a248-54bb-4368-9480-e6e3fe510b14@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <8SYx9TqaT4rL2o4BZ_Fnu_ZxD3vVMdYJS51dtGMK22I=.4b226895-ec4a-49bc-ab1a-c46a2e290405@github.com>
 <mOFTUALYYY7dLlbzIL7BqI0RsmohLvlNCtEcZ7k_pzk=.b043a248-54bb-4368-9480-e6e3fe510b14@github.com>
Message-ID: <tU4DhOPRjlWrTO-Zn-AfSlQ_OJFuRRViHzI1Z1ZpeMs=.520ee229-ebec-4e88-9818-d544400d8949@github.com>

On Sat, 16 Dec 2023 17:51:30 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8320971: Revert irrelevant changes
>
> test/jdk/java/io/BufferedInputStream/TransferToTrusted.java line 85:
> 
>> 83:     }
>> 84: 
>> 85:     private static void byteArrayOutputStream(BufferedInputStream bis, byte[] buf) throws IOException {
> 
> As we agreed that this PR shall only cover BIS, we can remove the additional classes' tests again.

Shouldn't we keep at least the method for the classes checked in `BIS.isTrusted()` (`ByteArrayOutputStream`, `FileOutputStream`, `PipedOutputStream`)?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1431195222

From stsypanov at openjdk.org  Tue Dec 19 10:18:11 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 19 Dec 2023 10:18:11 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v16]
In-Reply-To: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
Message-ID: <UYDhC9MD9jt1n_3Y6Hoc29AYEAaoRX5f0WlDr5sUNxY=.5251f559-ec37-4c96-86a4-b537d0ce40ee@github.com>

> It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`.
> 
> See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612

Sergey Tsypanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision:

 - 8322292: Remove TransferToTrusted.checkedOutputStream()
 - 8320971: Adjust JavaDoc
 - Merge branch 'master' into 8320971
 - 8320971: Revert irrelevant changes
 - 8320971: Add more tests
 - 8320971: Fix JavaDoc
 - 8320971: Whitespaces
 - 8320971: Fix build
 - 8320971: Move IOStreams to com.sun.io
 - Merge branch 'master' into 8320971
 - ... and 10 more: https://git.openjdk.org/jdk/compare/b8f084e1...84686bc6

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16879/files
  - new: https://git.openjdk.org/jdk/pull/16879/files/8626e926..84686bc6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16879&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16879&range=14-15

  Stats: 3675 lines in 269 files changed: 2030 ins; 696 del; 949 mod
  Patch: https://git.openjdk.org/jdk/pull/16879.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16879/head:pull/16879

PR: https://git.openjdk.org/jdk/pull/16879

From egahlin at openjdk.org  Tue Dec 19 10:47:43 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 19 Dec 2023 10:47:43 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v3]
In-Reply-To: <_8M6KPN0UJHeW1cx31IW0mIfaXG5ls5nUfZ0TwxMdAs=.fd4facc4-91d4-4117-9b1f-a2cc1806d2b7@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <_8M6KPN0UJHeW1cx31IW0mIfaXG5ls5nUfZ0TwxMdAs=.fd4facc4-91d4-4117-9b1f-a2cc1806d2b7@github.com>
Message-ID: <gOPRdEq2C_00uEZZZ7lbNIOPX691FD56u5AwpCgvv3A=.dfd20a18-b42a-49bd-b8e6-9b6b5ea3375f@github.com>

On Mon, 18 Dec 2023 17:49:04 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Event enabled on profile.jfc but disabled on default.jfc.

src/jdk.jfr/share/classes/jdk/jfr/events/SerializationMisdeclarationEvent.java line 41:

> 39: @Description("Methods and fields misdeclarations")
> 40: @MirrorEvent(className = "jdk.internal.event.SerializationMisdeclarationEvent")
> 41: @RemoveFields({"duration", "stackTrace", "thread"})

The field should be "eventThread" instead of "thread"

src/jdk.jfr/share/classes/jdk/jfr/events/SerializationMisdeclarationEvent.java line 45:

> 43: 
> 44:     @Label("Class")
> 45:     public Class<?> cls;

We have often used a prefix, i.e. misdeclaredClass, to avoid using a reserved word. We try to stay out of abbreviations.

src/jdk.jfr/share/classes/jdk/jfr/events/SerializationMisdeclarationEvent.java line 48:

> 46: 
> 47:     @Label("Kind")
> 48:     public int kind;

What is the use case for error codes? Are they public or an implementation detail?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431226200
PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431227843
PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431229900

From hgreule at openjdk.org  Tue Dec 19 11:03:37 2023
From: hgreule at openjdk.org (Hannes Greule)
Date: Tue, 19 Dec 2023 11:03:37 GMT
Subject: RFR: 8322292: Rearrange comparison of fields in Record.equals()
In-Reply-To: <EvBE54cgMGXSXuRwZ0cdP8et1XDQOLE7Ml4DrVwVQL4=.72de2396-1c17-4363-9c75-1b3534d319df@github.com>
References: <eNySqrZ9HgZrjF61lHA_6YecuPT7RB9xxz82U3zIjog=.f8b68ce5-3fab-4cfa-8709-17e51d77a958@github.com>
 <eqkuO0tHexUhpYZIwZjJMqT8JQzU8nXFwQ9sWvqj0gQ=.01df9224-992c-4e40-ba51-33c6f4ff7eec@github.com>
 <EvBE54cgMGXSXuRwZ0cdP8et1XDQOLE7Ml4DrVwVQL4=.72de2396-1c17-4363-9c75-1b3534d319df@github.com>
Message-ID: <rMhVI_GVA4keqohYuyRbV2Jl5hvkrmMBQ4wOEc78oZM=.0ed6c153-e711-4032-baf1-748b79bc48b8@github.com>

On Tue, 19 Dec 2023 09:41:45 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Isn't `Arrays.equals()` used under the hood?

The JLS and the API spec don't mention any special-casing of arrays, and the code seems to use `Objects.equals` for all non-primitive types: https://github.com/openjdk/jdk/blob/988601b324c971daf4e537074a007c25059af91b/src/java.base/share/classes/java/lang/runtime/ObjectMethods.java#L183-L187

(side note, it seems like `OBJECT_EQUALS` is unused?)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17143#issuecomment-1862550269

From rgiulietti at openjdk.org  Tue Dec 19 12:21:05 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 19 Dec 2023 12:21:05 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v4]
In-Reply-To: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
Message-ID: <XlnL2mY6CwDlnA_KPw-IRVx9QAJaXKEaS0cnMfc_0xk=.7783dbb7-3988-4319-9b85-2ac45fc26759@github.com>

> Adds serialization misdeclaration events to JFR.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Better name for a label, corrected name of removed field.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17129/files
  - new: https://git.openjdk.org/jdk/pull/17129/files/8534d7af..51507e4e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17129.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17129/head:pull/17129

PR: https://git.openjdk.org/jdk/pull/17129

From rgiulietti at openjdk.org  Tue Dec 19 12:21:09 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 19 Dec 2023 12:21:09 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v3]
In-Reply-To: <gOPRdEq2C_00uEZZZ7lbNIOPX691FD56u5AwpCgvv3A=.dfd20a18-b42a-49bd-b8e6-9b6b5ea3375f@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <_8M6KPN0UJHeW1cx31IW0mIfaXG5ls5nUfZ0TwxMdAs=.fd4facc4-91d4-4117-9b1f-a2cc1806d2b7@github.com>
 <gOPRdEq2C_00uEZZZ7lbNIOPX691FD56u5AwpCgvv3A=.dfd20a18-b42a-49bd-b8e6-9b6b5ea3375f@github.com>
Message-ID: <e7BeWWxzk-MqiZ4b0QMrnV_UhhjKFtZgUBzkV2wqX_M=.d65e9ba0-c1ed-43d9-a50c-b8452c537d75@github.com>

On Tue, 19 Dec 2023 10:43:57 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Event enabled on profile.jfc but disabled on default.jfc.
>
> src/jdk.jfr/share/classes/jdk/jfr/events/SerializationMisdeclarationEvent.java line 48:
> 
>> 46: 
>> 47:     @Label("Kind")
>> 48:     public int kind;
> 
> What is the use case for error codes? Are they public or an implementation detail?

The intent is that they are stable and for programmatic usage, whereas the message is more for human consumption. The codes are used in the test, for example, and are declared as public static in the event classes.

Alternatively, one could parse the message, but that's less robust in face of changes, I think.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431329983

From goetz at openjdk.org  Tue Dec 19 12:54:56 2023
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Tue, 19 Dec 2023 12:54:56 GMT
Subject: RFR: 8320798: Console read line with zero out should zero out when
 throwing exception
Message-ID: <OQ2mDsSWRLfNxXO0BapseECzeKY91cHesHXBQNKwNDU=.17212cbf-e920-4b99-8f70-8056f1d14fc3@github.com>

?g exception

After leaving the method by throwing an exception the data can not be cleaned any more.

-------------

Commit messages:
 - 8320798: Console read line with zero out should zero out when throwing exception

Changes: https://git.openjdk.org/jdk/pull/17156/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17156&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8320798
  Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17156.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17156/head:pull/17156

PR: https://git.openjdk.org/jdk/pull/17156

From jpai at openjdk.org  Tue Dec 19 14:23:37 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 19 Dec 2023 14:23:37 GMT
Subject: RFR: 8318971 : Better Error Handling for Jar Tool Processing of
 "@File"
In-Reply-To: <xht1jEn-KP8Fhz4Xa4MBxlhsvlxk3mdAkpdv9dF77oQ=.3fdc9a36-e7da-4230-9b26-40dacb8e92b6@github.com>
References: <xht1jEn-KP8Fhz4Xa4MBxlhsvlxk3mdAkpdv9dF77oQ=.3fdc9a36-e7da-4230-9b26-40dacb8e92b6@github.com>
Message-ID: <npJJHMmh-skT-OJE_GimMDhb7VsVfxb4GJT64RqeVug=.1bf86e21-e67d-4a14-a3ac-41c6eb014735@github.com>

On Wed, 13 Dec 2023 18:16:56 GMT, Weibing Xiao <duke at openjdk.org> wrote:

> Better Error Handling for Jar Tool Processing of "@File" <br>
> 
> This is a new PR for this PR since the original developer left the team. See all of the review history at https://github.com/openjdk/jdk/pull/16423.
> 
> Thank you.

Hello Weibing, I had another look at this today. The implementation change looks OK. But I think the JBS issue summary and the JBS issue description will need to be updated.

The real issue here isn't specific to the use of `@file` by the `jar` tool. Instead the issue is about an internal detail of the `jar` tool implementation. When the `jar` tool is launched either to create (`-c`) or to update (`-u`) a jar file, it gets passed a list of files to include/update the jar file with. One way to pass those options is literally as part of the command. The other way is to include those files path in a separate file and pass that file to the `jar` tool as the `@that-other-file`. The issue here affects both those variants.

The internal implementation of the `jar` tool in `sun/tools/jar/Main.java`, uses a flag called `ok` to keep track of whether there was any error during the `jar` tool action processing. This `ok` flagged is marked by various methods that get invoked during the `jar` processing. 

When `-c` or `-u` options are passed to the `jar` tool, the `sun/tools/jar/Main.java` calls an internal method `expand()`. This method is responsible for finalizing the files that need to be included in the jar that gets created or updated. This expand method is also responsible for marking that `ok` flag if there are any errors (like any file that was specified to be included/updated in the jar, is missing).  Once the `expand()` method returns, the internal implementation detail of the `jar` tool will go ahead and create a temporary file. Content will be written out to this temporary files. The more entries to create in the final jar being created/updated, the more time and more disk space this temporary file will consume. Finally, when writing out to the temporary file is done, the `ok` flag is checked to see if it was flagged as failed. If `ok` says no errors were noticed, then the temporary file that was created will be moved as the final jar that had to be created/updated. If `o
 k` said that there were failures, then the temporary file is deleted and the final jar to be created won't get created (rightly so) nor will the final jar get updated, in case of `-u` option (rightly so).

The issue here is that if the `expand()` method noticed that there was an error with the provided file paths (like 1 out of the 5 files specified is missing), then it marks the `ok` flag to indicate that, but the current implementation of the `jar` tool (before the change in this PR) just doesn't check the flag and goes on to do the expensive work of creating a temporary file (which will have the rest of the 4 files) and that temporary file will then finally get discarded at the end. This entire process of creating the temporary file can be avoided by checking the `ok` flag after the `expand()` method returns. That is what the proposal in the PR does and I think it looks good.

Given that, I think the JBS issue summary and the description doesn't match what we are doing here. Would you be able to update those accordingly? If you want me to do that, do let me know and you can then update this PR title.

As for the new test method introduced in this PR, in the existing `InputFilesTest`, it took me a while to understand what exactly this was doing. One part of it is due to a bit misleading method names - for example, `println()` method which going by that name, I thought was printing a new line (I didn't understand why) but turns out that method actually prints out the output that has been captured in a `ByteArrayOutputStream` by a  previous invocation of the `jar` tool from within the test method. That `println()` method has been that way even before the changes in this PR, so I think that is OK (unless you won't mind updating the name to something better?).

This existing `InputFilesTest` runs various tests for the `jar` tool by passing it file paths to be included/updated in the jar. It currently doesn't have any coverage for `@file` usages, so this new test method is adding that. However, this new test method isn't exercising the case where one or more file paths specified in the passed `@file` are missing. So it isn't exactly exercising the issue that is being fixed. I think the test you added is OK as a positive test (where all passed file paths are present), but I think we would also need one for missing files and then assert in that test that the final jar isn't created or updated and the `jar` tool returns a non-zero exit code. Please also add some comments to the newly introduced test methods to make it easier to understand what they are testing.

While at it, could you also please check if the `@file` usage has test coverage from some other existing test class? I am bit surprised that this `InputFilesTest` doesn't have any, so maybe it's tested elsewhere?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17088#issuecomment-1862849864

From jpai at openjdk.org  Tue Dec 19 14:42:49 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 19 Dec 2023 14:42:49 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v4]
In-Reply-To: <XlnL2mY6CwDlnA_KPw-IRVx9QAJaXKEaS0cnMfc_0xk=.7783dbb7-3988-4319-9b85-2ac45fc26759@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <XlnL2mY6CwDlnA_KPw-IRVx9QAJaXKEaS0cnMfc_0xk=.7783dbb7-3988-4319-9b85-2ac45fc26759@github.com>
Message-ID: <e-xe6KF01q-kqiws3Lh6OOm0gbyV-NAh9fkSt22ASxY=.a022fa86-4c0b-484b-997d-cc92a1e45247@github.com>

On Tue, 19 Dec 2023 12:21:05 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Better name for a label, corrected name of removed field.

Hello Raffaello, 

> On the other hand, the checks and the events generation are done for serializable classes that actually actively participate in serialization, lazily, and just once per class

Is it per class for each classloader that loads it? Or is it per class per JVM? It's more out of curiosity than anything else because I don't think it makes a big difference (I don't expect too many classloaders that would lead to the case of extremely large streams of events).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17129#issuecomment-1862882260

From mbaesken at openjdk.org  Tue Dec 19 14:43:37 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 19 Dec 2023 14:43:37 GMT
Subject: RFR: 8322417: Console read line with zero out should zero out when
 throwing exception
In-Reply-To: <OQ2mDsSWRLfNxXO0BapseECzeKY91cHesHXBQNKwNDU=.17212cbf-e920-4b99-8f70-8056f1d14fc3@github.com>
References: <OQ2mDsSWRLfNxXO0BapseECzeKY91cHesHXBQNKwNDU=.17212cbf-e920-4b99-8f70-8056f1d14fc3@github.com>
Message-ID: <ISHGAWuxdZoJMZYKU4Tw90JEx_SK1vdK_uY15c51QWQ=.a04021c5-846c-48f6-a014-5a3daf8f504a@github.com>

On Tue, 19 Dec 2023 12:47:53 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

> ?g exception
> 
> After leaving the method by throwing an exception the data can not be cleaned any more.

Marked as reviewed by mbaesken (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17156#pullrequestreview-1789017684

From rriggs at openjdk.org  Tue Dec 19 14:49:48 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Dec 2023 14:49:48 GMT
Subject: [jdk22] RFR: 8321514: UTF16 string gets constructed incorrectly
 from codepoints if CompactStrings is not enabled
In-Reply-To: <qYnMiDf6o6CjptzNwcIKfI9JJY-9wVn5gFonPB2_Aos=.4b4690ad-95da-4443-afd8-7e0cd473e33f@github.com>
References: <qYnMiDf6o6CjptzNwcIKfI9JJY-9wVn5gFonPB2_Aos=.4b4690ad-95da-4443-afd8-7e0cd473e33f@github.com>
Message-ID: <nBjQMyGj_tt9FLorfLNfm73y9EyMvc380OTThd0RigU=.9bf2a7ac-7ab8-4735-a44e-682b8c2cb7c0@github.com>

On Mon, 18 Dec 2023 11:56:50 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [fde5b168](https://github.com/openjdk/jdk/commit/fde5b16817c3263236993f2e8c2d2469610d99bd) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Aleksei Voitylov on 14 Dec 2023 and was reviewed by Roger Riggs.
> 
> Thanks!

Identical to mainline commit. Looks good

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk22/pull/18#pullrequestreview-1789030091

From jpai at openjdk.org  Tue Dec 19 14:55:50 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 19 Dec 2023 14:55:50 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v4]
In-Reply-To: <XlnL2mY6CwDlnA_KPw-IRVx9QAJaXKEaS0cnMfc_0xk=.7783dbb7-3988-4319-9b85-2ac45fc26759@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <XlnL2mY6CwDlnA_KPw-IRVx9QAJaXKEaS0cnMfc_0xk=.7783dbb7-3988-4319-9b85-2ac45fc26759@github.com>
Message-ID: <aKBHI3OVWXcRhVfKozoTP3DMsSarybVVja87AqB2Kms=.864e45be-abe6-4a81-9a51-5cae875b3195@github.com>

On Tue, 19 Dec 2023 12:21:05 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Better name for a label, corrected name of removed field.

src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 94:

> 92:         if (!isPrivate(f)) {
> 93:             commitEvent(SUID_PRIVATE,
> 94:                     SUID_NAME + " should be declared private");

Rest of the event messages use "... to be effective", should this one too use a similar text?

src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 108:

> 106:                     SUID_NAME + " should be declared of type long");
> 107:         }
> 108:         if (!isStatic(f)) {

Nit - perhaps save the return value from the previous call to `isStatic(f)` a few lines above and reuse it here?

src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 112:

> 110:         }
> 111:         f.setAccessible(true);
> 112:         if (getLong(f) == null) {

Is this check and the `setAccessible()` needed if a few lines above, the call to `f.getType()` returns `Long.TYPE` (i.e. primitive type)? Perhaps we can conditionally do these additional checks and calls, only if `f.getType()` isn't a primitive?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431512491
PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431506705
PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431511005

From jpai at openjdk.org  Tue Dec 19 15:04:51 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 19 Dec 2023 15:04:51 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v4]
In-Reply-To: <XlnL2mY6CwDlnA_KPw-IRVx9QAJaXKEaS0cnMfc_0xk=.7783dbb7-3988-4319-9b85-2ac45fc26759@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <XlnL2mY6CwDlnA_KPw-IRVx9QAJaXKEaS0cnMfc_0xk=.7783dbb7-3988-4319-9b85-2ac45fc26759@github.com>
Message-ID: <S3vzd7U-RB9SGnkJBaynMWc58nVn9bMD36Kqo9PEFVw=.d1f15a03-e713-48d1-b13d-f7cc95940878@github.com>

On Tue, 19 Dec 2023 12:21:05 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Better name for a label, corrected name of removed field.

src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 185:

> 183:             commitEvent(PRIV_METH_NON_STATIC,
> 184:                     m + " must be non-static to be effective");
> 185:         }

Should there also be a check to see if this `private` method is (misdeclared) as a `native` method?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431524703

From jpai at openjdk.org  Tue Dec 19 15:07:51 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 19 Dec 2023 15:07:51 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v4]
In-Reply-To: <XlnL2mY6CwDlnA_KPw-IRVx9QAJaXKEaS0cnMfc_0xk=.7783dbb7-3988-4319-9b85-2ac45fc26759@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <XlnL2mY6CwDlnA_KPw-IRVx9QAJaXKEaS0cnMfc_0xk=.7783dbb7-3988-4319-9b85-2ac45fc26759@github.com>
Message-ID: <XxxdrD61sYmwoKhKzW7eoAnWxkA2mIPdx3zz0btaz_0=.701adb15-8a99-4a32-a2e7-492c774b83ba@github.com>

On Tue, 19 Dec 2023 12:21:05 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Better name for a label, corrected name of removed field.

src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 276:

> 274:     }
> 275: 
> 276:     private static Object getObject(Field f) {

Should we call this method `getStaticFieldValue(...)`, because that's what the implementation is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431535049

From jpai at openjdk.org  Tue Dec 19 15:13:50 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 19 Dec 2023 15:13:50 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v4]
In-Reply-To: <XlnL2mY6CwDlnA_KPw-IRVx9QAJaXKEaS0cnMfc_0xk=.7783dbb7-3988-4319-9b85-2ac45fc26759@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <XlnL2mY6CwDlnA_KPw-IRVx9QAJaXKEaS0cnMfc_0xk=.7783dbb7-3988-4319-9b85-2ac45fc26759@github.com>
Message-ID: <dj7Iw8OGv-bD2NGZzxXOPTLdknKwqYOXfX9u01kTs80=.fa342b9d-c4fe-480e-bcef-ee74be44aab9@github.com>

On Tue, 19 Dec 2023 12:21:05 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Better name for a label, corrected name of removed field.

src/java.base/share/classes/jdk/internal/event/SerializationMisdeclarationEvent.java line 94:

> 92: 
> 93:     /*
> 94:      * These constants are not final on purpose.

Just curious - what's the purpose? I don't see them being changed/updated anywhere (not even in tests).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431551183

From jpai at openjdk.org  Tue Dec 19 15:23:49 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 19 Dec 2023 15:23:49 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v4]
In-Reply-To: <XlnL2mY6CwDlnA_KPw-IRVx9QAJaXKEaS0cnMfc_0xk=.7783dbb7-3988-4319-9b85-2ac45fc26759@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <XlnL2mY6CwDlnA_KPw-IRVx9QAJaXKEaS0cnMfc_0xk=.7783dbb7-3988-4319-9b85-2ac45fc26759@github.com>
Message-ID: <6cwqiWvcFYeHEcIuNky7QpmSLqRruKRi-LRfM7xtpM4=.37176dc7-14fa-47e9-af9b-1dfb12f6bcce@github.com>

On Tue, 19 Dec 2023 12:21:05 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Better name for a label, corrected name of removed field.

test/jdk/jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java line 112:

> 110:     @MethodSource
> 111:     public void testGoodClass(Class<?> cls) {
> 112:         assertEquals(0, getEventsFor(cls).size());

Can this and other assertions in this test be updated to include the class name which failed? You can still use `assertEquals(...)`, it takes an optional message as a third parameter which you could use to include the failing class name. It becomes a bit more easier to debug (unexpected) failures when the assertion includes these additional details.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431563775

From stsypanov at openjdk.org  Tue Dec 19 15:24:21 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 19 Dec 2023 15:24:21 GMT
Subject: RFR: 8322292: Rearrange comparison of fields in Record.equals()
 [v3]
In-Reply-To: <eNySqrZ9HgZrjF61lHA_6YecuPT7RB9xxz82U3zIjog=.f8b68ce5-3fab-4cfa-8709-17e51d77a958@github.com>
References: <eNySqrZ9HgZrjF61lHA_6YecuPT7RB9xxz82U3zIjog=.f8b68ce5-3fab-4cfa-8709-17e51d77a958@github.com>
Message-ID: <ZK7nP7wG2kYTtxv8Imn3H7HUHMHtTfu7D17GI7PaWRQ=.bd2602ac-013c-4e1d-9f03-091702917fc1@github.com>

> Currently if we create a record it's fields are compared in their declaration order. This might be ineffective in cases when two objects have "heavy" fields equals to each other, but different "lightweight" fields (heavy and lightweight in terms of comparison) e.g. primitives, enums, nullable/non-nulls etc.
> 
> If we have declared a record like
> 
> public record MyRecord(String field1, int field2) {}
> 
> It's equals() looks like:
> 
>   public final equals(Ljava/lang/Object;)Z
>    L0
>     LINENUMBER 3 L0
>     ALOAD 0
>     ALOAD 1
>     INVOKEDYNAMIC equals(Lcom/caspianone/openbanking/productservice/controller/MyRecord;Ljava/lang/Object;)Z [
>       // handle kind 0x6 : INVOKESTATIC
>       java/lang/runtime/ObjectMethods.bootstrap(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/TypeDescriptor;Ljava/lang/Class;Ljava/lang/String;[Ljava/lang/invoke/MethodHandle;)Ljava/lang/Object;
>       // arguments:
>       com.caspianone.openbanking.productservice.controller.MyRecord.class,
>       "field1;field2",
>       // handle kind 0x1 : GETFIELD
>       com/caspianone/openbanking/productservice/controller/MyRecord.field1(Ljava/lang/String;),
>       // handle kind 0x1 : GETFIELD
>       com/caspianone/openbanking/productservice/controller/MyRecord.field2(I)
>     ]
>     IRETURN
>    L1
>     LOCALVARIABLE this Lcom/caspianone/openbanking/productservice/controller/MyRecord; L0 L1 0
>     LOCALVARIABLE o Ljava/lang/Object; L0 L1 1
>     MAXSTACK = 2
>     MAXLOCALS = 2
> 
> This can be improved by rearranging the comparison order of the fields moving enums and primitives upper, and collections/arrays lower.

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  8322292: Shift arrays up

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17143/files
  - new: https://git.openjdk.org/jdk/pull/17143/files/988601b3..dded977f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17143&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17143&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17143/head:pull/17143

PR: https://git.openjdk.org/jdk/pull/17143

From jpai at openjdk.org  Tue Dec 19 15:28:48 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 19 Dec 2023 15:28:48 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v4]
In-Reply-To: <XlnL2mY6CwDlnA_KPw-IRVx9QAJaXKEaS0cnMfc_0xk=.7783dbb7-3988-4319-9b85-2ac45fc26759@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <XlnL2mY6CwDlnA_KPw-IRVx9QAJaXKEaS0cnMfc_0xk=.7783dbb7-3988-4319-9b85-2ac45fc26759@github.com>
Message-ID: <KXtZ4PZTMUqrQvePdPx2zTVmgxAg-5irOJSbmGgNDhE=.671bf8fb-2117-41a0-b34e-35fc8987176c@github.com>

On Tue, 19 Dec 2023 12:21:05 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Better name for a label, corrected name of removed field.

test/jdk/jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java line 144:

> 142:     }
> 143: 
> 144:     static {

It's a bit odd for a test case to be doing this in a static block. Could this instead be done in a `org.junit.jupiter.api.BeforeAll` method:


import org.junit.jupiter.api.BeforeAll;
...
@BeforeAll
static void recordEvents() {
  .... // that static block's code here
}

Any (unexpected) failures in that method will then be reported in a better way by the testing framework instead of an `ExceptionInInitializer` that would be reported from a failure in static block and the test class itself failing to load.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431571145

From jpai at openjdk.org  Tue Dec 19 15:34:49 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 19 Dec 2023 15:34:49 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v4]
In-Reply-To: <XlnL2mY6CwDlnA_KPw-IRVx9QAJaXKEaS0cnMfc_0xk=.7783dbb7-3988-4319-9b85-2ac45fc26759@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <XlnL2mY6CwDlnA_KPw-IRVx9QAJaXKEaS0cnMfc_0xk=.7783dbb7-3988-4319-9b85-2ac45fc26759@github.com>
Message-ID: <_O5pS8TSbnWoTnCwXIFWqHR9tMP_67ubEOqh6ZJP868=.7a3ad615-5bca-48d5-8a53-017f924e2f5c@github.com>

On Tue, 19 Dec 2023 12:21:05 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Better name for a label, corrected name of removed field.

test/jdk/jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java line 50:

> 48:  * @requires vm.hasJFR
> 49:  * @library /test/lib
> 50:  * @run junit/othervm jdk.jfr.event.io.TestSerializationMisdeclarationEvent

Is the use of "othervm" needed here because of the use of `jdk.jfr.consumer.RecordingStream`? Does `RecordingStream` do JVM wide state changes? I did a quick look at that class but couldn't come to a conclusion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431578942

From acobbs at openjdk.org  Tue Dec 19 15:44:46 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 19 Dec 2023 15:44:46 GMT
Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available()
 test for end-of-stream [v4]
In-Reply-To: <W9j_Me4qREmkU9yuC7XTC59gESkiF0rOsUKy8vvrwyI=.7abc9827-b987-4bff-8f5c-ce5ce1a758f0@github.com>
References: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
 <TJ8loA9R1Kf_GxXw9lR-XLW-xqjrkPhdCnZFwFExG1A=.e3d52b42-d008-4841-b979-88d88f04b525@github.com>
 <HXXiM-MGVLXh3gv7Abs4dd3ipgQqsWdCzPjfK-fG8CI=.584a80cc-9f8f-45f8-817c-54e3eaf468fc@github.com>
 <DnjQ9xoaQdr5XloN4Ayr6uBvuMdmUL_iUhYPrilPMbk=.dad11855-f2b1-434f-8c56-fdde644ee9ad@github.com>
 <W9j_Me4qREmkU9yuC7XTC59gESkiF0rOsUKy8vvrwyI=.7abc9827-b987-4bff-8f5c-ce5ce1a758f0@github.com>
Message-ID: <lcV9IHZ68FyTiTkj3PBJcvAngKWIgede4L6CW8DsRQ0=.37f97adf-394e-4d64-b76a-36823346eebe@github.com>

On Tue, 19 Dec 2023 08:11:42 GMT, Bernd <duke at openjdk.org> wrote:

> > If what you're saying is "Previously we were implicitly verifying that the data reported by `available()` was actually there, and now we're no longer verifying that" then that's not correct.
> 
> I mean it verified the non-zero behavior, not that the data length was correct. Not sure if that is somewhere tested now.

Ok gotcha.

The test `GZIPInputStreamRead.java` verifies that `available()` returns zero once all of the compressed data has been read out. So this verifies `available()` at the end of a stream. It doesn't appear there are any tests which verify `available()` in the middle of a stream. Adding such a test would be a great idea but is beyond the scope of this bug of course.

In any case, I don't think the code that was there before was providing much in the way of implicit testing of `available()` either:

// try concatenated case
if (this.in.available() > 0 || n > 26) {
    int m = 8;                  // this.trailer
    try {
        m += readHeader(in);    // next.header
    } catch (IOException ze) {
        return true;  // ignore any malformed, do nothing
    }
    inf.reset();
    if (n > m)
        inf.setInput(buf, len - n + m, n - m);
    return false;
}
return true;

As you can see, in the previous version, when `available() > 0`, there would be no noticeable side effect if there was actually less data than that ("do nothing").

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17113#issuecomment-1863006155

From rgiulietti at openjdk.org  Tue Dec 19 16:03:55 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 19 Dec 2023 16:03:55 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v4]
In-Reply-To: <e-xe6KF01q-kqiws3Lh6OOm0gbyV-NAh9fkSt22ASxY=.a022fa86-4c0b-484b-997d-cc92a1e45247@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <XlnL2mY6CwDlnA_KPw-IRVx9QAJaXKEaS0cnMfc_0xk=.7783dbb7-3988-4319-9b85-2ac45fc26759@github.com>
 <e-xe6KF01q-kqiws3Lh6OOm0gbyV-NAh9fkSt22ASxY=.a022fa86-4c0b-484b-997d-cc92a1e45247@github.com>
Message-ID: <I3hvzqeC4IG1kMeR0eBd5eQrKRy-tTjRR7LGojVir9g=.61da50a2-c07a-44fc-bcb1-a1291c1ae650@github.com>

On Tue, 19 Dec 2023 14:39:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Is it per class for each classloader that loads it? Or is it per class per JVM? It's more out of curiosity than anything else because I don't think it makes a big difference (I don't expect too many classloaders that would lead to the case of extremely large streams of events).

The checks are done on the `Class<?>` instance, that is, per each defined (as per JVMS) and _used_ serializable class, on first usage in serialization. If enabled at all, they are invoked by the private `ObjectStreamClass` constructor.

> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 94:
> 
>> 92:         if (!isPrivate(f)) {
>> 93:             commitEvent(SUID_PRIVATE,
>> 94:                     SUID_NAME + " should be declared private");
> 
> Rest of the event messages use "... to be effective", should this one too use a similar text?

The field needs not be declared `private` to be effective, although it is recommended to do so. In this sense, "should" is just a recommendation, while "must" is really needed to make something effective.

> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 108:
> 
>> 106:                     SUID_NAME + " should be declared of type long");
>> 107:         }
>> 108:         if (!isStatic(f)) {
> 
> Nit - perhaps save the return value from the previous call to `isStatic(f)` a few lines above and reuse it here?

Assuming that most serializable classes are declared correctly, I don't think that caching the value of `isStatic()` makes a measurable difference.
If at all, then I'd prefer to cache the modifiers and "inline" the masking logic of the individual is*() methods.

> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 112:
> 
>> 110:         }
>> 111:         f.setAccessible(true);
>> 112:         if (getLong(f) == null) {
> 
> Is this check and the `setAccessible()` needed if a few lines above, the call to `f.getType()` returns `Long.TYPE` (i.e. primitive type)? Perhaps we can conditionally do these additional checks and calls, only if `f.getType()` isn't a primitive?

Right, will be addressed in the next commit.

> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 185:
> 
>> 183:             commitEvent(PRIV_METH_NON_STATIC,
>> 184:                     m + " must be non-static to be effective");
>> 185:         }
> 
> Should there also be a check to see if this `private` method is (misdeclared) as a `native` method?

I'm not sure that a `native` method is not considered effective by serialization. I have to check.

> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 276:
> 
>> 274:     }
>> 275: 
>> 276:     private static Object getObject(Field f) {
> 
> Should we call this method `getStaticFieldValue(...)`, because that's what the implementation is.

Since the only parameter is `Field`, it has to be a static field almost for sure.
Further, there's a `getLong()` method down below that operates on a static field as well and that one would also need a renaming.
If I can come up with better names they will be in the next commit.

> src/java.base/share/classes/jdk/internal/event/SerializationMisdeclarationEvent.java line 94:
> 
>> 92: 
>> 93:     /*
>> 94:      * These constants are not final on purpose.
> 
> Just curious - what's the purpose? I don't see them being changed/updated anywhere (not even in tests).

Declaring a `public static int` field `final` means that the value is then stored in the client class. If a value is changed, then the client needs to be recompiled as well, but this is not enforced by the language, so it might lead to inconsistencies.

The clean solution would be to use an enum class, but that's not supported by JFR.

> test/jdk/jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java line 50:
> 
>> 48:  * @requires vm.hasJFR
>> 49:  * @library /test/lib
>> 50:  * @run junit/othervm jdk.jfr.event.io.TestSerializationMisdeclarationEvent
> 
> Is the use of "othervm" needed here because of the use of `jdk.jfr.consumer.RecordingStream`? Does `RecordingStream` do JVM wide state changes? I did a quick look at that class but couldn't come to a conclusion.

Not sure, I have to check.

> test/jdk/jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java line 112:
> 
>> 110:     @MethodSource
>> 111:     public void testGoodClass(Class<?> cls) {
>> 112:         assertEquals(0, getEventsFor(cls).size());
> 
> Can this and other assertions in this test be updated to include the class name which failed? You can still use `assertEquals(...)`, it takes an optional message as a third parameter which you could use to include the failing class name. It becomes a bit more easier to debug (unexpected) failures when the assertion includes these additional details.

Thanks for the suggestion, will take a look.

> test/jdk/jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java line 144:
> 
>> 142:     }
>> 143: 
>> 144:     static {
> 
> It's a bit odd for a test case to be doing this in a static block. Could this instead be done in a `org.junit.jupiter.api.BeforeAll` method:
> 
> 
> import org.junit.jupiter.api.BeforeAll;
> ...
> @BeforeAll
> static void recordEvents() {
>   .... // that static block's code here
> }
> 
> Any (unexpected) failures in that method will then be reported in a better way by the testing framework instead of an `ExceptionInInitializer` that would be reported from a failure in static block and the test class itself failing to load.

Yes, yours is a cleaner way to go. Will do.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17129#issuecomment-1863031458
PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431613663
PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431612831
PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431613065
PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431614036
PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431615365
PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431616847
PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431618143
PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431617706
PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431617951

From rgiulietti at openjdk.org  Tue Dec 19 16:30:47 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 19 Dec 2023 16:30:47 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v4]
In-Reply-To: <I3hvzqeC4IG1kMeR0eBd5eQrKRy-tTjRR7LGojVir9g=.61da50a2-c07a-44fc-bcb1-a1291c1ae650@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <XlnL2mY6CwDlnA_KPw-IRVx9QAJaXKEaS0cnMfc_0xk=.7783dbb7-3988-4319-9b85-2ac45fc26759@github.com>
 <e-xe6KF01q-kqiws3Lh6OOm0gbyV-NAh9fkSt22ASxY=.a022fa86-4c0b-484b-997d-cc92a1e45247@github.com>
 <I3hvzqeC4IG1kMeR0eBd5eQrKRy-tTjRR7LGojVir9g=.61da50a2-c07a-44fc-bcb1-a1291c1ae650@github.com>
Message-ID: <Ii0QEn1IdmBD1ec6G6AS9H0iSPqkonwAq0RgbKhl9Gw=.db2c6ed4-3825-46da-967a-a157d5178494@github.com>

On Tue, 19 Dec 2023 15:56:39 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> > Is it per class for each classloader that loads it? Or is it per class per JVM? It's more out of curiosity than anything else because I don't think it makes a big difference (I don't expect too many classloaders that would lead to the case of extremely large streams of events).
> 
> The checks are done on the `Class<?>` instance, that is, per each defined (as per JVMS) and _used_ serializable class, on first usage in serialization. If enabled at all, they are invoked by the private `ObjectStreamClass` constructor.

Well, in fact `ObjectStreamClass` maintains a cache of `Class<?>` -> `ObjectStreamClass` to avoid creating a new instance of `ObjectStreamClass` each time a `Class<?>` is looked up. It memoizes the association the first time.

However, the cache can be emptied under high memory pressure, so the `ObjectStreamClass` instance might be recreated later, thus re-invoking the serialization checker once again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17129#issuecomment-1863090984

From iris at openjdk.org  Tue Dec 19 16:37:51 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 19 Dec 2023 16:37:51 GMT
Subject: [jdk22] RFR: 8321514: UTF16 string gets constructed incorrectly
 from codepoints if CompactStrings is not enabled
In-Reply-To: <qYnMiDf6o6CjptzNwcIKfI9JJY-9wVn5gFonPB2_Aos=.4b4690ad-95da-4443-afd8-7e0cd473e33f@github.com>
References: <qYnMiDf6o6CjptzNwcIKfI9JJY-9wVn5gFonPB2_Aos=.4b4690ad-95da-4443-afd8-7e0cd473e33f@github.com>
Message-ID: <P8FzkyEvuUs6yJPk9gQOov6HORcrwkaX9MneJKpOG5o=.987c87f9-dca5-43ca-9f40-eab28990858b@github.com>

On Mon, 18 Dec 2023 11:56:50 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [fde5b168](https://github.com/openjdk/jdk/commit/fde5b16817c3263236993f2e8c2d2469610d99bd) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Aleksei Voitylov on 14 Dec 2023 and was reviewed by Roger Riggs.
> 
> Thanks!

Verified PR identical to openjdk/jdk PR.

-------------

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk22/pull/18#pullrequestreview-1789287452

From rgiulietti at openjdk.org  Tue Dec 19 16:45:04 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 19 Dec 2023 16:45:04 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v5]
In-Reply-To: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
Message-ID: <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com>

> Adds serialization misdeclaration events to JFR.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Changes according to reviewer's comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17129/files
  - new: https://git.openjdk.org/jdk/pull/17129/files/51507e4e..fa04bf48

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=03-04

  Stats: 44 lines in 2 files changed: 15 ins; 14 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/17129.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17129/head:pull/17129

PR: https://git.openjdk.org/jdk/pull/17129

From sviswanathan at openjdk.org  Tue Dec 19 16:52:49 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 19 Dec 2023 16:52:49 GMT
Subject: RFR: 8321688: Build on linux with GCC 7.5.0 fails after 8319577
 [v2]
In-Reply-To: <u1nX9_G34LVzhPfmQo1w7eTUR5DLF23SBmDKFXeKEGg=.26464d0a-7549-4794-8a5c-c0bd33be6597@github.com>
References: <vIByQ06ftSU9o1Rb4YOWXPrry1LkYSj-vJqLXaMXQ5g=.d5a0ea33-f57a-4549-addf-b7a9c5eaa67d@github.com>
 <IgVsEyruca5jYomg5OTMjFXt9kBhDS3KTp2prBY9sbQ=.8e140145-a9ed-494b-a10d-f5ffeb2bc142@github.com>
 <u1nX9_G34LVzhPfmQo1w7eTUR5DLF23SBmDKFXeKEGg=.26464d0a-7549-4794-8a5c-c0bd33be6597@github.com>
Message-ID: <7oAAfwWkBYD1qmmNA_qSXjqTL5ua5H1rGfz3x0N68qQ=.3bf6c4ab-9847-4fed-9511-7b5c499edf6a@github.com>

On Tue, 19 Dec 2023 02:22:05 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Bump the needed version of GCC.
>>  - Revert previous change.
>>  - Merge branch 'master' into JDK-8321688
>>  - JDK-8321688
>
>> Have you tested with gcc 9? Or is this just supposition based on gcc9 having removed the experimental
> status for C++17?
> 
> I have not tested GCC 8 and 9. @sviswa7 seems to test them.
> 
>> I have verified that with the above change the builds (release, fastdebug, slowdebug) all succeed with GCC 8.4.0 as well as prior GCC like GCC7.5.0 and the test/jdk/java/util/Arrays/Sorting.java passes successfully with these builds.
> 
> Thanks for your tests. But from the description of the [GCC document](https://gcc.gnu.org/projects/cxx-status.html), shown below, it may be good to skip GCC 8 and use GCC 9 directly if we want to switch to C++17.
> 
>>  Some C++17 features are available since GCC 5, but support was experimental and the ABI of C++17 features was not stable until GCC 9.
> 
> What do you think about it?

@lgxbslgx  We would like to keep GCC 8.4.0 as the minimum.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17047#issuecomment-1863127078

From coffeys at openjdk.org  Tue Dec 19 16:58:51 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 19 Dec 2023 16:58:51 GMT
Subject: RFR: JDK-8319626: Override toString() for ZipFile [v8]
In-Reply-To: <EEHjubpyde8VF6w4shuUjROZWwIabcGCI9DYMva_gy8=.afba4e81-0f88-4530-8e32-23ca7f949157@github.com>
References: <UEVJDXC8Cs_RSBUEsWgmq8SPvI-T4LSydbPKr8u29iA=.fdce7d47-87a8-42ba-9cd4-119bf9023ad9@github.com>
 <EEHjubpyde8VF6w4shuUjROZWwIabcGCI9DYMva_gy8=.afba4e81-0f88-4530-8e32-23ca7f949157@github.com>
Message-ID: <t12CEVGJsSzGj8Vv7CQZefDPwz48FuNVQun8BgIKL_M=.e34dbcba-d4aa-47aa-9584-d8d93dafc632@github.com>

On Mon, 11 Dec 2023 05:47:33 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319982) which overrides and provides an implementation of `toString()` in _java.util.zip.ZipFile_ (and by extension, _java.util.jar.JarFile_).
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8319626
>  - break line
>  - reflect review: change impl to store field name
>  - drop additional specification
>  - drop 2nd paragraph
>  - return base name, not full path
>  - shorten wording
>  - reflect review: use separator, clarify spec
>  - reflect review: change string value and drop spec
>  - init

Marked as reviewed by coffeys (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16643#pullrequestreview-1789330433

From egahlin at openjdk.org  Tue Dec 19 17:18:41 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 19 Dec 2023 17:18:41 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v5]
In-Reply-To: <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com>
Message-ID: <A87hMO-0rzYApVJxtsNeieVAdgv3bMzhxc2LI_8WQn8=.7393c686-42db-4bc4-99c1-60a14332f64b@github.com>

On Tue, 19 Dec 2023 16:45:04 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes according to reviewer's comments.

src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 39:

> 37: import static java.lang.reflect.Modifier.*;
> 38: 
> 39: final class SerializationMisdeclarationChecker {

Is there a reason this event is placed in java.io package and not jdk.internal.event like other events?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431717967

From egahlin at openjdk.org  Tue Dec 19 17:18:44 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 19 Dec 2023 17:18:44 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v3]
In-Reply-To: <e7BeWWxzk-MqiZ4b0QMrnV_UhhjKFtZgUBzkV2wqX_M=.d65e9ba0-c1ed-43d9-a50c-b8452c537d75@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <_8M6KPN0UJHeW1cx31IW0mIfaXG5ls5nUfZ0TwxMdAs=.fd4facc4-91d4-4117-9b1f-a2cc1806d2b7@github.com>
 <gOPRdEq2C_00uEZZZ7lbNIOPX691FD56u5AwpCgvv3A=.dfd20a18-b42a-49bd-b8e6-9b6b5ea3375f@github.com>
 <e7BeWWxzk-MqiZ4b0QMrnV_UhhjKFtZgUBzkV2wqX_M=.d65e9ba0-c1ed-43d9-a50c-b8452c537d75@github.com>
Message-ID: <fppK-cFkXoPVGEkFdrNiulF52OlgHSjBk6np1uM1or4=.70796d1e-8515-484b-b324-72e6a77d7250@github.com>

On Tue, 19 Dec 2023 12:17:38 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/jdk.jfr/share/classes/jdk/jfr/events/SerializationMisdeclarationEvent.java line 48:
>> 
>>> 46: 
>>> 47:     @Label("Kind")
>>> 48:     public int kind;
>> 
>> What is the use case for error codes? Are they public or an implementation detail?
>
> The intent is that they are stable and for programmatic usage, whereas the message is more for human consumption. The codes are used in the test, for example, and are declared as public static in the event classes.
> 
> Alternatively, one could parse the message, but that's less robust in face of changes, I think.

Users (not OpenJDK developers) don't know what the error code means. I think it's better to not have them. This is how other events work. If you want to guard against changes, I would export the package to the test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431716132

From duke at openjdk.org  Tue Dec 19 17:24:15 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Tue, 19 Dec 2023 17:24:15 GMT
Subject: RFR: 8318971 : Better Error Handling for Jar Tool When Processing
 Non-existent Files [v2]
In-Reply-To: <xht1jEn-KP8Fhz4Xa4MBxlhsvlxk3mdAkpdv9dF77oQ=.3fdc9a36-e7da-4230-9b26-40dacb8e92b6@github.com>
References: <xht1jEn-KP8Fhz4Xa4MBxlhsvlxk3mdAkpdv9dF77oQ=.3fdc9a36-e7da-4230-9b26-40dacb8e92b6@github.com>
Message-ID: <xCNZ_uRYLpfoe8scTPfPWDcHOXNn7qhq8l2MmSJFMOc=.1fa8dabd-536c-4429-b30f-4c23799a6d93@github.com>

> Better Error Handling for Jar Tool Processing of "@File" <br>
> 
> This is a new PR for this PR since the original developer left the team. See all of the review history at https://github.com/openjdk/jdk/pull/16423.
> 
> Thank you.

Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:

  remove one test case and add the comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17088/files
  - new: https://git.openjdk.org/jdk/pull/17088/files/b944aac8..62a52f5a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17088&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17088&range=00-01

  Stats: 27 lines in 1 file changed: 10 ins; 17 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17088.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17088/head:pull/17088

PR: https://git.openjdk.org/jdk/pull/17088

From stuefe at openjdk.org  Tue Dec 19 17:25:38 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 19 Dec 2023 17:25:38 GMT
Subject: RFR: 8322417: Console read line with zero out should zero out when
 throwing exception
In-Reply-To: <OQ2mDsSWRLfNxXO0BapseECzeKY91cHesHXBQNKwNDU=.17212cbf-e920-4b99-8f70-8056f1d14fc3@github.com>
References: <OQ2mDsSWRLfNxXO0BapseECzeKY91cHesHXBQNKwNDU=.17212cbf-e920-4b99-8f70-8056f1d14fc3@github.com>
Message-ID: <lu7HrVXsS7lD-4Icl8UNiB0utZe76qs7MkjD-ksNA5A=.2112c7b6-7be0-4930-bf4a-6973e9878be7@github.com>

On Tue, 19 Dec 2023 12:47:53 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

> ?g exception
> 
> After leaving the method by throwing an exception the data can not be cleaned any more.

Seems reasonable.

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17156#pullrequestreview-1789380436

From egahlin at openjdk.org  Tue Dec 19 17:27:54 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 19 Dec 2023 17:27:54 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v4]
In-Reply-To: <I3hvzqeC4IG1kMeR0eBd5eQrKRy-tTjRR7LGojVir9g=.61da50a2-c07a-44fc-bcb1-a1291c1ae650@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <XlnL2mY6CwDlnA_KPw-IRVx9QAJaXKEaS0cnMfc_0xk=.7783dbb7-3988-4319-9b85-2ac45fc26759@github.com>
 <e-xe6KF01q-kqiws3Lh6OOm0gbyV-NAh9fkSt22ASxY=.a022fa86-4c0b-484b-997d-cc92a1e45247@github.com>
 <I3hvzqeC4IG1kMeR0eBd5eQrKRy-tTjRR7LGojVir9g=.61da50a2-c07a-44fc-bcb1-a1291c1ae650@github.com>
Message-ID: <St5ZioT2GzcPZYENVTJAkfDezIOfXcSlJeBdyNni3pU=.86bb78bc-8ead-4192-b9ae-b45ca656faee@github.com>

On Tue, 19 Dec 2023 16:00:59 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> test/jdk/jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java line 50:
>> 
>>> 48:  * @requires vm.hasJFR
>>> 49:  * @library /test/lib
>>> 50:  * @run junit/othervm jdk.jfr.event.io.TestSerializationMisdeclarationEvent
>> 
>> Is the use of "othervm" needed here because of the use of `jdk.jfr.consumer.RecordingStream`? Does `RecordingStream` do JVM wide state changes? I did a quick look at that class but couldn't come to a conclusion.
>
> Not sure, I have to check.

All the other events run in othervm. While it may be possible in some case to not do that, it's much easier to analyse issues, if we are sure the JVM is fresh. For example, JFR may not generate bytecode if an event is disabled. The JFR tests have been hardened to be able to run in parallel, so they run pretty fast.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431727571

From sspitsyn at openjdk.org  Tue Dec 19 17:29:56 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 19 Dec 2023 17:29:56 GMT
Subject: Integrated: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable
In-Reply-To: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
Message-ID: <NlO9aF5Gj6YY0AJOdEOb6UfAD0jv8xkxnsJV8b-B7Gg=.0f89c40a-c739-42af-adfc-00ee3ef0a47d@github.com>

On Thu, 7 Dec 2023 06:28:43 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This fix is for JDK 23 but the intention is to back port it to 22 in RDP-1 time frame.
> It is fixing a deadlock issue between `VirtualThread` class critical sections with the `interruptLock` (in methods: `unpark()`, `interrupt()`, `getAndClearInterrupt()`, `threadState()`, `toString()`), `JvmtiVTMSTransitionDisabler` and JVMTI `Suspend/Resume` mechanisms.
> The deadlocking scenario is well described by Patricio in a bug report comment.
> In simple words, a virtual thread should not be suspended during 'interruptLock' critical sections.
> 
> The fix is to record that a virtual thread is in a critical section (`JavaThread`'s `_in_critical_section` bit) by notifying the VM/JVMTI about begin/end of critical section.
> This bit is used in `HandshakeState::get_op_for_self()` to filter out any `HandshakeOperation` if a target `JavaThread` is in a critical section.
> 
> Some of new notifications with `notifyJvmtiSync()` method is on a performance critical path. It is why this method has been intrincified.
> 
> New test was developed by Patricio:
>  `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
> The test is very nice as it reliably in 100% reproduces the deadlock without the fix.
> The test is never failing with this fix.
> 
> Testing:
>  - tested with newly added test: `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
>  - tested with mach5 tiers 1-6

This pull request has now been integrated.

Changeset: 0f8e4e0a
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0f8e4e0a81257c678e948c341a241dc0b810494f
Stats:     229 lines in 15 files changed: 196 ins; 0 del; 33 mod

8311218: fatal error: stuck in JvmtiVTMSTransitionDisabler::VTMS_transition_disable

Reviewed-by: lmesnik, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/17011

From naoto at openjdk.org  Tue Dec 19 17:31:49 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 19 Dec 2023 17:31:49 GMT
Subject: RFR: 8322417: Console read line with zero out should zero out when
 throwing exception
In-Reply-To: <OQ2mDsSWRLfNxXO0BapseECzeKY91cHesHXBQNKwNDU=.17212cbf-e920-4b99-8f70-8056f1d14fc3@github.com>
References: <OQ2mDsSWRLfNxXO0BapseECzeKY91cHesHXBQNKwNDU=.17212cbf-e920-4b99-8f70-8056f1d14fc3@github.com>
Message-ID: <blA_hCn9hZGe9GvEyL40ABblXpbVTvGqUeYOb05wKdg=.09ac6a17-4c6d-4baa-bcd3-c995a3ec8bee@github.com>

On Tue, 19 Dec 2023 12:47:53 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

> ?g exception
> 
> After leaving the method by throwing an exception the data can not be cleaned any more.

LGTM. Please remove the redundant package name before push.

src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 123:

> 121:                     }
> 122:                     if (ioe != null) {
> 123:                         java.util.Arrays.fill(passwd, ' ');

`java.util.` is redundant.

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17156#pullrequestreview-1789389076
PR Review Comment: https://git.openjdk.org/jdk/pull/17156#discussion_r1431731882

From rgiulietti at openjdk.org  Tue Dec 19 17:44:51 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 19 Dec 2023 17:44:51 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v5]
In-Reply-To: <A87hMO-0rzYApVJxtsNeieVAdgv3bMzhxc2LI_8WQn8=.7393c686-42db-4bc4-99c1-60a14332f64b@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com>
 <A87hMO-0rzYApVJxtsNeieVAdgv3bMzhxc2LI_8WQn8=.7393c686-42db-4bc4-99c1-60a14332f64b@github.com>
Message-ID: <yzGuV79E-uWo9gph3zHd_0N3CmMg8S2yieUIBuoqlrs=.e25b8c19-7f19-495c-83bb-5401b5268e18@github.com>

On Tue, 19 Dec 2023 17:15:40 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changes according to reviewer's comments.
>
> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 39:
> 
>> 37: import static java.lang.reflect.Modifier.*;
>> 38: 
>> 39: final class SerializationMisdeclarationChecker {
> 
> Is there a reason this event is placed in java.io package and not jdk.internal.event like other events?

The mirror event itself and the JFR event are placed in their standard locations.
Only the checker is in `java.io`, so I'm not sure what you mean here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431740613

From egahlin at openjdk.org  Tue Dec 19 17:44:49 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 19 Dec 2023 17:44:49 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v4]
In-Reply-To: <Ii0QEn1IdmBD1ec6G6AS9H0iSPqkonwAq0RgbKhl9Gw=.db2c6ed4-3825-46da-967a-a157d5178494@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <XlnL2mY6CwDlnA_KPw-IRVx9QAJaXKEaS0cnMfc_0xk=.7783dbb7-3988-4319-9b85-2ac45fc26759@github.com>
 <e-xe6KF01q-kqiws3Lh6OOm0gbyV-NAh9fkSt22ASxY=.a022fa86-4c0b-484b-997d-cc92a1e45247@github.com>
 <I3hvzqeC4IG1kMeR0eBd5eQrKRy-tTjRR7LGojVir9g=.61da50a2-c07a-44fc-bcb1-a1291c1ae650@github.com>
 <Ii0QEn1IdmBD1ec6G6AS9H0iSPqkonwAq0RgbKhl9Gw=.db2c6ed4-3825-46da-967a-a157d5178494@github.com>
Message-ID: <3W5zOlTu7-VH5IjzqDBjkB-B1aSzNBrqN85nIfo05Dk=.73042d7c-01bd-41ed-a0f1-8bc7d8625c97@github.com>

On Tue, 19 Dec 2023 16:28:03 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> However, the cache can be emptied under high memory pressure, so the `ObjectStreamClass` instance might be recreated later, thus re-invoking the serialization checker once again.

I think it would be good to state in the description when checks occur, something like: Only the first time a class is serialized are the misdeclaration checks carried out, but may happen happen more frequently under high memory pressure. (Try to avoid using the word "event")

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17129#issuecomment-1863216232

From rgiulietti at openjdk.org  Tue Dec 19 17:44:52 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 19 Dec 2023 17:44:52 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v3]
In-Reply-To: <fppK-cFkXoPVGEkFdrNiulF52OlgHSjBk6np1uM1or4=.70796d1e-8515-484b-b324-72e6a77d7250@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <_8M6KPN0UJHeW1cx31IW0mIfaXG5ls5nUfZ0TwxMdAs=.fd4facc4-91d4-4117-9b1f-a2cc1806d2b7@github.com>
 <gOPRdEq2C_00uEZZZ7lbNIOPX691FD56u5AwpCgvv3A=.dfd20a18-b42a-49bd-b8e6-9b6b5ea3375f@github.com>
 <e7BeWWxzk-MqiZ4b0QMrnV_UhhjKFtZgUBzkV2wqX_M=.d65e9ba0-c1ed-43d9-a50c-b8452c537d75@github.com>
 <fppK-cFkXoPVGEkFdrNiulF52OlgHSjBk6np1uM1or4=.70796d1e-8515-484b-b324-72e6a77d7250@github.com>
Message-ID: <LSDvl7Fa7yE5ZUulDOs3lvllMaevk9viTuBm5f5XhGQ=.0f52163a-9a6a-4b07-ac25-811c68166dcc@github.com>

On Tue, 19 Dec 2023 17:13:58 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> The intent is that they are stable and for programmatic usage, whereas the message is more for human consumption. The codes are used in the test, for example, and are declared as public static in the event classes.
>> 
>> Alternatively, one could parse the message, but that's less robust in face of changes, I think.
>
> Users (not OpenJDK developers) don't know what the error code means. I think it's better to not have them. This is how other events work. If you want to guard against changes, I would export the package to the test.

What about fixed `String`s rather than `int`s for the kind of error?
Something like `"SUID_INEFFECTIVE_ON_ENUM"`, and so on?
It would be nice to be able to use enums, but AFAIK that's not supported in JFR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431744479

From rgiulietti at openjdk.org  Tue Dec 19 17:48:48 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 19 Dec 2023 17:48:48 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v5]
In-Reply-To: <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com>
Message-ID: <VGZhe7hKW0Pex3QpoxMNOwoJkWRTLAiW472bMb93Nes=.069601f2-9f53-4492-8bd9-1f77880cf83f@github.com>

On Tue, 19 Dec 2023 16:45:04 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes according to reviewer's comments.

You mean, in the @Description annotation?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17129#issuecomment-1863223947

From egahlin at openjdk.org  Tue Dec 19 17:58:41 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 19 Dec 2023 17:58:41 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v5]
In-Reply-To: <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com>
Message-ID: <gr_5bhmiUoTPhWgNUIB9opi0LBK5k0lQwvjmiY-7UL4=.19731780-4a94-424d-b8b6-60b6d3adeec8@github.com>

On Tue, 19 Dec 2023 16:45:04 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes according to reviewer's comments.

> You mean, in the @description annotation?

Yes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17129#issuecomment-1863235723

From egahlin at openjdk.org  Tue Dec 19 17:58:44 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 19 Dec 2023 17:58:44 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v5]
In-Reply-To: <yzGuV79E-uWo9gph3zHd_0N3CmMg8S2yieUIBuoqlrs=.e25b8c19-7f19-495c-83bb-5401b5268e18@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com>
 <A87hMO-0rzYApVJxtsNeieVAdgv3bMzhxc2LI_8WQn8=.7393c686-42db-4bc4-99c1-60a14332f64b@github.com>
 <yzGuV79E-uWo9gph3zHd_0N3CmMg8S2yieUIBuoqlrs=.e25b8c19-7f19-495c-83bb-5401b5268e18@github.com>
Message-ID: <YcnG70IeHopQGZ_aW8QiY4VehBIUVeJ4UxIJVZZ19E4=.a6010239-6680-4589-9c4c-2874b5765569@github.com>

On Tue, 19 Dec 2023 17:37:50 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 39:
>> 
>>> 37: import static java.lang.reflect.Modifier.*;
>>> 38: 
>>> 39: final class SerializationMisdeclarationChecker {
>> 
>> Is there a reason this event is placed in java.io package and not jdk.internal.event like other events?
>
> The mirror event itself and the JFR event are placed in their standard locations.
> Only the checker is in `java.io`, so I'm not sure what you mean here.

Sorry, my fault. Github showed "SerializationMisdeclar..." and I thought it was the event.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431762931

From bpb at openjdk.org  Tue Dec 19 18:16:45 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 19 Dec 2023 18:16:45 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v15]
In-Reply-To: <tU4DhOPRjlWrTO-Zn-AfSlQ_OJFuRRViHzI1Z1ZpeMs=.520ee229-ebec-4e88-9818-d544400d8949@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <8SYx9TqaT4rL2o4BZ_Fnu_ZxD3vVMdYJS51dtGMK22I=.4b226895-ec4a-49bc-ab1a-c46a2e290405@github.com>
 <mOFTUALYYY7dLlbzIL7BqI0RsmohLvlNCtEcZ7k_pzk=.b043a248-54bb-4368-9480-e6e3fe510b14@github.com>
 <tU4DhOPRjlWrTO-Zn-AfSlQ_OJFuRRViHzI1Z1ZpeMs=.520ee229-ebec-4e88-9818-d544400d8949@github.com>
Message-ID: <YdGuF8FBJwIBgFtSmv6fA1hg_MKEHIqJuPazpo69z5g=.02eb0473-2f7f-4296-b09a-0f5babfead9b@github.com>

On Tue, 19 Dec 2023 10:14:44 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Shouldn't we keep at least the method for the classes checked in `BIS.isTrusted()`

You can keep it there or inline it. As Alan noted, the main thing is not to add something like a new package.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1431779354

From bpb at openjdk.org  Tue Dec 19 18:22:41 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 19 Dec 2023 18:22:41 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred [v4]
In-Reply-To: <MgqxdnIJbR-Kan1rvnLN0M63R5zLUcThXNHvdJDGCP4=.77f9b25a-12fa-4edb-935b-eb19196da8da@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
 <MgqxdnIJbR-Kan1rvnLN0M63R5zLUcThXNHvdJDGCP4=.77f9b25a-12fa-4edb-935b-eb19196da8da@github.com>
Message-ID: <DcqFoeac1QjH_W5DzKMWIigdheVlgrH6Zs59p-z6UR0=.8b83adb5-e56b-4ee9-a732-b656a133be6f@github.com>

On Sat, 16 Dec 2023 14:07:52 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Fixes JDK-8322141
>> 
>> As suggested by @vlsi and documented by @bplb this PR does not return, but only sets the maximum result value.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test was using Integer but must use Long

Approved.

Please note in future that it is better not to `/integrate` until the request has actually been approved by a Reviewer.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17119#pullrequestreview-1789475686

From bpb at openjdk.org  Tue Dec 19 18:33:41 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 19 Dec 2023 18:33:41 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred [v4]
In-Reply-To: <MgqxdnIJbR-Kan1rvnLN0M63R5zLUcThXNHvdJDGCP4=.77f9b25a-12fa-4edb-935b-eb19196da8da@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
 <MgqxdnIJbR-Kan1rvnLN0M63R5zLUcThXNHvdJDGCP4=.77f9b25a-12fa-4edb-935b-eb19196da8da@github.com>
Message-ID: <KCbi1Ao4WYyTZ2FXlmBC6ehIKimsPWrW1ecFO6q1Bio=.7d17b6d8-0d46-4af0-95cf-b04033ee1493@github.com>

On Sat, 16 Dec 2023 14:07:52 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Fixes JDK-8322141
>> 
>> As suggested by @vlsi and documented by @bplb this PR does not return, but only sets the maximum result value.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test was using Integer but must use Long

I verified that the test now fails without the source change but passes with it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17119#issuecomment-1863284534

From sgibbons at openjdk.org  Tue Dec 19 18:42:19 2023
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Tue, 19 Dec 2023 18:42:19 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v4]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <6xRfGFR2RIYln31ivz1ZITs5G5bzQ5BlnPdsQeyVbX0=.2797afc7-40ec-482e-9c64-b3ba746d2bd7@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Fix for JDK-8321599

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/5e03173e..48088348

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=02-03

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From mchung at openjdk.org  Tue Dec 19 18:56:54 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 19 Dec 2023 18:56:54 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v13]
In-Reply-To: <nwIS8DM4bg1KqmwxqY0btCqmlxhZ2DXtozgRKU9pqiA=.533711cd-da43-4850-9675-02ba2da81f11@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <1VoNUv8RTXkFcv411pVhC0E3AEZfsp_8EZNXn4IyP5M=.09425f9b-a6b4-4ed0-b659-09cf7aa4adba@github.com>
 <nwIS8DM4bg1KqmwxqY0btCqmlxhZ2DXtozgRKU9pqiA=.533711cd-da43-4850-9675-02ba2da81f11@github.com>
Message-ID: <k6iJYgVCLTVVFT-skJj7ecSXl5Z9cEPOUtX2o75h13M=.93a9f930-2c09-460e-b7f6-7029814ccfab@github.com>

On Fri, 15 Dec 2023 10:02:56 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Disallow packaged modules and run-time image link
>>  - Only check for existing path when not a scratch task
>>    
>>    When using a run-time image link and the initial build was produced with
>>    the --keep-packaged-modules option, we don't need to check existing
>>    paths to the location where packaged modules need to be copied. This
>>    breaks the --verbose output validation.
>
> Thanks. I'm not super happy with it either (yet). I'll do some pondering myself to try to clean this up. Basically it would be good to know if the functionality so far would be complete as far as you're concerned as I could then focus on a cleaner patch without needing to add more bits.

Thanks for the update @jerboaa.

`--unlock-run-image` is changed to be an internal option.  It is ok while we should 
revisit this per the customer feedback.  If not needed, we should take this out in
another release.    The help output for this option in `jlink.properties` is no longer
needed and should be removed.   Maybe this option should be `--ignore-modified-runtime`
or something explicit.

If I read the code correctly, the image created with this option will enable multi-hops unconditionally?
i.e. no timestamp file created and disable the check completely.   I think the .stamp file should be present in
any image created without packaged modules.   

I agree that there is no difference to the plugins of SORTER, PROCESSOR, COMPRESSOR
categories if the input to linking is packaged modules vs runtime image.

I also agree that the transformation done by filtering plugins will persist in the new
image if linking from the runtime image.   Currently, filtering plugins can be of
FILTER and TRANSFORMER category.

For the remaining plugins (ADDER and TRANSFORMER category) such as `--add-options`,
`--system-modules` etc,  it sounds right not to persist the transformed data.  But
a few exceptions:

  --vendor-bug-url
  --vendor-version
  --vendor-vm-bug-url


These plugins change the value of `java.vendor.*` system properties defined in
`VersionProps.class`.  This behavioral difference when linking with packaged
modules and runtime image is hard to notice as those would need the internal
knowledge of these plugins (note consider the future plugins too).

I also agree with Alan that --verbose output is a bit confusing (my initial feedback).  The image
has already been created.  The users can't tell which plugins are implicitly
run.   To list the plugin options, it has to delete the already-created image
and re-do the jlink command with `--verbose`.

In addition, this change would consider that the default module path now becomes:
    <paths-given-by-add-modules>:$JAVA_HOME/jmods:<runtime-image>

I wonder if the warning about "$JAVA_HOME/jmods" not present is strictly needed.

I am inclined to consider that non-filtering plugins are responsible to restore
the data if transformed to the original form.  It seems to be simpler model
for users to understand.  They can expect that the image produced is the same
when linking with packaged modules or from the runtime image except filtered data.

The use of `--exclude-resources` plugin to exclude transformed data to restore
the data back to original form is clever and works for plugins that add
new resources.  But it does not work for plugins that modifying existing data
(`--vendor-bug-url` etc plugins).   The change in `TaskHelper::getPluginsConfig`
raises the question that it isn't the right way to support this feature.   I think we need
to explore a better way to add this support.  One possibility I consider is to run 
non-filtering plugins of ADDER and TRANSFORMER categories always (similar
to auto-enabled).   It has to determine if it's requested by the user or 
to restore the data to original form via `Plugin::configure` time.  
`Plugin::transform` will handle if the data is from packaged-modules and
from runtime image which may contain the data transformed by this plugin.
I haven't explored this fully yet.

A side note: some filtering plugins are of TRANSFORMER plugin.   Maybe those
plugins should be FILTER category so that plugins not of FILTER category are 
non-filtering plugins and expected to restore the data to original form if linking
from the runtime image.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1863312923

From kbarrett at openjdk.org  Tue Dec 19 19:10:50 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 19 Dec 2023 19:10:50 GMT
Subject: RFR: 8321688: Build on linux with GCC 7.5.0 fails after 8319577
 [v2]
In-Reply-To: <u1nX9_G34LVzhPfmQo1w7eTUR5DLF23SBmDKFXeKEGg=.26464d0a-7549-4794-8a5c-c0bd33be6597@github.com>
References: <vIByQ06ftSU9o1Rb4YOWXPrry1LkYSj-vJqLXaMXQ5g=.d5a0ea33-f57a-4549-addf-b7a9c5eaa67d@github.com>
 <IgVsEyruca5jYomg5OTMjFXt9kBhDS3KTp2prBY9sbQ=.8e140145-a9ed-494b-a10d-f5ffeb2bc142@github.com>
 <u1nX9_G34LVzhPfmQo1w7eTUR5DLF23SBmDKFXeKEGg=.26464d0a-7549-4794-8a5c-c0bd33be6597@github.com>
Message-ID: <ndlUZLukWz6Cgz0EaxJLap6-dl8H4URIDZgiSYGVgds=.bbdcfb85-535d-49a0-a3c9-e8c69ef7f2b4@github.com>

On Tue, 19 Dec 2023 02:22:05 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Bump the needed version of GCC.
>>  - Revert previous change.
>>  - Merge branch 'master' into JDK-8321688
>>  - JDK-8321688
>
>> Have you tested with gcc 9? Or is this just supposition based on gcc9 having removed the experimental
> status for C++17?
> 
> I have not tested GCC 8 and 9. @sviswa7 seems to test them.
> 
>> I have verified that with the above change the builds (release, fastdebug, slowdebug) all succeed with GCC 8.4.0 as well as prior GCC like GCC7.5.0 and the test/jdk/java/util/Arrays/Sorting.java passes successfully with these builds.
> 
> Thanks for your tests. But from the description of the [GCC document](https://gcc.gnu.org/projects/cxx-status.html), shown below, it may be good to skip GCC 8 and use GCC 9 directly if we want to switch to C++17.
> 
>>  Some C++17 features are available since GCC 5, but support was experimental and the ABI of C++17 features was not stable until GCC 9.
> 
> What do you think about it?

> @lgxbslgx We would like to keep GCC 8.4.0 as the minimum.

Why?  That's likely going to be in conflict with https://github.com/openjdk/jdk/pull/14988.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17047#issuecomment-1863330523

From mchung at openjdk.org  Tue Dec 19 19:17:56 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 19 Dec 2023 19:17:56 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v13]
In-Reply-To: <1VoNUv8RTXkFcv411pVhC0E3AEZfsp_8EZNXn4IyP5M=.09425f9b-a6b4-4ed0-b659-09cf7aa4adba@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <1VoNUv8RTXkFcv411pVhC0E3AEZfsp_8EZNXn4IyP5M=.09425f9b-a6b4-4ed0-b659-09cf7aa4adba@github.com>
Message-ID: <jW2WKKwvN7S0BnZgj5Tq_Fo6BkVGol8xLCr9AwGINVY=.a1be7796-7112-45de-99d8-ccca057bd29e@github.com>

On Mon, 11 Dec 2023 16:37:38 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Disallow packaged modules and run-time image link
>  - Only check for existing path when not a scratch task
>    
>    When using a run-time image link and the initial build was produced with
>    the --keep-packaged-modules option, we don't need to check existing
>    paths to the location where packaged modules need to be copied. This
>    breaks the --verbose output validation.

FWIW.   [f623930](https://github.com/mlchung/jdk/commit/f623930cd529085ddb730a60b7facf106ea01955) for your reference.   I pulled your branch and refactored and made suggestions to the code while I was walking through the code.   Some observations:

The constants such as the pathname of the timestamp file and the internal file listing
per-module non-class non-resource files are part of jlink.  I move the constants to
`JlinkTask`to follow where `OPTIONS_RESOURCE` is defined.

`JRTArchive` scans the class and resource files of a given module from the runtime image.
It should also read `fs_$MODULE_files` to find the list of non-class and non-resource files.

The current implementation checks if a file is modified lazily when `Entry::stream`
is called and so it has to remember if file modification has been checked and
warning has been emitted.   I think doing the file modification check eagerly
when `collectFiles` is called would simplify the code.

For maintainability, better to move the reading of and writing to `fs_$MODULE_files`
together in a single class rather than separated in `JRTArchive` and `JlinkResourcesListPlugin`.
I move them to `JRTArchive.ResourceFileEntry` for now.   There may be a better place.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1863338821

From sviswanathan at openjdk.org  Tue Dec 19 19:40:48 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 19 Dec 2023 19:40:48 GMT
Subject: RFR: 8321688: Build on linux with GCC 7.5.0 fails after 8319577
 [v2]
In-Reply-To: <ndlUZLukWz6Cgz0EaxJLap6-dl8H4URIDZgiSYGVgds=.bbdcfb85-535d-49a0-a3c9-e8c69ef7f2b4@github.com>
References: <vIByQ06ftSU9o1Rb4YOWXPrry1LkYSj-vJqLXaMXQ5g=.d5a0ea33-f57a-4549-addf-b7a9c5eaa67d@github.com>
 <IgVsEyruca5jYomg5OTMjFXt9kBhDS3KTp2prBY9sbQ=.8e140145-a9ed-494b-a10d-f5ffeb2bc142@github.com>
 <u1nX9_G34LVzhPfmQo1w7eTUR5DLF23SBmDKFXeKEGg=.26464d0a-7549-4794-8a5c-c0bd33be6597@github.com>
 <ndlUZLukWz6Cgz0EaxJLap6-dl8H4URIDZgiSYGVgds=.bbdcfb85-535d-49a0-a3c9-e8c69ef7f2b4@github.com>
Message-ID: <FLMVLCF3T8VAs-NhiCQsSKfDvciM16zmWiyXxLo_fxY=.d4881557-2e0a-40ef-b09b-70c40ce03568@github.com>

On Tue, 19 Dec 2023 19:08:08 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>>> Have you tested with gcc 9? Or is this just supposition based on gcc9 having removed the experimental
>> status for C++17?
>> 
>> I have not tested GCC 8 and 9. @sviswa7 seems to test them.
>> 
>>> I have verified that with the above change the builds (release, fastdebug, slowdebug) all succeed with GCC 8.4.0 as well as prior GCC like GCC7.5.0 and the test/jdk/java/util/Arrays/Sorting.java passes successfully with these builds.
>> 
>> Thanks for your tests. But from the description of the [GCC document](https://gcc.gnu.org/projects/cxx-status.html), shown below, it may be good to skip GCC 8 and use GCC 9 directly if we want to switch to C++17.
>> 
>>>  Some C++17 features are available since GCC 5, but support was experimental and the ABI of C++17 features was not stable until GCC 9.
>> 
>> What do you think about it?
>
>> @lgxbslgx We would like to keep GCC 8.4.0 as the minimum.
> 
> Why?  That's likely going to be in conflict with https://github.com/openjdk/jdk/pull/14988.

@kimbarrett I meant to say that since the libsimdsort works with GCC 8.4.0, the #define guard in libsimdsort sources could be restricted to just that and we don't have to artificially raise it to GCC 9. Do you think that is an issue?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17047#issuecomment-1863367786

From rriggs at openjdk.org  Tue Dec 19 19:44:44 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Dec 2023 19:44:44 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v4]
In-Reply-To: <XlnL2mY6CwDlnA_KPw-IRVx9QAJaXKEaS0cnMfc_0xk=.7783dbb7-3988-4319-9b85-2ac45fc26759@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <XlnL2mY6CwDlnA_KPw-IRVx9QAJaXKEaS0cnMfc_0xk=.7783dbb7-3988-4319-9b85-2ac45fc26759@github.com>
Message-ID: <q0r65enUkcI9FACjbEt02JtmUrTtaxQvYAfvzy7LNY8=.d3fa8691-8063-42db-bf4d-7b88eaa6c953@github.com>

On Tue, 19 Dec 2023 12:21:05 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Better name for a label, corrected name of removed field.

src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 108:

> 106:                     SUID_NAME + " should be declared of type long");
> 107:         }
> 108:         if (!isStatic(f)) {

The two calls to isStatic could be reordered closer together to be a single if (isstatic()) { ... } else {... }.

src/java.base/share/classes/jdk/internal/event/SerializationMisdeclarationEvent.java line 126:

> 124:     public static int ACC_METH_PARAM_TYPES            = 404;
> 125:     public static int ACC_METH_NON_ACCESSIBLE         = 405;
> 126: 

I'd rather see few (fewer, just one) kinds of events, with so many different kinds of events there needs to be a convenient method to look for any kind of serialization mis-declaration.
Perhaps a single event with flags for the different kinds of errors.
The event classes could be responsible for turning the flags back into useful messages on display.

test/jdk/jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java line 157:

> 155:     }
> 156: 
> 157:     private static class A implements Serializable {

The test classes should document the good or badness of the class either in the class/field/method names or in comments.  What's wrong with this XXX.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431846034
PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431850091
PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431856800

From rriggs at openjdk.org  Tue Dec 19 19:44:45 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Dec 2023 19:44:45 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v3]
In-Reply-To: <LSDvl7Fa7yE5ZUulDOs3lvllMaevk9viTuBm5f5XhGQ=.0f52163a-9a6a-4b07-ac25-811c68166dcc@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <_8M6KPN0UJHeW1cx31IW0mIfaXG5ls5nUfZ0TwxMdAs=.fd4facc4-91d4-4117-9b1f-a2cc1806d2b7@github.com>
 <gOPRdEq2C_00uEZZZ7lbNIOPX691FD56u5AwpCgvv3A=.dfd20a18-b42a-49bd-b8e6-9b6b5ea3375f@github.com>
 <e7BeWWxzk-MqiZ4b0QMrnV_UhhjKFtZgUBzkV2wqX_M=.d65e9ba0-c1ed-43d9-a50c-b8452c537d75@github.com>
 <fppK-cFkXoPVGEkFdrNiulF52OlgHSjBk6np1uM1or4=.70796d1e-8515-484b-b324-72e6a77d7250@github.com>
 <LSDvl7Fa7yE5ZUulDOs3lvllMaevk9viTuBm5f5XhGQ=.0f52163a-9a6a-4b07-ac25-811c68166dcc@github.com>
Message-ID: <mTgctICvSwPCTJQi2aDT4QmXeiCaqlpNe_k5Cbk38Cg=.9415b7e2-23bb-451b-b435-3545e27479d0@github.com>

On Tue, 19 Dec 2023 17:41:57 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Users (not OpenJDK developers) don't know what the error code means. I think it's better to not have them. This is how other events work. If you want to guard against changes, I would export the package to the test.
>
> What about fixed `String`s rather than `int`s for the kind of error?
> Something like `"SUID_INEFFECTIVE_ON_ENUM"`, and so on?
> It would be nice to be able to use enums, but AFAIK that's not supported in JFR.

You could define them with an Enum but use the ordinal as the value for JFR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431864329

From forax at openjdk.org  Tue Dec 19 19:46:37 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 19 Dec 2023 19:46:37 GMT
Subject: RFR: 8322292: Rearrange comparison of fields in Record.equals()
In-Reply-To: <rMhVI_GVA4keqohYuyRbV2Jl5hvkrmMBQ4wOEc78oZM=.0ed6c153-e711-4032-baf1-748b79bc48b8@github.com>
References: <eNySqrZ9HgZrjF61lHA_6YecuPT7RB9xxz82U3zIjog=.f8b68ce5-3fab-4cfa-8709-17e51d77a958@github.com>
 <eqkuO0tHexUhpYZIwZjJMqT8JQzU8nXFwQ9sWvqj0gQ=.01df9224-992c-4e40-ba51-33c6f4ff7eec@github.com>
 <EvBE54cgMGXSXuRwZ0cdP8et1XDQOLE7Ml4DrVwVQL4=.72de2396-1c17-4363-9c75-1b3534d319df@github.com>
 <rMhVI_GVA4keqohYuyRbV2Jl5hvkrmMBQ4wOEc78oZM=.0ed6c153-e711-4032-baf1-748b79bc48b8@github.com>
Message-ID: <_9r2EAiiazThknDxTZZjHsNJKWvW5iArUEfejaiwlCo=.e0f98420-3f8f-4378-b5c9-d95e7151ebed@github.com>

On Tue, 19 Dec 2023 11:01:12 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

> Isn't Arrays.equals() used under the hood?
No, for arrays == is used

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17143#issuecomment-1863374656

From mchung at openjdk.org  Tue Dec 19 20:48:45 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 19 Dec 2023 20:48:45 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes
In-Reply-To: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
Message-ID: <cqiHlFTCPog_bjmtncLFa_PbazRXVF6iTw4hNbhtbE0=.4d83b089-3421-44f6-b791-c979596651eb@github.com>

On Fri, 15 Dec 2023 12:54:27 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes.
> 
> This patch converts it to use Classfile API.
> 
> It is continuation of https://github.com/openjdk/jdk/pull/10991
> 
> Any comments and suggestions are welcome.
> 
> Please review.
> 
> Thank you,
> Adam

Can you include a summary of the performance comparison before and after the patch per the [comment](https://github.com/openjdk/jdk/pull/10991#pullrequestreview-1333426016) in #10991.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17121#issuecomment-1863448643

From duke at openjdk.org  Tue Dec 19 21:08:51 2023
From: duke at openjdk.org (Valeh Hajiyev)
Date: Tue, 19 Dec 2023 21:08:51 GMT
Subject: RFR: 6356745: (coll) Add PriorityQueue(Collection,
 Comparator) [v3]
In-Reply-To: <zAcGyJ33ZP0osNg-HMJp4UCtOXYzdqi969ugDhJ7954=.c5f8e2de-cfe8-4224-a98e-70f49da9a7a3@github.com>
References: <zAcGyJ33ZP0osNg-HMJp4UCtOXYzdqi969ugDhJ7954=.c5f8e2de-cfe8-4224-a98e-70f49da9a7a3@github.com>
Message-ID: <jbbJx8il5u6DFRGDp0LJxzRFRUBYHENpgZsFUd7s5Q4=.8d2f9faf-4b8e-456a-a2ed-ae4224ca8520@github.com>

> This commit addresses the current limitation in the `PriorityQueue` implementation, which lacks a constructor to efficiently create a priority queue with a custom comparator and an existing collection. In order to create such a queue, we currently need to initialize a new queue with custom comparator, and after that populate the queue using `addAll()` method, which in the background calls `add()` method (which takes `O(logn)` time) for each element of the collection (`n` times).  This is resulting in an overall time complexity of `O(nlogn)`. 
> 
> 
> PriorityQueue<String> pq = new PriorityQueue<>(customComparator);
> pq.addAll(existingCollection);
> 
> 
> The pull request introduces a new constructor to streamline this process and reduce the time complexity to `O(n)`.  If you create the queue above using the new constructor, the contents of the collection will be copied (which takes `O(n)` time) and then later  `heapify()` operation (Floyd's algorithm) will be called once (another `O(n)` time). Overall the operation will be reduced from `O(nlogn)` to `O(2n)` -> `O(n)` time.
> 
> 
> PriorityQueue<String> pq = new PriorityQueue<>(existingCollection, customComparator);

Valeh Hajiyev has updated the pull request incrementally with one additional commit since the last revision:

  add since tag

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17045/files
  - new: https://git.openjdk.org/jdk/pull/17045/files/1cce713d..04811c98

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17045&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17045&range=01-02

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17045.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17045/head:pull/17045

PR: https://git.openjdk.org/jdk/pull/17045

From duke at openjdk.org  Tue Dec 19 21:17:02 2023
From: duke at openjdk.org (Valeh Hajiyev)
Date: Tue, 19 Dec 2023 21:17:02 GMT
Subject: RFR: 6356745: (coll) Add PriorityQueue(Collection,
 Comparator) [v4]
In-Reply-To: <zAcGyJ33ZP0osNg-HMJp4UCtOXYzdqi969ugDhJ7954=.c5f8e2de-cfe8-4224-a98e-70f49da9a7a3@github.com>
References: <zAcGyJ33ZP0osNg-HMJp4UCtOXYzdqi969ugDhJ7954=.c5f8e2de-cfe8-4224-a98e-70f49da9a7a3@github.com>
Message-ID: <3BInvmLUo5T1-DimTKsJ5DDcRwYUyNe5n3UqRr9tTs4=.886b4dfe-65ed-4476-9314-ce27759c034a@github.com>

> This commit addresses the current limitation in the `PriorityQueue` implementation, which lacks a constructor to efficiently create a priority queue with a custom comparator and an existing collection. In order to create such a queue, we currently need to initialize a new queue with custom comparator, and after that populate the queue using `addAll()` method, which in the background calls `add()` method (which takes `O(logn)` time) for each element of the collection (`n` times).  This is resulting in an overall time complexity of `O(nlogn)`. 
> 
> 
> PriorityQueue<String> pq = new PriorityQueue<>(customComparator);
> pq.addAll(existingCollection);
> 
> 
> The pull request introduces a new constructor to streamline this process and reduce the time complexity to `O(n)`.  If you create the queue above using the new constructor, the contents of the collection will be copied (which takes `O(n)` time) and then later  `heapify()` operation (Floyd's algorithm) will be called once (another `O(n)` time). Overall the operation will be reduced from `O(nlogn)` to `O(2n)` -> `O(n)` time.
> 
> 
> PriorityQueue<String> pq = new PriorityQueue<>(existingCollection, customComparator);

Valeh Hajiyev has updated the pull request incrementally with one additional commit since the last revision:

  updated the javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17045/files
  - new: https://git.openjdk.org/jdk/pull/17045/files/04811c98..6884929b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17045&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17045&range=02-03

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17045.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17045/head:pull/17045

PR: https://git.openjdk.org/jdk/pull/17045

From duke at openjdk.org  Tue Dec 19 21:17:04 2023
From: duke at openjdk.org (Valeh Hajiyev)
Date: Tue, 19 Dec 2023 21:17:04 GMT
Subject: RFR: 6356745: (coll) Add PriorityQueue(Collection,
 Comparator) [v2]
In-Reply-To: <tWAU74ffW_SCH-sc1TOKUwR7M30tej2O0UydQSKNvdI=.7cac8560-fe7f-44e1-b513-1c08da06cd5a@github.com>
References: <zAcGyJ33ZP0osNg-HMJp4UCtOXYzdqi969ugDhJ7954=.c5f8e2de-cfe8-4224-a98e-70f49da9a7a3@github.com>
 <coAODM-9CtXAmbfpMxBU6wEYu6DXFOJB6OHV_cVo0L4=.978b09e9-1231-4ff3-ac97-e6b40816bc36@github.com>
 <tWAU74ffW_SCH-sc1TOKUwR7M30tej2O0UydQSKNvdI=.7cac8560-fe7f-44e1-b513-1c08da06cd5a@github.com>
Message-ID: <na55oPfdp80x1Ytk4mk9su_TofOmG6trVPJEGbbQGVA=.604a44eb-2e98-4c5a-8992-f7885f4ea3af@github.com>

On Sun, 17 Dec 2023 09:42:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Valeh Hajiyev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated the javadoc
>
> src/java.base/share/classes/java/util/PriorityQueue.java line 215:
> 
>> 213:      * Creates a {@code PriorityQueue} containing the elements in the
>> 214:      * specified collection. The {@code PriorityQueue} will order its
>> 215:      * elements according to the specified comparator.
> 
> The wording "will order its elements" is consistent with the other constructors but I wonder if "its" might be mis-read to mean the collection rather than the queue. If you change it to "will order the priority queue's elements" will avoid that.
> 
> You'll need to add `@since 23`. Also new tests will need to be added for this constructor.

makes sense, updated it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17045#discussion_r1431942707

From duke at openjdk.org  Tue Dec 19 21:17:17 2023
From: duke at openjdk.org (Valeh Hajiyev)
Date: Tue, 19 Dec 2023 21:17:17 GMT
Subject: RFR: 6356745: (coll) Add PriorityQueue(Collection,
 Comparator) [v2]
In-Reply-To: <Hrv4ZAhQ0Rtc6jGWLOqKH_TjHPdJ7yrE8Jx1vSbbaBU=.12b0179d-6fed-4f28-b12c-a2b7564cf8cc@github.com>
References: <zAcGyJ33ZP0osNg-HMJp4UCtOXYzdqi969ugDhJ7954=.c5f8e2de-cfe8-4224-a98e-70f49da9a7a3@github.com>
 <coAODM-9CtXAmbfpMxBU6wEYu6DXFOJB6OHV_cVo0L4=.978b09e9-1231-4ff3-ac97-e6b40816bc36@github.com>
 <Hrv4ZAhQ0Rtc6jGWLOqKH_TjHPdJ7yrE8Jx1vSbbaBU=.12b0179d-6fed-4f28-b12c-a2b7564cf8cc@github.com>
Message-ID: <0zbcP0oCH4BdtaVJso5onAW_5Hjzpf9T_auYdDDBYc8=.2d9c3211-aa8a-4925-8c08-12a395f625df@github.com>

On Sun, 17 Dec 2023 15:20:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Valeh Hajiyev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated the javadoc
>
> You should update the GitHub PR title to `6356745: (coll) Add PriorityQueue(Collection, Comparator)` to match the JBS issue title.
> 
> In addition, you will need a [CSR](https://wiki.openjdk.org/display/csr) as the bot tells you. Its prompt is like:
> 
> Summary
> A concise description of the proposed change. The description should be one to two sentences long and written to be reusable in documents aggregating changes for a release.
> 
> Problem
> A brief description of the problem, optionally including the motivation for developing a solution.
> 
> Solution
> An overview of the solution. Alternative solutions may be discussed; links to rationale documents or review threads welcome to provide additional background to reviewers.
> 
> Specification
> The detailed changes. Acceptable normative formats include inline patches, attached webrevs, and attached specdiffs. The names of attached files are recommended to include a bug id. References to external webservers, such as http://cr.openjdk.java.net/, can be provided as informative supplements for the convenience of reviewers, but must be accompanied by a normative form of the specification directly associated with the CSR issue to satisfy archival purposes.
> 
> 
> I can create one for you, and here's my proposed CSR content:
> 
> Summary
> Add a new constructor to PriorityQueue that takes a Collection and a Comparator.
> 
> Problem
> Creating a PriorityQueue with an existing Collection and a custom Comparator is inefficient; it can use heapify which is `O(N)` in time complexity, but it currently has to be done via `addAll`, which has `O(N log N)` time complexity.
> 
> Solution
> Add a new constructor `PriorityQueue(Collection, Comparator)` to explicitly allow the heapify process when a custom comparator is given. This constructor would be in pair with `PriorityQueue(Collection)`, as all other PriorityQueue constructors come in natural-order and comparator pairs (`()` and `(Comparator)`, `(int)` and `(int, Comparator)` ones)
> 
> An alternative solution would be to override `addAll(Collection)` to call `initFromCollection` when the PriorityQueue is empty. This would have the same effect as the new constructor and is applicable to all empty PriorityQueues, but doesn't solve the parity issue mentioned above.
> 
> Specification
>     --- a/src/java.base/share/classes/java/util/PriorityQueue.java
>     +++ b/src/java.base/share/classes/java/util/PriorityQueue.java
>     @@ -209,6 +209,25 @@ else if (c instanceof PriorityQueue<?>) {
>              }
>          }
>      
>     +    /**...

@liach thanks for the help. I updated the PR title, also your proposed CSR content looks good to me. would you mind creating it with your proposed content?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17045#issuecomment-1863481650

From avoitylov at openjdk.org  Tue Dec 19 21:33:52 2023
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Tue, 19 Dec 2023 21:33:52 GMT
Subject: [jdk22] RFR: 8321514: UTF16 string gets constructed incorrectly
 from codepoints if CompactStrings is not enabled
In-Reply-To: <qYnMiDf6o6CjptzNwcIKfI9JJY-9wVn5gFonPB2_Aos=.4b4690ad-95da-4443-afd8-7e0cd473e33f@github.com>
References: <qYnMiDf6o6CjptzNwcIKfI9JJY-9wVn5gFonPB2_Aos=.4b4690ad-95da-4443-afd8-7e0cd473e33f@github.com>
Message-ID: <WA2v4okh7LwiTBYwOicuJX5mMS_fESYRWh4aqg0uO4A=.277e7c60-174c-4e11-8f10-a2ee3e6004c4@github.com>

On Mon, 18 Dec 2023 11:56:50 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [fde5b168](https://github.com/openjdk/jdk/commit/fde5b16817c3263236993f2e8c2d2469610d99bd) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Aleksei Voitylov on 14 Dec 2023 and was reviewed by Roger Riggs.
> 
> Thanks!

Thank you Roger and Iris!

-------------

PR Comment: https://git.openjdk.org/jdk22/pull/18#issuecomment-1863500159

From duke at openjdk.org  Tue Dec 19 21:34:02 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Tue, 19 Dec 2023 21:34:02 GMT
Subject: RFR: 8318971 : Better Error Handling for Jar Tool When Processing
 Non-existent Files [v3]
In-Reply-To: <xht1jEn-KP8Fhz4Xa4MBxlhsvlxk3mdAkpdv9dF77oQ=.3fdc9a36-e7da-4230-9b26-40dacb8e92b6@github.com>
References: <xht1jEn-KP8Fhz4Xa4MBxlhsvlxk3mdAkpdv9dF77oQ=.3fdc9a36-e7da-4230-9b26-40dacb8e92b6@github.com>
Message-ID: <Kj39R0NIbJH9NAR_pUse6OoQ_l8IaFoKg8ICgSnjuIY=.f8c6e22b-360e-4664-82f3-e22aa4616326@github.com>

> Better Error Handling for Jar Tool Processing of "@File" <br>
> 
> This is a new PR for this PR since the original developer left the team. See all of the review history at https://github.com/openjdk/jdk/pull/16423.
> 
> Thank you.

Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:

  updat testing cases

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17088/files
  - new: https://git.openjdk.org/jdk/pull/17088/files/62a52f5a..ba9335e0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17088&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17088&range=01-02

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17088.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17088/head:pull/17088

PR: https://git.openjdk.org/jdk/pull/17088

From duke at openjdk.org  Tue Dec 19 21:34:04 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Tue, 19 Dec 2023 21:34:04 GMT
Subject: RFR: 8318971 : Better Error Handling for Jar Tool When Processing
 Non-existent Files [v2]
In-Reply-To: <xCNZ_uRYLpfoe8scTPfPWDcHOXNn7qhq8l2MmSJFMOc=.1fa8dabd-536c-4429-b30f-4c23799a6d93@github.com>
References: <xht1jEn-KP8Fhz4Xa4MBxlhsvlxk3mdAkpdv9dF77oQ=.3fdc9a36-e7da-4230-9b26-40dacb8e92b6@github.com>
 <xCNZ_uRYLpfoe8scTPfPWDcHOXNn7qhq8l2MmSJFMOc=.1fa8dabd-536c-4429-b30f-4c23799a6d93@github.com>
Message-ID: <EjZlz-pIJvgOoXhiJSRbnFI41aVAWoUAea_cFyHHR3I=.481e3d50-a118-40e9-b8b1-34f76d0dee82@github.com>

On Tue, 19 Dec 2023 17:24:15 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> Better Error Handling for Jar Tool Processing of "@File" <br>
>> 
>> This is a new PR for this PR since the original developer left the team. See all of the review history at https://github.com/openjdk/jdk/pull/16423.
>> 
>> Thank you.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove one test case and add the comments

1) the man page update will be in another PR
2) Update the title of JBS bug and put the description in. Literarily I copied Jai's comments
3) Removed test case of testMultipleFilesInClassesList, I don't believe it is related to the change
4) Added the comments for two other test cases and updated the test.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17088#issuecomment-1863499364

From avoitylov at openjdk.org  Tue Dec 19 21:36:52 2023
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Tue, 19 Dec 2023 21:36:52 GMT
Subject: [jdk22] Integrated: 8321514: UTF16 string gets constructed incorrectly
 from codepoints if CompactStrings is not enabled
In-Reply-To: <qYnMiDf6o6CjptzNwcIKfI9JJY-9wVn5gFonPB2_Aos=.4b4690ad-95da-4443-afd8-7e0cd473e33f@github.com>
References: <qYnMiDf6o6CjptzNwcIKfI9JJY-9wVn5gFonPB2_Aos=.4b4690ad-95da-4443-afd8-7e0cd473e33f@github.com>
Message-ID: <DllhPYepT3iKBTnQG5hgL2xnlo-Ve0Q97cd1NuHjLf0=.fa1789ee-831e-4fca-b9df-29a01e839657@github.com>

On Mon, 18 Dec 2023 11:56:50 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [fde5b168](https://github.com/openjdk/jdk/commit/fde5b16817c3263236993f2e8c2d2469610d99bd) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Aleksei Voitylov on 14 Dec 2023 and was reviewed by Roger Riggs.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 049be572
Author:    Aleksei Voitylov <avoitylov at openjdk.org>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/049be572ef7a0f69b171928709784522ff42caa0
Stats:     27 lines in 2 files changed: 25 ins; 0 del; 2 mod

8321514: UTF16 string gets constructed incorrectly from codepoints if CompactStrings is not enabled

Reviewed-by: rriggs, iris
Backport-of: fde5b16817c3263236993f2e8c2d2469610d99bd

-------------

PR: https://git.openjdk.org/jdk22/pull/18

From kbarrett at openjdk.org  Tue Dec 19 23:27:50 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 19 Dec 2023 23:27:50 GMT
Subject: RFR: 8321688: Build on linux with GCC 7.5.0 fails after 8319577
 [v2]
In-Reply-To: <IgVsEyruca5jYomg5OTMjFXt9kBhDS3KTp2prBY9sbQ=.8e140145-a9ed-494b-a10d-f5ffeb2bc142@github.com>
References: <vIByQ06ftSU9o1Rb4YOWXPrry1LkYSj-vJqLXaMXQ5g=.d5a0ea33-f57a-4549-addf-b7a9c5eaa67d@github.com>
 <IgVsEyruca5jYomg5OTMjFXt9kBhDS3KTp2prBY9sbQ=.8e140145-a9ed-494b-a10d-f5ffeb2bc142@github.com>
Message-ID: <Ps8ErH0KrSs-C0Z9Va_hE1nRJDeGCEgdaURdF5I14q0=.79aac8ac-5d70-487f-a702-fd9b377640f1@github.com>

On Sun, 17 Dec 2023 13:25:00 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch fixes the building failure introduced by [JDK-8319577](https://bugs.openjdk.org/browse/JDK-8319577) in old GCC version (linux & GCC 7.5.0 locally).
>> 
>> Thanks for the review.
>> 
>>  Best Regards,
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Bump the needed version of GCC.
>  - Revert previous change.
>  - Merge branch 'master' into JDK-8321688
>  - JDK-8321688

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17047#pullrequestreview-1789856820

From kbarrett at openjdk.org  Tue Dec 19 23:27:51 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 19 Dec 2023 23:27:51 GMT
Subject: RFR: 8321688: Build on linux with GCC 7.5.0 fails after 8319577
 [v2]
In-Reply-To: <ndlUZLukWz6Cgz0EaxJLap6-dl8H4URIDZgiSYGVgds=.bbdcfb85-535d-49a0-a3c9-e8c69ef7f2b4@github.com>
References: <vIByQ06ftSU9o1Rb4YOWXPrry1LkYSj-vJqLXaMXQ5g=.d5a0ea33-f57a-4549-addf-b7a9c5eaa67d@github.com>
 <IgVsEyruca5jYomg5OTMjFXt9kBhDS3KTp2prBY9sbQ=.8e140145-a9ed-494b-a10d-f5ffeb2bc142@github.com>
 <u1nX9_G34LVzhPfmQo1w7eTUR5DLF23SBmDKFXeKEGg=.26464d0a-7549-4794-8a5c-c0bd33be6597@github.com>
 <ndlUZLukWz6Cgz0EaxJLap6-dl8H4URIDZgiSYGVgds=.bbdcfb85-535d-49a0-a3c9-e8c69ef7f2b4@github.com>
Message-ID: <hmDtBHc9ejkgjHJy31Zu7694-l8ce5ClUmal_qijkLU=.65362b08-bebb-4909-95b0-b60b312d3e31@github.com>

On Tue, 19 Dec 2023 19:08:08 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>>> Have you tested with gcc 9? Or is this just supposition based on gcc9 having removed the experimental
>> status for C++17?
>> 
>> I have not tested GCC 8 and 9. @sviswa7 seems to test them.
>> 
>>> I have verified that with the above change the builds (release, fastdebug, slowdebug) all succeed with GCC 8.4.0 as well as prior GCC like GCC7.5.0 and the test/jdk/java/util/Arrays/Sorting.java passes successfully with these builds.
>> 
>> Thanks for your tests. But from the description of the [GCC document](https://gcc.gnu.org/projects/cxx-status.html), shown below, it may be good to skip GCC 8 and use GCC 9 directly if we want to switch to C++17.
>> 
>>>  Some C++17 features are available since GCC 5, but support was experimental and the ABI of C++17 features was not stable until GCC 9.
>> 
>> What do you think about it?
>
>> @lgxbslgx We would like to keep GCC 8.4.0 as the minimum.
> 
> Why?  That's likely going to be in conflict with https://github.com/openjdk/jdk/pull/14988.

> @kimbarrett I meant to say that since the libsimdsort works with GCC 8.4.0, the #define guard in libsimdsort sources could be restricted to just that and we don't have to artificially raise it to GCC 9. Do you think that is an issue?

I don't think we should be depending on an experimental compiler feature when there are alternatives.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17047#issuecomment-1863608489

From sviswanathan at openjdk.org  Wed Dec 20 00:03:50 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 20 Dec 2023 00:03:50 GMT
Subject: RFR: 8321688: Build on linux with GCC 7.5.0 fails after 8319577
 [v2]
In-Reply-To: <IgVsEyruca5jYomg5OTMjFXt9kBhDS3KTp2prBY9sbQ=.8e140145-a9ed-494b-a10d-f5ffeb2bc142@github.com>
References: <vIByQ06ftSU9o1Rb4YOWXPrry1LkYSj-vJqLXaMXQ5g=.d5a0ea33-f57a-4549-addf-b7a9c5eaa67d@github.com>
 <IgVsEyruca5jYomg5OTMjFXt9kBhDS3KTp2prBY9sbQ=.8e140145-a9ed-494b-a10d-f5ffeb2bc142@github.com>
Message-ID: <-uMaGK76l2QQVJKQMFn15G44scDSVPYZ6nHlgw_SJq4=.faf45bef-b90d-4fa5-a495-aa5b4af1aaf6@github.com>

On Sun, 17 Dec 2023 13:25:00 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch fixes the building failure introduced by [JDK-8319577](https://bugs.openjdk.org/browse/JDK-8319577) in old GCC version (linux & GCC 7.5.0 locally).
>> 
>> Thanks for the review.
>> 
>>  Best Regards,
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Bump the needed version of GCC.
>  - Revert previous change.
>  - Merge branch 'master' into JDK-8321688
>  - JDK-8321688

Marked as reviewed by sviswanathan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17047#pullrequestreview-1789880110

From jpai at openjdk.org  Wed Dec 20 00:58:51 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 20 Dec 2023 00:58:51 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred [v4]
In-Reply-To: <MgqxdnIJbR-Kan1rvnLN0M63R5zLUcThXNHvdJDGCP4=.77f9b25a-12fa-4edb-935b-eb19196da8da@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
 <MgqxdnIJbR-Kan1rvnLN0M63R5zLUcThXNHvdJDGCP4=.77f9b25a-12fa-4edb-935b-eb19196da8da@github.com>
Message-ID: <QNoioaghcPUdQyFu6keJw5FGPkUmmef4nCLVIGXXDM8=.29e3fc24-9d15-4f52-b4c9-c4df34b0cc33@github.com>

On Sat, 16 Dec 2023 14:07:52 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Fixes JDK-8322141
>> 
>> As suggested by @vlsi and documented by @bplb this PR does not return, but only sets the maximum result value.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test was using Integer but must use Long

Thank you Markus for the update. The updated source change looks fine to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17119#pullrequestreview-1789914334

From jpai at openjdk.org  Wed Dec 20 01:21:50 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 20 Dec 2023 01:21:50 GMT
Subject: RFR: 8318971 : Better Error Handling for Jar Tool When Processing
 Non-existent Files [v3]
In-Reply-To: <Kj39R0NIbJH9NAR_pUse6OoQ_l8IaFoKg8ICgSnjuIY=.f8c6e22b-360e-4664-82f3-e22aa4616326@github.com>
References: <xht1jEn-KP8Fhz4Xa4MBxlhsvlxk3mdAkpdv9dF77oQ=.3fdc9a36-e7da-4230-9b26-40dacb8e92b6@github.com>
 <Kj39R0NIbJH9NAR_pUse6OoQ_l8IaFoKg8ICgSnjuIY=.f8c6e22b-360e-4664-82f3-e22aa4616326@github.com>
Message-ID: <BxK85Y_CNJskaEMchh32rzwDkfZuPBXKKgtQSbxxjXM=.86e80b14-2959-4ed1-a2c6-c17b4a18263d@github.com>

On Tue, 19 Dec 2023 21:34:02 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> Better Error Handling for Jar Tool Processing of "@File" <br>
>> 
>> This is a new PR for this PR since the original developer left the team. See all of the review history at https://github.com/openjdk/jdk/pull/16423.
>> 
>> Thank you.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updat testing cases

Thank you Weibing for these updates. I think this is now almost there. One final request, would you be able to add a test for the `-u` option as well?

test/jdk/tools/jar/InputFilesTest.java line 161:

> 159:      * IOException is triggered as expected.
> 160:      */
> 161:     @Test(expectedExceptions = {IOException.class})

Hello Weibing, I think using `expectedExceptions` here at the method level is too wide for this test, so might be better to remove it. I see that you use a catch block (at the right place) in this test method to verify you have received the correct `IOException`. What you could do is, don't rethrow it if it matches the expected IOException:


        try {
            jar("cf test.jar existingTestFile.txt nonExistentTestFile.txt");
        } catch (IOException e) {
             // expected to have received an IOException due to tool
            // returning non-zero exit code
            Assert.assertEquals(e.getMessage().trim(), "nonExistentTestFile.txt : no such file or directory");
            Assert.assertTrue(Files.notExists(Path.of("test.jar")), "Jar file should not be created.");
        }

Same comment for the other new test method.

test/jdk/tools/jar/InputFilesTest.java line 171:

> 169:             Assert.assertTrue(Files.notExists(Path.of("test.jar")), "Jar file should not be created.");
> 170:             throw e;
> 171:         }

There should be a `fail("jar tool unexpectedly completed successfully")` here so that we assert that the `jar` call actually fails. Same comment for the other new test method.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17088#issuecomment-1863693788
PR Review Comment: https://git.openjdk.org/jdk/pull/17088#discussion_r1432082929
PR Review Comment: https://git.openjdk.org/jdk/pull/17088#discussion_r1432083748

From duke at openjdk.org  Wed Dec 20 03:09:48 2023
From: duke at openjdk.org (duke)
Date: Wed, 20 Dec 2023 03:09:48 GMT
Subject: Withdrawn: 8317980: Optimization for Integer.parseInt and
 Long.parseLong
In-Reply-To: <xXubpoKlW4kakLKZ_bIAeg3KeENoeAKgoBh6fYqQ0ZM=.8bf6c2ed-249c-41d7-bd48-cc8fa6ab07ca@github.com>
References: <xXubpoKlW4kakLKZ_bIAeg3KeENoeAKgoBh6fYqQ0ZM=.8bf6c2ed-249c-41d7-bd48-cc8fa6ab07ca@github.com>
Message-ID: <SSuaeHxzuyGvBdmUqRbbabDVKsJiZzDcLej4tK7NpYY=.df4b0c4e-2c5e-49db-9384-6045b4a6ff60@github.com>

On Tue, 10 Oct 2023 02:54:05 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> By extracting the code that creates the exception, the CodeSize of these methods is less than the default FreqInlineSize 325.  and for the scenario where the most commonly used radix is not specified and the String coder is LATIN1, fast-path can improves the performance 10% of parseInt(String)/parseLong(String).

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/16112

From gli at openjdk.org  Wed Dec 20 04:02:53 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 20 Dec 2023 04:02:53 GMT
Subject: RFR: 8321688: Build on linux with GCC 7.5.0 fails after 8319577
 [v2]
In-Reply-To: <hmDtBHc9ejkgjHJy31Zu7694-l8ce5ClUmal_qijkLU=.65362b08-bebb-4909-95b0-b60b312d3e31@github.com>
References: <vIByQ06ftSU9o1Rb4YOWXPrry1LkYSj-vJqLXaMXQ5g=.d5a0ea33-f57a-4549-addf-b7a9c5eaa67d@github.com>
 <IgVsEyruca5jYomg5OTMjFXt9kBhDS3KTp2prBY9sbQ=.8e140145-a9ed-494b-a10d-f5ffeb2bc142@github.com>
 <u1nX9_G34LVzhPfmQo1w7eTUR5DLF23SBmDKFXeKEGg=.26464d0a-7549-4794-8a5c-c0bd33be6597@github.com>
 <ndlUZLukWz6Cgz0EaxJLap6-dl8H4URIDZgiSYGVgds=.bbdcfb85-535d-49a0-a3c9-e8c69ef7f2b4@github.com>
 <hmDtBHc9ejkgjHJy31Zu7694-l8ce5ClUmal_qijkLU=.65362b08-bebb-4909-95b0-b60b312d3e31@github.com>
Message-ID: <zwjY2gm4blICsla17v-LQ_AqfMMpZehxs1xCQPPrzeE=.8d1c38cb-26d1-4d0a-8f17-36a261b48377@github.com>

On Tue, 19 Dec 2023 23:23:28 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>>> @lgxbslgx We would like to keep GCC 8.4.0 as the minimum.
>> 
>> Why?  That's likely going to be in conflict with https://github.com/openjdk/jdk/pull/14988.
>
>> @kimbarrett I meant to say that since the libsimdsort works with GCC 8.4.0, the #define guard in libsimdsort sources could be restricted to just that and we don't have to artificially raise it to GCC 9. Do you think that is an issue?
> 
> I don't think we should be depending on an experimental compiler feature when there are alternatives.

@kimbarrett @sviswa7 Thanks for your reviews. Integrating.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17047#issuecomment-1863808489

From gli at openjdk.org  Wed Dec 20 04:02:55 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 20 Dec 2023 04:02:55 GMT
Subject: Integrated: 8321688: Build on linux with GCC 7.5.0 fails after 8319577
In-Reply-To: <vIByQ06ftSU9o1Rb4YOWXPrry1LkYSj-vJqLXaMXQ5g=.d5a0ea33-f57a-4549-addf-b7a9c5eaa67d@github.com>
References: <vIByQ06ftSU9o1Rb4YOWXPrry1LkYSj-vJqLXaMXQ5g=.d5a0ea33-f57a-4549-addf-b7a9c5eaa67d@github.com>
Message-ID: <mKvHyYS1UckaU6WT0wmn2gB3OgJNdrudy3xKITZLm_4=.5a99277c-3f91-46cf-908b-c85d4e9d7054@github.com>

On Mon, 11 Dec 2023 02:36:30 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch fixes the building failure introduced by [JDK-8319577](https://bugs.openjdk.org/browse/JDK-8319577) in old GCC version (linux & GCC 7.5.0 locally).
> 
> Thanks for the review.
> 
>  Best Regards,
> -- Guoxiong

This pull request has now been integrated.

Changeset: 97db6709
Author:    Guoxiong Li <gli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/97db670956d83749ec3fe1485bacd046662c6856
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8321688: Build on linux with GCC 7.5.0 fails after 8319577

Reviewed-by: kbarrett, sviswanathan

-------------

PR: https://git.openjdk.org/jdk/pull/17047

From dholmes at openjdk.org  Wed Dec 20 04:47:58 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Dec 2023 04:47:58 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v8]
In-Reply-To: <EwkIDbTs7wG5q6lcikgo0ycMFRpu5VXxvMbR3tOPAM8=.40c169b6-57df-4dc7-8726-fd6d8439c541@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
 <EwkIDbTs7wG5q6lcikgo0ycMFRpu5VXxvMbR3tOPAM8=.40c169b6-57df-4dc7-8726-fd6d8439c541@github.com>
Message-ID: <m3pEt7BjebAgGp1zZpD1LPyYKivqVkSuHGr-D6f-sVo=.f1ce13c8-c470-4ac1-882d-d9786a1a3f85@github.com>

On Mon, 18 Dec 2023 17:09:59 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fix is for JDK 23 but the intention is to back port it to 22 in RDP-1 time frame.
>> It is fixing a deadlock issue between `VirtualThread` class critical sections with the `interruptLock` (in methods: `unpark()`, `interrupt()`, `getAndClearInterrupt()`, `threadState()`, `toString()`), `JvmtiVTMSTransitionDisabler` and JVMTI `Suspend/Resume` mechanisms.
>> The deadlocking scenario is well described by Patricio in a bug report comment.
>> In simple words, a virtual thread should not be suspended during 'interruptLock' critical sections.
>> 
>> The fix is to record that a virtual thread is in a critical section (`JavaThread`'s `_in_critical_section` bit) by notifying the VM/JVMTI about begin/end of critical section.
>> This bit is used in `HandshakeState::get_op_for_self()` to filter out any `HandshakeOperation` if a target `JavaThread` is in a critical section.
>> 
>> Some of new notifications with `notifyJvmtiSync()` method is on a performance critical path. It is why this method has been intrincified.
>> 
>> New test was developed by Patricio:
>>  `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
>> The test is very nice as it reliably in 100% reproduces the deadlock without the fix.
>> The test is never failing with this fix.
>> 
>> Testing:
>>  - tested with newly added test: `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge
>  - review: improve an assert message
>  - review: moved a couple of comments out of try blocks
>  - review: moved notifyJvmtiDisableSuspend(true) out of try-block
>  - review: 1) replace CriticalLock with DisableSuspend; 2) minor tweaks
>  - review: (1) rename notifyJvmti method; (2) add try-final statements to VirtualThread methods
>  - Resolved merge conflict in VirtualThread.java
>  - added @summary to new test SuspendWithInterruptLock.java
>  - add new test SuspendWithInterruptLock.java
>  - 8311218: fatal error: stuck in JvmtiVTMSTransitionDisabler::VTMS_transition_disable

src/hotspot/share/prims/jvm.cpp line 4024:

> 4022: #else
> 4023:   fatal("Should only be called with JVMTI enabled");
> 4024: #endif

You can't do this! The Java code knows nothing about JVM TI being enabled/disabled and will call this function unconditionally.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1432241016

From smarks at openjdk.org  Wed Dec 20 05:07:48 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 20 Dec 2023 05:07:48 GMT
Subject: RFR: 6356745: (coll) Add PriorityQueue(Collection,
 Comparator) [v2]
In-Reply-To: <0zbcP0oCH4BdtaVJso5onAW_5Hjzpf9T_auYdDDBYc8=.2d9c3211-aa8a-4925-8c08-12a395f625df@github.com>
References: <zAcGyJ33ZP0osNg-HMJp4UCtOXYzdqi969ugDhJ7954=.c5f8e2de-cfe8-4224-a98e-70f49da9a7a3@github.com>
 <coAODM-9CtXAmbfpMxBU6wEYu6DXFOJB6OHV_cVo0L4=.978b09e9-1231-4ff3-ac97-e6b40816bc36@github.com>
 <Hrv4ZAhQ0Rtc6jGWLOqKH_TjHPdJ7yrE8Jx1vSbbaBU=.12b0179d-6fed-4f28-b12c-a2b7564cf8cc@github.com>
 <0zbcP0oCH4BdtaVJso5onAW_5Hjzpf9T_auYdDDBYc8=.2d9c3211-aa8a-4925-8c08-12a395f625df@github.com>
Message-ID: <BpvY-fOqoRafv8pAYWaWQXf2Vpd2cfqIrN-XIleVi68=.90b0d762-4945-45cf-ab41-7ed7b880c704@github.com>

On Tue, 19 Dec 2023 21:14:40 GMT, Valeh Hajiyev <duke at openjdk.org> wrote:

>> You should update the GitHub PR title to `6356745: (coll) Add PriorityQueue(Collection, Comparator)` to match the JBS issue title.
>> 
>> In addition, you will need a [CSR](https://wiki.openjdk.org/display/csr) as the bot tells you. Its prompt is like:
>> 
>> Summary
>> A concise description of the proposed change. The description should be one to two sentences long and written to be reusable in documents aggregating changes for a release.
>> 
>> Problem
>> A brief description of the problem, optionally including the motivation for developing a solution.
>> 
>> Solution
>> An overview of the solution. Alternative solutions may be discussed; links to rationale documents or review threads welcome to provide additional background to reviewers.
>> 
>> Specification
>> The detailed changes. Acceptable normative formats include inline patches, attached webrevs, and attached specdiffs. The names of attached files are recommended to include a bug id. References to external webservers, such as http://cr.openjdk.java.net/, can be provided as informative supplements for the convenience of reviewers, but must be accompanied by a normative form of the specification directly associated with the CSR issue to satisfy archival purposes.
>> 
>> 
>> I can create one for you, and here's my proposed CSR content:
>> 
>> Summary
>> Add a new constructor to PriorityQueue that takes a Collection and a Comparator.
>> 
>> Problem
>> Creating a PriorityQueue with an existing Collection and a custom Comparator is inefficient; it can use heapify which is `O(N)` in time complexity, but it currently has to be done via `addAll`, which has `O(N log N)` time complexity.
>> 
>> Solution
>> Add a new constructor `PriorityQueue(Collection, Comparator)` to explicitly allow the heapify process when a custom comparator is given. This constructor would be in pair with `PriorityQueue(Collection)`, as all other PriorityQueue constructors come in natural-order and comparator pairs (`()` and `(Comparator)`, `(int)` and `(int, Comparator)` ones)
>> 
>> An alternative solution would be to override `addAll(Collection)` to call `initFromCollection` when the PriorityQueue is empty. This would have the same effect as the new constructor and is applicable to all empty PriorityQueues, but doesn't solve the parity issue mentioned above.
>> 
>> Specification
>>     --- a/src/java.base/share/classes/java/util/PriorityQueue.java
>>     +++ b/src/java.base/share/classes/java/util/PriorityQueue.java
>>     @@ -209,6 +209,25 @@ else if (c instanc...
>
> @liach thanks for the help. I updated the PR title, also your proposed CSR content looks good to me. would you mind creating it with your proposed content?

@valeh

Hello, thanks for contributing this change. I can sponsor it.

Changes to the JDK such as this one require tests to be included. You can see some PriorityQueue tests in test/jdk/java/util/PriorityQueue. However, it looks like these are tests for specific features and bugfixes. A comprehensive set of tests resides in test/jdk/java/util/concurrent/tck/PriorityQueueTest.java. It might be best to add a test case for the new constructor there.

In addition, changes such as this will require a release note. I've added the `release-note=yes` label to the bug report to indicate this. The release note process is documented in the Developer's Guide here:

https://openjdk.org/guide/#release-notes

@liach 

Thanks for starting the CSR draft. It looks straightforward enough so far; a couple quick comments. 1) It's not necessary to include the implementation in the CSR, just the specification (or specification changes or diffs) and the method signature. 2) You might want to wait until the spec wording settles down before creating the CSR, otherwise you'll have to keep them in sync continually.

--

In passing, I note this Stack Overflow answer in response to a question about the lack of a PriorityQueue(Collection, Comparator) constructor:

https://stackoverflow.com/questions/66170496/java-priority-queue-build-heap-process-time-complexity/66174529#66174529

In the discussion of this bug report, I think we believe that constructing a PQ with the new constructor should be faster than constructing one with a Comparator and then calling addAll(), but this SO answer seems to indicate that this new constructor isn't necessary. I'm kind of skeptical of this, though. It would be good to have some confirmation that the new constructor indeed provides a performance improvement. Note however that benchmarking can easily turn into a distraction and a time sink, so I don't think a benchmark is required for this change. However, if somebody wants to try something out, please do so. If suitable, a benchmark could be added somewhere in the test/micro hierarchy (possibly as part of a different PR).

Finally, please note that with the holiday season, I'm planning to take several days away from work, so I might not respond quickly, but I eventually will.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17045#issuecomment-1863858667

From smarks at openjdk.org  Wed Dec 20 05:14:48 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 20 Dec 2023 05:14:48 GMT
Subject: RFR: 6356745: (coll) Add PriorityQueue(Collection,
 Comparator) [v4]
In-Reply-To: <3BInvmLUo5T1-DimTKsJ5DDcRwYUyNe5n3UqRr9tTs4=.886b4dfe-65ed-4476-9314-ce27759c034a@github.com>
References: <zAcGyJ33ZP0osNg-HMJp4UCtOXYzdqi969ugDhJ7954=.c5f8e2de-cfe8-4224-a98e-70f49da9a7a3@github.com>
 <3BInvmLUo5T1-DimTKsJ5DDcRwYUyNe5n3UqRr9tTs4=.886b4dfe-65ed-4476-9314-ce27759c034a@github.com>
Message-ID: <VifOwyf2eL69Aj79HQY8aAtzrsrkWnFkJOTvF6Z1Ic4=.67b542ad-4cf2-403f-a93d-26c9eb23ee42@github.com>

On Tue, 19 Dec 2023 21:17:02 GMT, Valeh Hajiyev <duke at openjdk.org> wrote:

>> This commit addresses the current limitation in the `PriorityQueue` implementation, which lacks a constructor to efficiently create a priority queue with a custom comparator and an existing collection. In order to create such a queue, we currently need to initialize a new queue with custom comparator, and after that populate the queue using `addAll()` method, which in the background calls `add()` method (which takes `O(logn)` time) for each element of the collection (`n` times).  This is resulting in an overall time complexity of `O(nlogn)`. 
>> 
>> 
>> PriorityQueue<String> pq = new PriorityQueue<>(customComparator);
>> pq.addAll(existingCollection);
>> 
>> 
>> The pull request introduces a new constructor to streamline this process and reduce the time complexity to `O(n)`.  If you create the queue above using the new constructor, the contents of the collection will be copied (which takes `O(n)` time) and then later  `heapify()` operation (Floyd's algorithm) will be called once (another `O(n)` time). Overall the operation will be reduced from `O(nlogn)` to `O(2n)` -> `O(n)` time.
>> 
>> 
>> PriorityQueue<String> pq = new PriorityQueue<>(existingCollection, customComparator);
>
> Valeh Hajiyev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated the javadoc

src/java.base/share/classes/java/util/PriorityQueue.java line 216:

> 214:      * specified collection. The {@code PriorityQueue} will order the
> 215:      * priority queue's elements elements according to the specified
> 216:      * comparator.

I know you updated this in response to Alan's comment, but the second sentence now says "elements elements". And repeating "priority queue" sounds somewhat redundant. Suggestion for the second sentence:

> The elements of the new {@code PriorityQueue} will be ordered according to
> the specified comparator.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17045#discussion_r1432255396

From alanb at openjdk.org  Wed Dec 20 08:05:06 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Dec 2023 08:05:06 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v8]
In-Reply-To: <m3pEt7BjebAgGp1zZpD1LPyYKivqVkSuHGr-D6f-sVo=.f1ce13c8-c470-4ac1-882d-d9786a1a3f85@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
 <EwkIDbTs7wG5q6lcikgo0ycMFRpu5VXxvMbR3tOPAM8=.40c169b6-57df-4dc7-8726-fd6d8439c541@github.com>
 <m3pEt7BjebAgGp1zZpD1LPyYKivqVkSuHGr-D6f-sVo=.f1ce13c8-c470-4ac1-882d-d9786a1a3f85@github.com>
Message-ID: <l9ccGru-LPBEE-BVjVM-buQI78OiaXupEfDRfCBA4ao=.e8ae4d5e-0eef-4868-a028-238ab101b32e@github.com>

On Wed, 20 Dec 2023 04:44:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

> You can't do this! The Java code knows nothing about JVM TI being enabled/disabled and will call this function unconditionally.

Indeed. I wonder if anyone is testing minimal builds to catch issues like this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1432377494

From goetz at openjdk.org  Wed Dec 20 08:06:53 2023
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Wed, 20 Dec 2023 08:06:53 GMT
Subject: RFR: 8322417: Console read line with zero out should zero out when
 throwing exception
In-Reply-To: <OQ2mDsSWRLfNxXO0BapseECzeKY91cHesHXBQNKwNDU=.17212cbf-e920-4b99-8f70-8056f1d14fc3@github.com>
References: <OQ2mDsSWRLfNxXO0BapseECzeKY91cHesHXBQNKwNDU=.17212cbf-e920-4b99-8f70-8056f1d14fc3@github.com>
Message-ID: <iiNbgLkRmD9T6fzk6SPDWV5Vlv1fUPpzRLC1I3lXQpY=.dd04faaf-97cd-4a8d-a68d-a4e45884eff8@github.com>

On Tue, 19 Dec 2023 12:47:53 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

> ?g exception
> 
> After leaving the method by throwing an exception the data can not be cleaned any more.

Thanks for the reviews!

SAPs nigthly testing passed for this change.

Sorry, I saw the java.uti. comment too late :(

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17156#issuecomment-1864024998
PR Comment: https://git.openjdk.org/jdk/pull/17156#issuecomment-1864029388

From goetz at openjdk.org  Wed Dec 20 08:06:54 2023
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Wed, 20 Dec 2023 08:06:54 GMT
Subject: Integrated: 8322417: Console read line with zero out should zero out
 when throwing exception
In-Reply-To: <OQ2mDsSWRLfNxXO0BapseECzeKY91cHesHXBQNKwNDU=.17212cbf-e920-4b99-8f70-8056f1d14fc3@github.com>
References: <OQ2mDsSWRLfNxXO0BapseECzeKY91cHesHXBQNKwNDU=.17212cbf-e920-4b99-8f70-8056f1d14fc3@github.com>
Message-ID: <Fwy3F7CAEJj9SOD9cYeV8Nhd5QL8yhhWxv-AHilBDfk=.2cce18a6-4cc2-4cee-85b7-0a1e1ca790aa@github.com>

On Tue, 19 Dec 2023 12:47:53 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

> ?g exception
> 
> After leaving the method by throwing an exception the data can not be cleaned any more.

This pull request has now been integrated.

Changeset: 2f917bff
Author:    Goetz Lindenmaier <goetz at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2f917bff5cbb71dccd70960f563ca1a05d109fda
Stats:     10 lines in 1 file changed: 9 ins; 0 del; 1 mod

8322417: Console read line with zero out should zero out when throwing exception

Reviewed-by: mbaesken, stuefe, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/17156

From alanb at openjdk.org  Wed Dec 20 08:10:47 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Dec 2023 08:10:47 GMT
Subject: RFR: 8322417: Console read line with zero out should zero out when
 throwing exception
In-Reply-To: <OQ2mDsSWRLfNxXO0BapseECzeKY91cHesHXBQNKwNDU=.17212cbf-e920-4b99-8f70-8056f1d14fc3@github.com>
References: <OQ2mDsSWRLfNxXO0BapseECzeKY91cHesHXBQNKwNDU=.17212cbf-e920-4b99-8f70-8056f1d14fc3@github.com>
Message-ID: <PTF-6aGprJfpvAvaG0WAYkjn8LXs8ZPtXLkcyvqdQqc=.bc64adf1-f8e7-428a-afd3-88d49d4fbbda@github.com>

On Tue, 19 Dec 2023 12:47:53 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

> ?g exception
> 
> After leaving the method by throwing an exception the data can not be cleaned any more.

src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 122:

> 120:                             ioe.addSuppressed(x);
> 121:                     }
> 122:                     if (ioe != null) {

I assume it's only important to zero the buffer when restoring the echo setting fails. If I read the changes correctly then it's been zero's even if readLine fails. It's okay, just probably unnecessary for that case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17156#discussion_r1432381996

From dfuchs at openjdk.org  Wed Dec 20 08:34:51 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 20 Dec 2023 08:34:51 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v3]
In-Reply-To: <mTgctICvSwPCTJQi2aDT4QmXeiCaqlpNe_k5Cbk38Cg=.9415b7e2-23bb-451b-b435-3545e27479d0@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <_8M6KPN0UJHeW1cx31IW0mIfaXG5ls5nUfZ0TwxMdAs=.fd4facc4-91d4-4117-9b1f-a2cc1806d2b7@github.com>
 <gOPRdEq2C_00uEZZZ7lbNIOPX691FD56u5AwpCgvv3A=.dfd20a18-b42a-49bd-b8e6-9b6b5ea3375f@github.com>
 <e7BeWWxzk-MqiZ4b0QMrnV_UhhjKFtZgUBzkV2wqX_M=.d65e9ba0-c1ed-43d9-a50c-b8452c537d75@github.com>
 <fppK-cFkXoPVGEkFdrNiulF52OlgHSjBk6np1uM1or4=.70796d1e-8515-484b-b324-72e6a77d7250@github.com>
 <LSDvl7Fa7yE5ZUulDOs3lvllMaevk9viTuBm5f5XhGQ=.0f52163a-9a6a-4b07-ac25-811c68166dcc@github.com>
 <mTgctICvSwPCTJQi2aDT4QmXeiCaqlpNe_k5Cbk38Cg=.9415b7e2-23bb-451b-b435-3545e27479d0@github.com>
Message-ID: <M3B-RXkUp7mUgagNSSt4MFGEWYrhEZBRdomCIJ9kCes=.171736ec-be0d-45f9-8a37-ae0d60b7c12e@github.com>

On Tue, 19 Dec 2023 19:39:22 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> What about fixed `String`s rather than `int`s for the kind of error?
>> Something like `"SUID_INEFFECTIVE_ON_ENUM"`, and so on?
>> It would be nice to be able to use enums, but AFAIK that's not supported in JFR.
>
> You could define them with an Enum but use the ordinal as the value for JFR.

Same remark here about finality as https://github.com/openjdk/jdk/pull/17129#discussion_r1432400888. public statics should be final.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1432402527

From dfuchs at openjdk.org  Wed Dec 20 08:34:49 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 20 Dec 2023 08:34:49 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v4]
In-Reply-To: <I3hvzqeC4IG1kMeR0eBd5eQrKRy-tTjRR7LGojVir9g=.61da50a2-c07a-44fc-bcb1-a1291c1ae650@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <XlnL2mY6CwDlnA_KPw-IRVx9QAJaXKEaS0cnMfc_0xk=.7783dbb7-3988-4319-9b85-2ac45fc26759@github.com>
 <e-xe6KF01q-kqiws3Lh6OOm0gbyV-NAh9fkSt22ASxY=.a022fa86-4c0b-484b-997d-cc92a1e45247@github.com>
 <I3hvzqeC4IG1kMeR0eBd5eQrKRy-tTjRR7LGojVir9g=.61da50a2-c07a-44fc-bcb1-a1291c1ae650@github.com>
Message-ID: <-0hCh3zRb_gxLlZ9RQaeVh3pgxXZShI8FCNE-RG2NIU=.fa6c30c2-2b7c-4d10-aed4-b6095d358939@github.com>

On Tue, 19 Dec 2023 16:00:09 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/event/SerializationMisdeclarationEvent.java line 94:
>> 
>>> 92: 
>>> 93:     /*
>>> 94:      * These constants are not final on purpose.
>> 
>> Just curious - what's the purpose? I don't see them being changed/updated anywhere (not even in tests).
>
> Declaring a `public static int` field `final` means that the value is then stored in the client class. If a value is changed, then the client needs to be recompiled as well, but this is not enforced by the language, so it might lead to inconsistencies.
> 
> The clean solution would be to use an enum class, but that's not supported by JFR.

Not having them final is a quite smelly. I would suggest to make them final with a comment that new values can be added but that existing values must not be changed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1432400888

From duke at openjdk.org  Wed Dec 20 09:49:41 2023
From: duke at openjdk.org (Markus KARG)
Date: Wed, 20 Dec 2023 09:49:41 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred [v4]
In-Reply-To: <DcqFoeac1QjH_W5DzKMWIigdheVlgrH6Zs59p-z6UR0=.8b83adb5-e56b-4ee9-a732-b656a133be6f@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
 <MgqxdnIJbR-Kan1rvnLN0M63R5zLUcThXNHvdJDGCP4=.77f9b25a-12fa-4edb-935b-eb19196da8da@github.com>
 <DcqFoeac1QjH_W5DzKMWIigdheVlgrH6Zs59p-z6UR0=.8b83adb5-e56b-4ee9-a732-b656a133be6f@github.com>
Message-ID: <ZqBxQhs0xDSKqasEtj4nVYF4sNf4pjxP3TbRy355NxM=.a152b16a-0e14-4797-aa97-fd5d65b5d876@github.com>

On Tue, 19 Dec 2023 18:20:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Approved.
> 
> Please note in future that it is better not to `/integrate` until the request has actually been approved by a Reviewer.

Alan actually did approve them on December 15.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17119#issuecomment-1864164861

From stsypanov at openjdk.org  Wed Dec 20 10:11:58 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 20 Dec 2023 10:11:58 GMT
Subject: RFR: 8322292: Rearrange comparison of fields in Record.equals()
 [v4]
In-Reply-To: <eNySqrZ9HgZrjF61lHA_6YecuPT7RB9xxz82U3zIjog=.f8b68ce5-3fab-4cfa-8709-17e51d77a958@github.com>
References: <eNySqrZ9HgZrjF61lHA_6YecuPT7RB9xxz82U3zIjog=.f8b68ce5-3fab-4cfa-8709-17e51d77a958@github.com>
Message-ID: <zpp5vJWq4GGvFjnLrlv2ZjnxqOhvd6J_sP5SQUJm98Y=.0cc71327-4c31-4b4d-b647-d6072bbeffff@github.com>

> Currently if we create a record it's fields are compared in their declaration order. This might be ineffective in cases when two objects have "heavy" fields equals to each other, but different "lightweight" fields (heavy and lightweight in terms of comparison) e.g. primitives, enums, nullable/non-nulls etc.
> 
> If we have declared a record like
> 
> public record MyRecord(String field1, int field2) {}
> 
> It's equals() looks like:
> 
>   public final equals(Ljava/lang/Object;)Z
>    L0
>     LINENUMBER 3 L0
>     ALOAD 0
>     ALOAD 1
>     INVOKEDYNAMIC equals(Lcom/caspianone/openbanking/productservice/controller/MyRecord;Ljava/lang/Object;)Z [
>       // handle kind 0x6 : INVOKESTATIC
>       java/lang/runtime/ObjectMethods.bootstrap(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/TypeDescriptor;Ljava/lang/Class;Ljava/lang/String;[Ljava/lang/invoke/MethodHandle;)Ljava/lang/Object;
>       // arguments:
>       com.caspianone.openbanking.productservice.controller.MyRecord.class,
>       "field1;field2",
>       // handle kind 0x1 : GETFIELD
>       com/caspianone/openbanking/productservice/controller/MyRecord.field1(Ljava/lang/String;),
>       // handle kind 0x1 : GETFIELD
>       com/caspianone/openbanking/productservice/controller/MyRecord.field2(I)
>     ]
>     IRETURN
>    L1
>     LOCALVARIABLE this Lcom/caspianone/openbanking/productservice/controller/MyRecord; L0 L1 0
>     LOCALVARIABLE o Ljava/lang/Object; L0 L1 1
>     MAXSTACK = 2
>     MAXLOCALS = 2
> 
> This can be improved by rearranging the comparison order of the fields moving enums and primitives upper, and collections/arrays lower.

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  8322292: Tiny improvement

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17143/files
  - new: https://git.openjdk.org/jdk/pull/17143/files/dded977f..9c8ae4fb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17143&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17143&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17143/head:pull/17143

PR: https://git.openjdk.org/jdk/pull/17143

From duke at openjdk.org  Wed Dec 20 10:12:44 2023
From: duke at openjdk.org (Markus KARG)
Date: Wed, 20 Dec 2023 10:12:44 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred [v4]
In-Reply-To: <KCbi1Ao4WYyTZ2FXlmBC6ehIKimsPWrW1ecFO6q1Bio=.7d17b6d8-0d46-4af0-95cf-b04033ee1493@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
 <MgqxdnIJbR-Kan1rvnLN0M63R5zLUcThXNHvdJDGCP4=.77f9b25a-12fa-4edb-935b-eb19196da8da@github.com>
 <KCbi1Ao4WYyTZ2FXlmBC6ehIKimsPWrW1ecFO6q1Bio=.7d17b6d8-0d46-4af0-95cf-b04033ee1493@github.com>
Message-ID: <pTRH4Sl-AEPAzNSpx4mlxKkRi4ROk481qkN7HUiPsaA=.a64eaa00-b8c3-46f8-b7ca-38062d1f76c8@github.com>

On Tue, 19 Dec 2023 18:31:19 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test was using Integer but must use Long
>
> I verified that the test now fails without the source change but passes with it.

@bplb Apparently Skara wants you to repeat your sponsoring again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17119#issuecomment-1864199779

From aturbanov at openjdk.org  Wed Dec 20 10:40:53 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 20 Dec 2023 10:40:53 GMT
Subject: RFR: 8321786: SegmentAllocator:allocateFrom(ValueLayout,
 MemorySegment, ValueLayout, long,
 long) spec mismatch in exception scenario [v7]
In-Reply-To: <fIgTI18rDEAOjj1I2lsKGD8-fLIvLxKijZVY-0alQos=.d776b77e-1415-4952-9de8-baf43960b5f5@github.com>
References: <-VY5wYQXjxv1dg1I0pqwcsONzuSQDcKVLIST-4HJUqw=.360b5491-8d6d-48fd-acb1-7e477e71d654@github.com>
 <fIgTI18rDEAOjj1I2lsKGD8-fLIvLxKijZVY-0alQos=.d776b77e-1415-4952-9de8-baf43960b5f5@github.com>
Message-ID: <5QGz_J0fAoeGSmI-6mc7hwLCda3j-25TqgxPGX0c6zA=.06631abb-f142-4ae2-8c00-f82efd9ee3ca@github.com>

On Tue, 12 Dec 2023 15:45:47 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to change the specification for some methods that take `long` offsets so that they will throw an `IllegalArgumentException` rather than an `IndexOutOfBoundsException` for negative values.
>> 
>> The PR also proposes to fix a bug where the allocation size would overflow and the specified exception was not thrown.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move @throws tag

test/jdk/java/foreign/TestSegmentCopy.java line 183:

> 181:         byte[] dst = new byte[] {1, 2, 3, 4};
> 182:         assertThrows(IndexOutOfBoundsException.class, () ->
> 183:                 MemorySegment.copy(src, JAVA_BYTE, -1, dst,0, 4)

Suggestion:

                MemorySegment.copy(src, JAVA_BYTE, -1, dst, 0, 4)

test/jdk/java/foreign/TestSegmentCopy.java line 186:

> 184:         );
> 185:         assertThrows(IndexOutOfBoundsException.class, () ->
> 186:                 MemorySegment.copy(src, JAVA_BYTE, 0, dst,-1, 4)

Suggestion:

                MemorySegment.copy(src, JAVA_BYTE, 0, dst, -1, 4)

test/jdk/java/foreign/TestSegmentCopy.java line 189:

> 187:         );
> 188:         assertThrows(IndexOutOfBoundsException.class, () ->
> 189:                 MemorySegment.copy(src, JAVA_BYTE, 0, dst,0, -1)

Suggestion:

                MemorySegment.copy(src, JAVA_BYTE, 0, dst, 0, -1)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17079#discussion_r1432545779
PR Review Comment: https://git.openjdk.org/jdk/pull/17079#discussion_r1432546057
PR Review Comment: https://git.openjdk.org/jdk/pull/17079#discussion_r1432546260

From sspitsyn at openjdk.org  Wed Dec 20 10:42:59 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 20 Dec 2023 10:42:59 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v8]
In-Reply-To: <l9ccGru-LPBEE-BVjVM-buQI78OiaXupEfDRfCBA4ao=.e8ae4d5e-0eef-4868-a028-238ab101b32e@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
 <EwkIDbTs7wG5q6lcikgo0ycMFRpu5VXxvMbR3tOPAM8=.40c169b6-57df-4dc7-8726-fd6d8439c541@github.com>
 <m3pEt7BjebAgGp1zZpD1LPyYKivqVkSuHGr-D6f-sVo=.f1ce13c8-c470-4ac1-882d-d9786a1a3f85@github.com>
 <l9ccGru-LPBEE-BVjVM-buQI78OiaXupEfDRfCBA4ao=.e8ae4d5e-0eef-4868-a028-238ab101b32e@github.com>
Message-ID: <KwtMPcY1e45DC5i0xJ1DFGtVz2rVJsIBvgTA6w6UsLs=.3621cd02-67d2-4bb3-844b-7383cbdc78d9@github.com>

On Wed, 20 Dec 2023 08:02:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/hotspot/share/prims/jvm.cpp line 4024:
>> 
>>> 4022: #else
>>> 4023:   fatal("Should only be called with JVMTI enabled");
>>> 4024: #endif
>> 
>> You can't do this! The Java code knows nothing about JVM TI being enabled/disabled and will call this function unconditionally.
>
>> You can't do this! The Java code knows nothing about JVM TI being enabled/disabled and will call this function unconditionally.
> 
> Indeed. I wonder if anyone is testing minimal builds to catch issues like this.

Good catch, David!
Filed a cleanup bug: https://bugs.openjdk.org/browse/JDK-8322538

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1432548911

From rgiulietti at openjdk.org  Wed Dec 20 11:14:42 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 20 Dec 2023 11:14:42 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v4]
In-Reply-To: <q0r65enUkcI9FACjbEt02JtmUrTtaxQvYAfvzy7LNY8=.d3fa8691-8063-42db-bf4d-7b88eaa6c953@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <XlnL2mY6CwDlnA_KPw-IRVx9QAJaXKEaS0cnMfc_0xk=.7783dbb7-3988-4319-9b85-2ac45fc26759@github.com>
 <q0r65enUkcI9FACjbEt02JtmUrTtaxQvYAfvzy7LNY8=.d3fa8691-8063-42db-bf4d-7b88eaa6c953@github.com>
Message-ID: <kVN9hfDGJnHfN6SUyzM11Tm8OQ3qPzu-xUenkGru6rw=.52758f12-c5e2-431d-ba31-3b6286617622@github.com>

On Tue, 19 Dec 2023 19:19:35 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Better name for a label, corrected name of removed field.
>
> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 108:
> 
>> 106:                     SUID_NAME + " should be declared of type long");
>> 107:         }
>> 108:         if (!isStatic(f)) {
> 
> The two calls to isStatic could be reordered closer together to be a single if (isstatic()) { ... } else {... }.

I guess you are looking to an older commit?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1432581987

From alanb at openjdk.org  Wed Dec 20 14:19:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Dec 2023 14:19:04 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v8]
In-Reply-To: <EwkIDbTs7wG5q6lcikgo0ycMFRpu5VXxvMbR3tOPAM8=.40c169b6-57df-4dc7-8726-fd6d8439c541@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
 <EwkIDbTs7wG5q6lcikgo0ycMFRpu5VXxvMbR3tOPAM8=.40c169b6-57df-4dc7-8726-fd6d8439c541@github.com>
Message-ID: <wRxh33DFXd4sEYOhUe11uBf0ERpHwU6RsW-E-gJQAI8=.9bcc0bf4-48e8-4cad-b7df-86e83d1e4097@github.com>

On Mon, 18 Dec 2023 17:09:59 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fix is for JDK 23 but the intention is to back port it to 22 in RDP-1 time frame.
>> It is fixing a deadlock issue between `VirtualThread` class critical sections with the `interruptLock` (in methods: `unpark()`, `interrupt()`, `getAndClearInterrupt()`, `threadState()`, `toString()`), `JvmtiVTMSTransitionDisabler` and JVMTI `Suspend/Resume` mechanisms.
>> The deadlocking scenario is well described by Patricio in a bug report comment.
>> In simple words, a virtual thread should not be suspended during 'interruptLock' critical sections.
>> 
>> The fix is to record that a virtual thread is in a critical section (`JavaThread`'s `_in_critical_section` bit) by notifying the VM/JVMTI about begin/end of critical section.
>> This bit is used in `HandshakeState::get_op_for_self()` to filter out any `HandshakeOperation` if a target `JavaThread` is in a critical section.
>> 
>> Some of new notifications with `notifyJvmtiSync()` method is on a performance critical path. It is why this method has been intrincified.
>> 
>> New test was developed by Patricio:
>>  `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
>> The test is very nice as it reliably in 100% reproduces the deadlock without the fix.
>> The test is never failing with this fix.
>> 
>> Testing:
>>  - tested with newly added test: `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge
>  - review: improve an assert message
>  - review: moved a couple of comments out of try blocks
>  - review: moved notifyJvmtiDisableSuspend(true) out of try-block
>  - review: 1) replace CriticalLock with DisableSuspend; 2) minor tweaks
>  - review: (1) rename notifyJvmti method; (2) add try-final statements to VirtualThread methods
>  - Resolved merge conflict in VirtualThread.java
>  - added @summary to new test SuspendWithInterruptLock.java
>  - add new test SuspendWithInterruptLock.java
>  - 8311218: fatal error: stuck in JvmtiVTMSTransitionDisabler::VTMS_transition_disable

src/hotspot/share/runtime/javaThread.hpp line 652:

> 650: 
> 651:   bool is_disable_suspend() const                { return _is_disable_suspend; }
> 652:   void toggle_is_disable_suspend()               { _is_disable_suspend = !_is_disable_suspend; };

Looking at this again then I don't think it can be a bit that is toggled on and off will work. Consider the case where several threads attempt to poll the state of a virtual Thread with Thread::getState at the same time. This can't work without an atomic counter and further coordination. So I think further work is required on this issue.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1432770204

From rriggs at openjdk.org  Wed Dec 20 14:19:51 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 20 Dec 2023 14:19:51 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v3]
In-Reply-To: <M3B-RXkUp7mUgagNSSt4MFGEWYrhEZBRdomCIJ9kCes=.171736ec-be0d-45f9-8a37-ae0d60b7c12e@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <_8M6KPN0UJHeW1cx31IW0mIfaXG5ls5nUfZ0TwxMdAs=.fd4facc4-91d4-4117-9b1f-a2cc1806d2b7@github.com>
 <gOPRdEq2C_00uEZZZ7lbNIOPX691FD56u5AwpCgvv3A=.dfd20a18-b42a-49bd-b8e6-9b6b5ea3375f@github.com>
 <e7BeWWxzk-MqiZ4b0QMrnV_UhhjKFtZgUBzkV2wqX_M=.d65e9ba0-c1ed-43d9-a50c-b8452c537d75@github.com>
 <fppK-cFkXoPVGEkFdrNiulF52OlgHSjBk6np1uM1or4=.70796d1e-8515-484b-b324-72e6a77d7250@github.com>
 <LSDvl7Fa7yE5ZUulDOs3lvllMaevk9viTuBm5f5XhGQ=.0f52163a-9a6a-4b07-ac25-811c68166dcc@github.com>
 <mTgctICvSwPCTJQi2aDT4QmXeiCaqlpNe_k5Cbk38Cg=.9415b7e2-23bb-451b-b435-3545e27479d0@github.com>
 <M3B-RXkUp7mUgagNSSt4MFGEWYrhEZBRdomCIJ9kCes=.171736ec-be0d-45f9-8a37-ae0d60b7c12e@github.com>
Message-ID: <Ggza0fmS9G92lfZsaMRk481LD40h-S7X5Zyc6M0jxAg=.329339de-da03-46d6-858c-0087f6ccf686@github.com>

On Wed, 20 Dec 2023 08:29:19 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> You could define them with an Enum but use the ordinal as the value for JFR.
>
> Same remark here about finality as https://github.com/openjdk/jdk/pull/17129#discussion_r1432400888. public statics should be final.

I'd also remove the error codes, the string messages will be pretty stable and the extra surface area of the constants is just maintenance overhead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1432772028

From rriggs at openjdk.org  Wed Dec 20 14:24:51 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 20 Dec 2023 14:24:51 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v5]
In-Reply-To: <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com>
Message-ID: <U6sbty-LIZoA7RGD-xkGTF-aJ7PHjeajz195PX7n20M=.279fcfd7-fd71-48ef-8857-54b2753ed687@github.com>

On Tue, 19 Dec 2023 16:45:04 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes according to reviewer's comments.

src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 113:

> 111:             if (longFromStatic(f) == null) {
> 112:                 commitEvent(SUID_CONVERTIBLE_TO_LONG,
> 113:                         SUID_NAME + " must be convertible to long via widening to be effective");

The serialization spec only shows using long.  If any recommendation is made it should be to declare the field as a `long`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1432778556

From rriggs at openjdk.org  Wed Dec 20 14:31:54 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 20 Dec 2023 14:31:54 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v5]
In-Reply-To: <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com>
Message-ID: <2yRrfqmGcf3cIYkaaNuVXMzLQ6jNKoOCKZJXuYcwbgk=.b16d767f-88b1-47f6-a4bb-98d6c435401e@github.com>

On Tue, 19 Dec 2023 16:45:04 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes according to reviewer's comments.

It would also be useful/interesting to include a test that checks every Serializable class (by  Invoking `ObjectStreamClass.lookup(clazz)`) in the Java runtime and reports any jfr events.  
Fixing them would be a separate task.  The compiler warnings from last year should have fixed most/many non-conforming classes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17129#issuecomment-1864569540

From rgiulietti at openjdk.org  Wed Dec 20 15:06:53 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 20 Dec 2023 15:06:53 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v5]
In-Reply-To: <2yRrfqmGcf3cIYkaaNuVXMzLQ6jNKoOCKZJXuYcwbgk=.b16d767f-88b1-47f6-a4bb-98d6c435401e@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com>
 <2yRrfqmGcf3cIYkaaNuVXMzLQ6jNKoOCKZJXuYcwbgk=.b16d767f-88b1-47f6-a4bb-98d6c435401e@github.com>
Message-ID: <HkiH11EVsyZna7xzTrMG-qmims-l-QX7GEhXT6EqVQw=.87c0d76c-2982-4956-bb15-c54aeda07357@github.com>

On Wed, 20 Dec 2023 14:28:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changes according to reviewer's comments.
>
> It would also be useful/interesting to include a test that checks every Serializable class (by  Invoking `ObjectStreamClass.lookup(clazz)`) in the Java runtime and reports any jfr events.  
> Fixing them would be a separate task.  The compiler warnings from last year should have fixed most/many non-conforming classes.

@RogerRiggs Do you mean a permanent test in the codebase, or just a throwaway run? Anyway, interesting suggestion.

> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 113:
> 
>> 111:             if (longFromStatic(f) == null) {
>> 112:                 commitEvent(SUID_CONVERTIBLE_TO_LONG,
>> 113:                         SUID_NAME + " must be convertible to long via widening to be effective");
> 
> The serialization spec only shows using long.  If any recommendation is made it should be to declare the field as a `long`

There's a check on the type at L.104 which is about the "should" recommendation, since serialization does not care about the type of the field being `long`.

This check is about the value at runtime, which is a "must" because serialization expects it to be convertible to long by widening.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17129#issuecomment-1864628102
PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1432827176

From rgiulietti at openjdk.org  Wed Dec 20 15:06:55 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 20 Dec 2023 15:06:55 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v3]
In-Reply-To: <Ggza0fmS9G92lfZsaMRk481LD40h-S7X5Zyc6M0jxAg=.329339de-da03-46d6-858c-0087f6ccf686@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <_8M6KPN0UJHeW1cx31IW0mIfaXG5ls5nUfZ0TwxMdAs=.fd4facc4-91d4-4117-9b1f-a2cc1806d2b7@github.com>
 <gOPRdEq2C_00uEZZZ7lbNIOPX691FD56u5AwpCgvv3A=.dfd20a18-b42a-49bd-b8e6-9b6b5ea3375f@github.com>
 <e7BeWWxzk-MqiZ4b0QMrnV_UhhjKFtZgUBzkV2wqX_M=.d65e9ba0-c1ed-43d9-a50c-b8452c537d75@github.com>
 <fppK-cFkXoPVGEkFdrNiulF52OlgHSjBk6np1uM1or4=.70796d1e-8515-484b-b324-72e6a77d7250@github.com>
 <LSDvl7Fa7yE5ZUulDOs3lvllMaevk9viTuBm5f5XhGQ=.0f52163a-9a6a-4b07-ac25-811c68166dcc@github.com>
 <mTgctICvSwPCTJQi2aDT4QmXeiCaqlpNe_k5Cbk38Cg=.9415b7e2-23bb-451b-b435-3545e27479d0@github.com>
 <M3B-RXkUp7mUgagNSSt4MFGEWYrhEZBRdomCIJ9kCes=.171736ec-be0d-45f9-8a37-ae0d60b7c12e@github.com>
 <Ggza0fmS9G92lfZsaMRk481LD40h-S7X5Zyc6M0jxAg=.329339de-da03-46d6-858c-0087f6ccf686@github.com>
Message-ID: <X2nVzqEpyOYh268SZfVQMqdKAUY-sUx2tqOv91B0Yxc=.4f87dd5c-b7ca-4591-a2b8-a53d533ce24c@github.com>

On Wed, 20 Dec 2023 14:17:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Same remark here about finality as https://github.com/openjdk/jdk/pull/17129#discussion_r1432400888. public statics should be final.
>
> I'd also remove the error codes, the string messages will be pretty stable and the extra surface area of the constants is just maintenance overhead.

Working on that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1432828516

From rriggs at openjdk.org  Wed Dec 20 15:09:58 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 20 Dec 2023 15:09:58 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v5]
In-Reply-To: <HkiH11EVsyZna7xzTrMG-qmims-l-QX7GEhXT6EqVQw=.87c0d76c-2982-4956-bb15-c54aeda07357@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com>
 <2yRrfqmGcf3cIYkaaNuVXMzLQ6jNKoOCKZJXuYcwbgk=.b16d767f-88b1-47f6-a4bb-98d6c435401e@github.com>
 <HkiH11EVsyZna7xzTrMG-qmims-l-QX7GEhXT6EqVQw=.87c0d76c-2982-4956-bb15-c54aeda07357@github.com>
Message-ID: <jEEV5rqhYzmE2-bChIj_J8lN64JJmlDp9YazJSYKitI=.9203bf5b-94a1-4b38-b175-a4437f588d81@github.com>

On Wed, 20 Dec 2023 15:01:02 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 113:
>> 
>>> 111:             if (longFromStatic(f) == null) {
>>> 112:                 commitEvent(SUID_CONVERTIBLE_TO_LONG,
>>> 113:                         SUID_NAME + " must be convertible to long via widening to be effective");
>> 
>> The serialization spec only shows using long.  If any recommendation is made it should be to declare the field as a `long`
>
> There's a check on the type at L.104 which is about the "should" recommendation, since serialization does not care about the type of the field being `long`.
> 
> This check is about the value at runtime, which is a "must" because serialization expects it to be convertible to long by widening.

The implementation should not show through. I don't remember if the particular implementation was intentional or just a shortcut to get the value. But any suggestion that implies a fix should be to recommend the best practice.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1432834402

From rriggs at openjdk.org  Wed Dec 20 15:12:56 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 20 Dec 2023 15:12:56 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v5]
In-Reply-To: <2yRrfqmGcf3cIYkaaNuVXMzLQ6jNKoOCKZJXuYcwbgk=.b16d767f-88b1-47f6-a4bb-98d6c435401e@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com>
 <2yRrfqmGcf3cIYkaaNuVXMzLQ6jNKoOCKZJXuYcwbgk=.b16d767f-88b1-47f6-a4bb-98d6c435401e@github.com>
Message-ID: <TR75Bnc3Wh_sgKFRyTyBsFyJ1mnXIka6Nfn2m6bMsts=.a9674615-742c-4001-a364-dab1e1edf3c9@github.com>

On Wed, 20 Dec 2023 14:28:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changes according to reviewer's comments.
>
> It would also be useful/interesting to include a test that checks every Serializable class (by  Invoking `ObjectStreamClass.lookup(clazz)`) in the Java runtime and reports any jfr events.  
> Fixing them would be a separate task.  The compiler warnings from last year should have fixed most/many non-conforming classes.

> @RogerRiggs Do you mean a permanent test in the codebase, or just a throwaway run? Anyway, interesting suggestion.

A separate PR to add permanent test would advise about the current state and prevent new cases.
If there are cases that can't be fixed (because of some kind of backward compatibility issue), there might need to be an exclusion list.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17129#issuecomment-1864639166

From coffeys at openjdk.org  Wed Dec 20 15:44:06 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 20 Dec 2023 15:44:06 GMT
Subject: RFR: 8322078: ZipSourceCache.testKeySourceMapping() test fails with
 The process cannot access the file because it is being used by another process
Message-ID: <zpE9gY4PyEr3ETGEOwinsdkuE-6d8yRAg5xKshdvZjM=.bcb98f28-3371-4c7a-bede-b9c34c6b5858@github.com>

trivial test edit to use FileUtils.deleteFileIfExistsWithRetry test library API

tested on CI system with test-repeat = 20 - no issues seen.

-------------

Commit messages:
 - 8322078

Changes: https://git.openjdk.org/jdk/pull/17169/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17169&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322078
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17169.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17169/head:pull/17169

PR: https://git.openjdk.org/jdk/pull/17169

From duke at openjdk.org  Wed Dec 20 16:29:59 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Wed, 20 Dec 2023 16:29:59 GMT
Subject: RFR: 8318971 : Better Error Handling for Jar Tool When Processing
 Non-existent Files [v4]
In-Reply-To: <xht1jEn-KP8Fhz4Xa4MBxlhsvlxk3mdAkpdv9dF77oQ=.3fdc9a36-e7da-4230-9b26-40dacb8e92b6@github.com>
References: <xht1jEn-KP8Fhz4Xa4MBxlhsvlxk3mdAkpdv9dF77oQ=.3fdc9a36-e7da-4230-9b26-40dacb8e92b6@github.com>
Message-ID: <yVI-yJS9g5tNnGTT1KHEOJvrYf895NiMn49_p2xHNWI=.ecaaff80-6fd0-4529-aeb0-d597828f00f8@github.com>

> Better Error Handling for Jar Tool Processing of "@File" <br>
> 
> This is a new PR for this PR since the original developer left the team. See all of the review history at https://github.com/openjdk/jdk/pull/16423.
> 
> Thank you.

Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:

  update the test cases

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17088/files
  - new: https://git.openjdk.org/jdk/pull/17088/files/ba9335e0..ff349833

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17088&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17088&range=02-03

  Stats: 39 lines in 1 file changed: 35 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17088.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17088/head:pull/17088

PR: https://git.openjdk.org/jdk/pull/17088

From bpb at openjdk.org  Wed Dec 20 16:56:49 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 20 Dec 2023 16:56:49 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred [v4]
In-Reply-To: <ZqBxQhs0xDSKqasEtj4nVYF4sNf4pjxP3TbRy355NxM=.a152b16a-0e14-4797-aa97-fd5d65b5d876@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
 <MgqxdnIJbR-Kan1rvnLN0M63R5zLUcThXNHvdJDGCP4=.77f9b25a-12fa-4edb-935b-eb19196da8da@github.com>
 <DcqFoeac1QjH_W5DzKMWIigdheVlgrH6Zs59p-z6UR0=.8b83adb5-e56b-4ee9-a732-b656a133be6f@github.com>
 <ZqBxQhs0xDSKqasEtj4nVYF4sNf4pjxP3TbRy355NxM=.a152b16a-0e14-4797-aa97-fd5d65b5d876@github.com>
Message-ID: <pupyLRe_qwP3uStEtzXPgg-yhD8SZOgfbjauDG7AYCw=.0139aa52-733d-4971-928e-7c345908dfa6@github.com>

On Wed, 20 Dec 2023 09:47:05 GMT, Markus KARG <duke at openjdk.org> wrote:

> Alan actually did approve them on December 15.

I know, with requested changes. I didn't see the request transition to "Ready" which is where it needs to be to `/integrate`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17119#issuecomment-1864815013

From bpb at openjdk.org  Wed Dec 20 16:56:50 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 20 Dec 2023 16:56:50 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred [v4]
In-Reply-To: <pupyLRe_qwP3uStEtzXPgg-yhD8SZOgfbjauDG7AYCw=.0139aa52-733d-4971-928e-7c345908dfa6@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
 <MgqxdnIJbR-Kan1rvnLN0M63R5zLUcThXNHvdJDGCP4=.77f9b25a-12fa-4edb-935b-eb19196da8da@github.com>
 <DcqFoeac1QjH_W5DzKMWIigdheVlgrH6Zs59p-z6UR0=.8b83adb5-e56b-4ee9-a732-b656a133be6f@github.com>
 <ZqBxQhs0xDSKqasEtj4nVYF4sNf4pjxP3TbRy355NxM=.a152b16a-0e14-4797-aa97-fd5d65b5d876@github.com>
 <pupyLRe_qwP3uStEtzXPgg-yhD8SZOgfbjauDG7AYCw=.0139aa52-733d-4971-928e-7c345908dfa6@github.com>
Message-ID: <kGBy2rC-vWBntHIS868stwvKha0K6liM_yXstbqa26E=.c4da7d8c-010d-4ab5-8206-1ebcb865fb01@github.com>

On Wed, 20 Dec 2023 16:52:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>>> Approved.
>>> 
>>> Please note in future that it is better not to `/integrate` until the request has actually been approved by a Reviewer.
>> 
>> Alan actually did approve them on December 15.
>
>> Alan actually did approve them on December 15.
> 
> I know, with requested changes. I didn't see the request transition to "Ready" which is where it needs to be to `/integrate`.

> @bplb Apparently Skara wants you to repeat your sponsoring again.

Yes, because the PR was updated since the previous `/integrate`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17119#issuecomment-1864817465

From rgiulietti at openjdk.org  Wed Dec 20 17:00:10 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 20 Dec 2023 17:00:10 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v6]
In-Reply-To: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
Message-ID: <WW2A91JNOREfY5MnvkD_oc79DEM_zRsFvBz3y8-bjJE=.21beb9e1-5542-4f1b-8a41-e9b99ccb9eb2@github.com>

> Adds serialization misdeclaration events to JFR.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Removed event kind.
  serialVersionUID must have type long.
  Test now base on keyword search in event message.
  Commented test classes about misdeclarations.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17129/files
  - new: https://git.openjdk.org/jdk/pull/17129/files/fa04bf48..a6f80250

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=04-05

  Stats: 285 lines in 4 files changed: 87 ins; 96 del; 102 mod
  Patch: https://git.openjdk.org/jdk/pull/17129.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17129/head:pull/17129

PR: https://git.openjdk.org/jdk/pull/17129

From bpb at openjdk.org  Wed Dec 20 17:03:57 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 20 Dec 2023 17:03:57 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred [v4]
In-Reply-To: <QNoioaghcPUdQyFu6keJw5FGPkUmmef4nCLVIGXXDM8=.29e3fc24-9d15-4f52-b4c9-c4df34b0cc33@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
 <MgqxdnIJbR-Kan1rvnLN0M63R5zLUcThXNHvdJDGCP4=.77f9b25a-12fa-4edb-935b-eb19196da8da@github.com>
 <QNoioaghcPUdQyFu6keJw5FGPkUmmef4nCLVIGXXDM8=.29e3fc24-9d15-4f52-b4c9-c4df34b0cc33@github.com>
Message-ID: <XPnVtugbQuLNUCP6NiIl5ypBWhHv1WMTjyJThVSGnxk=.6db84b44-1138-4ffb-b8a7-49f162fe2b99@github.com>

On Wed, 20 Dec 2023 00:56:16 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> The updated source change looks fine to me.

@jaikiran Thanks for the corroboration.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17119#issuecomment-1864827299

From duke at openjdk.org  Wed Dec 20 17:03:59 2023
From: duke at openjdk.org (Markus KARG)
Date: Wed, 20 Dec 2023 17:03:59 GMT
Subject: Integrated: JDK-8322141: SequenceInputStream.transferTo should not
 return as soon as Long.MAX_VALUE bytes have been transferred
In-Reply-To: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
Message-ID: <DQnlV5cT7OeoLIo-tg3kS2UYglt9uDkSEie0eSangmk=.7d827f79-dde8-4858-a965-489a1895861c@github.com>

On Fri, 15 Dec 2023 08:23:58 GMT, Markus KARG <duke at openjdk.org> wrote:

> Fixes JDK-8322141
> 
> As suggested by @vlsi and documented by @bplb this PR does not return, but only sets the maximum result value.

This pull request has now been integrated.

Changeset: 2d609557
Author:    Markus KARG <markus at headcrashing.eu>
Committer: Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2d609557ffe8e15ab81fb51dce90e40780598371
Stats:     50 lines in 2 files changed: 48 ins; 0 del; 2 mod

8322141: SequenceInputStream.transferTo should not return as soon as Long.MAX_VALUE bytes have been transferred

Reviewed-by: vsitnikov, bpb, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/17119

From rgiulietti at openjdk.org  Wed Dec 20 17:09:05 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 20 Dec 2023 17:09:05 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v7]
In-Reply-To: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
Message-ID: <nLymumK33vKwN0yCV1et1F9uX0pN1S9BBvl8LnQyYoU=.a4a94e45-f47c-41ac-b35f-909769e07506@github.com>

> Adds serialization misdeclaration events to JFR.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Minor changes.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17129/files
  - new: https://git.openjdk.org/jdk/pull/17129/files/a6f80250..0cab1c1b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=05-06

  Stats: 10 lines in 2 files changed: 0 ins; 8 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17129.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17129/head:pull/17129

PR: https://git.openjdk.org/jdk/pull/17129

From lancea at openjdk.org  Wed Dec 20 17:42:47 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 20 Dec 2023 17:42:47 GMT
Subject: RFR: 8322078: ZipSourceCache.testKeySourceMapping() test fails
 with The process cannot access the file because it is being used by another
 process
In-Reply-To: <zpE9gY4PyEr3ETGEOwinsdkuE-6d8yRAg5xKshdvZjM=.bcb98f28-3371-4c7a-bede-b9c34c6b5858@github.com>
References: <zpE9gY4PyEr3ETGEOwinsdkuE-6d8yRAg5xKshdvZjM=.bcb98f28-3371-4c7a-bede-b9c34c6b5858@github.com>
Message-ID: <HkKFTvebRRLS6zghBt6fkEqyOO-ovddGaFSqvGeJQlA=.f907a670-8338-4ea4-9d19-3455a8307346@github.com>

On Wed, 20 Dec 2023 15:37:37 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> trivial test edit to use FileUtils.deleteFileIfExistsWithRetry test library API
> 
> tested on CI system with test-repeat = 20 - no issues seen.

Hi Sean,

Thank you for tackling this.

Would it be beneficial to use a try-with-resources for the zip file opened on lines 88 and 98 just to rule out any other weirdness on windows?

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17169#pullrequestreview-1791382251

From duke at openjdk.org  Wed Dec 20 17:56:57 2023
From: duke at openjdk.org (Markus KARG)
Date: Wed, 20 Dec 2023 17:56:57 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred [v4]
In-Reply-To: <pupyLRe_qwP3uStEtzXPgg-yhD8SZOgfbjauDG7AYCw=.0139aa52-733d-4971-928e-7c345908dfa6@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
 <MgqxdnIJbR-Kan1rvnLN0M63R5zLUcThXNHvdJDGCP4=.77f9b25a-12fa-4edb-935b-eb19196da8da@github.com>
 <DcqFoeac1QjH_W5DzKMWIigdheVlgrH6Zs59p-z6UR0=.8b83adb5-e56b-4ee9-a732-b656a133be6f@github.com>
 <ZqBxQhs0xDSKqasEtj4nVYF4sNf4pjxP3TbRy355NxM=.a152b16a-0e14-4797-aa97-fd5d65b5d876@github.com>
 <pupyLRe_qwP3uStEtzXPgg-yhD8SZOgfbjauDG7AYCw=.0139aa52-733d-4971-928e-7c345908dfa6@github.com>
Message-ID: <WEpa1rkqWdE1PYwAnWJdJfOsJ3yOVEXu-xWMXCvNDeQ=.f7bd55c5-e270-4905-92c3-32a286bc2a76@github.com>

On Wed, 20 Dec 2023 16:52:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> > Alan actually did approve them on December 15.
> 
> I know, with requested changes. I didn't see the request transition to "Ready" which is where it needs to be to `/integrate`.

Looking at the Github history I need to say that I cannot see that Alan approved *with change requests*. Maybe I am missing something. I see his approval on Dec 15 directly before my `/integrate` on the same day, but no change request *there*, and I can see his change request *after* my `/integrate` where he says "I think jai is right". But where do you see a change request from Alan *before* I posted `/integrate`? I am pretty sure you are right, but where actually do you see this in the Github history? Thanks. :-)

BTW, here is the "Ready" label you did not see: https://github.com/openjdk/jdk/pull/17119#event-11256913866

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17119#issuecomment-1864893934

From bpb at openjdk.org  Wed Dec 20 18:01:03 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 20 Dec 2023 18:01:03 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred [v4]
In-Reply-To: <MgqxdnIJbR-Kan1rvnLN0M63R5zLUcThXNHvdJDGCP4=.77f9b25a-12fa-4edb-935b-eb19196da8da@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
 <MgqxdnIJbR-Kan1rvnLN0M63R5zLUcThXNHvdJDGCP4=.77f9b25a-12fa-4edb-935b-eb19196da8da@github.com>
Message-ID: <zCO9W1s6tmrLa9-dXRkSVly7-do42asQNCaB8zYLGxE=.46888072-3d6e-4759-9c0b-83d9c7a85048@github.com>

On Sat, 16 Dec 2023 14:07:52 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Fixes JDK-8322141
>> 
>> As suggested by @vlsi and documented by @bplb this PR does not return, but only sets the maximum result value.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test was using Integer but must use Long

> But where do you see a change request from Alan _before_ I posted `/integrate`?

Mouse-over the icon to the right of his name at the top right under "Reviewers."

> BTW, here is the "Ready" label you did not see: [#17119 (comment)](https://github.com/openjdk/jdk/pull/17119#event-11256913866)

Ack.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17119#issuecomment-1864901444

From rgiulietti at openjdk.org  Wed Dec 20 18:08:09 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 20 Dec 2023 18:08:09 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v8]
In-Reply-To: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
Message-ID: <9tk_5iLxqgURHyC59--KpXolXd11NV3gd8L4bCxigjU=.e8bef2cd-9934-451e-a428-8fb2a1283ec6@github.com>

> Adds serialization misdeclaration events to JFR.

Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:

 - Merge branch 'master' into 8275338
 - Renamed an event field.
 - Minor changes.
 - Removed event kind.
   serialVersionUID must have type long.
   Test now base on keyword search in event message.
   Commented test classes about misdeclarations.
 - Changes according to reviewer's comments.
 - Better name for a label, corrected name of removed field.
 - Event enabled on profile.jfc but disabled on default.jfc.
 - Restrict accessibility of nested classes.
 - Make use of EventNames.
 - Merge branch 'master' into 8275338
 - ... and 1 more: https://git.openjdk.org/jdk/compare/6ea0f368...94fc01ba

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17129/files
  - new: https://git.openjdk.org/jdk/pull/17129/files/0cab1c1b..94fc01ba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=06-07

  Stats: 2512 lines in 172 files changed: 1722 ins; 321 del; 469 mod
  Patch: https://git.openjdk.org/jdk/pull/17129.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17129/head:pull/17129

PR: https://git.openjdk.org/jdk/pull/17129

From duke at openjdk.org  Wed Dec 20 18:30:55 2023
From: duke at openjdk.org (Markus KARG)
Date: Wed, 20 Dec 2023 18:30:55 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred [v4]
In-Reply-To: <zCO9W1s6tmrLa9-dXRkSVly7-do42asQNCaB8zYLGxE=.46888072-3d6e-4759-9c0b-83d9c7a85048@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
 <MgqxdnIJbR-Kan1rvnLN0M63R5zLUcThXNHvdJDGCP4=.77f9b25a-12fa-4edb-935b-eb19196da8da@github.com>
 <zCO9W1s6tmrLa9-dXRkSVly7-do42asQNCaB8zYLGxE=.46888072-3d6e-4759-9c0b-83d9c7a85048@github.com>
Message-ID: <LJ1KhHytvfyidEBE-Pwe9YSg1_3sOvl9TjotPD5XBEk=.a1650f3f-daa6-45bc-bdd1-bea0fae1ec9f@github.com>

On Wed, 20 Dec 2023 17:57:57 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> > But where do you see a change request from Alan _before_ I posted `/integrate`?
> 
> Mouse-over the icon to the right of his name at the top right under "Reviewers."

I might be wrong, but IMHO this icon only says that Alan made change requests, but not *when*. This means, the icon pops up even when requesting the changes *after* approving. But I again, I might be wrong.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17119#issuecomment-1864945556

From bpb at openjdk.org  Wed Dec 20 18:53:02 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 20 Dec 2023 18:53:02 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred [v4]
In-Reply-To: <LJ1KhHytvfyidEBE-Pwe9YSg1_3sOvl9TjotPD5XBEk=.a1650f3f-daa6-45bc-bdd1-bea0fae1ec9f@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
 <MgqxdnIJbR-Kan1rvnLN0M63R5zLUcThXNHvdJDGCP4=.77f9b25a-12fa-4edb-935b-eb19196da8da@github.com>
 <zCO9W1s6tmrLa9-dXRkSVly7-do42asQNCaB8zYLGxE=.46888072-3d6e-4759-9c0b-83d9c7a85048@github.com>
 <LJ1KhHytvfyidEBE-Pwe9YSg1_3sOvl9TjotPD5XBEk=.a1650f3f-daa6-45bc-bdd1-bea0fae1ec9f@github.com>
Message-ID: <6-b9qNtsUySa28dsdHBd9lIwlmCqJLIJyi2u5PrgthI=.e43ef15a-3a4c-4c0f-98df-d6e61228014a@github.com>

On Wed, 20 Dec 2023 18:28:27 GMT, Markus KARG <duke at openjdk.org> wrote:

> this icon only says that Alan made change requests

I think it's if the "changes requested" button is selected in the "Submit Review" popup under "Files Changed."

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17119#issuecomment-1864976239

From achung at openjdk.org  Wed Dec 20 19:06:58 2023
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 20 Dec 2023 19:06:58 GMT
Subject: [jdk22] RFR: 8322041: JDK 22 RDP1 L10n resource files update
Message-ID: <ScWKiofw7L7JtFHjUM6_pBd1tnTojgfsmqVS36QG4j0=.560e2662-4db2-4748-83c5-91d3c0d1ec77@github.com>

Backport of JDK-8322041

-------------

Commit messages:
 - Backport b061b6678fde891974d5b58cec963b3481099a8d

Changes: https://git.openjdk.org/jdk22/pull/22/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=22&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322041
  Stats: 290 lines in 36 files changed: 166 ins; 15 del; 109 mod
  Patch: https://git.openjdk.org/jdk22/pull/22.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/22/head:pull/22

PR: https://git.openjdk.org/jdk22/pull/22

From kcr at openjdk.org  Wed Dec 20 19:18:50 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 20 Dec 2023 19:18:50 GMT
Subject: [jdk22] RFR: 8322041: JDK 22 RDP1 L10n resource files update
In-Reply-To: <ScWKiofw7L7JtFHjUM6_pBd1tnTojgfsmqVS36QG4j0=.560e2662-4db2-4748-83c5-91d3c0d1ec77@github.com>
References: <ScWKiofw7L7JtFHjUM6_pBd1tnTojgfsmqVS36QG4j0=.560e2662-4db2-4748-83c5-91d3c0d1ec77@github.com>
Message-ID: <0PwfnK4xd97FHzIR9ChcGQXtE1EExZ-YgFSRY6T2oDQ=.899d8f7b-9807-4d6d-b63a-12bf207c68d7@github.com>

On Wed, 20 Dec 2023 19:00:50 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Backport of JDK-8322041

The patch looks good. Additionally, I confirmed that the files in question are identical to those in jdk mainline after this patch is applied.

It will need a "R"eviewer to approve.

-------------

Marked as reviewed by kcr (Author).

PR Review: https://git.openjdk.org/jdk22/pull/22#pullrequestreview-1791515826

From asotona at openjdk.org  Wed Dec 20 20:08:08 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 20 Dec 2023 20:08:08 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v2]
In-Reply-To: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
Message-ID: <JSMrLvi1QMQWRoKViwkMm7ZUUeelmNQD_Ddvoh9rBWY=.832937be-2df0-4ba2-97f7-1618900c902b@github.com>

> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes.
> 
> This patch converts it to use Classfile API.
> 
> It is continuation of https://github.com/openjdk/jdk/pull/10991
> 
> Any comments and suggestions are welcome.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:

 - performance improvements
 - StackCounter performance boost
 - performance improvements

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17121/files
  - new: https://git.openjdk.org/jdk/pull/17121/files/0267d657..a21fb264

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17121&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17121&range=00-01

  Stats: 338 lines in 2 files changed: 166 ins; 33 del; 139 mod
  Patch: https://git.openjdk.org/jdk/pull/17121.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17121/head:pull/17121

PR: https://git.openjdk.org/jdk/pull/17121

From asotona at openjdk.org  Wed Dec 20 20:08:08 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 20 Dec 2023 20:08:08 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes
In-Reply-To: <cqiHlFTCPog_bjmtncLFa_PbazRXVF6iTw4hNbhtbE0=.4d83b089-3421-44f6-b791-c979596651eb@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
 <cqiHlFTCPog_bjmtncLFa_PbazRXVF6iTw4hNbhtbE0=.4d83b089-3421-44f6-b791-c979596651eb@github.com>
Message-ID: <4I4ZJsLUJ79wkVSisPhs0KZvYl0cfKsNPnlQ80M1tfw=.247dc3c5-8822-49f1-a57a-2f6326822f58@github.com>

On Tue, 19 Dec 2023 20:45:58 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Can you include a summary of the performance comparison before and after the patch per the [comment](https://github.com/openjdk/jdk/pull/10991#pullrequestreview-1333426016) in #10991.

I've found significant performance regressions when running these recommended benchmark.
Performance improvements are now in progress.

Thanks for the reminder.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17121#issuecomment-1865062212

From jlaskey at openjdk.org  Wed Dec 20 20:29:53 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 20 Dec 2023 20:29:53 GMT
Subject: RFR: JDK-8322512 StringBuffer.repeat does not work correctly after
 toString() was called
Message-ID: <ckv4vEc57mqb3WVvqK4Jzgg_XyxksNhQJOkWs8OkY1U=.cf8e712e-3051-4a1d-a338-acdb5c18a43e@github.com>

The new repeat methods were not clearing the toStringCache.

-------------

Commit messages:
 - Clear toStringCache when calling StringBuffer::repeat

Changes: https://git.openjdk.org/jdk/pull/17172/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17172&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322512
  Stats: 16 lines in 2 files changed: 15 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17172.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17172/head:pull/17172

PR: https://git.openjdk.org/jdk/pull/17172

From mchung at openjdk.org  Wed Dec 20 20:40:46 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 20 Dec 2023 20:40:46 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v2]
In-Reply-To: <JSMrLvi1QMQWRoKViwkMm7ZUUeelmNQD_Ddvoh9rBWY=.832937be-2df0-4ba2-97f7-1618900c902b@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
 <JSMrLvi1QMQWRoKViwkMm7ZUUeelmNQD_Ddvoh9rBWY=.832937be-2df0-4ba2-97f7-1618900c902b@github.com>
Message-ID: <EHjsO3F--4PDf9jnBXIBlQ7SZE-_rWKFnOvG4idCUFA=.3f99d126-213a-4be8-9905-cec781c6c86a@github.com>

On Wed, 20 Dec 2023 20:08:08 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes.
>> 
>> This patch converts it to use Classfile API.
>> 
>> It is continuation of https://github.com/openjdk/jdk/pull/10991
>> 
>> Any comments and suggestions are welcome.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - performance improvements
>  - StackCounter performance boost
>  - performance improvements

Can you explain the changes to resolve the performance regressions?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17121#issuecomment-1865107527

From mchung at openjdk.org  Wed Dec 20 20:42:41 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 20 Dec 2023 20:42:41 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v4]
In-Reply-To: <e3svw09clM3QZVdC3shb8DcJdvSkubsQv7-u1YFcRqk=.b4996354-c254-4cce-9b3f-d72347f81fde@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <e3svw09clM3QZVdC3shb8DcJdvSkubsQv7-u1YFcRqk=.b4996354-c254-4cce-9b3f-d72347f81fde@github.com>
Message-ID: <BLmNmlobY0BB35-NhDUhKdwHB8ECXBKMxdupIFm-5-M=.c5d0c0f6-f501-43c7-b833-b9b9ad4a0cd8@github.com>

On Mon, 18 Dec 2023 11:03:10 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
>> 
>> This patch converts ASM calls to Classfile API.
>> 
>> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
>> 
>> Any comments and suggestions are welcome.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: liach <7806504+liach at users.noreply.github.com>

Can you include the performance comparison before and after this change and what performance benchmarks you run?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17108#issuecomment-1865109693

From naoto at openjdk.org  Wed Dec 20 20:46:51 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 20 Dec 2023 20:46:51 GMT
Subject: [jdk22] RFR: 8322041: JDK 22 RDP1 L10n resource files update
In-Reply-To: <ScWKiofw7L7JtFHjUM6_pBd1tnTojgfsmqVS36QG4j0=.560e2662-4db2-4748-83c5-91d3c0d1ec77@github.com>
References: <ScWKiofw7L7JtFHjUM6_pBd1tnTojgfsmqVS36QG4j0=.560e2662-4db2-4748-83c5-91d3c0d1ec77@github.com>
Message-ID: <iYq79_yXwnDH-tNdASBaMjtOOMzLdC263z8BOa0sLCc=.693f7bbe-9a1b-4916-98bd-ca89acf5acc0@github.com>

On Wed, 20 Dec 2023 19:00:50 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Backport of JDK-8322041

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk22/pull/22#pullrequestreview-1791633961

From sspitsyn at openjdk.org  Wed Dec 20 21:06:59 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 20 Dec 2023 21:06:59 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v8]
In-Reply-To: <wRxh33DFXd4sEYOhUe11uBf0ERpHwU6RsW-E-gJQAI8=.9bcc0bf4-48e8-4cad-b7df-86e83d1e4097@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
 <EwkIDbTs7wG5q6lcikgo0ycMFRpu5VXxvMbR3tOPAM8=.40c169b6-57df-4dc7-8726-fd6d8439c541@github.com>
 <wRxh33DFXd4sEYOhUe11uBf0ERpHwU6RsW-E-gJQAI8=.9bcc0bf4-48e8-4cad-b7df-86e83d1e4097@github.com>
Message-ID: <91xGNVFk3N8kP6sdAHhaGp9HhSaGS52_D6xW3aDivSY=.3196af09-9998-462d-9fe0-f91b2afd184a@github.com>

On Wed, 20 Dec 2023 14:15:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Update: ignore this I mis-read that it updates the current thread's suspend value, not the thread's suspend value.

Thanks, Alan. I've also got confused with this and even filed a follow up bug. :)
Yes, the initial design was the `_is_disable_suspend` is set/modified/accessed on the current thread only.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1433182764

From duke at openjdk.org  Wed Dec 20 21:08:53 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 20 Dec 2023 21:08:53 GMT
Subject: RFR: 8322565 (zipfs) Files.setPosixPermissions should preserve
 'external file attributes' bits
Message-ID: <pevNk5fRRJnjARO_Cq-JwzguZ6SbKXKJRih1J-J_yWg=.342e031f-7c27-4577-87dc-bbcb0d6ddfb9@github.com>

This PR suggests that `Files.setPosixPermissions`as implemented by `ZipFileSystem` should preserve the leading seven bits of the 'external file attributes' field. These bits contain the 'file type', 'setuid', 'setgid', and 'sticky' bits. These are unrelated to permissions and should not be modified by this operation.

The fix is to update `Entry.readCEN` to read all 16 bits and to update `ZipFileSystem.setPermissions` to preserve the leading 7 bits when updating the trailing 9 permission-related bits of the `Entry.posixPerms` field.

The PR adds a new test `TestPosix.preserveRemainingBits()` which verifies that the leading 7 bits are not affected by `Files.setPosixPermissions`.

Note that this PR does not aim to preserve the leading seven bits for the case when `Files.setPosixPermissions` is called with a `null` permission set. (The implementation currently interprets this as a signal that the 'external file attributes'  should not be populated and the 'version made by' OS will be MSDOS instead of Unix)

-------------

Commit messages:
 - Preserve non-permission 'external file attributes' bits when setting posix permissions

Changes: https://git.openjdk.org/jdk/pull/17170/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17170&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322565
  Stats: 83 lines in 2 files changed: 75 ins; 4 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/17170.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17170/head:pull/17170

PR: https://git.openjdk.org/jdk/pull/17170

From duke at openjdk.org  Wed Dec 20 21:15:22 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 20 Dec 2023 21:15:22 GMT
Subject: RFR: 8321616: Retire binary test vectors in
 test/jdk/java/util/zip/ZipFile [v8]
In-Reply-To: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
References: <1wVVRHdtdtmxgbNEwmi6b02rDYpPLRqkvBV-bzxaPUs=.55d38fe1-24b5-4735-a01c-486caae18afe@github.com>
Message-ID: <xeqXEdOQOZbVUkPbmOjAH-Ol6aHDMQ8Wewm3WAO-TN0=.a0c76410-2ca3-47f1-969a-efd0ad949466@github.com>

> This PR suggests we retire the binary test vectors `ZipFile/input.zip`, `ZipFile/input.jar` and `ZipFile/crash.jar`
> 
> Binary test vectors are harder to analyze,  and sharing test vectors across unrelated tests increases maintenance burden. It would be better to have each test produce its own test vectors independently.
> 
> While visiting these dusty tests, we should take the opportunity to convert them to JUnit, add more comments and perform some mild modernization and cleanups where appropriate. We should also consider whether any test are duplicated and can be retired or moved into other test files as separate methods. See comments below.
> 
> To help reviewers, here are some comments on the updated tests:
> 
> `Available.java`
> This test currently has no jtreg `@test` header, so isn't currently active. After discussion, we decided to merge this test into `ReadZip.java`. I added some checks to verify that reading from the stream reduces the number of available bytes accordingly, also checking the behavior when the stream is closed.
> 
> `CopyJar.java`
> The concern of copying entries seems to now have better coverage in the test `zip/CopyZipFile`. We decided to retire this test rather than convert it and instead convert `CopyZipFile` to JUnit.
> 
> `EnumAfterClose.java`
> To prevent confusion with Java Enums, I suggest we rename this test to `EnumerateAfterClose`.
> 
> `FinalizeInflater.java`  
> The code verified by this test has been updated to use cleaners instead of finalizers. Still, this test code relies on finalizers. Not sure if this is an issue, but this test will need to be updated when finalizers are finally removed.
> 
> `GetDirEntry.java`
> We decided to merge this test into `ReadZip.readDirectoryEntries` rather than keeping it as a separate test.
> 
> `ReadZip.java`
> Nothing exciting here, the single main method was split into multiple JUnit methods, each focusing on a separate concern.
> 
> `ReleaseInflater.java`
> Nothing exciting, tried to add some comment to help understanding of what is tested.
> 
> `StreamZipEntriesTest.java`
> This test was using TestNG so was converted to JUnit for consistency. Added some comments to help understanding.
> 
> `ReadAfterClose.java`
> This uses the binary test vector `crash.jar`. The test is converted to JUnit and moved to `ReadZip.readAfterClose?. The test is expanded to exercise more read methods.

Eirik Bjorsnos has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:

 - Merge branch 'master' into readzip-junit
 - Merge the ReadAfterClose test into ReadZip, converting it to JUnit.
 - Improve comment explaining what happens when ZipEntry.setCompressedSize is calledExplicitly
 - Convert CopyZipFile.java to JUnit
 - Remove trailing whitespace
 - Merge GetDirEntry.java into ReadZip.readDirectoryEntries()
 - Retire redundant test ZipFile/CopyJar
 - Merge Available.java into ReadZip.java
 - Add @bug reference 4401122 on the Available.java test
 - Merge branch 'master' into readzip-junit
 - ... and 4 more: https://git.openjdk.org/jdk/compare/82804792...85500cd8

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17038/files
  - new: https://git.openjdk.org/jdk/pull/17038/files/27fe1131..85500cd8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17038&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17038&range=06-07

  Stats: 3896 lines in 272 files changed: 2360 ins; 631 del; 905 mod
  Patch: https://git.openjdk.org/jdk/pull/17038.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17038/head:pull/17038

PR: https://git.openjdk.org/jdk/pull/17038

From sspitsyn at openjdk.org  Wed Dec 20 21:34:19 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 20 Dec 2023 21:34:19 GMT
Subject: [jdk22] RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable
Message-ID: <COoQMKqmu8SrsLBpcEAL6FYJIkg-4CKgpBJhincsgAA=.230c8c6f-5dcc-46b9-aedc-8b99f7b43439@github.com>

Hi all,

This pull request contains a backport of commit [0f8e4e0a](https://github.com/openjdk/jdk/commit/0f8e4e0a81257c678e948c341a241dc0b810494f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Serguei Spitsyn on 19 Dec 2023 and was reviewed by Leonid Mesnik and Alan Bateman.

Thanks!

-------------

Commit messages:
 - Backport 0f8e4e0a81257c678e948c341a241dc0b810494f

Changes: https://git.openjdk.org/jdk22/pull/23/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=23&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311218
  Stats: 229 lines in 15 files changed: 196 ins; 0 del; 33 mod
  Patch: https://git.openjdk.org/jdk22/pull/23.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/23/head:pull/23

PR: https://git.openjdk.org/jdk22/pull/23

From achung at openjdk.org  Wed Dec 20 21:44:48 2023
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 20 Dec 2023 21:44:48 GMT
Subject: [jdk22] Integrated: 8322041: JDK 22 RDP1 L10n resource files update
In-Reply-To: <ScWKiofw7L7JtFHjUM6_pBd1tnTojgfsmqVS36QG4j0=.560e2662-4db2-4748-83c5-91d3c0d1ec77@github.com>
References: <ScWKiofw7L7JtFHjUM6_pBd1tnTojgfsmqVS36QG4j0=.560e2662-4db2-4748-83c5-91d3c0d1ec77@github.com>
Message-ID: <yCyGyO_7UOEIfk5gKLcCBlk8BCsqOlMFX4IWvaSylG4=.da243501-12cc-4ee5-ab6f-7c2e64b202a3@github.com>

On Wed, 20 Dec 2023 19:00:50 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Backport of JDK-8322041

This pull request has now been integrated.

Changeset: a05f3d10
Author:    Alisen Chung <achung at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/a05f3d10cc374297fd9b0fa27305c9b26f8081d2
Stats:     290 lines in 36 files changed: 166 ins; 15 del; 109 mod

8322041: JDK 22 RDP1 L10n resource files update

Reviewed-by: kcr, naoto
Backport-of: b061b6678fde891974d5b58cec963b3481099a8d

-------------

PR: https://git.openjdk.org/jdk22/pull/22

From rriggs at openjdk.org  Wed Dec 20 21:55:39 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 20 Dec 2023 21:55:39 GMT
Subject: RFR: JDK-8322512 StringBuffer.repeat does not work correctly after
 toString() was called
In-Reply-To: <ckv4vEc57mqb3WVvqK4Jzgg_XyxksNhQJOkWs8OkY1U=.cf8e712e-3051-4a1d-a338-acdb5c18a43e@github.com>
References: <ckv4vEc57mqb3WVvqK4Jzgg_XyxksNhQJOkWs8OkY1U=.cf8e712e-3051-4a1d-a338-acdb5c18a43e@github.com>
Message-ID: <OP3INtymu78Nvza-njnpMuefmf33Ys6HplRsuzhB8zE=.b802b3ad-3884-4515-847c-5368c195ee7c@github.com>

On Wed, 20 Dec 2023 20:25:07 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> The new repeat methods were not clearing the toStringCache.

src/java.base/share/classes/java/lang/StringBuffer.java line 719:

> 717:     public synchronized StringBuffer repeat(int codePoint, int count) {
> 718:         super.repeat(codePoint, count);
> 719:         toStringCache = null;

The other cases in StringBuffer clear toStringCache *before* performing the modification.
For consistency, I'd suggest doing the same.

src/java.base/share/classes/java/lang/StringBuffer.java line 731:

> 729:     public synchronized StringBuffer repeat(CharSequence cs, int count) {
> 730:         super.repeat(cs, count);
> 731:         toStringCache = null;

Ditto, clear toStringCache before the modification.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17172#discussion_r1433218351
PR Review Comment: https://git.openjdk.org/jdk/pull/17172#discussion_r1433218688

From coffeys at openjdk.org  Wed Dec 20 22:05:53 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 20 Dec 2023 22:05:53 GMT
Subject: RFR: 8322078: ZipSourceCache.testKeySourceMapping() test fails
 with The process cannot access the file because it is being used by another
 process
In-Reply-To: <zpE9gY4PyEr3ETGEOwinsdkuE-6d8yRAg5xKshdvZjM=.bcb98f28-3371-4c7a-bede-b9c34c6b5858@github.com>
References: <zpE9gY4PyEr3ETGEOwinsdkuE-6d8yRAg5xKshdvZjM=.bcb98f28-3371-4c7a-bede-b9c34c6b5858@github.com>
Message-ID: <bMi5tgOuxnTvtjRb8DsBqHCSrYqKxWgc3r4q_LGU0FI=.7bfcbcf0-b6a5-47d2-9248-d1db224ba04c@github.com>

On Wed, 20 Dec 2023 15:37:37 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> trivial test edit to use FileUtils.deleteFileIfExistsWithRetry test library API
> 
> tested on CI system with test-repeat = 20 - no issues seen.

Thanks for the review Lance. I didn't use try-with-resources during test creation in those locations since the timing of the close() operation is key to the test. Being able to control when the files are closed allows extra sanity checks to be performed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17169#issuecomment-1865200537

From coffeys at openjdk.org  Wed Dec 20 22:05:53 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 20 Dec 2023 22:05:53 GMT
Subject: Integrated: 8322078: ZipSourceCache.testKeySourceMapping() test fails
 with The process cannot access the file because it is being used by
 another process
In-Reply-To: <zpE9gY4PyEr3ETGEOwinsdkuE-6d8yRAg5xKshdvZjM=.bcb98f28-3371-4c7a-bede-b9c34c6b5858@github.com>
References: <zpE9gY4PyEr3ETGEOwinsdkuE-6d8yRAg5xKshdvZjM=.bcb98f28-3371-4c7a-bede-b9c34c6b5858@github.com>
Message-ID: <tbKNfqpB_mGWlz6FnyNfUPwvUezLpKvf2mSsrOvuRko=.a2ad93ed-99c0-4e1d-a49e-7bb55176d174@github.com>

On Wed, 20 Dec 2023 15:37:37 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> trivial test edit to use FileUtils.deleteFileIfExistsWithRetry test library API
> 
> tested on CI system with test-repeat = 20 - no issues seen.

This pull request has now been integrated.

Changeset: f6fe39ff
Author:    Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f6fe39ff1168d27f4d0ea3e4c7f3f17ecae9e1ab
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8322078: ZipSourceCache.testKeySourceMapping() test fails with The process cannot access the file because it is being used by another process

Reviewed-by: lancea

-------------

PR: https://git.openjdk.org/jdk/pull/17169

From jlaskey at openjdk.org  Wed Dec 20 22:18:08 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 20 Dec 2023 22:18:08 GMT
Subject: RFR: JDK-8322512 StringBuffer.repeat does not work correctly after
 toString() was called [v2]
In-Reply-To: <ckv4vEc57mqb3WVvqK4Jzgg_XyxksNhQJOkWs8OkY1U=.cf8e712e-3051-4a1d-a338-acdb5c18a43e@github.com>
References: <ckv4vEc57mqb3WVvqK4Jzgg_XyxksNhQJOkWs8OkY1U=.cf8e712e-3051-4a1d-a338-acdb5c18a43e@github.com>
Message-ID: <4dsw9PpupmaAYyUU1Chso28_5ceXQM83Cxuoiw8o538=.f0289813-ddc4-4200-a817-57753214dbed@github.com>

> The new repeat methods were not clearing the toStringCache.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Clear sooner

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17172/files
  - new: https://git.openjdk.org/jdk/pull/17172/files/82b7e342..66eb7f71

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17172&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17172&range=00-01

  Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17172.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17172/head:pull/17172

PR: https://git.openjdk.org/jdk/pull/17172

From rriggs at openjdk.org  Wed Dec 20 22:18:08 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 20 Dec 2023 22:18:08 GMT
Subject: RFR: JDK-8322512 StringBuffer.repeat does not work correctly after
 toString() was called [v2]
In-Reply-To: <4dsw9PpupmaAYyUU1Chso28_5ceXQM83Cxuoiw8o538=.f0289813-ddc4-4200-a817-57753214dbed@github.com>
References: <ckv4vEc57mqb3WVvqK4Jzgg_XyxksNhQJOkWs8OkY1U=.cf8e712e-3051-4a1d-a338-acdb5c18a43e@github.com>
 <4dsw9PpupmaAYyUU1Chso28_5ceXQM83Cxuoiw8o538=.f0289813-ddc4-4200-a817-57753214dbed@github.com>
Message-ID: <zywT69b-Rnbho7TGwLijbx27use3RxfjVNLdilI-ueI=.8e87dcfa-5666-4594-b4b5-7fa34da4c208@github.com>

On Wed, 20 Dec 2023 22:15:04 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> The new repeat methods were not clearing the toStringCache.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clear sooner

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17172#pullrequestreview-1791741828

From duke at openjdk.org  Wed Dec 20 22:18:08 2023
From: duke at openjdk.org (Markus KARG)
Date: Wed, 20 Dec 2023 22:18:08 GMT
Subject: RFR: JDK-8322512 StringBuffer.repeat does not work correctly after
 toString() was called [v2]
In-Reply-To: <4dsw9PpupmaAYyUU1Chso28_5ceXQM83Cxuoiw8o538=.f0289813-ddc4-4200-a817-57753214dbed@github.com>
References: <ckv4vEc57mqb3WVvqK4Jzgg_XyxksNhQJOkWs8OkY1U=.cf8e712e-3051-4a1d-a338-acdb5c18a43e@github.com>
 <4dsw9PpupmaAYyUU1Chso28_5ceXQM83Cxuoiw8o538=.f0289813-ddc4-4200-a817-57753214dbed@github.com>
Message-ID: <Df0Sa1PgsFf1nWbW5-VPoJJso9UPUTLKjoS6h8Zb1Z4=.ff645af3-7019-4c0f-8d0d-68ff30d8f2b2@github.com>

On Wed, 20 Dec 2023 22:15:04 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> The new repeat methods were not clearing the toStringCache.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clear sooner

LGTM.

-------------

Marked as reviewed by mkarg at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/17172#pullrequestreview-1791741679

From jlaskey at openjdk.org  Wed Dec 20 22:18:08 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 20 Dec 2023 22:18:08 GMT
Subject: RFR: JDK-8322512 StringBuffer.repeat does not work correctly after
 toString() was called [v2]
In-Reply-To: <OP3INtymu78Nvza-njnpMuefmf33Ys6HplRsuzhB8zE=.b802b3ad-3884-4515-847c-5368c195ee7c@github.com>
References: <ckv4vEc57mqb3WVvqK4Jzgg_XyxksNhQJOkWs8OkY1U=.cf8e712e-3051-4a1d-a338-acdb5c18a43e@github.com>
 <OP3INtymu78Nvza-njnpMuefmf33Ys6HplRsuzhB8zE=.b802b3ad-3884-4515-847c-5368c195ee7c@github.com>
Message-ID: <xnGuxgqck4Ru2gfYyWR7P97HooZbxu-G-DXo3vmbM3Q=.98d4b799-3c7b-4aae-8d01-c40222e989f9@github.com>

On Wed, 20 Dec 2023 21:52:40 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clear sooner
>
> src/java.base/share/classes/java/lang/StringBuffer.java line 719:
> 
>> 717:     public synchronized StringBuffer repeat(int codePoint, int count) {
>> 718:         super.repeat(codePoint, count);
>> 719:         toStringCache = null;
> 
> The other cases in StringBuffer clear toStringCache *before* performing the modification.
> For consistency, I'd suggest doing the same.

Changed

> src/java.base/share/classes/java/lang/StringBuffer.java line 731:
> 
>> 729:     public synchronized StringBuffer repeat(CharSequence cs, int count) {
>> 730:         super.repeat(cs, count);
>> 731:         toStringCache = null;
> 
> Ditto, clear toStringCache before the modification.

Changed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17172#discussion_r1433234794
PR Review Comment: https://git.openjdk.org/jdk/pull/17172#discussion_r1433234928

From sviswanathan at openjdk.org  Wed Dec 20 22:35:43 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 20 Dec 2023 22:35:43 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v4]
In-Reply-To: <6xRfGFR2RIYln31ivz1ZITs5G5bzQ5BlnPdsQeyVbX0=.2797afc7-40ec-482e-9c64-b3ba746d2bd7@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <6xRfGFR2RIYln31ivz1ZITs5G5bzQ5BlnPdsQeyVbX0=.2797afc7-40ec-482e-9c64-b3ba746d2bd7@github.com>
Message-ID: <1nXsCTf2xdJslW020JbSxgLRbdcz3VHBbFRw_SuT2bo=.12349ba4-d5bd-4709-a9fc-5f184b54a6e3@github.com>

On Tue, 19 Dec 2023 18:42:19 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix for JDK-8321599

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2543:

> 2541: 
> 2542:     // Strip pad characters, if any, and adjust length and mask
> 2543:     __ addq(length, start_offset);

This change is unrelated to this PR.

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2548:

> 2546: 
> 2547:     __ BIND(L_donePadding);
> 2548:     __ subq(length, start_offset);

This change is unrelated to this PR.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 3:

> 1: /*
> 2:  * Copyright (c) 2023, Intel Corporation. All rights reserved.
> 3:  * Intel Math Library (LIBM) Source Code

Please remove the line "Intel Math Library ..." as this is not from there.

test/jdk/java/lang/StringBuffer/IndexOf.java line 45:

> 43:     System.err.println(gg);
> 44: 
> 45:     } else {

Some changes in this test file looks like a leftover from debugging.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1433245292
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1433245471
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1433245843
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1433247486

From sviswanathan at openjdk.org  Wed Dec 20 22:35:46 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 20 Dec 2023 22:35:46 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v2]
In-Reply-To: <ll7rKgq3ZtMRa_E2jiCblSpkallAM5ph2esi64Xefp0=.c9a88df3-336e-4a01-869a-09e1223225f5@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <ll7rKgq3ZtMRa_E2jiCblSpkallAM5ph2esi64Xefp0=.c9a88df3-336e-4a01-869a-09e1223225f5@github.com>
Message-ID: <V3aetKCQwpQcE_Skt0FbJdaTo3__n_e9ry4XQjc_BeE=.265ab980-4269-4a2d-9364-b8601df6515d@github.com>

On Wed, 29 Nov 2023 15:01:32 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Only use optimization when EnableX86ECoreOpts is true

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 42:

> 40: // 2. Broadcast the last byte of the needle to a different ymm register
> 41: // 3. Compare the first-byte ymm register to the first 32 bytes of the haystack
> 42: // 4. Compare the last-byte register to the 32 bytes of the haystack at the (k-1)st position

It would be good to mention that k is the length of the needle.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 117:

> 115: /******************************************************************************/
> 116: 
> 117: void StubGenerator::loop_helper(int size, Label& bailout, Label& loop_top) {

Let us name this method as string_indexof_loop_helper() instead of just loop_helper().

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1409626570
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1409623608

From duke at openjdk.org  Wed Dec 20 22:49:58 2023
From: duke at openjdk.org (Markus KARG)
Date: Wed, 20 Dec 2023 22:49:58 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred [v4]
In-Reply-To: <6-b9qNtsUySa28dsdHBd9lIwlmCqJLIJyi2u5PrgthI=.e43ef15a-3a4c-4c0f-98df-d6e61228014a@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
 <MgqxdnIJbR-Kan1rvnLN0M63R5zLUcThXNHvdJDGCP4=.77f9b25a-12fa-4edb-935b-eb19196da8da@github.com>
 <zCO9W1s6tmrLa9-dXRkSVly7-do42asQNCaB8zYLGxE=.46888072-3d6e-4759-9c0b-83d9c7a85048@github.com>
 <LJ1KhHytvfyidEBE-Pwe9YSg1_3sOvl9TjotPD5XBEk=.a1650f3f-daa6-45bc-bdd1-bea0fae1ec9f@github.com>
 <6-b9qNtsUySa28dsdHBd9lIwlmCqJLIJyi2u5PrgthI=.e43ef15a-3a4c-4c0f-98df-d6e61228014a@github.com>
Message-ID: <2dqEzi1nu2MTbpG4txRB5yc5h5NgOsH2YKzQdQxchXc=.b2d12708-88db-4c15-a92b-9e739d6ec4c6@github.com>

On Wed, 20 Dec 2023 18:49:39 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> > this icon only says that Alan made change requests
> 
> I think it's if the "changes requested" button is selected in the "Submit Review" popup under "Files Changed."

Typically yes. But not in the current case: Alan pressed "approve" first *without* giving a comment leading to this entry:

![grafik](https://github.com/openjdk/jdk/assets/1701815/edcc8a43-1b17-47e7-9307-e518267ffcf6)

...then...

![grafik](https://github.com/openjdk/jdk/assets/1701815/df35e7a0-7233-42f3-9fec-15ec4d10b45e)

...and **after that** Alan pressed `Request changes` button in the review dialog (note the heading "Alan Bateman suggested changes last week"):

![grafik](https://github.com/openjdk/jdk/assets/1701815/14f42334-d008-46e9-88c5-dbca9a5b5320)

So the comment "I think jai is right" was the trigger to set that icon, but that icon was definitively **not** set before.

So I did not do something wrong but finally I learned Github forensics now. ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17119#issuecomment-1865242504

From bpb at openjdk.org  Wed Dec 20 22:57:58 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 20 Dec 2023 22:57:58 GMT
Subject: RFR: JDK-8322141: SequenceInputStream.transferTo should not return
 as soon as Long.MAX_VALUE bytes have been transferred [v4]
In-Reply-To: <2dqEzi1nu2MTbpG4txRB5yc5h5NgOsH2YKzQdQxchXc=.b2d12708-88db-4c15-a92b-9e739d6ec4c6@github.com>
References: <DerIZGWVTV1UoX0FCoE5AZ7pxcjs0W2q23LMYPFX3zI=.638a1637-4248-4d76-b0e2-55b14ce9576d@github.com>
 <MgqxdnIJbR-Kan1rvnLN0M63R5zLUcThXNHvdJDGCP4=.77f9b25a-12fa-4edb-935b-eb19196da8da@github.com>
 <zCO9W1s6tmrLa9-dXRkSVly7-do42asQNCaB8zYLGxE=.46888072-3d6e-4759-9c0b-83d9c7a85048@github.com>
 <LJ1KhHytvfyidEBE-Pwe9YSg1_3sOvl9TjotPD5XBEk=.a1650f3f-daa6-45bc-bdd1-bea0fae1ec9f@github.com>
 <6-b9qNtsUySa28dsdHBd9lIwlmCqJLIJyi2u5PrgthI=.e43ef15a-3a4c-4c0f-98df-d6e61228014a@github.com>
 <2dqEzi1nu2MTbpG4txRB5yc5h5NgOsH2YKzQdQxchXc=.b2d12708-88db-4c15-a92b-9e739d6ec4c6@github.com>
Message-ID: <5H5aCPM0nY0A-xC-Ta5q8CL7Vg8dxLwtfp2mTR8nGDo=.c4becd40-f041-4082-83f1-f97922540c1c@github.com>

On Wed, 20 Dec 2023 22:46:32 GMT, Markus KARG <duke at openjdk.org> wrote:

> So I did not do something wrong but finally I learned Github forensics now.

If no crime was committed, I would call it archaeology.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17119#issuecomment-1865249242

From asotona at openjdk.org  Thu Dec 21 01:12:07 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 21 Dec 2023 01:12:07 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v3]
In-Reply-To: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
Message-ID: <B5XP8rjT47fY8ht1TUkzgcy6D4jiKxCQlf7jz_8uRZc=.cf1fc710-e215-4817-b4cd-0e74415dd2bb@github.com>

> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes.
> 
> This patch converts it to use Classfile API.
> 
> It is continuation of https://github.com/openjdk/jdk/pull/10991
> 
> Any comments and suggestions are welcome.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - performance improvements
 - SplitConstantPool performance fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17121/files
  - new: https://git.openjdk.org/jdk/pull/17121/files/a21fb264..75e31e3a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17121&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17121&range=01-02

  Stats: 76 lines in 2 files changed: 21 ins; 10 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/17121.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17121/head:pull/17121

PR: https://git.openjdk.org/jdk/pull/17121

From asotona at openjdk.org  Thu Dec 21 01:36:52 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 21 Dec 2023 01:36:52 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v3]
In-Reply-To: <B5XP8rjT47fY8ht1TUkzgcy6D4jiKxCQlf7jz_8uRZc=.cf1fc710-e215-4817-b4cd-0e74415dd2bb@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
 <B5XP8rjT47fY8ht1TUkzgcy6D4jiKxCQlf7jz_8uRZc=.cf1fc710-e215-4817-b4cd-0e74415dd2bb@github.com>
Message-ID: <cpI1U6NuFEawsga3apAVh2Xe6kU9vbTsC0yWtEAkXws=.05883c49-d650-40ae-a1b3-05ad0906230a@github.com>

On Thu, 21 Dec 2023 01:12:07 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes.
>> 
>> This patch converts it to use Classfile API.
>> 
>> It is continuation of https://github.com/openjdk/jdk/pull/10991
>> 
>> Any comments and suggestions are welcome.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - performance improvements
>  - SplitConstantPool performance fix

Profiling of the benchmarks revealed several slowdowns:

- many expensive conversions from `Class<?>` to `ClassDesc` to `ClassEntry`, or even more expensive `MethodTypeDesc`
- building proxy class from scratch from symbols also involves a lot of `String` concatenations, hashing, encoding and comparisons
- computation of stack maps is also still expensive
- `SplitConstantPool` was ineffective in some specific cases

Proposed performance improvements use pre-generated template class and each proxy is then transformed with share constant pool.
Frequently used constant pool entries are materialized in the template class constant pool to avoid expensive conversions, comparisons and hashing.
Stack maps are generated manually.

Performance fixes related to ClassFile API `SplitConstantPool` and `StackCounter` may be separated into another PR. 
For now I keep them together to measure synergic effect.

Full benchmark numbers will be ready soon.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17121#issuecomment-1865353203

From asotona at openjdk.org  Thu Dec 21 01:46:40 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 21 Dec 2023 01:46:40 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v4]
In-Reply-To: <BLmNmlobY0BB35-NhDUhKdwHB8ECXBKMxdupIFm-5-M=.c5d0c0f6-f501-43c7-b833-b9b9ad4a0cd8@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <e3svw09clM3QZVdC3shb8DcJdvSkubsQv7-u1YFcRqk=.b4996354-c254-4cce-9b3f-d72347f81fde@github.com>
 <BLmNmlobY0BB35-NhDUhKdwHB8ECXBKMxdupIFm-5-M=.c5d0c0f6-f501-43c7-b833-b9b9ad4a0cd8@github.com>
Message-ID: <s-Hq6SG5BxG6ItRvcnU11BPb5cewUSGOGZJluA4vabQ=.3b06ce5b-b894-4072-9342-7d5500caecc2@github.com>

On Wed, 20 Dec 2023 20:39:55 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Can you include the performance comparison before and after this change and what performance benchmarks you run?

I've run two batches on Aurora with mixed results (linked to [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960)): `org.openjdk.bech.java.lang.invoke.+` and startup benchmarks

I can attach some of them here if needed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17108#issuecomment-1865359565

From asotona at openjdk.org  Thu Dec 21 02:02:39 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 21 Dec 2023 02:02:39 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v3]
In-Reply-To: <B5XP8rjT47fY8ht1TUkzgcy6D4jiKxCQlf7jz_8uRZc=.cf1fc710-e215-4817-b4cd-0e74415dd2bb@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
 <B5XP8rjT47fY8ht1TUkzgcy6D4jiKxCQlf7jz_8uRZc=.cf1fc710-e215-4817-b4cd-0e74415dd2bb@github.com>
Message-ID: <ypckcX-tmlvl0dG539lJmGWPAM1IMQk8pd1dDX2nVa4=.d2f35f4e-d834-4df2-8aaa-b62cc7368c1d@github.com>

On Thu, 21 Dec 2023 01:12:07 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes.
>> 
>> This patch converts it to use Classfile API.
>> 
>> It is continuation of https://github.com/openjdk/jdk/pull/10991
>> 
>> Any comments and suggestions are welcome.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - performance improvements
>  - SplitConstantPool performance fix

Here are actual numbers (_22 is before this patch):

Benchmark                      Mode  Cnt      Score      Error  Units
ProxyPerf.genIntf_1            avgt    5  18354.110 ?  696.706  ns/op
ProxyPerf.genIntf_1_22         avgt    5  15744.305 ? 1032.092  ns/op
ProxyPerf.genStringsIntf_3     avgt    5  26388.493 ? 2614.877  ns/op
ProxyPerf.genStringsIntf_3_22  avgt    5  21431.752 ?  398.627  ns/op
ProxyPerf.genZeroParams        avgt    5  17627.978 ?  456.046  ns/op
ProxyPerf.genZeroParams_22     avgt    5  15411.519 ? 6426.321  ns/op
ProxyPerf.getPrimsIntf_2       avgt    5  23862.592 ? 2274.386  ns/op
ProxyPerf.getPrimsIntf_2_22    avgt    5  19148.768 ?  648.304  ns/op
Finished running test 'micro:.+ProxyPerf.+'

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17121#issuecomment-1865370450

From jpai at openjdk.org  Thu Dec 21 07:02:48 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 21 Dec 2023 07:02:48 GMT
Subject: RFR: 8318971 : Better Error Handling for Jar Tool When Processing
 Non-existent Files [v4]
In-Reply-To: <yVI-yJS9g5tNnGTT1KHEOJvrYf895NiMn49_p2xHNWI=.ecaaff80-6fd0-4529-aeb0-d597828f00f8@github.com>
References: <xht1jEn-KP8Fhz4Xa4MBxlhsvlxk3mdAkpdv9dF77oQ=.3fdc9a36-e7da-4230-9b26-40dacb8e92b6@github.com>
 <yVI-yJS9g5tNnGTT1KHEOJvrYf895NiMn49_p2xHNWI=.ecaaff80-6fd0-4529-aeb0-d597828f00f8@github.com>
Message-ID: <YVm5wSnU65AHo-uufU5Vno4R54RBQqo0jqSxI8U2N0E=.8861612d-4154-4ae5-865f-b1cff9beaa03@github.com>

On Wed, 20 Dec 2023 16:29:59 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> Better Error Handling for Jar Tool Processing of "@File" <br>
>> 
>> This is a new PR for this PR since the original developer left the team. See all of the review history at https://github.com/openjdk/jdk/pull/16423.
>> 
>> Thank you.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update the test cases

Marked as reviewed by jpai (Reviewer).

The current state in `ff349833` looks good to me. Thank you for these updates. Please run tier1, tier2, tier3 before integrating.

-------------

PR Review: https://git.openjdk.org/jdk/pull/17088#pullrequestreview-1792326348
PR Comment: https://git.openjdk.org/jdk/pull/17088#issuecomment-1865680335

From jpai at openjdk.org  Thu Dec 21 07:58:49 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 21 Dec 2023 07:58:49 GMT
Subject: RFR: JDK-8322512 StringBuffer.repeat does not work correctly after
 toString() was called [v2]
In-Reply-To: <4dsw9PpupmaAYyUU1Chso28_5ceXQM83Cxuoiw8o538=.f0289813-ddc4-4200-a817-57753214dbed@github.com>
References: <ckv4vEc57mqb3WVvqK4Jzgg_XyxksNhQJOkWs8OkY1U=.cf8e712e-3051-4a1d-a338-acdb5c18a43e@github.com>
 <4dsw9PpupmaAYyUU1Chso28_5ceXQM83Cxuoiw8o538=.f0289813-ddc4-4200-a817-57753214dbed@github.com>
Message-ID: <yUVsv4S546vPlgikTle1iWBieDOoUVO-FAbsJCyoBEI=.cf27a6e7-2f29-4776-84c6-cf8cbce1ae7e@github.com>

On Wed, 20 Dec 2023 22:18:08 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> The new repeat methods were not clearing the toStringCache.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clear sooner

The changes look good to me. I just have a minor comment about the `assertEquals` usage which I've added inline.

test/jdk/java/lang/StringBuilder/StringBufferRepeat.java line 138:

> 136:         sb.repeat('*', 5);
> 137:         expected = "*****";
> 138:         assertEquals(expected, sb.toString());

Hello Jim, just a minor detail - in case of testng's `Assert.assertEquals()` the first param is the `actual` and the second is the `expected`. Some other existing usages of this method in this test also have the incorrect order.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17172#pullrequestreview-1792409092
PR Review Comment: https://git.openjdk.org/jdk/pull/17172#discussion_r1433678563

From duke at openjdk.org  Thu Dec 21 08:37:23 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 21 Dec 2023 08:37:23 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v6]
In-Reply-To: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
Message-ID: <4-Zn9oqXC-_d38CRCI15yMAO48ZGquByySQxffBhRSk=.27a99d39-65e2-43a3-87e0-ec6bfe04b2f0@github.com>

> @cl4es made performance optimizations for the simple specifiers of String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the same idea, I continued to make improvements. I made patterns like %2d %02d also be optimized.
> 
> The following are the test results based on MacBookPro M1 Pro: 
> 
> 
> -Benchmark                          Mode  Cnt     Score     Error  Units
> -StringFormat.complexFormat         avgt   15  1862.233 ? 217.479  ns/op
> -StringFormat.int02Format           avgt   15   312.491 ?  26.021  ns/op
> -StringFormat.intFormat             avgt   15    84.432 ?   4.145  ns/op
> -StringFormat.longFormat            avgt   15    87.330 ?   6.111  ns/op
> -StringFormat.stringFormat          avgt   15    63.985 ?  11.366  ns/op
> -StringFormat.stringIntFormat       avgt   15    87.422 ?   0.147  ns/op
> -StringFormat.widthStringFormat     avgt   15   250.740 ?  32.639  ns/op
> -StringFormat.widthStringIntFormat  avgt   15   312.474 ?  16.309  ns/op
> 
> +Benchmark                          Mode  Cnt    Score    Error  Units
> +StringFormat.complexFormat         avgt   15  740.626 ? 66.671  ns/op (+151.45)
> +StringFormat.int02Format           avgt   15  131.049 ?  0.432  ns/op (+138.46)
> +StringFormat.intFormat             avgt   15   67.229 ?  4.155  ns/op (+25.59)
> +StringFormat.longFormat            avgt   15   66.444 ?  0.614  ns/op (+31.44)
> +StringFormat.stringFormat          avgt   15   62.619 ?  4.652  ns/op (+2.19)
> +StringFormat.stringIntFormat       avgt   15   89.606 ? 13.966  ns/op (-2.44)
> +StringFormat.widthStringFormat     avgt   15   52.462 ? 15.649  ns/op (+377.95)
> +StringFormat.widthStringIntFormat  avgt   15  101.814 ?  3.147  ns/op (+206.91)

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 40 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into optim_for_string_format
 - fix from @rgiulietti 's review
 - add document
 - fix FormatterBuilder testcase handle lineSeparator on windows
 - fix from @rgiulietti 's review
 - move testcases to Basic.java
 - move testcase from BasicInt to Basic-X
 - add copyright info
 - Improve the readability, suggestion from @rgiulietti
 - Improve the readability of parseArgument, suggestion from @rgiulietti
 - ... and 30 more: https://git.openjdk.org/jdk/compare/d69c9736...9618d61d

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15776/files
  - new: https://git.openjdk.org/jdk/pull/15776/files/289a0249..9618d61d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=04-05

  Stats: 885728 lines in 6433 files changed: 233035 ins; 559174 del; 93519 mod
  Patch: https://git.openjdk.org/jdk/pull/15776.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15776/head:pull/15776

PR: https://git.openjdk.org/jdk/pull/15776

From duke at openjdk.org  Thu Dec 21 08:38:16 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 21 Dec 2023 08:38:16 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v14]
In-Reply-To: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
Message-ID: <9N2vrl6xumm9rU5JyuMTIm9uikjLxPUYCTLgywWzOjw=.48d37291-5a69-45db-b59e-61728dfcb6ea@github.com>

> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
> 
> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
> Please review and don't hesitate to critique my approach and patch.

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Merge remote-tracking branch 'upstream/master' into optim_decimal_to_string_x1
 - revert use JLA
 - merge from master
 - Merge remote-tracking branch 'upstream/master' into optim_decimal_to_string_x1
   
   # Conflicts:
   #	src/java.base/share/classes/java/math/BigDecimal.java
 - use JLA
 - update copyright info & comments
 - reduce duplicate code & code format & refactor benchmark case
 - Merge remote-tracking branch 'upstream/master' into optim_decimal_to_string_x1
 - remove JLA
 - recipe ("\1.\1\1")
 - ... and 7 more: https://git.openjdk.org/jdk/compare/e8768ae0...0ac31c5c

-------------

Changes: https://git.openjdk.org/jdk/pull/16006/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16006&range=13
  Stats: 464 lines in 3 files changed: 215 ins; 139 del; 110 mod
  Patch: https://git.openjdk.org/jdk/pull/16006.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16006/head:pull/16006

PR: https://git.openjdk.org/jdk/pull/16006

From rgiulietti at openjdk.org  Thu Dec 21 09:36:06 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 21 Dec 2023 09:36:06 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v9]
In-Reply-To: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
Message-ID: <TKYUTKkpMCPZHEwRCCuRrbWZOhlN1DuffWS71lD_8yI=.b17a1d25-fe1a-41ed-8a16-b477b9b2b193@github.com>

> Adds serialization misdeclaration events to JFR.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Removed @module from test.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17129/files
  - new: https://git.openjdk.org/jdk/pull/17129/files/94fc01ba..3289bee3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=07-08

  Stats: 14 lines in 1 file changed: 0 ins; 2 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/17129.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17129/head:pull/17129

PR: https://git.openjdk.org/jdk/pull/17129

From sgehwolf at openjdk.org  Thu Dec 21 09:39:55 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 21 Dec 2023 09:39:55 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v13]
In-Reply-To: <jW2WKKwvN7S0BnZgj5Tq_Fo6BkVGol8xLCr9AwGINVY=.a1be7796-7112-45de-99d8-ccca057bd29e@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <1VoNUv8RTXkFcv411pVhC0E3AEZfsp_8EZNXn4IyP5M=.09425f9b-a6b4-4ed0-b659-09cf7aa4adba@github.com>
 <jW2WKKwvN7S0BnZgj5Tq_Fo6BkVGol8xLCr9AwGINVY=.a1be7796-7112-45de-99d8-ccca057bd29e@github.com>
Message-ID: <o_cK3DXEXBP4DPu7hqNYQkXdEIH4_nWnpL9kHve4yN8=.f6909a22-ed74-4989-8116-3c5996862dda@github.com>

On Tue, 19 Dec 2023 19:14:42 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Disallow packaged modules and run-time image link
>>  - Only check for existing path when not a scratch task
>>    
>>    When using a run-time image link and the initial build was produced with
>>    the --keep-packaged-modules option, we don't need to check existing
>>    paths to the location where packaged modules need to be copied. This
>>    breaks the --verbose output validation.
>
> FWIW.   [f623930](https://github.com/mlchung/jdk/commit/f623930cd529085ddb730a60b7facf106ea01955) for your reference.   I pulled your branch and refactored and made suggestions to the code while I was walking through the code.   Some observations:
> 
> The constants such as the pathname of the timestamp file and the internal file listing
> per-module non-class non-resource files are part of jlink.  I move the constants to
> `JlinkTask`to follow where `OPTIONS_RESOURCE` is defined.
> 
> `JRTArchive` scans the class and resource files of a given module from the runtime image.
> It should also read `fs_$MODULE_files` to find the list of non-class and non-resource files.
> 
> The current implementation checks if a file is modified lazily when `Entry::stream`
> is called and so it has to remember if file modification has been checked and
> warning has been emitted.   I think doing the file modification check eagerly
> when `collectFiles` is called would simplify the code.
> 
> For maintainability, better to move the reading of and writing to `fs_$MODULE_files`
> together in a single class rather than separated in `JRTArchive` and `JlinkResourcesListPlugin`.
> I move them to `JRTArchive.ResourceFileEntry` for now.   There may be a better place.

Thanks, @mlchung! I'll incorporate your refactoring into the PR and will address review feedback in the new year. Thanks for the review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1865943588

From egahlin at openjdk.org  Thu Dec 21 09:42:06 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 21 Dec 2023 09:42:06 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v9]
In-Reply-To: <TKYUTKkpMCPZHEwRCCuRrbWZOhlN1DuffWS71lD_8yI=.b17a1d25-fe1a-41ed-8a16-b477b9b2b193@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <TKYUTKkpMCPZHEwRCCuRrbWZOhlN1DuffWS71lD_8yI=.b17a1d25-fe1a-41ed-8a16-b477b9b2b193@github.com>
Message-ID: <PQWLipkMqlrYsRMQ2ujiAeBtRheaLwU5rUYnkB4mCgI=.8c1a993b-96a2-49a6-8b32-e7b57f06a0bd@github.com>

On Thu, 21 Dec 2023 09:36:06 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed @module from test.

src/jdk.jfr/share/classes/jdk/jfr/events/SerializationMisdeclarationEvent.java line 37:

> 35: 
> 36: @Name(Type.EVENT_NAME_PREFIX + "SerializationMisdeclaration")
> 37: @Label("Serialization Deserialization")

The label of the event seems incorrect, shouldn't it be "Serialization Misdeclaration"?

src/jdk.jfr/share/classes/jdk/jfr/events/SerializationMisdeclarationEvent.java line 47:

> 45: public final class SerializationMisdeclarationEvent extends AbstractJDKEvent {
> 46: 
> 47:     @Label("MisdeclaredClass")

Should be "Misdeclared Class"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1433814736
PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1433813701

From rgiulietti at openjdk.org  Thu Dec 21 09:53:10 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 21 Dec 2023 09:53:10 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v10]
In-Reply-To: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
Message-ID: <v_nmDEgUdTZ4AJ9vp14fAql9k5CmIGN8HKAbK76m5Dk=.b7b33f62-f241-428c-96e1-7c5abd568c65@github.com>

> Adds serialization misdeclaration events to JFR.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Corrected @Label of event and of field.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17129/files
  - new: https://git.openjdk.org/jdk/pull/17129/files/3289bee3..9cb25a12

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=08-09

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17129.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17129/head:pull/17129

PR: https://git.openjdk.org/jdk/pull/17129

From stsypanov at openjdk.org  Thu Dec 21 12:03:40 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 21 Dec 2023 12:03:40 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v3]
In-Reply-To: <B5XP8rjT47fY8ht1TUkzgcy6D4jiKxCQlf7jz_8uRZc=.cf1fc710-e215-4817-b4cd-0e74415dd2bb@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
 <B5XP8rjT47fY8ht1TUkzgcy6D4jiKxCQlf7jz_8uRZc=.cf1fc710-e215-4817-b4cd-0e74415dd2bb@github.com>
Message-ID: <9XVcjLUEyCkGNzyKlzpzhOEGrVzf_UD9vIQAx5BDG_o=.7f134387-1b7e-4a45-a42d-7e517799d5ee@github.com>

On Thu, 21 Dec 2023 01:12:07 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes.
>> 
>> This patch converts it to use Classfile API.
>> 
>> It is continuation of https://github.com/openjdk/jdk/pull/10991
>> 
>> Any comments and suggestions are welcome.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - performance improvements
>  - SplitConstantPool performance fix

src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java line 62:

> 60:     private final Utf8Entry methodDesc;
> 61:     private final SplitConstantPool cp;
> 62:     private final LinkedList<Target> targets;

Wouldn't it be better to use `ArrayDeque` instead of `LinkedList`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17121#discussion_r1433979344

From goetz at openjdk.org  Thu Dec 21 12:06:56 2023
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Thu, 21 Dec 2023 12:06:56 GMT
Subject: RFR: 8322417: Console read line with zero out should zero out when
 throwing exception
In-Reply-To: <PTF-6aGprJfpvAvaG0WAYkjn8LXs8ZPtXLkcyvqdQqc=.bc64adf1-f8e7-428a-afd3-88d49d4fbbda@github.com>
References: <OQ2mDsSWRLfNxXO0BapseECzeKY91cHesHXBQNKwNDU=.17212cbf-e920-4b99-8f70-8056f1d14fc3@github.com>
 <PTF-6aGprJfpvAvaG0WAYkjn8LXs8ZPtXLkcyvqdQqc=.bc64adf1-f8e7-428a-afd3-88d49d4fbbda@github.com>
Message-ID: <MdVoOREBc_IC49JJ25Q6RAjp7dpx8pU4eDE8IxQIKaA=.73efbf47-f07f-4919-8e62-6b5836d42937@github.com>

On Wed, 20 Dec 2023 08:07:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> ?g exception
>> 
>> After leaving the method by throwing an exception the data can not be cleaned any more.
>
> src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 122:
> 
>> 120:                             ioe.addSuppressed(x);
>> 121:                     }
>> 122:                     if (ioe != null) {
> 
> I assume it's only important to zero the buffer when restoring the echo setting fails. If I read the changes correctly then it's been zero's even if readLine fails. It's okay, just probably unnecessary for that case.

Yes, but this way it's assured we clean before we return.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17156#discussion_r1433984024

From asotona at openjdk.org  Thu Dec 21 12:35:51 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 21 Dec 2023 12:35:51 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v3]
In-Reply-To: <9XVcjLUEyCkGNzyKlzpzhOEGrVzf_UD9vIQAx5BDG_o=.7f134387-1b7e-4a45-a42d-7e517799d5ee@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
 <B5XP8rjT47fY8ht1TUkzgcy6D4jiKxCQlf7jz_8uRZc=.cf1fc710-e215-4817-b4cd-0e74415dd2bb@github.com>
 <9XVcjLUEyCkGNzyKlzpzhOEGrVzf_UD9vIQAx5BDG_o=.7f134387-1b7e-4a45-a42d-7e517799d5ee@github.com>
Message-ID: <RxFMlJRn9AclG1KYyc8WIS7DTvAhNUedwrsh-QyLWvk=.181e1675-c6cc-4cce-87e4-20fc0ed3ab5f@github.com>

On Thu, 21 Dec 2023 12:01:25 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - performance improvements
>>  - SplitConstantPool performance fix
>
> src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java line 62:
> 
>> 60:     private final Utf8Entry methodDesc;
>> 61:     private final SplitConstantPool cp;
>> 62:     private final LinkedList<Target> targets;
> 
> Wouldn't it be better to use `ArrayDeque` instead of `LinkedList`?

Good point, I'll change it, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17121#discussion_r1434015586

From asotona at openjdk.org  Thu Dec 21 12:49:02 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 21 Dec 2023 12:49:02 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v4]
In-Reply-To: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
Message-ID: <lxdJSV0sQvWWdmZVnRy22DwRc94p7E9f6ZSqWkkk4uc=.0f94785f-b082-4f98-90f8-1cf96cbf38ce@github.com>

> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes.
> 
> This patch converts it to use Classfile API.
> 
> It is continuation of https://github.com/openjdk/jdk/pull/10991
> 
> Any comments and suggestions are welcome.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  applied the recommended changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17121/files
  - new: https://git.openjdk.org/jdk/pull/17121/files/75e31e3a..7d0da2c0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17121&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17121&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17121.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17121/head:pull/17121

PR: https://git.openjdk.org/jdk/pull/17121

From asotona at openjdk.org  Thu Dec 21 13:32:12 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 21 Dec 2023 13:32:12 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v5]
In-Reply-To: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
Message-ID: <b6zMiAP6xVsRojzfRXDi_lgOcnEgsd0tYMG4TCBGWx0=.d63ac3fc-21ea-4ac3-a10a-3b6a9310e44a@github.com>

> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes.
> 
> This patch converts it to use Classfile API.
> 
> It is continuation of https://github.com/openjdk/jdk/pull/10991
> 
> Any comments and suggestions are welcome.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  minor StackCounter fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17121/files
  - new: https://git.openjdk.org/jdk/pull/17121/files/7d0da2c0..41e87934

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17121&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17121&range=03-04

  Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17121.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17121/head:pull/17121

PR: https://git.openjdk.org/jdk/pull/17121

From duke at openjdk.org  Thu Dec 21 14:50:38 2023
From: duke at openjdk.org (ExE Boss)
Date: Thu, 21 Dec 2023 14:50:38 GMT
Subject: RFR: 8322292: Rearrange comparison of fields in Record.equals()
 [v4]
In-Reply-To: <zpp5vJWq4GGvFjnLrlv2ZjnxqOhvd6J_sP5SQUJm98Y=.0cc71327-4c31-4b4d-b647-d6072bbeffff@github.com>
References: <eNySqrZ9HgZrjF61lHA_6YecuPT7RB9xxz82U3zIjog=.f8b68ce5-3fab-4cfa-8709-17e51d77a958@github.com>
 <zpp5vJWq4GGvFjnLrlv2ZjnxqOhvd6J_sP5SQUJm98Y=.0cc71327-4c31-4b4d-b647-d6072bbeffff@github.com>
Message-ID: <R4MlhLv6do4_NuulNdpF9cbfakVEn0_cfzfyFXabQr4=.9e207be9-4018-44b5-b344-1501002f8039@github.com>

On Wed, 20 Dec 2023 10:11:58 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Currently if we create a record it's fields are compared in their declaration order. This might be ineffective in cases when two objects have "heavy" fields equals to each other, but different "lightweight" fields (heavy and lightweight in terms of comparison) e.g. primitives, enums, nullable/non-nulls etc.
>> 
>> If we have declared a record like
>> 
>> public record MyRecord(String field1, int field2) {}
>> 
>> It's equals() looks like:
>> 
>>   public final equals(Ljava/lang/Object;)Z
>>    L0
>>     LINENUMBER 3 L0
>>     ALOAD 0
>>     ALOAD 1
>>     INVOKEDYNAMIC equals(Lcom/caspianone/openbanking/productservice/controller/MyRecord;Ljava/lang/Object;)Z [
>>       // handle kind 0x6 : INVOKESTATIC
>>       java/lang/runtime/ObjectMethods.bootstrap(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/TypeDescriptor;Ljava/lang/Class;Ljava/lang/String;[Ljava/lang/invoke/MethodHandle;)Ljava/lang/Object;
>>       // arguments:
>>       com.caspianone.openbanking.productservice.controller.MyRecord.class,
>>       "field1;field2",
>>       // handle kind 0x1 : GETFIELD
>>       com/caspianone/openbanking/productservice/controller/MyRecord.field1(Ljava/lang/String;),
>>       // handle kind 0x1 : GETFIELD
>>       com/caspianone/openbanking/productservice/controller/MyRecord.field2(I)
>>     ]
>>     IRETURN
>>    L1
>>     LOCALVARIABLE this Lcom/caspianone/openbanking/productservice/controller/MyRecord; L0 L1 0
>>     LOCALVARIABLE o Ljava/lang/Object; L0 L1 1
>>     MAXSTACK = 2
>>     MAXLOCALS = 2
>> 
>> This can be improved by rearranging the comparison order of the fields moving enums and primitives upper, and collections/arrays lower.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8322292: Tiny improvement

src/java.base/share/classes/java/lang/runtime/ObjectMethods.java line 227:

> 225:             }
> 226:             return rt1.isPrimitive() || rt1.isEnum() || rt1.isArray() ? 1 : Iterable.class.isAssignableFrom(rt1) ? -1 : 0;
> 227:         });

The?way this?comparator is?currently?implemented, the?`signum(c.compare(mh1,?mh2)) ==?-signum(c.compare(mh2,?mh1))` assertion?won?t?hold, which?will?cause the?sorting to?be?unstable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17143#discussion_r1434166820

From duke at openjdk.org  Thu Dec 21 14:57:48 2023
From: duke at openjdk.org (ExE Boss)
Date: Thu, 21 Dec 2023 14:57:48 GMT
Subject: RFR: 8322292: Rearrange comparison of fields in Record.equals()
 [v4]
In-Reply-To: <R4MlhLv6do4_NuulNdpF9cbfakVEn0_cfzfyFXabQr4=.9e207be9-4018-44b5-b344-1501002f8039@github.com>
References: <eNySqrZ9HgZrjF61lHA_6YecuPT7RB9xxz82U3zIjog=.f8b68ce5-3fab-4cfa-8709-17e51d77a958@github.com>
 <zpp5vJWq4GGvFjnLrlv2ZjnxqOhvd6J_sP5SQUJm98Y=.0cc71327-4c31-4b4d-b647-d6072bbeffff@github.com>
 <R4MlhLv6do4_NuulNdpF9cbfakVEn0_cfzfyFXabQr4=.9e207be9-4018-44b5-b344-1501002f8039@github.com>
Message-ID: <bB2GFWk2brt7TgUxUSrRLNtUchmSJf40GbyC7UY36sU=.a664d057-320d-4d30-af37-fe77279bef4c@github.com>

On Thu, 21 Dec 2023 14:47:43 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8322292: Tiny improvement
>
> src/java.base/share/classes/java/lang/runtime/ObjectMethods.java line 227:
> 
>> 225:             }
>> 226:             return rt1.isPrimitive() || rt1.isEnum() || rt1.isArray() ? 1 : Iterable.class.isAssignableFrom(rt1) ? -1 : 0;
>> 227:         });
> 
> The?way this?comparator is?currently?implemented, the?`signum(c.compare(mh1,?mh2)) ==?-signum(c.compare(mh2,?mh1))` assertion?won?t?hold, which?will?cause the?sorting to?be?unstable.

This?should?ensure stable?ordering:
Suggestion:

        Arrays.sort(equalsGetters, (mh1, mh2) -> {
            var rt1 = mh1.type().returnType();
            var rt2 = mh2.type().returnType();
            return Integer.compare(
                rt1.isPrimitive() || rt1.isEnum() || rt1.isArray() ? 1 : Iterable.class.isAssignableFrom(rt1) ? -1 : 0,
                rt2.isPrimitive() || rt2.isEnum() || rt2.isArray() ? 1 : Iterable.class.isAssignableFrom(rt2) ? -1 : 0
            );
        });

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17143#discussion_r1434173126

From jpai at openjdk.org  Thu Dec 21 14:59:50 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 21 Dec 2023 14:59:50 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v8]
In-Reply-To: <p7nchdmmsLLGEepc2Zo1_GDjm2s9Sbzr8PsHqtBBQU0=.88eadba5-d0ab-4aa8-a148-1a4a23b13256@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <YC-brtYplAtPMhbeW2nv1XxQRLNVMEKRHbJv8JFVQQM=.8d8c7d60-27c4-4a61-b9cf-45dad0da18c2@github.com>
 <p7nchdmmsLLGEepc2Zo1_GDjm2s9Sbzr8PsHqtBBQU0=.88eadba5-d0ab-4aa8-a148-1a4a23b13256@github.com>
Message-ID: <z-iKOhk1El5H4P1H-9qNFnQRJQspxXW5jcYt4CVDyUs=.b9c02462-4a99-4a3a-9bae-1943a858041e@github.com>

On Tue, 28 Nov 2023 18:38:42 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Extract ZIP64_BLOCK_SIZE_OFFSET as a constant
>
> Thanks for your patient and thorough review of this long-lived PR, Lance!
> 
> No worries, we can hold off the integration until after 22 is forked off mainline.

Hello Eirik @eirbjo, if this isn't sponsored by tomorrow, then I'll go ahead and do it for you tomorrow. I would have done it now, but there appear to be far too many commits in mainline (540 odd) since this PR was last synced against master branch. Before sponsoring, I'll run a CI test to make sure this doesn't cause any unexpected issues in any area.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12524#issuecomment-1866424258

From sgibbons at openjdk.org  Thu Dec 21 15:21:08 2023
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 21 Dec 2023 15:21:08 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v5]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <jjgXujKNdw7Bt5KopUrv05_onDaqVqRU1auhh5kNqbA=.a9218000-d912-4395-85fd-59d67128d40d@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Addressing review comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/48088348..63db0961

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=03-04

  Stats: 43 lines in 4 files changed: 1 ins; 11 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From rgiulietti at openjdk.org  Thu Dec 21 15:56:52 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 21 Dec 2023 15:56:52 GMT
Subject: RFR: JDK-8311009: Long.toUnsignedString(long,
 int) doesn't have to create a BigInteger [v2]
In-Reply-To: <sWHpozHw3XmXWKJPEHK96mUHbLtIh1lNHwz1vZvCTLg=.094e1e22-3207-4440-89d3-ca228b330140@github.com>
References: <Z_k_zxsuiNiiI9DqGZVPXALlqcXxOJ2VFrK9UQf3Ugw=.a8687de6-4cb4-4560-b830-0e74b12c012e@github.com>
 <sWHpozHw3XmXWKJPEHK96mUHbLtIh1lNHwz1vZvCTLg=.094e1e22-3207-4440-89d3-ca228b330140@github.com>
Message-ID: <tYwt4lyRr3Bu1mF5JmAqPCtyrpdM7g36lB1u1yY1vy8=.26eef2ac-47dd-464d-8432-7c976f82b92d@github.com>

On Wed, 28 Jun 2023 07:57:25 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

>> This PR changes the implementation of `Long.toUnsignedString(long, int)` for "default" radices, which avoids creating a `BigInteger` and makes use of `Long.divideUnsigned` and `Long.remainderUnsigned`.
>> 
>> I've run the test on `test/jdk/java/lang/Long/Unsigned.java` and it works correctly. I believe that there is no need to add more test cases.
>> 
>> I've added a benchmark case to `test/micro/org/openjdk/bench/java/lang/Longs.java` for this method. Here is the benchmark result tested on my machine:
>> 
>> Before (JDK 20.0.1):
>> 
>> 
>> Benchmark                       (size)  Mode  Cnt     Score    Error  Units
>> Longs.toUnsignedStringNegative     500  avgt   15  6428.711 ? 63.142  us/op
>> 
>> 
>> After:
>> 
>> 
>> Benchmark                       (size)  Mode  Cnt     Score     Error  Units
>> Longs.toUnsignedStringNegative     500  avgt   15  3823.655 ? 146.171  us/op
>> 
>> 
>> No CSR needed since the behavior is not changed.
>
> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

src/java.base/share/classes/java/lang/Long.java line 242:

> 240:                 default -> {
> 241:                     long leadingDigits = divideUnsigned(i, radix);  // always positive
> 242:                     int lastDigit = (int)remainderUnsigned(i, radix);

You can avoid the additional division from `remainderUnsigned()` like so
Suggestion:

                    int lastDigit = (int)(i - leadingDigits * radix);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14654#discussion_r1434242670

From stsypanov at openjdk.org  Thu Dec 21 16:58:00 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 21 Dec 2023 16:58:00 GMT
Subject: RFR: 8322292: Rearrange comparison of fields in Record.equals()
 [v5]
In-Reply-To: <eNySqrZ9HgZrjF61lHA_6YecuPT7RB9xxz82U3zIjog=.f8b68ce5-3fab-4cfa-8709-17e51d77a958@github.com>
References: <eNySqrZ9HgZrjF61lHA_6YecuPT7RB9xxz82U3zIjog=.f8b68ce5-3fab-4cfa-8709-17e51d77a958@github.com>
Message-ID: <JDhp3AQMPf_WCjxhNHok4uo6RkmqYqj0g-uknZTTPRw=.16b81d77-3254-4154-bcf0-5e27705598b8@github.com>

> Currently if we create a record it's fields are compared in their declaration order. This might be ineffective in cases when two objects have "heavy" fields equals to each other, but different "lightweight" fields (heavy and lightweight in terms of comparison) e.g. primitives, enums, nullable/non-nulls etc.
> 
> If we have declared a record like
> 
> public record MyRecord(String field1, int field2) {}
> 
> It's equals() looks like:
> 
>   public final equals(Ljava/lang/Object;)Z
>    L0
>     LINENUMBER 3 L0
>     ALOAD 0
>     ALOAD 1
>     INVOKEDYNAMIC equals(Lcom/caspianone/openbanking/productservice/controller/MyRecord;Ljava/lang/Object;)Z [
>       // handle kind 0x6 : INVOKESTATIC
>       java/lang/runtime/ObjectMethods.bootstrap(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/TypeDescriptor;Ljava/lang/Class;Ljava/lang/String;[Ljava/lang/invoke/MethodHandle;)Ljava/lang/Object;
>       // arguments:
>       com.caspianone.openbanking.productservice.controller.MyRecord.class,
>       "field1;field2",
>       // handle kind 0x1 : GETFIELD
>       com/caspianone/openbanking/productservice/controller/MyRecord.field1(Ljava/lang/String;),
>       // handle kind 0x1 : GETFIELD
>       com/caspianone/openbanking/productservice/controller/MyRecord.field2(I)
>     ]
>     IRETURN
>    L1
>     LOCALVARIABLE this Lcom/caspianone/openbanking/productservice/controller/MyRecord; L0 L1 0
>     LOCALVARIABLE o Ljava/lang/Object; L0 L1 1
>     MAXSTACK = 2
>     MAXLOCALS = 2
> 
> This can be improved by rearranging the comparison order of the fields moving enums and primitives upper, and collections/arrays lower.

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/runtime/ObjectMethods.java
  
  Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17143/files
  - new: https://git.openjdk.org/jdk/pull/17143/files/9c8ae4fb..158d9a83

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17143&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17143&range=03-04

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/17143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17143/head:pull/17143

PR: https://git.openjdk.org/jdk/pull/17143

From duke at openjdk.org  Thu Dec 21 17:07:48 2023
From: duke at openjdk.org (Markus KARG)
Date: Thu, 21 Dec 2023 17:07:48 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v16]
In-Reply-To: <UYDhC9MD9jt1n_3Y6Hoc29AYEAaoRX5f0WlDr5sUNxY=.5251f559-ec37-4c96-86a4-b537d0ce40ee@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <UYDhC9MD9jt1n_3Y6Hoc29AYEAaoRX5f0WlDr5sUNxY=.5251f559-ec37-4c96-86a4-b537d0ce40ee@github.com>
Message-ID: <LmVwlJtlhYcjxnnAzcSdTsbK-R4-przd_gnjPugcvyg=.c120df37-9397-4d88-8b31-0a3f74a3a951@github.com>

On Tue, 19 Dec 2023 10:18:11 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`.
>> 
>> See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612
>
> Sergey Tsypanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision:
> 
>  - 8322292: Remove TransferToTrusted.checkedOutputStream()
>  - 8320971: Adjust JavaDoc
>  - Merge branch 'master' into 8320971
>  - 8320971: Revert irrelevant changes
>  - 8320971: Add more tests
>  - 8320971: Fix JavaDoc
>  - 8320971: Whitespaces
>  - 8320971: Fix build
>  - 8320971: Move IOStreams to com.sun.io
>  - Merge branch 'master' into 8320971
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/2de7943f...84686bc6

Still +1 :-)

-------------

Marked as reviewed by mkarg at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/16879#pullrequestreview-1793369387

From bpb at openjdk.org  Thu Dec 21 17:31:55 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 21 Dec 2023 17:31:55 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v16]
In-Reply-To: <UYDhC9MD9jt1n_3Y6Hoc29AYEAaoRX5f0WlDr5sUNxY=.5251f559-ec37-4c96-86a4-b537d0ce40ee@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <UYDhC9MD9jt1n_3Y6Hoc29AYEAaoRX5f0WlDr5sUNxY=.5251f559-ec37-4c96-86a4-b537d0ce40ee@github.com>
Message-ID: <LXA8rCKDJ1FfKEYhhT0tkZ8CLurkONzDjPmDWiQEAiM=.7c10fe31-e5aa-4c90-b809-6606edc6868b@github.com>

On Tue, 19 Dec 2023 10:18:11 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`.
>> 
>> See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612
>
> Sergey Tsypanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision:
> 
>  - 8322292: Remove TransferToTrusted.checkedOutputStream()
>  - 8320971: Adjust JavaDoc
>  - Merge branch 'master' into 8320971
>  - 8320971: Revert irrelevant changes
>  - 8320971: Add more tests
>  - 8320971: Fix JavaDoc
>  - 8320971: Whitespaces
>  - 8320971: Fix build
>  - 8320971: Move IOStreams to com.sun.io
>  - Merge branch 'master' into 8320971
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/54ca8c60...84686bc6

The test does not fail when run against the mainline (HEAD: Thu Dec 21 15:20:01 2023 +0000 UTC). As previously mentioned elsewhere, normally a deterministic test should fail before the proposed source patch is applied, and succeed thereafter.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16879#issuecomment-1866685521

From duke at openjdk.org  Thu Dec 21 18:33:48 2023
From: duke at openjdk.org (Rob Spoor)
Date: Thu, 21 Dec 2023 18:33:48 GMT
Subject: RFR: 8322292: Rearrange comparison of fields in Record.equals()
 [v5]
In-Reply-To: <JDhp3AQMPf_WCjxhNHok4uo6RkmqYqj0g-uknZTTPRw=.16b81d77-3254-4154-bcf0-5e27705598b8@github.com>
References: <eNySqrZ9HgZrjF61lHA_6YecuPT7RB9xxz82U3zIjog=.f8b68ce5-3fab-4cfa-8709-17e51d77a958@github.com>
 <JDhp3AQMPf_WCjxhNHok4uo6RkmqYqj0g-uknZTTPRw=.16b81d77-3254-4154-bcf0-5e27705598b8@github.com>
Message-ID: <dbf6t1a6hKEySSC_9hhoXsuhoYgl66c4QxiIvhuSQ-I=.3e7031cb-0edb-4497-884b-c0ea9af1a4c8@github.com>

On Thu, 21 Dec 2023 16:58:00 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Currently if we create a record it's fields are compared in their declaration order. This might be ineffective in cases when two objects have "heavy" fields equals to each other, but different "lightweight" fields (heavy and lightweight in terms of comparison) e.g. primitives, enums, nullable/non-nulls etc.
>> 
>> If we have declared a record like
>> 
>> public record MyRecord(String field1, int field2) {}
>> 
>> It's equals() looks like:
>> 
>>   public final equals(Ljava/lang/Object;)Z
>>    L0
>>     LINENUMBER 3 L0
>>     ALOAD 0
>>     ALOAD 1
>>     INVOKEDYNAMIC equals(Lcom/caspianone/openbanking/productservice/controller/MyRecord;Ljava/lang/Object;)Z [
>>       // handle kind 0x6 : INVOKESTATIC
>>       java/lang/runtime/ObjectMethods.bootstrap(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/TypeDescriptor;Ljava/lang/Class;Ljava/lang/String;[Ljava/lang/invoke/MethodHandle;)Ljava/lang/Object;
>>       // arguments:
>>       com.caspianone.openbanking.productservice.controller.MyRecord.class,
>>       "field1;field2",
>>       // handle kind 0x1 : GETFIELD
>>       com/caspianone/openbanking/productservice/controller/MyRecord.field1(Ljava/lang/String;),
>>       // handle kind 0x1 : GETFIELD
>>       com/caspianone/openbanking/productservice/controller/MyRecord.field2(I)
>>     ]
>>     IRETURN
>>    L1
>>     LOCALVARIABLE this Lcom/caspianone/openbanking/productservice/controller/MyRecord; L0 L1 0
>>     LOCALVARIABLE o Ljava/lang/Object; L0 L1 1
>>     MAXSTACK = 2
>>     MAXLOCALS = 2
>> 
>> This can be improved by rearranging the comparison order of the fields moving enums and primitives upper, and collections/arrays lower.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/runtime/ObjectMethods.java
>   
>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

src/java.base/share/classes/java/lang/runtime/ObjectMethods.java line 224:

> 222:             var rt2 = mh2.type().returnType();
> 223:             return Integer.compare(
> 224:                 rt1.isPrimitive() || rt1.isEnum() || rt1.isArray() ? 1 : Iterable.class.isAssignableFrom(rt1) ? -1 : 0,

Doesn't this put primitives, enums and arrays at the end instead of at the start? I've tried this with a simple array:

Class<?>[] types = { int.class, String.class, List.class, long.class, TimeUnit.class, byte[].class, Integer.class };

The result of sorting:

 Class[7] { interface java.util.List, class java.lang.String, class java.lang.Integer, int, long, class java.util.concurrent.TimeUnit, class [B }

By switching the -1 and 1 I get the primitives etc.  at the start:

 Class[7] { int, long, class java.util.concurrent.TimeUnit, class [B, class java.lang.String, class java.lang.Integer, interface java.util.List }
``

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17143#discussion_r1434386929

From ccheung at openjdk.org  Thu Dec 21 19:15:53 2023
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 21 Dec 2023 19:15:53 GMT
Subject: RFR: 8322322: Support archived full module graph when
 -Xbootclasspath/a is used
Message-ID: <3kfpHpIrCoXI2e1E8Ht-ZrxBjeRdgp0Qisfk8UvYCMw=.6b7fc4e2-9031-42e3-8811-2bbb0dfd329d@github.com>

Please review this change for enabling full module graph even when -Xbootclasspath/a is specified. The validation of -Xbootclasspath/a is already being done in `FileMapInfo::validate_boot_class_paths()`. The full module graph will be disabled if there's a mismatch in -Xbootclasspath/a between dump time and runtime.

The changes in ClassLoaders.java is for setting up the append class path for the boot loader retrieved from the CDS archive. It is required because some existing tests are using the `getResourceAsStream()` api. Those tests would fail without the change.

Passed tiers 1 - 4 testing.

-------------

Commit messages:
 - 8322322: Support archived full module graph when -Xbootclasspath/a is used

Changes: https://git.openjdk.org/jdk/pull/17178/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17178&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322322
  Stats: 46 lines in 4 files changed: 33 ins; 10 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17178.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17178/head:pull/17178

PR: https://git.openjdk.org/jdk/pull/17178

From duke at openjdk.org  Thu Dec 21 19:46:48 2023
From: duke at openjdk.org (ExE Boss)
Date: Thu, 21 Dec 2023 19:46:48 GMT
Subject: RFR: 8322292: Rearrange comparison of fields in Record.equals()
 [v5]
In-Reply-To: <dbf6t1a6hKEySSC_9hhoXsuhoYgl66c4QxiIvhuSQ-I=.3e7031cb-0edb-4497-884b-c0ea9af1a4c8@github.com>
References: <eNySqrZ9HgZrjF61lHA_6YecuPT7RB9xxz82U3zIjog=.f8b68ce5-3fab-4cfa-8709-17e51d77a958@github.com>
 <JDhp3AQMPf_WCjxhNHok4uo6RkmqYqj0g-uknZTTPRw=.16b81d77-3254-4154-bcf0-5e27705598b8@github.com>
 <dbf6t1a6hKEySSC_9hhoXsuhoYgl66c4QxiIvhuSQ-I=.3e7031cb-0edb-4497-884b-c0ea9af1a4c8@github.com>
Message-ID: <DVDq3I7_cWEQOSmrOxsCXPKVYv69TOZGGCP02ZyKfKQ=.93afdf31-27a7-4675-b3fa-092588398f04@github.com>

On Thu, 21 Dec 2023 18:30:40 GMT, Rob Spoor <duke at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/java/lang/runtime/ObjectMethods.java
>>   
>>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>
> src/java.base/share/classes/java/lang/runtime/ObjectMethods.java line 224:
> 
>> 222:             var rt2 = mh2.type().returnType();
>> 223:             return Integer.compare(
>> 224:                 rt1.isPrimitive() || rt1.isEnum() || rt1.isArray() ? 1 : Iterable.class.isAssignableFrom(rt1) ? -1 : 0,
> 
> Doesn't this put primitives, enums and arrays at the end instead of at the start? I've tried this with a simple array:
> 
> Class<?>[] types = { int.class, String.class, List.class, long.class, TimeUnit.class, byte[].class, Integer.class };
> 
> The result of sorting:
> 
>  Class[7] { interface java.util.List, class java.lang.String, class java.lang.Integer, int, long, class java.util.concurrent.TimeUnit, class [B }
> 
> By switching the -1 and 1 I get the primitives etc.  at the start:
> 
>  Class[7] { int, long, class java.util.concurrent.TimeUnit, class [B, class java.lang.String, class java.lang.Integer, interface java.util.List }
> ``

The?`equalator`s are?joined?together in?reverse?order, so?this is?actually?correct for?the?current?implementation:


record Example(A a, B b, C c) {
	public static void main(String... args) {
		final var left	= new Example(new A(), new B(), new C());
		final var right	= new Example(new A(), new B(), new C());

		left.equals(right);
		// prints:
		// > C::equals()
		// > B::equals()
		// > A::equals()
	}
}

record A() {
	@Override
	public boolean equals(Object other) {
		System.out.println("A::equals()");
		return other instanceof A;
	}
}

record B() {
	@Override
	public boolean equals(Object other) {
		System.out.println("B::equals()");
		return other instanceof B;
	}
}

record C() {
	@Override
	public boolean equals(Object other) {
		System.out.println("C::equals()");
		return other instanceof C;
	}
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17143#discussion_r1434439484

From rriggs at openjdk.org  Thu Dec 21 21:49:55 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 21 Dec 2023 21:49:55 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v10]
In-Reply-To: <v_nmDEgUdTZ4AJ9vp14fAql9k5CmIGN8HKAbK76m5Dk=.b7b33f62-f241-428c-96e1-7c5abd568c65@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <v_nmDEgUdTZ4AJ9vp14fAql9k5CmIGN8HKAbK76m5Dk=.b7b33f62-f241-428c-96e1-7c5abd568c65@github.com>
Message-ID: <V5XeScTz90RwzMseScn5pofoMmumoybfspExxDqq0B8=.0a67d890-0026-438d-aad0-76bc63511883@github.com>

On Thu, 21 Dec 2023 09:53:10 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Corrected @Label of event and of field.

src/java.base/share/classes/java/io/ObjectStreamClass.java line 466:

> 464: 
> 465:         if (SerializationMisdeclarationEvent.enabled() && serializable) {
> 466:             new SerializationMisdeclarationChecker(cl).checkMisdeclarations();

Is there any benefit to avoiding the allocation and passing the class through the methods as an extra arg?

src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 149:

> 147:         if (!(spf instanceof ObjectStreamField[])) {
> 148:             commitEvent(SERIAL_PERSISTENT_FIELDS_NAME +
> 149:                     " must be an instance of ObjectStreamField[] to be effective");

Hmmm...  

The terminology "to be effective" seems a bit indirect and may lead to some head scratching.
In most cases it means it is ignored.
I might suggest to just state the condition that is required and drop the extra phrase.
For example,  "xxx should be an instance of ObjectStreamField[]".
It would result in shorter messages and if further explanation of the message is needed it can more completely elaborate on the impact of the incorrect declaration.

src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 165:

> 163:             commitEvent("method " + m + " on an enum class is not effective");
> 164:         } else if (cl.isRecord()) {
> 165:             commitEvent("method " + m + " on an record class is not effective");

"an record" -> "a record"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1434524764
PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1434512690
PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1434513714

From emcmanus at openjdk.org  Thu Dec 21 21:57:02 2023
From: emcmanus at openjdk.org (Eamonn McManus)
Date: Thu, 21 Dec 2023 21:57:02 GMT
Subject: RFR: 8068958: Timestamp.from(Instant) should throw when conversion is
 not possible
Message-ID: <LhDps2Gcl43rCkFQI-Msuk5Ysb0ndEr4JqA_Ba2j0E8=.79f63a5d-540b-4543-87a0-4017aabf91ef@github.com>

Multiplying with `*` never produces `ArithmeticException`, so the catch in the existing code is never triggered. `Math.multiplyExact` does produce `ArithmeticException` if the multiplication overflows. So we can use that, and rethrow `IllegalArgumentException` as the specification says.

There is a small compatibility risk, in that code may have been relying on the previous silent overflow, and will now get an exception. But an exception is surely better than the nonsense results that overflow produces.

Thanks to Kurt Kluever for the test cases.

-------------

Commit messages:
 - 8068958: Timestamp.from(Instant) should throw when conversion is not possible

Changes: https://git.openjdk.org/jdk/pull/17181/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17181&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8068958
  Stats: 30 lines in 2 files changed: 29 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17181.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17181/head:pull/17181

PR: https://git.openjdk.org/jdk/pull/17181

From rgiulietti at openjdk.org  Thu Dec 21 22:27:09 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 21 Dec 2023 22:27:09 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v11]
In-Reply-To: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
Message-ID: <71dcKEKrAclcdZ8eYRsC0RZzlVT_Yg7hej-NSMrY1to=.d5c7901c-78d1-4476-a67d-9e8df58d611d@github.com>

> Adds serialization misdeclaration events to JFR.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Simplified event messages.
  Remove ckecker allocation.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17129/files
  - new: https://git.openjdk.org/jdk/pull/17129/files/9cb25a12..91523c67

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=09-10

  Stats: 82 lines in 2 files changed: 7 ins; 19 del; 56 mod
  Patch: https://git.openjdk.org/jdk/pull/17129.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17129/head:pull/17129

PR: https://git.openjdk.org/jdk/pull/17129

From rgiulietti at openjdk.org  Thu Dec 21 22:27:10 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 21 Dec 2023 22:27:10 GMT
Subject: RFR: 8275338: Add JFR events for notable serialization situations
 [v10]
In-Reply-To: <V5XeScTz90RwzMseScn5pofoMmumoybfspExxDqq0B8=.0a67d890-0026-438d-aad0-76bc63511883@github.com>
References: <NpaITf1wFqtNBBBFkDPsLlRZNonpZtpNANVS7hHYHb8=.2f4e7aa3-aec1-4e97-8550-5750bf0493fc@github.com>
 <v_nmDEgUdTZ4AJ9vp14fAql9k5CmIGN8HKAbK76m5Dk=.b7b33f62-f241-428c-96e1-7c5abd568c65@github.com>
 <V5XeScTz90RwzMseScn5pofoMmumoybfspExxDqq0B8=.0a67d890-0026-438d-aad0-76bc63511883@github.com>
Message-ID: <qB1Yga0AEJ3TGKdWYFMpD6mlDt9JtessGdkYA-gqqE4=.4ef624a8-3064-4cb6-a517-c0ca6359b318@github.com>

On Thu, 21 Dec 2023 21:24:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Corrected @Label of event and of field.
>
> src/java.base/share/classes/java/io/ObjectStreamClass.java line 466:
> 
>> 464: 
>> 465:         if (SerializationMisdeclarationEvent.enabled() && serializable) {
>> 466:             new SerializationMisdeclarationChecker(cl).checkMisdeclarations();
> 
> Is there any benefit to avoiding the allocation and passing the class through the methods as an extra arg?

The allocation has been removed and the event messages have been simplified in the most recent commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1434558624

From emcmanus at openjdk.org  Thu Dec 21 23:22:46 2023
From: emcmanus at openjdk.org (Eamonn McManus)
Date: Thu, 21 Dec 2023 23:22:46 GMT
Subject: RFR: 8068958: Timestamp.from(Instant) should throw when conversion
 is not possible
In-Reply-To: <LhDps2Gcl43rCkFQI-Msuk5Ysb0ndEr4JqA_Ba2j0E8=.79f63a5d-540b-4543-87a0-4017aabf91ef@github.com>
References: <LhDps2Gcl43rCkFQI-Msuk5Ysb0ndEr4JqA_Ba2j0E8=.79f63a5d-540b-4543-87a0-4017aabf91ef@github.com>
Message-ID: <I3t6rNAS0Whk_fhs5vU_Jty7QN7wHoLCwuutobz0p8U=.645a081b-4430-4a75-9b31-e4b550c1bccf@github.com>

On Thu, 21 Dec 2023 21:51:10 GMT, Eamonn McManus <emcmanus at openjdk.org> wrote:

> Multiplying with `*` never produces `ArithmeticException`, so the catch in the existing code is never triggered. `Math.multiplyExact` does produce `ArithmeticException` if the multiplication overflows. So we can use that, and rethrow `IllegalArgumentException` as the specification says.
> 
> There is a small compatibility risk, in that code may have been relying on the previous silent overflow, and will now get an exception. But an exception is surely better than the nonsense results that overflow produces.
> 
> Thanks to Kurt Kluever for the test cases.

I think the three overflow cases we have are probably enough? (Just too big, as big as possible, as small as possible.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17181#discussion_r1434585279

From duke at openjdk.org  Fri Dec 22 01:43:05 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 22 Dec 2023 01:43:05 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v6]
In-Reply-To: <4-Zn9oqXC-_d38CRCI15yMAO48ZGquByySQxffBhRSk=.27a99d39-65e2-43a3-87e0-ec6bfe04b2f0@github.com>
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
 <4-Zn9oqXC-_d38CRCI15yMAO48ZGquByySQxffBhRSk=.27a99d39-65e2-43a3-87e0-ec6bfe04b2f0@github.com>
Message-ID: <1o4Iez4JGZNl4jQk5X11v2t8kWFdTad-Q65ImZZqIXY=.cf1d09e8-6b85-4e12-b376-89f99220667b@github.com>

On Thu, 21 Dec 2023 08:37:23 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> @cl4es made performance optimizations for the simple specifiers of String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the same idea, I continued to make improvements. I made patterns like %2d %02d also be optimized.
>> 
>> The following are the test results based on MacBookPro M1 Pro: 
>> 
>> 
>> -Benchmark                          Mode  Cnt     Score     Error  Units
>> -StringFormat.complexFormat         avgt   15  1862.233 ? 217.479  ns/op
>> -StringFormat.int02Format           avgt   15   312.491 ?  26.021  ns/op
>> -StringFormat.intFormat             avgt   15    84.432 ?   4.145  ns/op
>> -StringFormat.longFormat            avgt   15    87.330 ?   6.111  ns/op
>> -StringFormat.stringFormat          avgt   15    63.985 ?  11.366  ns/op
>> -StringFormat.stringIntFormat       avgt   15    87.422 ?   0.147  ns/op
>> -StringFormat.widthStringFormat     avgt   15   250.740 ?  32.639  ns/op
>> -StringFormat.widthStringIntFormat  avgt   15   312.474 ?  16.309  ns/op
>> 
>> +Benchmark                          Mode  Cnt    Score    Error  Units
>> +StringFormat.complexFormat         avgt   15  740.626 ? 66.671  ns/op (+151.45)
>> +StringFormat.int02Format           avgt   15  131.049 ?  0.432  ns/op (+138.46)
>> +StringFormat.intFormat             avgt   15   67.229 ?  4.155  ns/op (+25.59)
>> +StringFormat.longFormat            avgt   15   66.444 ?  0.614  ns/op (+31.44)
>> +StringFormat.stringFormat          avgt   15   62.619 ?  4.652  ns/op (+2.19)
>> +StringFormat.stringIntFormat       avgt   15   89.606 ? 13.966  ns/op (-2.44)
>> +StringFormat.widthStringFormat     avgt   15   52.462 ? 15.649  ns/op (+377.95)
>> +StringFormat.widthStringIntFormat  avgt   15  101.814 ?  3.147  ns/op (+206.91)
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 40 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into optim_for_string_format
>  - fix from @rgiulietti 's review
>  - add document
>  - fix FormatterBuilder testcase handle lineSeparator on windows
>  - fix from @rgiulietti 's review
>  - move testcases to Basic.java
>  - move testcase from BasicInt to Basic-X
>  - add copyright info
>  - Improve the readability, suggestion from @rgiulietti
>  - Improve the readability of parseArgument, suggestion from @rgiulietti
>  - ... and 30 more: https://git.openjdk.org/jdk/compare/013daea1...9618d61d

@AlanBateman @cl4es Can you help me continue to complete the review of this PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1867124158

From duke at openjdk.org  Fri Dec 22 04:25:56 2023
From: duke at openjdk.org (duke)
Date: Fri, 22 Dec 2023 04:25:56 GMT
Subject: Withdrawn: 8318486: Rename JavaLangAccess.xxNoRepl to xxReportError
In-Reply-To: <F7eDLEii8Z3rjPEX2nqORl1jhfa5xI0QzbgnNVF6QeQ=.76e1b612-73bd-4d7f-9170-98b9688dfdb0@github.com>
References: <F7eDLEii8Z3rjPEX2nqORl1jhfa5xI0QzbgnNVF6QeQ=.76e1b612-73bd-4d7f-9170-98b9688dfdb0@github.com>
Message-ID: <qW10bPIIWi1eEECM30_QlncdiaQHADjHVGBqHPmETDA=.ddae1d0b-f6e5-459a-b4cb-49b3ec739a63@github.com>

On Thu, 19 Oct 2023 07:04:50 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review a patch that renames `JavaLangAccess::xxNoRepl` to `xxReportError` to explicitly indicate these APIs report encoding errors.
> 
> The old "NoRepl" suffix presumably means "No Replacement", but it has been misunderstood as "No Replication" (#16209) and misused as an array sharing API in performance optimization patches.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/16260

From duke at openjdk.org  Fri Dec 22 07:50:55 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 22 Dec 2023 07:50:55 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files
In-Reply-To: <cbrnMfVEbMt0BR9CcuxKH_qAu9ANnL4mCzJPTZ8DpTE=.e6b9eb22-0792-40a0-ad92-29b7c56c15f5@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
 <cbrnMfVEbMt0BR9CcuxKH_qAu9ANnL4mCzJPTZ8DpTE=.e6b9eb22-0792-40a0-ad92-29b7c56c15f5@github.com>
Message-ID: <OBOytYvXSxfQ9JyTN7kz0Hq51J-TPcKjyeQofA7YLJw=.ffbd430f-54cb-4dd3-ac82-f4aa09c91404@github.com>

On Sun, 12 Feb 2023 17:04:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the number of compressed or uncompressed bytes read from the inflater is larger than the Zip64 magic value.
>> 
>> While the ZIP format  mandates that the data descriptor `SHOULD be stored in ZIP64 format (as 8 byte values) when a file's size exceeds 0xFFFFFFFF`, it also states that `ZIP64 format MAY be used regardless of the size of a file`. For such small entries, the above assumption does not hold.
>> 
>> This PR augments ZipInputStream.readEnd to also assume 8-byte sizes if the ZipEntry includes a Zip64 extra information field. This brings ZipInputStream into alignment with the APPNOTE format spec:
>> 
>> 
>> When extracting, if the zip64 extended information extra 
>> field is present for the file the compressed and 
>> uncompressed sizes will be 8 byte values.
>> 
>> 
>> While small Zip64 files with 8-byte data descriptors are not commonly found in the wild, it is possible to create one using the Info-ZIP command line `-fd` flag:
>> 
>> `echo hello | zip -fd > hello.zip`
>> 
>> The PR also adds a test verifying that such a small Zip64 file can be parsed by ZipInputStream.
>
> This proposed change will require a lot of review cycles and a lot of testing. The current implementation came about because of issues with several zip tools so we have to be very careful changing it.

@AlanBateman I was planning to integrate this myself pending the OpenJDK census update for my JDK Commiter status and the Skara team linking my Github account.

But there is no rush here, I'm happy to hold off until you find time to provide feedback. This can wait, please enjoy your holidays! :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12524#issuecomment-1867350502

From duke at openjdk.org  Fri Dec 22 07:55:24 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 22 Dec 2023 07:55:24 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v9]
In-Reply-To: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
Message-ID: <3KjBjm_luIFfKpWgFI2g7YLfGEYPPEIdwB1EsgFb2l8=.860081a4-7c8e-4867-b6f9-2a7b9061fba2@github.com>

> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the number of compressed or uncompressed bytes read from the inflater is larger than the Zip64 magic value.
> 
> While the ZIP format  mandates that the data descriptor `SHOULD be stored in ZIP64 format (as 8 byte values) when a file's size exceeds 0xFFFFFFFF`, it also states that `ZIP64 format MAY be used regardless of the size of a file`. For such small entries, the above assumption does not hold.
> 
> This PR augments ZipInputStream.readEnd to also assume 8-byte sizes if the ZipEntry includes a Zip64 extra information field. This brings ZipInputStream into alignment with the APPNOTE format spec:
> 
> 
> When extracting, if the zip64 extended information extra 
> field is present for the file the compressed and 
> uncompressed sizes will be 8 byte values.
> 
> 
> While small Zip64 files with 8-byte data descriptors are not commonly found in the wild, it is possible to create one using the Info-ZIP command line `-fd` flag:
> 
> `echo hello | zip -fd > hello.zip`
> 
> The PR also adds a test verifying that such a small Zip64 file can be parsed by ZipInputStream.

Eirik Bjorsnos has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:

 - Merge branch 'master' into data-descriptor
 - Extract ZIP64_BLOCK_SIZE_OFFSET as a constant
 - A Zip64 extra field used in a LOC header must include both the uncompressed and compressed size fields, and does not include local header offset or disk start number fields. Conequently, a valid LOC Zip64 block must always be 16 bytes long.
 - Document better the zip command and options used to generate the test vector ZIP
 - Fix spelling of "presence"
 - Add a @bug reference in the test
 - Use the term "block size" when referring to the size of a Zip64 extra field data block
 - Update comment reflect that a Zip64 extended field in a LOC header has only two valid block sizes
 - Convert test from testNG to JUnit
 - Fix the check that the size of an extra field block size must not grow past the total extra field length
 - ... and 23 more: https://git.openjdk.org/jdk/compare/e2042421...ddff130f

-------------

Changes: https://git.openjdk.org/jdk/pull/12524/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12524&range=08
  Stats: 238 lines in 2 files changed: 237 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12524.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12524/head:pull/12524

PR: https://git.openjdk.org/jdk/pull/12524

From alanb at openjdk.org  Fri Dec 22 08:49:48 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 22 Dec 2023 08:49:48 GMT
Subject: RFR: 8322322: Support archived full module graph when
 -Xbootclasspath/a is used
In-Reply-To: <3kfpHpIrCoXI2e1E8Ht-ZrxBjeRdgp0Qisfk8UvYCMw=.6b7fc4e2-9031-42e3-8811-2bbb0dfd329d@github.com>
References: <3kfpHpIrCoXI2e1E8Ht-ZrxBjeRdgp0Qisfk8UvYCMw=.6b7fc4e2-9031-42e3-8811-2bbb0dfd329d@github.com>
Message-ID: <cAEuPqPXJyWPzaPb778D5zKagfiqn-BQZ8hn5qgOgWQ=.619a61e1-ac71-4fbe-ace6-8ee221865ab5@github.com>

On Thu, 21 Dec 2023 19:10:59 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Please review this change for enabling full module graph even when -Xbootclasspath/a is specified. The validation of -Xbootclasspath/a is already being done in `FileMapInfo::validate_boot_class_paths()`. The full module graph will be disabled if there's a mismatch in -Xbootclasspath/a between dump time and runtime.
> 
> The changes in ClassLoaders.java is for setting up the append class path for the boot loader retrieved from the CDS archive. It is required because some existing tests are using the `getResourceAsStream()` api. Those tests would fail without the change.
> 
> Passed tiers 1 - 4 testing.

Changes looks okay although running -Xbootclasspath/a is an outliner that I wouldn't expect to see at dump time or runtime, the motive here seems to be tests.

src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java line 71:

> 69:         URLClassPath bootAppendUcp = (append != null && !append.isEmpty())
> 70:                 ? new URLClassPath(append, true)
> 71:                 : null;

Would you mind renaming this to bootUcp or bcp? The reason is that this is the boot loader's class path, not the append path. The system property has "append" in the name as it's communicating the value of -Xbootclasspath/a to the library code, this came about when -Xbootclasspath and -Xbootclasspath/p were removed.

src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java line 76:

> 74:             BOOT_LOADER = (BootClassLoader) archivedClassLoaders.bootLoader();
> 75:             setArchivedServicesCatalog(BOOT_LOADER);
> 76:             BOOT_LOADER.setClassPath(bootAppendUcp);

It might be clearer to set this before calling setArchivedServicesCatalog.

-------------

PR Review: https://git.openjdk.org/jdk/pull/17178#pullrequestreview-1794149461
PR Review Comment: https://git.openjdk.org/jdk/pull/17178#discussion_r1434844648
PR Review Comment: https://git.openjdk.org/jdk/pull/17178#discussion_r1434845035

From rgiulietti at openjdk.org  Fri Dec 22 09:10:49 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 22 Dec 2023 09:10:49 GMT
Subject: RFR: 8068958: Timestamp.from(Instant) should throw when conversion
 is not possible
In-Reply-To: <LhDps2Gcl43rCkFQI-Msuk5Ysb0ndEr4JqA_Ba2j0E8=.79f63a5d-540b-4543-87a0-4017aabf91ef@github.com>
References: <LhDps2Gcl43rCkFQI-Msuk5Ysb0ndEr4JqA_Ba2j0E8=.79f63a5d-540b-4543-87a0-4017aabf91ef@github.com>
Message-ID: <0y4o6MMe_haSzAK3Cbq9p7PTMm2qqV3xvcfWuGMO0a8=.683fb50b-02a6-464f-9ae6-5cd7ecfdc98b@github.com>

On Thu, 21 Dec 2023 21:51:10 GMT, Eamonn McManus <emcmanus at openjdk.org> wrote:

> Multiplying with `*` never produces `ArithmeticException`, so the catch in the existing code is never triggered. `Math.multiplyExact` does produce `ArithmeticException` if the multiplication overflows. So we can use that, and rethrow `IllegalArgumentException` as the specification says.
> 
> There is a small compatibility risk, in that code may have been relying on the previous silent overflow, and will now get an exception. But an exception is surely better than the nonsense results that overflow produces.
> 
> Thanks to Kurt Kluever for the test cases.

Please update the copyright years in both the files.

test/jdk/java/sql/testng/test/sql/TimestampTests.java line 649:

> 647:         // The latest Instant that can be converted to a Timestamp.
> 648:         Instant instant1 = Instant.ofEpochSecond(Long.MAX_VALUE / 1000, 999_999_999);
> 649:         assertEquals(instant1, Timestamp.from(instant1).toInstant());

The 1st arg to `assertEquals()` should be the actual value, the 2nd should be the expected result. I guess you expect `instant1` to be the expected result.
(TestNG and JUnit have opposite conventions...)

test/jdk/java/sql/testng/test/sql/TimestampTests.java line 658:

> 656:         } catch (IllegalArgumentException expected) {
> 657:         }
> 658: 

TestNG supports a better way for expected exceptions, as an attribute of the @Test annotation. Maybe it can be used here for the expected failing cases?

-------------

PR Review: https://git.openjdk.org/jdk/pull/17181#pullrequestreview-1794185027
PR Review Comment: https://git.openjdk.org/jdk/pull/17181#discussion_r1434867044
PR Review Comment: https://git.openjdk.org/jdk/pull/17181#discussion_r1434867239

From stsypanov at openjdk.org  Fri Dec 22 09:55:15 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 22 Dec 2023 09:55:15 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v17]
In-Reply-To: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
Message-ID: <0yHNMSapOJmfRyGfe_DeqnFIl6yheCjtBKMKKNfDVK0=.78284283-237e-4b14-bb7d-bddf11026a7e@github.com>

> It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`.
> 
> See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612

Sergey Tsypanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision:

 - Merge branch 'master' into 8320971
 - 8320971: Inline tests
 - 8322292: Remove TransferToTrusted.checkedOutputStream()
 - 8320971: Adjust JavaDoc
 - Merge branch 'master' into 8320971
 - 8320971: Revert irrelevant changes
 - 8320971: Add more tests
 - 8320971: Fix JavaDoc
 - 8320971: Whitespaces
 - 8320971: Fix build
 - ... and 12 more: https://git.openjdk.org/jdk/compare/15c2671f...ee035998

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16879/files
  - new: https://git.openjdk.org/jdk/pull/16879/files/84686bc6..ee035998

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16879&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16879&range=15-16

  Stats: 1284 lines in 66 files changed: 844 ins; 243 del; 197 mod
  Patch: https://git.openjdk.org/jdk/pull/16879.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16879/head:pull/16879

PR: https://git.openjdk.org/jdk/pull/16879

From stsypanov at openjdk.org  Fri Dec 22 09:55:18 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 22 Dec 2023 09:55:18 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v16]
In-Reply-To: <LXA8rCKDJ1FfKEYhhT0tkZ8CLurkONzDjPmDWiQEAiM=.7c10fe31-e5aa-4c90-b809-6606edc6868b@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <UYDhC9MD9jt1n_3Y6Hoc29AYEAaoRX5f0WlDr5sUNxY=.5251f559-ec37-4c96-86a4-b537d0ce40ee@github.com>
 <LXA8rCKDJ1FfKEYhhT0tkZ8CLurkONzDjPmDWiQEAiM=.7c10fe31-e5aa-4c90-b809-6606edc6868b@github.com>
Message-ID: <yfd5fRBSxeKRh50I5Do77-8TRWYlHXlzQvCfJnYySlA=.3cd2db8a-7e82-4f1c-8149-7655adda2e84@github.com>

On Thu, 21 Dec 2023 17:29:16 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision:
>> 
>>  - 8322292: Remove TransferToTrusted.checkedOutputStream()
>>  - 8320971: Adjust JavaDoc
>>  - Merge branch 'master' into 8320971
>>  - 8320971: Revert irrelevant changes
>>  - 8320971: Add more tests
>>  - 8320971: Fix JavaDoc
>>  - 8320971: Whitespaces
>>  - 8320971: Fix build
>>  - 8320971: Move IOStreams to com.sun.io
>>  - Merge branch 'master' into 8320971
>>  - ... and 10 more: https://git.openjdk.org/jdk/compare/6b2d77cf...84686bc6
>
> The test does not fail when run against the mainline (HEAD: Thu Dec 21 15:20:01 2023 +0000 UTC). As previously mentioned elsewhere, normally a deterministic test should fail before the proposed source patch is applied, and succeed thereafter.

@bplb the test doesn't fail because buffer copying is already there in BIS

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16879#issuecomment-1867475999

From stsypanov at openjdk.org  Fri Dec 22 13:00:11 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 22 Dec 2023 13:00:11 GMT
Subject: RFR: 8322292: Rearrange comparison of fields in Record.equals()
 [v6]
In-Reply-To: <eNySqrZ9HgZrjF61lHA_6YecuPT7RB9xxz82U3zIjog=.f8b68ce5-3fab-4cfa-8709-17e51d77a958@github.com>
References: <eNySqrZ9HgZrjF61lHA_6YecuPT7RB9xxz82U3zIjog=.f8b68ce5-3fab-4cfa-8709-17e51d77a958@github.com>
Message-ID: <ZcEkUGVaklPTLkHo8X147Mpt5-9kHIgYpIUHL1Hr3mM=.419e2246-e7a6-48f7-a114-1c34d50d6200@github.com>

> Currently if we create a record it's fields are compared in their declaration order. This might be ineffective in cases when two objects have "heavy" fields equals to each other, but different "lightweight" fields (heavy and lightweight in terms of comparison) e.g. primitives, enums, nullable/non-nulls etc.
> 
> If we have declared a record like
> 
> public record MyRecord(String field1, int field2) {}
> 
> It's equals() looks like:
> 
>   public final equals(Ljava/lang/Object;)Z
>    L0
>     LINENUMBER 3 L0
>     ALOAD 0
>     ALOAD 1
>     INVOKEDYNAMIC equals(Lcom/caspianone/openbanking/productservice/controller/MyRecord;Ljava/lang/Object;)Z [
>       // handle kind 0x6 : INVOKESTATIC
>       java/lang/runtime/ObjectMethods.bootstrap(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/TypeDescriptor;Ljava/lang/Class;Ljava/lang/String;[Ljava/lang/invoke/MethodHandle;)Ljava/lang/Object;
>       // arguments:
>       com.caspianone.openbanking.productservice.controller.MyRecord.class,
>       "field1;field2",
>       // handle kind 0x1 : GETFIELD
>       com/caspianone/openbanking/productservice/controller/MyRecord.field1(Ljava/lang/String;),
>       // handle kind 0x1 : GETFIELD
>       com/caspianone/openbanking/productservice/controller/MyRecord.field2(I)
>     ]
>     IRETURN
>    L1
>     LOCALVARIABLE this Lcom/caspianone/openbanking/productservice/controller/MyRecord; L0 L1 0
>     LOCALVARIABLE o Ljava/lang/Object; L0 L1 1
>     MAXSTACK = 2
>     MAXLOCALS = 2
> 
> This can be improved by rearranging the comparison order of the fields moving enums and primitives upper, and collections/arrays lower.

Sergey Tsypanov has updated the pull request incrementally with two additional commits since the last revision:

 - Merge remote-tracking branch 'origin/record-equals' into record-equals
 - 8322292: Add test case

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17143/files
  - new: https://git.openjdk.org/jdk/pull/17143/files/158d9a83..037a3fd1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17143&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17143&range=04-05

  Stats: 42 lines in 1 file changed: 41 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17143/head:pull/17143

PR: https://git.openjdk.org/jdk/pull/17143

From stsypanov at openjdk.org  Fri Dec 22 13:00:11 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 22 Dec 2023 13:00:11 GMT
Subject: RFR: 8322292: Rearrange comparison of fields in Record.equals()
 [v5]
In-Reply-To: <DVDq3I7_cWEQOSmrOxsCXPKVYv69TOZGGCP02ZyKfKQ=.93afdf31-27a7-4675-b3fa-092588398f04@github.com>
References: <eNySqrZ9HgZrjF61lHA_6YecuPT7RB9xxz82U3zIjog=.f8b68ce5-3fab-4cfa-8709-17e51d77a958@github.com>
 <JDhp3AQMPf_WCjxhNHok4uo6RkmqYqj0g-uknZTTPRw=.16b81d77-3254-4154-bcf0-5e27705598b8@github.com>
 <dbf6t1a6hKEySSC_9hhoXsuhoYgl66c4QxiIvhuSQ-I=.3e7031cb-0edb-4497-884b-c0ea9af1a4c8@github.com>
 <DVDq3I7_cWEQOSmrOxsCXPKVYv69TOZGGCP02ZyKfKQ=.93afdf31-27a7-4675-b3fa-092588398f04@github.com>
Message-ID: <62qi7_c0WUiS4Yolq6kFy-2fopKxiBRbMbUiq-fMnqs=.1dff38f6-09b3-4998-ba31-19e6489f823d@github.com>

On Thu, 21 Dec 2023 19:43:50 GMT, ExE Boss <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/runtime/ObjectMethods.java line 224:
>> 
>>> 222:             var rt2 = mh2.type().returnType();
>>> 223:             return Integer.compare(
>>> 224:                 rt1.isPrimitive() || rt1.isEnum() || rt1.isArray() ? 1 : Iterable.class.isAssignableFrom(rt1) ? -1 : 0,
>> 
>> Doesn't this put primitives, enums and arrays at the end instead of at the start? I've tried this with a simple array:
>> 
>> Class<?>[] types = { int.class, String.class, List.class, long.class, TimeUnit.class, byte[].class, Integer.class };
>> 
>> The result of sorting:
>> 
>>  Class[7] { interface java.util.List, class java.lang.String, class java.lang.Integer, int, long, class java.util.concurrent.TimeUnit, class [B }
>> 
>> By switching the -1 and 1 I get the primitives etc.  at the start:
>> 
>>  Class[7] { int, long, class java.util.concurrent.TimeUnit, class [B, class java.lang.String, class java.lang.Integer, interface java.util.List }
>> ``
>
> The?`equalator`s are?joined?together in?reverse?order, so?this is?actually?correct for?the?current?implementation:
> 
> 
> record Example(A a, B b, C c) {
> 	public static void main(String... args) {
> 		final var left	= new Example(new A(), new B(), new C());
> 		final var right	= new Example(new A(), new B(), new C());
> 
> 		left.equals(right);
> 		// prints:
> 		// > C::equals()
> 		// > B::equals()
> 		// > A::equals()
> 	}
> }
> 
> record A() {
> 	@Override
> 	public boolean equals(Object other) {
> 		System.out.println("A::equals()");
> 		return other instanceof A;
> 	}
> }
> 
> record B() {
> 	@Override
> 	public boolean equals(Object other) {
> 		System.out.println("B::equals()");
> 		return other instanceof B;
> 	}
> }
> 
> record C() {
> 	@Override
> 	public boolean equals(Object other) {
> 		System.out.println("C::equals()");
> 		return other instanceof C;
> 	}
> }

I've added the test case for the current algorithm

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17143#discussion_r1435034161

From duke at openjdk.org  Fri Dec 22 13:22:58 2023
From: duke at openjdk.org (Markus KARG)
Date: Fri, 22 Dec 2023 13:22:58 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v17]
In-Reply-To: <0yHNMSapOJmfRyGfe_DeqnFIl6yheCjtBKMKKNfDVK0=.78284283-237e-4b14-bb7d-bddf11026a7e@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <0yHNMSapOJmfRyGfe_DeqnFIl6yheCjtBKMKKNfDVK0=.78284283-237e-4b14-bb7d-bddf11026a7e@github.com>
Message-ID: <7iNfYPMzS9YgYNcvPErUBjT-nuaQxNeEccXtmUCnF0A=.b89af814-f95e-49ae-bb8a-5283f5d4491b@github.com>

On Fri, 22 Dec 2023 09:55:15 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`.
>> 
>> See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612
>
> Sergey Tsypanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8320971
>  - 8320971: Inline tests
>  - 8322292: Remove TransferToTrusted.checkedOutputStream()
>  - 8320971: Adjust JavaDoc
>  - Merge branch 'master' into 8320971
>  - 8320971: Revert irrelevant changes
>  - 8320971: Add more tests
>  - 8320971: Fix JavaDoc
>  - 8320971: Whitespaces
>  - 8320971: Fix build
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/17ab55e8...ee035998

test/jdk/java/io/BufferedInputStream/TransferToTrusted.java line 68:

> 66: 
> 67:         var bis = new BufferedInputStream(new ByteArrayInputStream(dup));
> 68:         bis.mark(dup.length);

If you take a closer look into `BIS::transferTo()` then you will notice that in case you call `bis.mark()` then your optimization will effectively *not getting called at all*, due to this line: https://github.com/openjdk/jdk/pull/16879/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1L643. So Brian's comment still applies and you should fix your test before this PR can be accepted for a merge (hence: you MUST get rid of `mark()`).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1435050559

From vsitnikov at openjdk.org  Fri Dec 22 13:57:02 2023
From: vsitnikov at openjdk.org (Vladimir Sitnikov)
Date: Fri, 22 Dec 2023 13:57:02 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v17]
In-Reply-To: <7iNfYPMzS9YgYNcvPErUBjT-nuaQxNeEccXtmUCnF0A=.b89af814-f95e-49ae-bb8a-5283f5d4491b@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <0yHNMSapOJmfRyGfe_DeqnFIl6yheCjtBKMKKNfDVK0=.78284283-237e-4b14-bb7d-bddf11026a7e@github.com>
 <7iNfYPMzS9YgYNcvPErUBjT-nuaQxNeEccXtmUCnF0A=.b89af814-f95e-49ae-bb8a-5283f5d4491b@github.com>
Message-ID: <noeDADduWdGZmIP5VqlTIYpZOYnxqkUZy8pXD2PWlSg=.3dc15610-983e-461f-972f-8a61a5cd1031@github.com>

On Fri, 22 Dec 2023 13:19:46 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8320971
>>  - 8320971: Inline tests
>>  - 8322292: Remove TransferToTrusted.checkedOutputStream()
>>  - 8320971: Adjust JavaDoc
>>  - Merge branch 'master' into 8320971
>>  - 8320971: Revert irrelevant changes
>>  - 8320971: Add more tests
>>  - 8320971: Fix JavaDoc
>>  - 8320971: Whitespaces
>>  - 8320971: Fix build
>>  - ... and 12 more: https://git.openjdk.org/jdk/compare/d38d95d8...ee035998
>
> test/jdk/java/io/BufferedInputStream/TransferToTrusted.java line 68:
> 
>> 66: 
>> 67:         var bis = new BufferedInputStream(new ByteArrayInputStream(dup));
>> 68:         bis.mark(dup.length);
> 
> If you take a closer look into `BIS::transferTo()` then you will notice that in case you call `bis.mark()` then your optimization will effectively *not getting called at all*, due to this line: https://github.com/openjdk/jdk/pull/16879/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1L643. So Brian's comment still applies and you should fix your test before this PR can be accepted for a merge (hence: you MUST get rid of `mark()`).

Can anybody give a hint how one can create assertions in OpenJDK test code that would check the amount of allocated heap for the tested method?

Since the change here is "removal of an allocation", the assert in the code should probably allow only a very small allocation in `.transferTo`.

Does `com.sun.management.ThreadMXBean#getCurrentThreadAllocatedBytes()` sound right for the test?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1435074076

From duke at openjdk.org  Fri Dec 22 14:29:54 2023
From: duke at openjdk.org (Markus KARG)
Date: Fri, 22 Dec 2023 14:29:54 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v17]
In-Reply-To: <noeDADduWdGZmIP5VqlTIYpZOYnxqkUZy8pXD2PWlSg=.3dc15610-983e-461f-972f-8a61a5cd1031@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <0yHNMSapOJmfRyGfe_DeqnFIl6yheCjtBKMKKNfDVK0=.78284283-237e-4b14-bb7d-bddf11026a7e@github.com>
 <7iNfYPMzS9YgYNcvPErUBjT-nuaQxNeEccXtmUCnF0A=.b89af814-f95e-49ae-bb8a-5283f5d4491b@github.com>
 <noeDADduWdGZmIP5VqlTIYpZOYnxqkUZy8pXD2PWlSg=.3dc15610-983e-461f-972f-8a61a5cd1031@github.com>
Message-ID: <wK-DgnIz6FUS8mnmyM2rSEnyaI1wToAZLzfD3MugVfw=.c080f943-ece7-4a23-b29b-54c6936c4f8d@github.com>

On Fri, 22 Dec 2023 13:53:42 GMT, Vladimir Sitnikov <vsitnikov at openjdk.org> wrote:

>> test/jdk/java/io/BufferedInputStream/TransferToTrusted.java line 68:
>> 
>>> 66: 
>>> 67:         var bis = new BufferedInputStream(new ByteArrayInputStream(dup));
>>> 68:         bis.mark(dup.length);
>> 
>> If you take a closer look into `BIS::transferTo()` then you will notice that in case you call `bis.mark()` then your optimization will effectively *not getting called at all*, due to this line: https://github.com/openjdk/jdk/pull/16879/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1L643. So Brian's comment still applies and you should fix your test before this PR can be accepted for a merge (hence: you MUST get rid of `mark()`).
>
> Can anybody give a hint how one can create assertions in OpenJDK test code that would check the amount of allocated heap for the tested method?
> 
> Since the change here is "removal of an allocation", the assert in the code should probably allow only a very small allocation in `.transferTo`.
> 
> Does `com.sun.management.ThreadMXBean#getCurrentThreadAllocatedBytes()` sound right for the test?

I think there is a misundertanding. This PR is not intendend to reduce the *amount* of allocated heap, it is about sparing time by not creating *temporary  copies*. The latter should be rather easy to check: Invoke `transferTo(out)` two times in a row and compare the *identity* of the two byte arrays passed to `out.write()`. If they stay the same, then apparently no *temporary copy* was created. Two achieve this, the BIS must be wrapper around an extendable input stream (like `FileInputStream`) so between calls the stream could get extended (e. g. by writing into the file).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1435108416

From rgiulietti at openjdk.org  Fri Dec 22 14:34:40 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 22 Dec 2023 14:34:40 GMT
Subject: RFR: 8316662: Remove one allocation per conversion in
 Double.toString(double) and Float.toString(float) [v3]
In-Reply-To: <54uc54dqaE7tut0nQ9_jdWzMjnMdGDGbw0UZNtdzqM8=.50178293-96f5-4115-a7ee-93cbdd3b8e42@github.com>
References: <ktZDmC-1cjJNkiYuIvbPzNWNSoffSbGAVtTFYLhBCbI=.9e41dd82-3dd7-4bfd-943c-35b1fae10a47@github.com>
 <54uc54dqaE7tut0nQ9_jdWzMjnMdGDGbw0UZNtdzqM8=.50178293-96f5-4115-a7ee-93cbdd3b8e42@github.com>
Message-ID: <-0UoEWbA3BEm5KxRHf9yuq0jz6LA6H_etKx3znO0cTY=.cc0dadc0-6201-409c-a71d-0c42bb2d9448@github.com>

On Fri, 27 Oct 2023 12:10:07 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> By correctly sizing an intermediate `byte[]` and making use of the internal `newStringNoRepl()` method, one allocation per conversion can be avoided when the runtime uses compact strings.
>
> Raffaello Giulietti has updated the pull request with a new target base 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 8316662
>  - Uppercase JLA.
>  - 8316662: Remove one allocation per conversion in Double.toString(double) and Float.toString(float)

Ping

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15861#issuecomment-1867753439

From vsitnikov at openjdk.org  Fri Dec 22 14:39:54 2023
From: vsitnikov at openjdk.org (Vladimir Sitnikov)
Date: Fri, 22 Dec 2023 14:39:54 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v17]
In-Reply-To: <wK-DgnIz6FUS8mnmyM2rSEnyaI1wToAZLzfD3MugVfw=.c080f943-ece7-4a23-b29b-54c6936c4f8d@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <0yHNMSapOJmfRyGfe_DeqnFIl6yheCjtBKMKKNfDVK0=.78284283-237e-4b14-bb7d-bddf11026a7e@github.com>
 <7iNfYPMzS9YgYNcvPErUBjT-nuaQxNeEccXtmUCnF0A=.b89af814-f95e-49ae-bb8a-5283f5d4491b@github.com>
 <noeDADduWdGZmIP5VqlTIYpZOYnxqkUZy8pXD2PWlSg=.3dc15610-983e-461f-972f-8a61a5cd1031@github.com>
 <wK-DgnIz6FUS8mnmyM2rSEnyaI1wToAZLzfD3MugVfw=.c080f943-ece7-4a23-b29b-54c6936c4f8d@github.com>
Message-ID: <iUHMng1JW8bOrtiYyc5SkJdRWC6iCMTfXuG0spm1sZA=.27cdf176-d776-4ec4-9f3b-0396e6f03ff2@github.com>

On Fri, 22 Dec 2023 14:27:16 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Can anybody give a hint how one can create assertions in OpenJDK test code that would check the amount of allocated heap for the tested method?
>> 
>> Since the change here is "removal of an allocation", the assert in the code should probably allow only a very small allocation in `.transferTo`.
>> 
>> Does `com.sun.management.ThreadMXBean#getCurrentThreadAllocatedBytes()` sound right for the test?
>
> I think there is a misundertanding. This PR is not intendend to reduce the *amount* of allocated heap, it is about sparing time by not creating *temporary  copies*. The latter should be rather easy to check: Invoke `transferTo(out)` two times in a row and compare the *identity* of the two byte arrays passed to `out.write()`. If they stay the same, then apparently no *temporary copy* was created. Two achieve this, the BIS must be wrapper around an extendable input stream (like `FileInputStream`) so between calls the stream could get extended (e. g. by writing into the file).

Markus, could you please double-check? A temporary allocation *is* an allocation, and it is the point of the change to avoid allocation and copying the temp data when the output stream is known to behave well. I am sure the allocation "before the change" would be non-trivial (more than several KiB), and after the change the allocation within .transferTo would be minimal (few bytes) assuming the output stream has already allocated its buffer

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1435120325

From duke at openjdk.org  Fri Dec 22 15:11:54 2023
From: duke at openjdk.org (Markus KARG)
Date: Fri, 22 Dec 2023 15:11:54 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v17]
In-Reply-To: <iUHMng1JW8bOrtiYyc5SkJdRWC6iCMTfXuG0spm1sZA=.27cdf176-d776-4ec4-9f3b-0396e6f03ff2@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <0yHNMSapOJmfRyGfe_DeqnFIl6yheCjtBKMKKNfDVK0=.78284283-237e-4b14-bb7d-bddf11026a7e@github.com>
 <7iNfYPMzS9YgYNcvPErUBjT-nuaQxNeEccXtmUCnF0A=.b89af814-f95e-49ae-bb8a-5283f5d4491b@github.com>
 <noeDADduWdGZmIP5VqlTIYpZOYnxqkUZy8pXD2PWlSg=.3dc15610-983e-461f-972f-8a61a5cd1031@github.com>
 <wK-DgnIz6FUS8mnmyM2rSEnyaI1wToAZLzfD3MugVfw=.c080f943-ece7-4a23-b29b-54c6936c4f8d@github.com>
 <iUHMng1JW8bOrtiYyc5SkJdRWC6iCMTfXuG0spm1sZA=.27cdf176-d776-4ec4-9f3b-0396e6f03ff2@github.com>
Message-ID: <jJX3usPijJElNxNS05gFZ6pq7A45fQLiVqZP7Jqk0IE=.e48a30f5-a553-4097-835c-bef115c26050@github.com>

On Fri, 22 Dec 2023 14:37:26 GMT, Vladimir Sitnikov <vsitnikov at openjdk.org> wrote:

>> I think there is a misundertanding. This PR is not intendend to reduce the *amount* of allocated heap, it is about sparing time by not creating *temporary  copies*. The latter should be rather easy to check: Invoke `transferTo(out)` two times in a row and compare the *identity* of the two byte arrays passed to `out.write()`. If they stay the same, then apparently no *temporary copy* was created. Two achieve this, the BIS must be wrapper around an extendable input stream (like `FileInputStream`) so between calls the stream could get extended (e. g. by writing into the file).
>
> Markus, could you please double-check? A temporary allocation *is* an allocation, and it is the point of the change to avoid allocation and copying the temp data when the output stream is known to behave well. I am sure the allocation "before the change" would be non-trivial (more than several KiB), and after the change the allocation within .transferTo would be minimal (few bytes) assuming the output stream has already allocated its buffer

IMHO the trigger for this PR was sparing *time*, not necessarily sparing *bytes* (the default buffer size is just 8K); the latter certainly is a nice and beneficial side effect. But I may be wrong here, then the original contributor should chime in now and clarify.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1435146173

From eirbjo at openjdk.org  Fri Dec 22 16:11:53 2023
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 22 Dec 2023 16:11:53 GMT
Subject: Integrated: 8321802: (zipfs) Add validation of incorrect LOC signature
 in ZipFileSystem
In-Reply-To: <9OyZCEKEcOKOhnzSo8Ls4EfxijWzTVhp1H_SBaisYY8=.b82a211b-b98a-451d-8ce2-47b53314c492@github.com>
References: <9OyZCEKEcOKOhnzSo8Ls4EfxijWzTVhp1H_SBaisYY8=.b82a211b-b98a-451d-8ce2-47b53314c492@github.com>
Message-ID: <xS-i8voq0Qv0CN4ZWUd-kv5DRZ4MYUARq9mo3cduGNU=.3673235e-916a-4043-b014-1adb03b7d0a0@github.com>

On Mon, 11 Dec 2023 15:38:28 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which adds validation of incorrect LOC signatures in `ZipFileSystem`.
> 
> `ZipFile` already rejects the case where the  offset pointed to from the CEN header does not start with the expected LOC signature. It makes sense to add this check to `ZipFileSystem` as well.

This pull request has now been integrated.

Changeset: 93fedc12
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/93fedc12db95d1e61c17537652cac3d4e27ddf2c
Stats:     15 lines in 2 files changed: 13 ins; 0 del; 2 mod

8321802: (zipfs) Add validation of incorrect LOC signature in ZipFileSystem

Reviewed-by: alanb, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/17059

From ccheung at openjdk.org  Fri Dec 22 18:33:59 2023
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 22 Dec 2023 18:33:59 GMT
Subject: RFR: 8322322: Support archived full module graph when
 -Xbootclasspath/a is used [v2]
In-Reply-To: <3kfpHpIrCoXI2e1E8Ht-ZrxBjeRdgp0Qisfk8UvYCMw=.6b7fc4e2-9031-42e3-8811-2bbb0dfd329d@github.com>
References: <3kfpHpIrCoXI2e1E8Ht-ZrxBjeRdgp0Qisfk8UvYCMw=.6b7fc4e2-9031-42e3-8811-2bbb0dfd329d@github.com>
Message-ID: <2BOx3oXzgpyp3YbJGv3OsC76C4jv9MflhJPjJCCltys=.92e4bdc7-ab76-4896-8e85-3a7c78d94183@github.com>

> Please review this change for enabling full module graph even when -Xbootclasspath/a is specified. The validation of -Xbootclasspath/a is already being done in `FileMapInfo::validate_boot_class_paths()`. The full module graph will be disabled if there's a mismatch in -Xbootclasspath/a between dump time and runtime.
> 
> The changes in ClassLoaders.java is for setting up the append class path for the boot loader retrieved from the CDS archive. It is required because some existing tests are using the `getResourceAsStream()` api. Those tests would fail without the change.
> 
> Passed tiers 1 - 4 testing.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  comments from Alan and Ioi

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17178/files
  - new: https://git.openjdk.org/jdk/pull/17178/files/b177c6c0..d06b98ff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17178&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17178&range=00-01

  Stats: 22 lines in 3 files changed: 18 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17178.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17178/head:pull/17178

PR: https://git.openjdk.org/jdk/pull/17178

From ccheung at openjdk.org  Fri Dec 22 18:37:49 2023
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 22 Dec 2023 18:37:49 GMT
Subject: RFR: 8322322: Support archived full module graph when
 -Xbootclasspath/a is used [v2]
In-Reply-To: <cAEuPqPXJyWPzaPb778D5zKagfiqn-BQZ8hn5qgOgWQ=.619a61e1-ac71-4fbe-ace6-8ee221865ab5@github.com>
References: <3kfpHpIrCoXI2e1E8Ht-ZrxBjeRdgp0Qisfk8UvYCMw=.6b7fc4e2-9031-42e3-8811-2bbb0dfd329d@github.com>
 <cAEuPqPXJyWPzaPb778D5zKagfiqn-BQZ8hn5qgOgWQ=.619a61e1-ac71-4fbe-ace6-8ee221865ab5@github.com>
Message-ID: <uFjZja22nFzs-r9l7KyTc27rFe2y2DY3jZbY4nvjm1A=.8b75708a-6fdc-4f06-8ba3-8d58510d2569@github.com>

On Fri, 22 Dec 2023 08:40:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comments from Alan and Ioi
>
> src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java line 71:
> 
>> 69:         URLClassPath bootAppendUcp = (append != null && !append.isEmpty())
>> 70:                 ? new URLClassPath(append, true)
>> 71:                 : null;
> 
> Would you mind renaming this to bootUcp or bcp? The reason is that this is the boot loader's class path, not the append path. The system property has "append" in the name as it's communicating the value of -Xbootclasspath/a to the library code, this came about when -Xbootclasspath and -Xbootclasspath/p were removed.

A full bcp would contain the path to the module image as the first path. This "append" property only contains the path specified in -Xbootclasspath/a. That's why I had bootAppendUcp as the variable name.
I've changed it to `bootUcp` per your suggestion.

> src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java line 76:
> 
>> 74:             BOOT_LOADER = (BootClassLoader) archivedClassLoaders.bootLoader();
>> 75:             setArchivedServicesCatalog(BOOT_LOADER);
>> 76:             BOOT_LOADER.setClassPath(bootAppendUcp);
> 
> It might be clearer to set this before calling setArchivedServicesCatalog.

Fixed. Also removed the commented assert statement.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17178#discussion_r1435274444
PR Review Comment: https://git.openjdk.org/jdk/pull/17178#discussion_r1435274493

From naoto at openjdk.org  Fri Dec 22 19:05:05 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 22 Dec 2023 19:05:05 GMT
Subject: RFR: 8322647: Short name for the `Europe/Lisbon` time zone is
 incorrect
Message-ID: <cBXYY9xbMBf9qIWtQ5bg-JrtQRO0XBzPNj7NHrUKbS8=.80cda0a4-4008-4b48-b3f5-2d736ac60a9c@github.com>

This is a regression caused by the fix to [JDK-8317979](https://bugs.openjdk.org/browse/JDK-8317979), where the parsing of TZDB files was incorrect. With this fix, `TimeZoneNames_en.java` which is generated during the build time has the following diffs from the previous (incorrect) one:

--- master/build/macosx-aarch64/support/gensrc/java.base/sun/util/resources/cldr/TimeZoneNames_en.java	2023-12-18 10:28:57
+++ tz/build/macosx-aarch64/support/gensrc/java.base/sun/util/resources/cldr/TimeZoneNames_en.java	2023-12-22 10:09:13
@@ -304,11 +304,11 @@
             };
         final String[] Azores = new String[] {
                "Azores Standard Time",
-               "HMT",
+               "",
                "Azores Summer Time",
-               "HMT",
+               "",
                "Azores Time",
-               "HMT",
+               "",
             };
         final String[] Bhutan = new String[] {
                "Bhutan Time",
@@ -968,11 +968,11 @@
             };
         final String[] Africa_Central = new String[] {
                "Central Africa Time",
-               "SAST",
-               "",
-               "SAST",
+               "CAT",
                "",
-               "SAST",
+               "CAT",
+               "",
+               "CAT",
             };
         final String[] Africa_Eastern = new String[] {
                "East Africa Time",
@@ -1016,11 +1016,11 @@
             };
         final String[] Europe_Western = new String[] {
                "Western European Standard Time",
-               "FMT",
-               "Western European Summer Time",
-               "FMT",
+               "WET",
+               "Western European Summer Time",
+               "WEST",
                "Western European Time",
-               "FMT",
+               "WET",
             };
         final String[] Mexico_Pacific = new String[] {
                "Mexican Pacific Standard Time",
@@ -1152,11 +1152,11 @@
             };
         final String[] Australia_Western = new String[] {
                "Australian Western Standard Time",
-               "",
+               "AWST",
                "Australian Western Daylight Time",
-               "",
+               "AWDT",
                "Western Australia Time",
-               "",
+               "AWT",
             };
         final String[] Greenland_Eastern = new String[] {
                "East Greenland Standard Time",

Previously, they all had wrong short names due to incorrect parsing.

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/17187/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17187&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322647
  Stats: 94 lines in 3 files changed: 72 ins; 2 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/17187.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17187/head:pull/17187

PR: https://git.openjdk.org/jdk/pull/17187

From joehw at openjdk.org  Fri Dec 22 20:21:48 2023
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 22 Dec 2023 20:21:48 GMT
Subject: RFR: 8322647: Short name for the `Europe/Lisbon` time zone is
 incorrect
In-Reply-To: <cBXYY9xbMBf9qIWtQ5bg-JrtQRO0XBzPNj7NHrUKbS8=.80cda0a4-4008-4b48-b3f5-2d736ac60a9c@github.com>
References: <cBXYY9xbMBf9qIWtQ5bg-JrtQRO0XBzPNj7NHrUKbS8=.80cda0a4-4008-4b48-b3f5-2d736ac60a9c@github.com>
Message-ID: <rDHsAtW1dC8upvjlnb0io4sorYAJY4Qp9IwQYvZNjm4=.2c538f1b-a201-4680-8a10-3c33e8b51331@github.com>

On Fri, 22 Dec 2023 18:59:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a regression caused by the fix to [JDK-8317979](https://bugs.openjdk.org/browse/JDK-8317979), where the parsing of TZDB files was incorrect. With this fix, `TimeZoneNames_en.java` which is generated during the build time has the following diffs from the previous (incorrect) one:
> 
> --- master/build/macosx-aarch64/support/gensrc/java.base/sun/util/resources/cldr/TimeZoneNames_en.java	2023-12-18 10:28:57
> +++ tz/build/macosx-aarch64/support/gensrc/java.base/sun/util/resources/cldr/TimeZoneNames_en.java	2023-12-22 10:09:13
> @@ -304,11 +304,11 @@
>              };
>          final String[] Azores = new String[] {
>                 "Azores Standard Time",
> -               "HMT",
> +               "",
>                 "Azores Summer Time",
> -               "HMT",
> +               "",
>                 "Azores Time",
> -               "HMT",
> +               "",
>              };
>          final String[] Bhutan = new String[] {
>                 "Bhutan Time",
> @@ -968,11 +968,11 @@
>              };
>          final String[] Africa_Central = new String[] {
>                 "Central Africa Time",
> -               "SAST",
> -               "",
> -               "SAST",
> +               "CAT",
>                 "",
> -               "SAST",
> +               "CAT",
> +               "",
> +               "CAT",
>              };
>          final String[] Africa_Eastern = new String[] {
>                 "East Africa Time",
> @@ -1016,11 +1016,11 @@
>              };
>          final String[] Europe_Western = new String[] {
>                 "Western European Standard Time",
> -               "FMT",
> -               "Western European Summer Time",
> -               "FMT",
> +               "WET",
> +               "Western European Summer Time",
> +               "WEST",
>                 "Western European Time",
> -               "FMT",
> +               "WET",
>              };
>          final String[] Mexico_Pacific = new String[] {
>                 "Mexican Pacific Standard Time",
> @@ -1152,11 +1152,11 @@
>              };
>          final String[] Australia_Western = new String[] {
>                 "Australian Western Standard Time",
> -               "",
> +               "AWST",
>                 "Australian Western Daylight Time",
> -               "",
> +               "AWDT",
>                 "Western Australia Time",
> -               "",
> +               "AWT",
>              };
>          final String[] Greenland_Eastern = new String[] {
>                 "East Greenland Standard Time",
> 
> Previously, they all had wrong short names due to incorrect parsi...

Marked as reviewed by joehw (Reviewer).

make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java line 2:

> 1: /*
> 2:  * Copyright (c) 2012, 2024, Oracle and/or its affiliates. All rights reserved.

2024 already? ;-)

-------------

PR Review: https://git.openjdk.org/jdk/pull/17187#pullrequestreview-1795051559
PR Review Comment: https://git.openjdk.org/jdk/pull/17187#discussion_r1435330060

From iris at openjdk.org  Fri Dec 22 20:43:44 2023
From: iris at openjdk.org (Iris Clark)
Date: Fri, 22 Dec 2023 20:43:44 GMT
Subject: RFR: 8322647: Short name for the `Europe/Lisbon` time zone is
 incorrect
In-Reply-To: <cBXYY9xbMBf9qIWtQ5bg-JrtQRO0XBzPNj7NHrUKbS8=.80cda0a4-4008-4b48-b3f5-2d736ac60a9c@github.com>
References: <cBXYY9xbMBf9qIWtQ5bg-JrtQRO0XBzPNj7NHrUKbS8=.80cda0a4-4008-4b48-b3f5-2d736ac60a9c@github.com>
Message-ID: <TsheEDcHf-fmMNaBZ_-bLt3bNK1ikRShN0_nG4QbQYA=.cd24c607-3cb5-4b69-b1ec-91e277b7cf40@github.com>

On Fri, 22 Dec 2023 18:59:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a regression caused by the fix to [JDK-8317979](https://bugs.openjdk.org/browse/JDK-8317979), where the parsing of TZDB files was incorrect. With this fix, `TimeZoneNames_en.java` which is generated during the build time has the following diffs from the previous (incorrect) one:
> 
> --- master/build/macosx-aarch64/support/gensrc/java.base/sun/util/resources/cldr/TimeZoneNames_en.java	2023-12-18 10:28:57
> +++ tz/build/macosx-aarch64/support/gensrc/java.base/sun/util/resources/cldr/TimeZoneNames_en.java	2023-12-22 10:09:13
> @@ -304,11 +304,11 @@
>              };
>          final String[] Azores = new String[] {
>                 "Azores Standard Time",
> -               "HMT",
> +               "",
>                 "Azores Summer Time",
> -               "HMT",
> +               "",
>                 "Azores Time",
> -               "HMT",
> +               "",
>              };
>          final String[] Bhutan = new String[] {
>                 "Bhutan Time",
> @@ -968,11 +968,11 @@
>              };
>          final String[] Africa_Central = new String[] {
>                 "Central Africa Time",
> -               "SAST",
> -               "",
> -               "SAST",
> +               "CAT",
>                 "",
> -               "SAST",
> +               "CAT",
> +               "",
> +               "CAT",
>              };
>          final String[] Africa_Eastern = new String[] {
>                 "East Africa Time",
> @@ -1016,11 +1016,11 @@
>              };
>          final String[] Europe_Western = new String[] {
>                 "Western European Standard Time",
> -               "FMT",
> -               "Western European Summer Time",
> -               "FMT",
> +               "WET",
> +               "Western European Summer Time",
> +               "WEST",
>                 "Western European Time",
> -               "FMT",
> +               "WET",
>              };
>          final String[] Mexico_Pacific = new String[] {
>                 "Mexican Pacific Standard Time",
> @@ -1152,11 +1152,11 @@
>              };
>          final String[] Australia_Western = new String[] {
>                 "Australian Western Standard Time",
> -               "",
> +               "AWST",
>                 "Australian Western Daylight Time",
> -               "",
> +               "AWDT",
>                 "Western Australia Time",
> -               "",
> +               "AWT",
>              };
>          final String[] Greenland_Eastern = new String[] {
>                 "East Greenland Standard Time",
> 
> Previously, they all had wrong short names due to incorrect parsi...

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17187#pullrequestreview-1795097842

From naoto at openjdk.org  Fri Dec 22 21:39:37 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 22 Dec 2023 21:39:37 GMT
Subject: RFR: 8322647: Short name for the `Europe/Lisbon` time zone is
 incorrect
In-Reply-To: <rDHsAtW1dC8upvjlnb0io4sorYAJY4Qp9IwQYvZNjm4=.2c538f1b-a201-4680-8a10-3c33e8b51331@github.com>
References: <cBXYY9xbMBf9qIWtQ5bg-JrtQRO0XBzPNj7NHrUKbS8=.80cda0a4-4008-4b48-b3f5-2d736ac60a9c@github.com>
 <rDHsAtW1dC8upvjlnb0io4sorYAJY4Qp9IwQYvZNjm4=.2c538f1b-a201-4680-8a10-3c33e8b51331@github.com>
Message-ID: <E0fm1LjNwiF2elwb8e7ivMz5jeULiFeDIvwCTO_1FLY=.031fd9c7-342c-4830-ae74-6424c127f063@github.com>

On Fri, 22 Dec 2023 20:19:17 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> This is a regression caused by the fix to [JDK-8317979](https://bugs.openjdk.org/browse/JDK-8317979), where the parsing of TZDB files was incorrect. With this fix, `TimeZoneNames_en.java` which is generated during the build time has the following diffs from the previous (incorrect) one:
>> 
>> --- master/build/macosx-aarch64/support/gensrc/java.base/sun/util/resources/cldr/TimeZoneNames_en.java	2023-12-18 10:28:57
>> +++ tz/build/macosx-aarch64/support/gensrc/java.base/sun/util/resources/cldr/TimeZoneNames_en.java	2023-12-22 10:09:13
>> @@ -304,11 +304,11 @@
>>              };
>>          final String[] Azores = new String[] {
>>                 "Azores Standard Time",
>> -               "HMT",
>> +               "",
>>                 "Azores Summer Time",
>> -               "HMT",
>> +               "",
>>                 "Azores Time",
>> -               "HMT",
>> +               "",
>>              };
>>          final String[] Bhutan = new String[] {
>>                 "Bhutan Time",
>> @@ -968,11 +968,11 @@
>>              };
>>          final String[] Africa_Central = new String[] {
>>                 "Central Africa Time",
>> -               "SAST",
>> -               "",
>> -               "SAST",
>> +               "CAT",
>>                 "",
>> -               "SAST",
>> +               "CAT",
>> +               "",
>> +               "CAT",
>>              };
>>          final String[] Africa_Eastern = new String[] {
>>                 "East Africa Time",
>> @@ -1016,11 +1016,11 @@
>>              };
>>          final String[] Europe_Western = new String[] {
>>                 "Western European Standard Time",
>> -               "FMT",
>> -               "Western European Summer Time",
>> -               "FMT",
>> +               "WET",
>> +               "Western European Summer Time",
>> +               "WEST",
>>                 "Western European Time",
>> -               "FMT",
>> +               "WET",
>>              };
>>          final String[] Mexico_Pacific = new String[] {
>>                 "Mexican Pacific Standard Time",
>> @@ -1152,11 +1152,11 @@
>>              };
>>          final String[] Australia_Western = new String[] {
>>                 "Australian Western Standard Time",
>> -               "",
>> +               "AWST",
>>                 "Australian Western Daylight Time",
>> -               "",
>> +               "AWDT",
>>                 "Western Australia Time",
>> -               "",
>> +               "AWT",
>>              };
>>          final String[] Greenland_Eastern =...
>
> make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2012, 2024, Oracle and/or its affiliates. All rights reserved.
> 
> 2024 already? ;-)

Thanks, Joe. Not planning to integrate it this year, so.
There's a Japanese proverb, saying demons would laugh if speaking of the next year, though ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17187#discussion_r1435356191

From joehw at openjdk.org  Fri Dec 22 22:30:47 2023
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 22 Dec 2023 22:30:47 GMT
Subject: RFR: 8322647: Short name for the `Europe/Lisbon` time zone is
 incorrect
In-Reply-To: <E0fm1LjNwiF2elwb8e7ivMz5jeULiFeDIvwCTO_1FLY=.031fd9c7-342c-4830-ae74-6424c127f063@github.com>
References: <cBXYY9xbMBf9qIWtQ5bg-JrtQRO0XBzPNj7NHrUKbS8=.80cda0a4-4008-4b48-b3f5-2d736ac60a9c@github.com>
 <rDHsAtW1dC8upvjlnb0io4sorYAJY4Qp9IwQYvZNjm4=.2c538f1b-a201-4680-8a10-3c33e8b51331@github.com>
 <E0fm1LjNwiF2elwb8e7ivMz5jeULiFeDIvwCTO_1FLY=.031fd9c7-342c-4830-ae74-6424c127f063@github.com>
Message-ID: <xR3Nn0rZrD_08ltuWewQGCoUB7OTNYs0gQUTCJZ9Kq0=.1e011a54-6fa9-4124-abf8-7d9aa235744a@github.com>

On Fri, 22 Dec 2023 21:36:32 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java line 2:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2012, 2024, Oracle and/or its affiliates. All rights reserved.
>> 
>> 2024 already? ;-)
>
> Thanks, Joe. Not planning to integrate it this year, so.
> There's a Japanese proverb, saying demons would laugh if speaking of the next year, though ?

I know what you mean. Ugh, I mean I know nothing about next year least 
????????????

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17187#discussion_r1435370022

From emcmanus at openjdk.org  Fri Dec 22 22:55:09 2023
From: emcmanus at openjdk.org (Eamonn McManus)
Date: Fri, 22 Dec 2023 22:55:09 GMT
Subject: RFR: 8068958: Timestamp.from(Instant) should throw when conversion
 is not possible [v2]
In-Reply-To: <LhDps2Gcl43rCkFQI-Msuk5Ysb0ndEr4JqA_Ba2j0E8=.79f63a5d-540b-4543-87a0-4017aabf91ef@github.com>
References: <LhDps2Gcl43rCkFQI-Msuk5Ysb0ndEr4JqA_Ba2j0E8=.79f63a5d-540b-4543-87a0-4017aabf91ef@github.com>
Message-ID: <HnPtMXnhAZUFJy45VIuLW5t7s7FREtK4M6s2PUF2_mE=.d732aa4f-6303-4a14-afb3-298d7f52141f@github.com>

> Multiplying with `*` never produces `ArithmeticException`, so the catch in the existing code is never triggered. `Math.multiplyExact` does produce `ArithmeticException` if the multiplication overflows. So we can use that, and rethrow `IllegalArgumentException` as the specification says.
> 
> There is a small compatibility risk, in that code may have been relying on the previous silent overflow, and will now get an exception. But an exception is surely better than the nonsense results that overflow produces.
> 
> Thanks to Kurt Kluever for the test cases.

Eamonn McManus has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments about the new test.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17181/files
  - new: https://git.openjdk.org/jdk/pull/17181/files/32b3de53..8f2e929c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17181&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17181&range=00-01

  Stats: 20 lines in 1 file changed: 4 ins; 8 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/17181.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17181/head:pull/17181

PR: https://git.openjdk.org/jdk/pull/17181

From emcmanus at openjdk.org  Fri Dec 22 22:55:10 2023
From: emcmanus at openjdk.org (Eamonn McManus)
Date: Fri, 22 Dec 2023 22:55:10 GMT
Subject: RFR: 8068958: Timestamp.from(Instant) should throw when conversion
 is not possible [v2]
In-Reply-To: <0y4o6MMe_haSzAK3Cbq9p7PTMm2qqV3xvcfWuGMO0a8=.683fb50b-02a6-464f-9ae6-5cd7ecfdc98b@github.com>
References: <LhDps2Gcl43rCkFQI-Msuk5Ysb0ndEr4JqA_Ba2j0E8=.79f63a5d-540b-4543-87a0-4017aabf91ef@github.com>
 <0y4o6MMe_haSzAK3Cbq9p7PTMm2qqV3xvcfWuGMO0a8=.683fb50b-02a6-464f-9ae6-5cd7ecfdc98b@github.com>
Message-ID: <dF6j19T-14nKpubP4XRNIh2_NsZWQxALV6x_Vcp1PWg=.39d37375-080a-4bf4-a08d-4bd21bbf2c14@github.com>

On Fri, 22 Dec 2023 09:07:31 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Eamonn McManus has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments about the new test.
>
> test/jdk/java/sql/testng/test/sql/TimestampTests.java line 649:
> 
>> 647:         // The latest Instant that can be converted to a Timestamp.
>> 648:         Instant instant1 = Instant.ofEpochSecond(Long.MAX_VALUE / 1000, 999_999_999);
>> 649:         assertEquals(instant1, Timestamp.from(instant1).toInstant());
> 
> The 1st arg to `assertEquals()` should be the actual value, the 2nd should be the expected result. I guess you expect `instant1` to be the expected result.
> (TestNG and JUnit have opposite conventions...)

Thanks, I hadn't realized that.

> test/jdk/java/sql/testng/test/sql/TimestampTests.java line 658:
> 
>> 656:         } catch (IllegalArgumentException expected) {
>> 657:         }
>> 658: 
> 
> TestNG supports a better way for expected exceptions, as an attribute of the @Test annotation. Maybe it can be used here for the expected failing cases?

I'm not very familiar with TestNG, as you'll have noticed. But I see it has a better way yet, namely `expectThrows`, like JUnit's `assertThrows`. So I've updated the code to use that. Thanks for the hint!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17181#discussion_r1435375742
PR Review Comment: https://git.openjdk.org/jdk/pull/17181#discussion_r1435376042

From rgiulietti at openjdk.org  Fri Dec 22 23:28:47 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 22 Dec 2023 23:28:47 GMT
Subject: RFR: 8068958: Timestamp.from(Instant) should throw when conversion
 is not possible [v2]
In-Reply-To: <HnPtMXnhAZUFJy45VIuLW5t7s7FREtK4M6s2PUF2_mE=.d732aa4f-6303-4a14-afb3-298d7f52141f@github.com>
References: <LhDps2Gcl43rCkFQI-Msuk5Ysb0ndEr4JqA_Ba2j0E8=.79f63a5d-540b-4543-87a0-4017aabf91ef@github.com>
 <HnPtMXnhAZUFJy45VIuLW5t7s7FREtK4M6s2PUF2_mE=.d732aa4f-6303-4a14-afb3-298d7f52141f@github.com>
Message-ID: <Wvfe0hlobjjHQDsZlPW-jYRupHB3pxEsLd6HP2t-Fng=.4c0e80c8-bc9d-47d2-9bd8-0091bea08710@github.com>

On Fri, 22 Dec 2023 22:55:09 GMT, Eamonn McManus <emcmanus at openjdk.org> wrote:

>> Multiplying with `*` never produces `ArithmeticException`, so the catch in the existing code is never triggered. `Math.multiplyExact` does produce `ArithmeticException` if the multiplication overflows. So we can use that, and rethrow `IllegalArgumentException` as the specification says.
>> 
>> There is a small compatibility risk, in that code may have been relying on the previous silent overflow, and will now get an exception. But an exception is surely better than the nonsense results that overflow produces.
>> 
>> Thanks to Kurt Kluever for the test cases.
>
> Eamonn McManus has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments about the new test.

Don't forget to update the copyright years in both files, please ;-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17181#issuecomment-1868127480

From alanb at openjdk.org  Sat Dec 23 08:11:46 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 23 Dec 2023 08:11:46 GMT
Subject: RFR: 8322322: Support archived full module graph when
 -Xbootclasspath/a is used [v2]
In-Reply-To: <2BOx3oXzgpyp3YbJGv3OsC76C4jv9MflhJPjJCCltys=.92e4bdc7-ab76-4896-8e85-3a7c78d94183@github.com>
References: <3kfpHpIrCoXI2e1E8Ht-ZrxBjeRdgp0Qisfk8UvYCMw=.6b7fc4e2-9031-42e3-8811-2bbb0dfd329d@github.com>
 <2BOx3oXzgpyp3YbJGv3OsC76C4jv9MflhJPjJCCltys=.92e4bdc7-ab76-4896-8e85-3a7c78d94183@github.com>
Message-ID: <X6As3w0bawd3coW-UchQXR4p13qb7Da3HzcOszD2s30=.d588a922-9d4a-49f6-a3f0-8482d9ec7804@github.com>

On Fri, 22 Dec 2023 18:33:59 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Please review this change for enabling full module graph even when -Xbootclasspath/a is specified. The validation of -Xbootclasspath/a is already being done in `FileMapInfo::validate_boot_class_paths()`. The full module graph will be disabled if there's a mismatch in -Xbootclasspath/a between dump time and runtime.
>> 
>> The changes in ClassLoaders.java is for setting up the append class path for the boot loader retrieved from the CDS archive. It is required because some existing tests are using the `getResourceAsStream()` api. Those tests would fail without the change.
>> 
>> Passed tiers 1 - 4 testing.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comments from Alan and Ioi

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17178#pullrequestreview-1795413891

From alanb at openjdk.org  Sat Dec 23 08:11:47 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 23 Dec 2023 08:11:47 GMT
Subject: RFR: 8322322: Support archived full module graph when
 -Xbootclasspath/a is used [v2]
In-Reply-To: <uFjZja22nFzs-r9l7KyTc27rFe2y2DY3jZbY4nvjm1A=.8b75708a-6fdc-4f06-8ba3-8d58510d2569@github.com>
References: <3kfpHpIrCoXI2e1E8Ht-ZrxBjeRdgp0Qisfk8UvYCMw=.6b7fc4e2-9031-42e3-8811-2bbb0dfd329d@github.com>
 <cAEuPqPXJyWPzaPb778D5zKagfiqn-BQZ8hn5qgOgWQ=.619a61e1-ac71-4fbe-ace6-8ee221865ab5@github.com>
 <uFjZja22nFzs-r9l7KyTc27rFe2y2DY3jZbY4nvjm1A=.8b75708a-6fdc-4f06-8ba3-8d58510d2569@github.com>
Message-ID: <wm_MFSAbnP07lPp-Ob6zftMGu3e5yOEi6F2_DRvPc6g=.cd1398ac-f06a-4375-8ed4-edbd33f3c19c@github.com>

On Fri, 22 Dec 2023 18:34:30 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> A full bcp would contain the path to the module image as the first path. This "append" property only contains the path specified in -Xbootclasspath/a. That's why I had bootAppendUcp as the variable name. I've changed it to `bootUcp` per your suggestion.

There is no boot class path by default since JDK 9. If the boot loader is asked to load a class in a package that doesn't map to one of the modules defined to the boot loader then there is no class path to search. You've renamed it to bootUcp so I think we are good now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17178#discussion_r1435525651

From liach at openjdk.org  Sat Dec 23 12:43:48 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 23 Dec 2023 12:43:48 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v5]
In-Reply-To: <b6zMiAP6xVsRojzfRXDi_lgOcnEgsd0tYMG4TCBGWx0=.d63ac3fc-21ea-4ac3-a10a-3b6a9310e44a@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
 <b6zMiAP6xVsRojzfRXDi_lgOcnEgsd0tYMG4TCBGWx0=.d63ac3fc-21ea-4ac3-a10a-3b6a9310e44a@github.com>
Message-ID: <d3YUbM6x8g1gbTCHJ_JwY5JzuekKows3Bw51q6NUE7g=.bbe242e8-af75-45ee-a51d-2cfc109a3f63@github.com>

On Thu, 21 Dec 2023 13:32:12 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes.
>> 
>> This patch converts it to use Classfile API.
>> 
>> It is continuation of https://github.com/openjdk/jdk/pull/10991
>> 
>> Any comments and suggestions are welcome.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor StackCounter fix

src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java line 49:

> 47:                 dcb,
> 48:                 dcb.methodInfo.methodName(),
> 49:                 dcb.methodInfo.methodType(),

Can you enlighten me on why this actually leads to a performance improvement? Don't we already generate the methods with MethodTypeDesc symbols in ProxyGenerator so that they should be cached?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17121#discussion_r1435592097

From emcmanus at openjdk.org  Sat Dec 23 15:22:58 2023
From: emcmanus at openjdk.org (Eamonn McManus)
Date: Sat, 23 Dec 2023 15:22:58 GMT
Subject: RFR: 8068958: Timestamp.from(Instant) should throw when conversion
 is not possible [v3]
In-Reply-To: <LhDps2Gcl43rCkFQI-Msuk5Ysb0ndEr4JqA_Ba2j0E8=.79f63a5d-540b-4543-87a0-4017aabf91ef@github.com>
References: <LhDps2Gcl43rCkFQI-Msuk5Ysb0ndEr4JqA_Ba2j0E8=.79f63a5d-540b-4543-87a0-4017aabf91ef@github.com>
Message-ID: <B2SKPir7Z7bahB3cTLyn4iZh_tID82xgSkMvkJQORX0=.60ab03ac-96b8-4a81-a584-61d9b6b0a0d2@github.com>

> Multiplying with `*` never produces `ArithmeticException`, so the catch in the existing code is never triggered. `Math.multiplyExact` does produce `ArithmeticException` if the multiplication overflows. So we can use that, and rethrow `IllegalArgumentException` as the specification says.
> 
> There is a small compatibility risk, in that code may have been relying on the previous silent overflow, and will now get an exception. But an exception is surely better than the nonsense results that overflow produces.
> 
> Thanks to Kurt Kluever for the test cases.

Eamonn McManus has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17181/files
  - new: https://git.openjdk.org/jdk/pull/17181/files/8f2e929c..9f3cbf12

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17181&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17181&range=01-02

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17181.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17181/head:pull/17181

PR: https://git.openjdk.org/jdk/pull/17181

From emcmanus at openjdk.org  Sat Dec 23 15:23:00 2023
From: emcmanus at openjdk.org (Eamonn McManus)
Date: Sat, 23 Dec 2023 15:23:00 GMT
Subject: RFR: 8068958: Timestamp.from(Instant) should throw when conversion
 is not possible [v2]
In-Reply-To: <Wvfe0hlobjjHQDsZlPW-jYRupHB3pxEsLd6HP2t-Fng=.4c0e80c8-bc9d-47d2-9bd8-0091bea08710@github.com>
References: <LhDps2Gcl43rCkFQI-Msuk5Ysb0ndEr4JqA_Ba2j0E8=.79f63a5d-540b-4543-87a0-4017aabf91ef@github.com>
 <HnPtMXnhAZUFJy45VIuLW5t7s7FREtK4M6s2PUF2_mE=.d732aa4f-6303-4a14-afb3-298d7f52141f@github.com>
 <Wvfe0hlobjjHQDsZlPW-jYRupHB3pxEsLd6HP2t-Fng=.4c0e80c8-bc9d-47d2-9bd8-0091bea08710@github.com>
Message-ID: <b0P6U1nOgV6IvxHxuD0J2tb6IZE9-yw_IFclPfb2jP0=.13d8df11-c777-43b3-aa81-c49865c9af48@github.com>

On Fri, 22 Dec 2023 23:25:35 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Don't forget to update the copyright years in both files, please ;-)

Done. (I'm a bit surprised there isn't some sort of automated check if this is a requirement.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17181#issuecomment-1868314411

From duke at openjdk.org  Sat Dec 23 15:27:47 2023
From: duke at openjdk.org (ExE Boss)
Date: Sat, 23 Dec 2023 15:27:47 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v5]
In-Reply-To: <d3YUbM6x8g1gbTCHJ_JwY5JzuekKows3Bw51q6NUE7g=.bbe242e8-af75-45ee-a51d-2cfc109a3f63@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
 <b6zMiAP6xVsRojzfRXDi_lgOcnEgsd0tYMG4TCBGWx0=.d63ac3fc-21ea-4ac3-a10a-3b6a9310e44a@github.com>
 <d3YUbM6x8g1gbTCHJ_JwY5JzuekKows3Bw51q6NUE7g=.bbe242e8-af75-45ee-a51d-2cfc109a3f63@github.com>
Message-ID: <Gfb59xa6iI6P37dIEdn_HPfm92Ly_et4Kdm_2-zJuhw=.9fc6dd45-8fec-4799-bc69-97bb1e5e5a07@github.com>

On Sat, 23 Dec 2023 12:40:33 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor StackCounter fix
>
> src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java line 49:
> 
>> 47:                 dcb,
>> 48:                 dcb.methodInfo.methodName(),
>> 49:                 dcb.methodInfo.methodType(),
> 
> Can you enlighten me on why this actually leads to a performance improvement? Don't we already generate the methods with MethodTypeDesc symbols in ProxyGenerator so that they should be cached?

This?code is?part of?the?**ClassFile?API**?s internals, and?so it?doesn?t have?access to?`ProxyGenerator`?s cached?`MethodTypeDesc`s, only?the?underlying `Utf8Entry`, so?it?d?need to?be?parsed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17121#discussion_r1435630982

From duke at openjdk.org  Sat Dec 23 15:27:49 2023
From: duke at openjdk.org (ExE Boss)
Date: Sat, 23 Dec 2023 15:27:49 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v4]
In-Reply-To: <lxdJSV0sQvWWdmZVnRy22DwRc94p7E9f6ZSqWkkk4uc=.0f94785f-b082-4f98-90f8-1cf96cbf38ce@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
 <lxdJSV0sQvWWdmZVnRy22DwRc94p7E9f6ZSqWkkk4uc=.0f94785f-b082-4f98-90f8-1cf96cbf38ce@github.com>
Message-ID: <DvifBeznTZHiQbKMSgLSLRAsA-GZwWd5Sj8dEX3LoWY=.0de3dace-748d-465e-8bfb-0205edbb47c3@github.com>

On Thu, 21 Dec 2023 12:49:02 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes.
>> 
>> This patch converts it to use Classfile API.
>> 
>> It is continuation of https://github.com/openjdk/jdk/pull/10991
>> 
>> Any comments and suggestions are welcome.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   applied the recommended changes

src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java line 62:

> 60:     private final Utf8Entry methodDesc;
> 61:     private final SplitConstantPool cp;
> 62:     private final ArrayDeque<Target> targets;

This?field can?probably be?typed as?a?`Deque`:
Suggestion:

    private final Deque<Target> targets;


Or?as a?`Queue`:
Suggestion:

    private final Queue<Target> targets;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17121#discussion_r1435349464

From zjx001202 at gmail.com  Sat Dec 23 18:18:45 2023
From: zjx001202 at gmail.com (Glavo)
Date: Sun, 24 Dec 2023 02:18:45 +0800
Subject: The default java.library.path on Linux does not include the library
 paths in the mulitarch-spec
Message-ID: <CAJL5A3kbtMhiet7DOJzUay27XsX=zdmdewo0EVEw4Vi3q=xt=A@mail.gmail.com>

Hi,

There are already many Linux distributions that are following the
multiarch-spec[1] and adding the following paths to the default library
path list:

   - /usr/local/lib/<triplet>
   - /lib/<triplet>
   - /usr/lib/<triplet>

But OpenJDK doesn't add these paths to the java.library.path by default, so
System.loadLibrary(String) has annoying behavior differences with ld.
Many libraries already installed on the system cannot be found by
System.loadLibrary(String).

I wish OpenJDK would parse the /etc/ld.so.conf to get the full library path
list so it would be consistent with the behavior of ld.
Can anyone consider this suggestion?

Glavo

[1]: https://wiki.ubuntu.com/MultiarchSpec
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20231224/627f201e/attachment.htm>

From rgiulietti at openjdk.org  Sat Dec 23 20:28:47 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Sat, 23 Dec 2023 20:28:47 GMT
Subject: RFR: 8068958: Timestamp.from(Instant) should throw when conversion
 is not possible [v3]
In-Reply-To: <B2SKPir7Z7bahB3cTLyn4iZh_tID82xgSkMvkJQORX0=.60ab03ac-96b8-4a81-a584-61d9b6b0a0d2@github.com>
References: <LhDps2Gcl43rCkFQI-Msuk5Ysb0ndEr4JqA_Ba2j0E8=.79f63a5d-540b-4543-87a0-4017aabf91ef@github.com>
 <B2SKPir7Z7bahB3cTLyn4iZh_tID82xgSkMvkJQORX0=.60ab03ac-96b8-4a81-a584-61d9b6b0a0d2@github.com>
Message-ID: <usP2PwyD23HidR-KPSbMQmpMy68maQvxTe4FPH8kSq4=.4df1cb71-7256-4459-a453-913401b75f17@github.com>

On Sat, 23 Dec 2023 15:22:58 GMT, Eamonn McManus <emcmanus at openjdk.org> wrote:

>> Multiplying with `*` never produces `ArithmeticException`, so the catch in the existing code is never triggered. `Math.multiplyExact` does produce `ArithmeticException` if the multiplication overflows. So we can use that, and rethrow `IllegalArgumentException` as the specification says.
>> 
>> There is a small compatibility risk, in that code may have been relying on the previous silent overflow, and will now get an exception. But an exception is surely better than the nonsense results that overflow produces.
>> 
>> Thanks to Kurt Kluever for the test cases.
>
> Eamonn McManus has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year.

Marked as reviewed by rgiulietti (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17181#pullrequestreview-1795472693

From rriggs at openjdk.org  Sat Dec 23 21:22:47 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Sat, 23 Dec 2023 21:22:47 GMT
Subject: RFR: 8068958: Timestamp.from(Instant) should throw when conversion
 is not possible [v3]
In-Reply-To: <B2SKPir7Z7bahB3cTLyn4iZh_tID82xgSkMvkJQORX0=.60ab03ac-96b8-4a81-a584-61d9b6b0a0d2@github.com>
References: <LhDps2Gcl43rCkFQI-Msuk5Ysb0ndEr4JqA_Ba2j0E8=.79f63a5d-540b-4543-87a0-4017aabf91ef@github.com>
 <B2SKPir7Z7bahB3cTLyn4iZh_tID82xgSkMvkJQORX0=.60ab03ac-96b8-4a81-a584-61d9b6b0a0d2@github.com>
Message-ID: <5U_jbsX7zaaJe4FriW2s0CcNQve_pZOO3I-QT4JPcVw=.82bb35a3-100b-4da4-8881-5ea28437cfec@github.com>

On Sat, 23 Dec 2023 15:22:58 GMT, Eamonn McManus <emcmanus at openjdk.org> wrote:

>> Multiplying with `*` never produces `ArithmeticException`, so the catch in the existing code is never triggered. `Math.multiplyExact` does produce `ArithmeticException` if the multiplication overflows. So we can use that, and rethrow `IllegalArgumentException` as the specification says.
>> 
>> There is a small compatibility risk, in that code may have been relying on the previous silent overflow, and will now get an exception. But an exception is surely better than the nonsense results that overflow produces.
>> 
>> Thanks to Kurt Kluever for the test cases.
>
> Eamonn McManus has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year.

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17181#pullrequestreview-1795494200

From emcmanus at openjdk.org  Sat Dec 23 22:55:54 2023
From: emcmanus at openjdk.org (Eamonn McManus)
Date: Sat, 23 Dec 2023 22:55:54 GMT
Subject: Integrated: 8068958: Timestamp.from(Instant) should throw when
 conversion is not possible
In-Reply-To: <LhDps2Gcl43rCkFQI-Msuk5Ysb0ndEr4JqA_Ba2j0E8=.79f63a5d-540b-4543-87a0-4017aabf91ef@github.com>
References: <LhDps2Gcl43rCkFQI-Msuk5Ysb0ndEr4JqA_Ba2j0E8=.79f63a5d-540b-4543-87a0-4017aabf91ef@github.com>
Message-ID: <QFhnE4bPyMttvzwG7ShzGXHFz66jBN67Zo8lyMg-4lE=.a2bd271d-322d-452f-91dd-9c2e740dec8e@github.com>

On Thu, 21 Dec 2023 21:51:10 GMT, Eamonn McManus <emcmanus at openjdk.org> wrote:

> Multiplying with `*` never produces `ArithmeticException`, so the catch in the existing code is never triggered. `Math.multiplyExact` does produce `ArithmeticException` if the multiplication overflows. So we can use that, and rethrow `IllegalArgumentException` as the specification says.
> 
> There is a small compatibility risk, in that code may have been relying on the previous silent overflow, and will now get an exception. But an exception is surely better than the nonsense results that overflow produces.
> 
> Thanks to Kurt Kluever for the test cases.

This pull request has now been integrated.

Changeset: 4fc6b0ff
Author:    Eamonn McManus <emcmanus at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4fc6b0ffa4f771991a5ebd982b5133d2e364fdae
Stats:     28 lines in 2 files changed: 25 ins; 0 del; 3 mod

8068958: Timestamp.from(Instant) should throw when conversion is not possible

Reviewed-by: rgiulietti, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/17181

From liach at openjdk.org  Sun Dec 24 03:17:50 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 24 Dec 2023 03:17:50 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v5]
In-Reply-To: <b6zMiAP6xVsRojzfRXDi_lgOcnEgsd0tYMG4TCBGWx0=.d63ac3fc-21ea-4ac3-a10a-3b6a9310e44a@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
 <b6zMiAP6xVsRojzfRXDi_lgOcnEgsd0tYMG4TCBGWx0=.d63ac3fc-21ea-4ac3-a10a-3b6a9310e44a@github.com>
Message-ID: <6QJXbG4RyTpE8Xnbsr1NNTuAqokhgKbgbERN6t2VJso=.de1c67b9-8755-4b25-9f85-c92455ff12eb@github.com>

On Thu, 21 Dec 2023 13:32:12 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes.
>> 
>> This patch converts it to use Classfile API.
>> 
>> It is continuation of https://github.com/openjdk/jdk/pull/10991
>> 
>> Any comments and suggestions are welcome.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor StackCounter fix

src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 737:

> 735:         private void generateMethod(ClassBuilder clb, ClassEntry className) {
> 736:             var cp = clb.constantPool();
> 737:             var desc = new StringJoiner("", "(", ")" + returnType.descriptorString());

We should just use an MTD here; the MTD will be passed to StackCounter so we don't have to recompute a MTD.

The MT to MTD conversion shouldn't be too costly; the overhead probably comes from Optional, which we have to wait until Valhalla, as proxy generation is unlikely to be hot and compiled by C2.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17121#discussion_r1435756657

From liach at openjdk.org  Sun Dec 24 04:09:51 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 24 Dec 2023 04:09:51 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v5]
In-Reply-To: <Gfb59xa6iI6P37dIEdn_HPfm92Ly_et4Kdm_2-zJuhw=.9fc6dd45-8fec-4799-bc69-97bb1e5e5a07@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
 <b6zMiAP6xVsRojzfRXDi_lgOcnEgsd0tYMG4TCBGWx0=.d63ac3fc-21ea-4ac3-a10a-3b6a9310e44a@github.com>
 <d3YUbM6x8g1gbTCHJ_JwY5JzuekKows3Bw51q6NUE7g=.bbe242e8-af75-45ee-a51d-2cfc109a3f63@github.com>
 <Gfb59xa6iI6P37dIEdn_HPfm92Ly_et4Kdm_2-zJuhw=.9fc6dd45-8fec-4799-bc69-97bb1e5e5a07@github.com>
Message-ID: <E98eLURLO5V9RD5LBvvi9hxgS9v64sojZEarTCawtuk=.1a0e510e-6bdd-4b54-8040-10e2a1712cbc@github.com>

On Sat, 23 Dec 2023 15:24:55 GMT, ExE Boss <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java line 49:
>> 
>>> 47:                 dcb,
>>> 48:                 dcb.methodInfo.methodName(),
>>> 49:                 dcb.methodInfo.methodType(),
>> 
>> Can you enlighten me on why this actually leads to a performance improvement? Don't we already generate the methods with MethodTypeDesc symbols in ProxyGenerator so that they should be cached?
>
> This?code is?part of?the?**ClassFile?API**?s internals, and?so it?doesn?t have?access to?`ProxyGenerator`?s cached?`MethodTypeDesc`s, only?the?underlying `Utf8Entry`, so?it?d?need to?be?parsed.

I see that now Class return type and Class array parameter types are directly converted to Strings instead of MTDs. I think that we should really run ProxyGenerator with JFR to profile and see the results (for instance, old ASM has a stackmap generation penalty due to parsing method descriptors on the fly compared to CF API, despite CF's slower overall performance due to allocations like Optional)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17121#discussion_r1435760771

From liangchenblue at gmail.com  Sun Dec 24 16:20:06 2023
From: liangchenblue at gmail.com (-)
Date: Sun, 24 Dec 2023 10:20:06 -0600
Subject: Should Class.name field be @Stable?
In-Reply-To: <CABe8uE0p2M1+CGOepGJrzeJq7qn0esLi=AFcC4oi09=hRXp58w@mail.gmail.com>
References: <CABe8uE0+5Te8yvZgUrkHn3miY9QF6Z_Cv6=O-+HQ_78SM8C1ww@mail.gmail.com>
 <3e19a48a-940a-4625-909f-f446304b70b5@gmail.com>
 <CABe8uE0p2M1+CGOepGJrzeJq7qn0esLi=AFcC4oi09=hRXp58w@mail.gmail.com>
Message-ID: <CABe8uE1MZcGsfa7bwV9k7H=TJaY=o0vOFWXzpEUe9zJHzq2nbA@mail.gmail.com>

After another peek, I find a few other fields in Class can benefit from @Stable
too:
classData, packageName, allPermDomain, reflectionFactory, classValueMap.
They are all accessed with benign race.

There are other fields I'm interested in promoting to @Stable, most
notably enumConstants and enumConstantsDirectory; they use mutable data
structures and need extra release/store (LoadStore+StoreStore) fences. In
addition, I am not sure if Class redefinition would tamper these fields.
Thus, I am also CC'ing serviceability-dev for a confirmation. Same question
applies to genericInfo field, which is not protected as part of
ReflectionData (that explicitly supports JVMTI redefinitions) somehow.

Curious, Chen

On Tue, Dec 19, 2023 at 7:38?AM - <liangchenblue at gmail.com> wrote:

> Thanks for the analysis. I know that in a race, VM is free to promote any
> non-null value to a constant. Thus using @Stable is totally safe;
> similarly, the reflectionFactory is @Stable and created with a benign race.
> I'll create an RFE then.
>
>
> On Tue, Dec 19, 2023, 3:40 AM Jaikiran Pai <jai.forums2013 at gmail.com>
> wrote:
>
>> Hello Chen,
>>
>> Looking at the implementation of java.lang.Class.getName(), which then
>> triggers the hotspot code to initialize this "name" field, I suspect there
>> will be a (harmless) race in the hotspot implementation where more than one
>> thread could end up writing the "name" field (with the same value of
>> course)
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/classfile/javaClasses.cpp#L1237.
>> I don't know how the JVM would then react if such a field is marked @Stable
>> (the javadoc of @Stable states that the behaviour is such cases is
>> undefined).
>>
>> -Jaikiran
>> On 16/12/23 8:37 pm, - wrote:
>>
>> Hello,
>> I just noticed the Class.name field is mutable but not @Stable, meaning
>> `Class.getName()` calls are not eligible for constant folding.
>>
>> The last update to this field is in 2019 in JDK-8216302 when the field
>> initialization was done directly by a write from hotspot code (for the
>> class name is interned anyways, though interning limits scalability of
>> hidden classes)
>>
>> Would it be a good idea to submit a patch to mark this field @Stable?
>> Given class names may be frequently used to quickly identify a class, to
>> create descriptors.
>>
>> Chen Liang
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20231224/74275d55/attachment.htm>

From zjx001202 at gmail.com  Mon Dec 25 03:29:47 2023
From: zjx001202 at gmail.com (Glavo)
Date: Mon, 25 Dec 2023 11:29:47 +0800
Subject: Optimize RandomGenerator::nextBytes
Message-ID: <CAJL5A3nqxMNGVyJgkSMgLiQzTC+GLfhXkm8t9Lxzv8agnxZcfQ@mail.gmail.com>

I created a PR[1] to optimize the implementation of `nextBytes`  in Random
and RandomGenerator by using Unsafe and ByteArrayLittleEndian.

JMH benchmarking says it's very useful, with performance improvements of up
to 180% in some cases.

Would anyone like to take a look at it?

Glavo

[1]: https://github.com/openjdk/jdk/pull/14638
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20231225/e724ed6b/attachment.htm>

From duke at openjdk.org  Mon Dec 25 05:55:52 2023
From: duke at openjdk.org (jmehrens)
Date: Mon, 25 Dec 2023 05:55:52 GMT
Subject: RFR: 6356745: (coll) Add PriorityQueue(Collection,
 Comparator) [v4]
In-Reply-To: <3BInvmLUo5T1-DimTKsJ5DDcRwYUyNe5n3UqRr9tTs4=.886b4dfe-65ed-4476-9314-ce27759c034a@github.com>
References: <zAcGyJ33ZP0osNg-HMJp4UCtOXYzdqi969ugDhJ7954=.c5f8e2de-cfe8-4224-a98e-70f49da9a7a3@github.com>
 <3BInvmLUo5T1-DimTKsJ5DDcRwYUyNe5n3UqRr9tTs4=.886b4dfe-65ed-4476-9314-ce27759c034a@github.com>
Message-ID: <Gqf_U53wONgz9-UOorE6z-AJ_Z8LE1aFUVPVG9C3EPA=.f8140203-32b2-44cd-bd53-4dc2381d2f48@github.com>

On Tue, 19 Dec 2023 21:17:02 GMT, Valeh Hajiyev <duke at openjdk.org> wrote:

>> This commit addresses the current limitation in the `PriorityQueue` implementation, which lacks a constructor to efficiently create a priority queue with a custom comparator and an existing collection. In order to create such a queue, we currently need to initialize a new queue with custom comparator, and after that populate the queue using `addAll()` method, which in the background calls `add()` method (which takes `O(logn)` time) for each element of the collection (`n` times).  This is resulting in an overall time complexity of `O(nlogn)`. 
>> 
>> 
>> PriorityQueue<String> pq = new PriorityQueue<>(customComparator);
>> pq.addAll(existingCollection);
>> 
>> 
>> The pull request introduces a new constructor to streamline this process and reduce the time complexity to `O(n)`.  If you create the queue above using the new constructor, the contents of the collection will be copied (which takes `O(n)` time) and then later  `heapify()` operation (Floyd's algorithm) will be called once (another `O(n)` time). Overall the operation will be reduced from `O(nlogn)` to `O(2n)` -> `O(n)` time.
>> 
>> 
>> PriorityQueue<String> pq = new PriorityQueue<>(existingCollection, customComparator);
>
> Valeh Hajiyev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated the javadoc

Would adding a fast path to addAll solve this issue?  I asked this back in 2006 in JDK-6356745.  The [TreeMap::putAll](https://github.com/openjdk/jdk/blob/2d609557ffe8e15ab81fb51dce90e40780598371/src/java.base/share/classes/java/util/TreeMap.java#L348) is already implemented to work this way so we could apply the same concept to PriorityQueue and BlockingPriorityQueue

For example sake:

 public boolean addAll(Collection<? extends E> c) {
        if (c == null)
            throw new NullPointerException();
        if (c == this)
            throw new IllegalArgumentException();
        
        if (size == 0) {
            return addAllEmpty(c); 
        }
        return super.addAll(c);
    }
    
    private boolean addAllEmpty(Collection<? extends E> c) {
        //assert size == 0 : size;
        Object[] old = this.queue;
        try {
            if (c instanceof SortedSet<?> ss 
                && Objects.equals(this.comparator, ss.comparator()) {
                initElementsFromCollection(ss);
            }
            else if (c instanceof PriorityQueue<?> pq
                && Objects.equals(this.comparator, pq.comparator())) {
                initFromPriorityQueue(pq);
            } else {
                initFromCollection(c);
            }
        } catch (Throwable t) {
            size = 0;
            this.queue = old;
            //super.addAll(c); //Punish the wicked or get rid of all or nothing behavior.
            throw t;
        }
        return size != 0;
    }


This would allow an empty PQ to heapfiy/siftDown.  There is a change in that the addAll is all or nothing in the empty case.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17045#issuecomment-1868759233

From duke at openjdk.org  Mon Dec 25 20:07:56 2023
From: duke at openjdk.org (duke)
Date: Mon, 25 Dec 2023 20:07:56 GMT
Subject: Withdrawn: 8233160: Add java.vendor.url.bug to list of recognized
 standard system properties
In-Reply-To: <eGXBuA25OQADEjNQXlWYOUCfXdPZZ84KGm7VgtIr3Ik=.15ffdb50-be18-4f15-a9d1-0cb46cc3ac80@github.com>
References: <eGXBuA25OQADEjNQXlWYOUCfXdPZZ84KGm7VgtIr3Ik=.15ffdb50-be18-4f15-a9d1-0cb46cc3ac80@github.com>
Message-ID: <hxKkerJspaJOhufKS8bGX0UCW1uy5ahh3KHnkBYoTb0=.b4210035-99e6-41ef-a026-e0b42b30980b@github.com>

On Thu, 31 Aug 2023 06:53:45 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8233160?
> 
> It has been noted in https://bugs.openjdk.org/browse/JDK-8232753 that:
> 
>> The java.vendor.url.bug property has been defined by every Sun/Oracle JDK going all the way back to JDK 5 (and possibly earlier; JDK 5 is the oldest release that I can still run on my development machine). Yet, it's never been specified.
> 
> The OpenJDK builds too by default set a value for this system property.
> 
> The commit in this PR updates the javadoc of `System.getProperties()` to include this system property in the list of specified properties. Additionally, the `test/jdk/java/lang/System/PropertyTest.java` test has been updated to verify that this property is indeed available in the Properties returned by `System.getProperites()`.
> 
> I'll create a CSR shortly for this change.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/15504

From duke at openjdk.org  Tue Dec 26 22:13:58 2023
From: duke at openjdk.org (duke)
Date: Tue, 26 Dec 2023 22:13:58 GMT
Subject: Withdrawn: 8315004: Runtime.halt() debug logging
In-Reply-To: <rK1UbMwvq7pLAgQRAe9O8c5-FUXflM2FcNpvR9vfye0=.acbc1359-8b45-43d4-b5c8-15c249f038da@github.com>
References: <rK1UbMwvq7pLAgQRAe9O8c5-FUXflM2FcNpvR9vfye0=.acbc1359-8b45-43d4-b5c8-15c249f038da@github.com>
Message-ID: <nz4ShrJAR1nzwE2kXACDdSyeR_aPDwEBeJZOAcrJaCE=.6aa5abcf-fa83-40c3-988c-f175c9a9259d@github.com>

On Fri, 25 Aug 2023 09:37:47 GMT, Masanori Yano <myano at openjdk.org> wrote:

> I want to add a log output similar to JDK-8301627 to Runtime.halt().
> To avoid double logging of Runtime.exit(), add a flag to indicate whether logging was done, and fix it so that logging is done only once.
> Could someone please review this fix?

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/15426

From duke at openjdk.org  Tue Dec 26 22:48:54 2023
From: duke at openjdk.org (duke)
Date: Tue, 26 Dec 2023 22:48:54 GMT
Subject: Withdrawn: 8305734: BitSet.get(int,
 int) always returns the empty BitSet when the Integer.MAX VALUE is set
In-Reply-To: <r6FXfPbcMJR2bDlx6Al2rWdZkPBAfARx_FHXCt_tKfc=.79b978b0-9486-4839-a035-34f5ad4fd749@github.com>
References: <r6FXfPbcMJR2bDlx6Al2rWdZkPBAfARx_FHXCt_tKfc=.79b978b0-9486-4839-a035-34f5ad4fd749@github.com>
Message-ID: <Lrra2CCB8e4abAC3BoqX8EoJ7N1cI_9tuLBwY6SpvC4=.212168ac-85b7-4bf3-9a14-895dd620e8b4@github.com>

On Fri, 7 Apr 2023 12:22:03 GMT, Andy-Tatman <duke at openjdk.org> wrote:

> See https://bugs.java.com/bugdatabase/view_bug?bug_id=8305734 and https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8311905

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/13388

From duke at openjdk.org  Thu Dec 28 00:04:11 2023
From: duke at openjdk.org (Valeh Hajiyev)
Date: Thu, 28 Dec 2023 00:04:11 GMT
Subject: RFR: 6356745: (coll) Add PriorityQueue(Collection,
 Comparator) [v5]
In-Reply-To: <zAcGyJ33ZP0osNg-HMJp4UCtOXYzdqi969ugDhJ7954=.c5f8e2de-cfe8-4224-a98e-70f49da9a7a3@github.com>
References: <zAcGyJ33ZP0osNg-HMJp4UCtOXYzdqi969ugDhJ7954=.c5f8e2de-cfe8-4224-a98e-70f49da9a7a3@github.com>
Message-ID: <wxW2IMzGUKDq6dfgoJcBCjeXfI23FlD2laMm5WQf-_4=.730c9b21-db13-44d3-8f03-cfd9dfde7edf@github.com>

> This commit addresses the current limitation in the `PriorityQueue` implementation, which lacks a constructor to efficiently create a priority queue with a custom comparator and an existing collection. In order to create such a queue, we currently need to initialize a new queue with custom comparator, and after that populate the queue using `addAll()` method, which in the background calls `add()` method (which takes `O(logn)` time) for each element of the collection (`n` times).  This is resulting in an overall time complexity of `O(nlogn)`. 
> 
> 
> PriorityQueue<String> pq = new PriorityQueue<>(customComparator);
> pq.addAll(existingCollection);
> 
> 
> The pull request introduces a new constructor to streamline this process and reduce the time complexity to `O(n)`.  If you create the queue above using the new constructor, the contents of the collection will be copied (which takes `O(n)` time) and then later  `heapify()` operation (Floyd's algorithm) will be called once (another `O(n)` time). Overall the operation will be reduced from `O(nlogn)` to `O(2n)` -> `O(n)` time.
> 
> 
> PriorityQueue<String> pq = new PriorityQueue<>(existingCollection, customComparator);

Valeh Hajiyev has updated the pull request incrementally with one additional commit since the last revision:

  updated javadoc, added tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17045/files
  - new: https://git.openjdk.org/jdk/pull/17045/files/6884929b..03ce7e04

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17045&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17045&range=03-04

  Stats: 35 lines in 2 files changed: 31 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17045.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17045/head:pull/17045

PR: https://git.openjdk.org/jdk/pull/17045

From duke at openjdk.org  Thu Dec 28 00:09:09 2023
From: duke at openjdk.org (Valeh Hajiyev)
Date: Thu, 28 Dec 2023 00:09:09 GMT
Subject: RFR: 6356745: (coll) Add PriorityQueue(Collection,
 Comparator) [v6]
In-Reply-To: <zAcGyJ33ZP0osNg-HMJp4UCtOXYzdqi969ugDhJ7954=.c5f8e2de-cfe8-4224-a98e-70f49da9a7a3@github.com>
References: <zAcGyJ33ZP0osNg-HMJp4UCtOXYzdqi969ugDhJ7954=.c5f8e2de-cfe8-4224-a98e-70f49da9a7a3@github.com>
Message-ID: <FR8BSAikgxqhGe-_lkFNUI2TOQ4V-W1iNfptNe84CoE=.f501a415-2f10-4ae9-8ded-ffc02a02dd35@github.com>

> This commit addresses the current limitation in the `PriorityQueue` implementation, which lacks a constructor to efficiently create a priority queue with a custom comparator and an existing collection. In order to create such a queue, we currently need to initialize a new queue with custom comparator, and after that populate the queue using `addAll()` method, which in the background calls `add()` method (which takes `O(logn)` time) for each element of the collection (`n` times).  This is resulting in an overall time complexity of `O(nlogn)`. 
> 
> 
> PriorityQueue<String> pq = new PriorityQueue<>(customComparator);
> pq.addAll(existingCollection);
> 
> 
> The pull request introduces a new constructor to streamline this process and reduce the time complexity to `O(n)`.  If you create the queue above using the new constructor, the contents of the collection will be copied (which takes `O(n)` time) and then later  `heapify()` operation (Floyd's algorithm) will be called once (another `O(n)` time). Overall the operation will be reduced from `O(nlogn)` to `O(2n)` -> `O(n)` time.
> 
> 
> PriorityQueue<String> pq = new PriorityQueue<>(existingCollection, customComparator);

Valeh Hajiyev has updated the pull request incrementally with one additional commit since the last revision:

  fix style

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17045/files
  - new: https://git.openjdk.org/jdk/pull/17045/files/03ce7e04..139abc45

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17045&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17045&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17045.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17045/head:pull/17045

PR: https://git.openjdk.org/jdk/pull/17045

From duke at openjdk.org  Thu Dec 28 00:13:51 2023
From: duke at openjdk.org (Valeh Hajiyev)
Date: Thu, 28 Dec 2023 00:13:51 GMT
Subject: RFR: 6356745: (coll) Add PriorityQueue(Collection,
 Comparator) [v4]
In-Reply-To: <VifOwyf2eL69Aj79HQY8aAtzrsrkWnFkJOTvF6Z1Ic4=.67b542ad-4cf2-403f-a93d-26c9eb23ee42@github.com>
References: <zAcGyJ33ZP0osNg-HMJp4UCtOXYzdqi969ugDhJ7954=.c5f8e2de-cfe8-4224-a98e-70f49da9a7a3@github.com>
 <3BInvmLUo5T1-DimTKsJ5DDcRwYUyNe5n3UqRr9tTs4=.886b4dfe-65ed-4476-9314-ce27759c034a@github.com>
 <VifOwyf2eL69Aj79HQY8aAtzrsrkWnFkJOTvF6Z1Ic4=.67b542ad-4cf2-403f-a93d-26c9eb23ee42@github.com>
Message-ID: <h_xVtuKiJ4lvuj_YxPF0cV1SUMGmhOY7tY_AUURpbd4=.030c8e0e-09ef-4162-92e1-2f5bdc719544@github.com>

On Wed, 20 Dec 2023 05:12:05 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Valeh Hajiyev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated the javadoc
>
> src/java.base/share/classes/java/util/PriorityQueue.java line 216:
> 
>> 214:      * specified collection. The {@code PriorityQueue} will order the
>> 215:      * priority queue's elements elements according to the specified
>> 216:      * comparator.
> 
> I know you updated this in response to Alan's comment, but the second sentence now says "elements elements". And repeating "priority queue" sounds somewhat redundant. Suggestion for the second sentence:
> 
>> The elements of the new {@code PriorityQueue} will be ordered according to
>> the specified comparator.

updated, thanks for the suggestion

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17045#discussion_r1437300604

From duke at openjdk.org  Thu Dec 28 00:13:49 2023
From: duke at openjdk.org (Valeh Hajiyev)
Date: Thu, 28 Dec 2023 00:13:49 GMT
Subject: RFR: 6356745: (coll) Add PriorityQueue(Collection,
 Comparator) [v2]
In-Reply-To: <BpvY-fOqoRafv8pAYWaWQXf2Vpd2cfqIrN-XIleVi68=.90b0d762-4945-45cf-ab41-7ed7b880c704@github.com>
References: <zAcGyJ33ZP0osNg-HMJp4UCtOXYzdqi969ugDhJ7954=.c5f8e2de-cfe8-4224-a98e-70f49da9a7a3@github.com>
 <coAODM-9CtXAmbfpMxBU6wEYu6DXFOJB6OHV_cVo0L4=.978b09e9-1231-4ff3-ac97-e6b40816bc36@github.com>
 <Hrv4ZAhQ0Rtc6jGWLOqKH_TjHPdJ7yrE8Jx1vSbbaBU=.12b0179d-6fed-4f28-b12c-a2b7564cf8cc@github.com>
 <0zbcP0oCH4BdtaVJso5onAW_5Hjzpf9T_auYdDDBYc8=.2d9c3211-aa8a-4925-8c08-12a395f625df@github.com>
 <BpvY-fOqoRafv8pAYWaWQXf2Vpd2cfqIrN-XIleVi68=.90b0d762-4945-45cf-ab41-7ed7b880c704@github.com>
Message-ID: <xX6h6L9U5oUeYnEnhpbgMLY697wmSUN9DvmRaQpE5ek=.1be52ae0-dfd9-47a6-8e64-cb92dbb1a4f5@github.com>

On Wed, 20 Dec 2023 05:05:09 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> @liach thanks for the help. I updated the PR title, also your proposed CSR content looks good to me. would you mind creating it with your proposed content?
>
> @valeh
> 
> Hello, thanks for contributing this change. I can sponsor it.
> 
> Changes to the JDK such as this one require tests to be included. You can see some PriorityQueue tests in test/jdk/java/util/PriorityQueue. However, it looks like these are tests for specific features and bugfixes. A comprehensive set of tests resides in test/jdk/java/util/concurrent/tck/PriorityQueueTest.java. It might be best to add a test case for the new constructor there.
> 
> In addition, changes such as this will require a release note. I've added the `release-note=yes` label to the bug report to indicate this. The release note process is documented in the Developer's Guide here:
> 
> https://openjdk.org/guide/#release-notes
> 
> @liach 
> 
> Thanks for starting the CSR draft. It looks straightforward enough so far; a couple quick comments. 1) It's not necessary to include the implementation in the CSR, just the specification (or specification changes or diffs) and the method signature. 2) You might want to wait until the spec wording settles down before creating the CSR, otherwise you'll have to keep them in sync continually.
> 
> --
> 
> In passing, I note this Stack Overflow answer in response to a question about the lack of a PriorityQueue(Collection, Comparator) constructor:
> 
> https://stackoverflow.com/questions/66170496/java-priority-queue-build-heap-process-time-complexity/66174529#66174529
> 
> In the discussion of this bug report, I think we believe that constructing a PQ with the new constructor should be faster than constructing one with a Comparator and then calling addAll(), but this SO answer seems to indicate that this new constructor isn't necessary. I'm kind of skeptical of this, though. It would be good to have some confirmation that the new constructor indeed provides a performance improvement. Note however that benchmarking can easily turn into a distraction and a time sink, so I don't think a benchmark is required for this change. However, if somebody wants to try something out, please do so. If suitable, a benchmark could be added somewhere in the test/micro hierarchy (possibly as part of a different PR).
> 
> Finally, please note that with the holiday season, I'm planning to take several days away from work, so I might not respond quickly, but I eventually will.

@stuart-marks thanks for the suggestions, I also added the tests as you suggested

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17045#issuecomment-1870705915

From duke at openjdk.org  Thu Dec 28 00:29:40 2023
From: duke at openjdk.org (Valeh Hajiyev)
Date: Thu, 28 Dec 2023 00:29:40 GMT
Subject: RFR: 6356745: (coll) Add PriorityQueue(Collection,
 Comparator) [v4]
In-Reply-To: <Gqf_U53wONgz9-UOorE6z-AJ_Z8LE1aFUVPVG9C3EPA=.f8140203-32b2-44cd-bd53-4dc2381d2f48@github.com>
References: <zAcGyJ33ZP0osNg-HMJp4UCtOXYzdqi969ugDhJ7954=.c5f8e2de-cfe8-4224-a98e-70f49da9a7a3@github.com>
 <3BInvmLUo5T1-DimTKsJ5DDcRwYUyNe5n3UqRr9tTs4=.886b4dfe-65ed-4476-9314-ce27759c034a@github.com>
 <Gqf_U53wONgz9-UOorE6z-AJ_Z8LE1aFUVPVG9C3EPA=.f8140203-32b2-44cd-bd53-4dc2381d2f48@github.com>
Message-ID: <wUkyNw64UM-SZmhx_nv0z23TD8jC9aH2Z5OaMuFbSJg=.3dd6abf3-cd6d-4d46-adc2-9c4a86ff8a53@github.com>

On Mon, 25 Dec 2023 05:52:51 GMT, jmehrens <duke at openjdk.org> wrote:

>> Valeh Hajiyev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated the javadoc
>
> Would adding a fast path to addAll solve this issue?  I asked this back in 2006 in JDK-6356745.  The [TreeMap::putAll](https://github.com/openjdk/jdk/blob/2d609557ffe8e15ab81fb51dce90e40780598371/src/java.base/share/classes/java/util/TreeMap.java#L348) is already implemented to work this way so we could apply the same concept to PriorityQueue and BlockingPriorityQueue
> 
> For example sake:
> 
>  public boolean addAll(Collection<? extends E> c) {
>         if (c == null)
>             throw new NullPointerException();
>         if (c == this)
>             throw new IllegalArgumentException();
>         
>         if (size == 0) {
>             return addAllEmpty(c); 
>         }
>         return super.addAll(c);
>     }
>     
>     private boolean addAllEmpty(Collection<? extends E> c) {
>         //assert size == 0 : size;
>         Object[] old = this.queue;
>         try {
>             if (c instanceof SortedSet<?> ss 
>                 && Objects.equals(this.comparator, ss.comparator()) {
>                 initElementsFromCollection(ss);
>             }
>             else if (c instanceof PriorityQueue<?> pq
>                 && Objects.equals(this.comparator, pq.comparator())) {
>                 initFromPriorityQueue(pq);
>             } else {
>                 initFromCollection(c);
>             }
>         } catch (Throwable t) {
>             size = 0;
>             this.queue = old;
>             //super.addAll(c); //Punish the wicked or get rid of all or nothing behavior.
>             throw t;
>         }
>         return size != 0;
>     }
> 
> 
> This would allow an empty PQ to heapfiy/siftDown.  There is a change in that the addAll is all or nothing in the empty case.

@jmehrens  it's true that leveraging the `addAll` method could solve this issue, but I'd like to emphasize the consistency in the API design. If we apply the similar way of thinking,  the `PriorityQueue(Collection)` constructor should not exist either, as it is redundant because of the `addAll()` method. Given that we already have constructors like `PriorityQueue(Collection)` and `PriorityQueue(Comparator)`, it seems appropriate to maintain a similar approach. I believe introducing `PriorityQueue(Collection, Comparator)` aligns with the selected design appraoch and offers users a clear and intuitive way to initialize the queue based on the specifications. wdyt?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17045#issuecomment-1870712555

From jkratochvil at openjdk.org  Thu Dec 28 13:02:04 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 28 Dec 2023 13:02:04 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected
Message-ID: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>

The testcase requires root permissions.

-------------

Commit messages:
 - 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected
 - 4c556a78: <no commit message found>

Changes: https://git.openjdk.org/jdk/pull/17198/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17198&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322420
  Stats: 276 lines in 11 files changed: 216 ins; 7 del; 53 mod
  Patch: https://git.openjdk.org/jdk/pull/17198.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17198/head:pull/17198

PR: https://git.openjdk.org/jdk/pull/17198

From vsitnikov at openjdk.org  Thu Dec 28 15:09:09 2023
From: vsitnikov at openjdk.org (Vladimir Sitnikov)
Date: Thu, 28 Dec 2023 15:09:09 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v17]
In-Reply-To: <jbv8tpQ8C-MfRtWeA0Kcr-pUmwHv26xX0LymXcVqcT4=.e6beb1f6-9c03-4515-99fb-d69a272391ea@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <0yHNMSapOJmfRyGfe_DeqnFIl6yheCjtBKMKKNfDVK0=.78284283-237e-4b14-bb7d-bddf11026a7e@github.com>
 <7iNfYPMzS9YgYNcvPErUBjT-nuaQxNeEccXtmUCnF0A=.b89af814-f95e-49ae-bb8a-5283f5d4491b@github.com>
 <noeDADduWdGZmIP5VqlTIYpZOYnxqkUZy8pXD2PWlSg=.3dc15610-983e-461f-972f-8a61a5cd1031@github.com>
 <wK-DgnIz6FUS8mnmyM2rSEnyaI1wToAZLzfD3MugVfw=.c080f943-ece7-4a23-b29b-54c6936c4f8d@github.com>
 <iUHMng1JW8bOrtiYyc5SkJdRWC6iCMTfXuG0spm1sZA=.27cdf176-d776-4ec4-9f3b-0396e6f03ff2@github.com>
 <jJX3usPijJElNxNS05gFZ6pq7A45fQLiVqZP7Jqk0IE=.e48a30f5-a553-4097-835c-bef115c26050@github.com>
 <LISgjwRKAiuCSuKEpAdSY3P6L0bsTZ5ausLJGHbgPCA=.1683ead6-80b0-4465-bc0f-cb9de7791d97@github.com>
 <jbv8tpQ8C-MfRtWeA0Kcr-pUmwHv26xX0LymXcVqcT4=.e6beb1f6-9c03-4515-99fb-d69a272391ea@github.com>
Message-ID: <6aj-IGk0emk8un3vjbs8x0FP6yaJFPokPBzrbZWgWCs=.4eb6a778-bd91-4bbb-96d2-6bb161cd8cd3@github.com>

On Sat, 23 Dec 2023 13:01:09 GMT, Markus KARG <duke at openjdk.org> wrote:

>Typically it was sufficient to document the JMH results before and after a PR just once (not dynamically in the form of a test).

The problem with "results before and after a PR just once" is those benchmarks will not automatically fail the build if somebody else breaks the optimization unintentionally. In other words, benchmarks do not serve as a safety net.

At the same time, if the test code were to ensure "less than 20 bytes allocated" in a common case of transferring data from `BufferedInputStream` to `ByteArrayOutputStream`, then it would be a nice safety net so the optimization will not be broken unintentionally.

>The latter should be rather easy to check: Invoke transferTo(out) two times in a row and compare the identity of the two byte arrays passed to out.write(). If they stay the same, then apparently no temporary copy was created. Two achieve this, the BIS must be wrapper around an extendable input stream (like FileInputStream) so between calls the stream could get extended (e. g. by writing into the file)

Markus, I am afraid you missed that anything that "extends FileOutputStream" (I assume you mean `FileOutputStream`, not `FileInputStream`) would **not** qualify as a trusted stream, and `transferTo` will make a copy. The current check is `clazz == FileOutputStream.class`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1435625914

From duke at openjdk.org  Thu Dec 28 15:09:10 2023
From: duke at openjdk.org (Markus KARG)
Date: Thu, 28 Dec 2023 15:09:10 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v18]
In-Reply-To: <YpKGqzlqyio-LJQbTNZt7FNX3SzO_m7y4DE4od5DK-Y=.be3e69fe-dbd0-472a-ab83-a33e97cf0852@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <YpKGqzlqyio-LJQbTNZt7FNX3SzO_m7y4DE4od5DK-Y=.be3e69fe-dbd0-472a-ab83-a33e97cf0852@github.com>
Message-ID: <7bPmKuWw3rXPzIg5F0TsMajkrZ2R6g7gYM7A9XNWGX8=.395a2759-f81a-4bde-bf85-d4b33b80086e@github.com>

On Thu, 28 Dec 2023 15:06:47 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`.
>> 
>> See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8320971: Fix test

test/jdk/java/io/BufferedInputStream/TransferToTrusted.java line 81:

> 79:                 bis.read();//need this to fill the BIS.buf in
> 80:                 bis.transferTo(out);
> 81:                 var internalBuffer = bis.getClass().getDeclaredField("buf");

IMHO you don't need to whitebox here, as the blackbox approach described by me earlier should be sufficient to assert the claim of this PR.

test/jdk/java/io/BufferedInputStream/TransferToTrusted.java line 83:

> 81:                 var internalBuffer = bis.getClass().getDeclaredField("buf");
> 82:                 internalBuffer.setAccessible(true);
> 83:                 if (!Arrays.equals(buf, Arrays.copyOf((byte[]) internalBuffer.get(bis), length))) {

This is not testing the absence of a copy.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1435597922
PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1435598381

From duke at openjdk.org  Thu Dec 28 15:09:09 2023
From: duke at openjdk.org (Markus KARG)
Date: Thu, 28 Dec 2023 15:09:09 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v17]
In-Reply-To: <LISgjwRKAiuCSuKEpAdSY3P6L0bsTZ5ausLJGHbgPCA=.1683ead6-80b0-4465-bc0f-cb9de7791d97@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <0yHNMSapOJmfRyGfe_DeqnFIl6yheCjtBKMKKNfDVK0=.78284283-237e-4b14-bb7d-bddf11026a7e@github.com>
 <7iNfYPMzS9YgYNcvPErUBjT-nuaQxNeEccXtmUCnF0A=.b89af814-f95e-49ae-bb8a-5283f5d4491b@github.com>
 <noeDADduWdGZmIP5VqlTIYpZOYnxqkUZy8pXD2PWlSg=.3dc15610-983e-461f-972f-8a61a5cd1031@github.com>
 <wK-DgnIz6FUS8mnmyM2rSEnyaI1wToAZLzfD3MugVfw=.c080f943-ece7-4a23-b29b-54c6936c4f8d@github.com>
 <iUHMng1JW8bOrtiYyc5SkJdRWC6iCMTfXuG0spm1sZA=.27cdf176-d776-4ec4-9f3b-0396e6f03ff2@github.com>
 <jJX3usPijJElNxNS05gFZ6pq7A45fQLiVqZP7Jqk0IE=.e48a30f5-a553-4097-835c-bef115c26050@github.com>
 <LISgjwRKAiuCSuKEpAdSY3P6L0bsTZ5ausLJGHbgPCA=.1683ead6-80b0-4465-bc0f-cb9de7791d97@github.com>
Message-ID: <jbv8tpQ8C-MfRtWeA0Kcr-pUmwHv26xX0LymXcVqcT4=.e6beb1f6-9c03-4515-99fb-d69a272391ea@github.com>

On Fri, 22 Dec 2023 16:25:29 GMT, Vladimir Sitnikov <vsitnikov at openjdk.org> wrote:

>> IMHO the trigger for this PR was sparing *time*, not necessarily sparing *bytes* (the default buffer size is just 8K); the latter certainly is a nice and beneficial side effect. But I may be wrong here, then the original contributor should chime in now and clarify.
>
>> IMHO the trigger for this PR was sparing time
> 
> That is fair. Do you know how one could create a reliable test for performance that would fail without the fix and succeed with the fix?
> 
> I think the allocation is a reasonable proxy for the duration in this case, and the allocation is more-or-less easy to measure and test if the JVM supports `getCurrentThreadAllocatedBytes`.

Why do you want to put *that* in a test case at all? So far I did not come across performance-based *tests* (only *benchmarks*), i. e. nobody ever requested that from me in any of my NIO optimizations. Typically it was sufficient to document the JMH results before and after a PR *just once* (not dynamically in the form of a test).

For *this* PR it is sufficient to proof what the PR's title says: Proof the *direct* call (i. e. the *absence of a copy*) and we're good to merge. I already explained how to proof *that*.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1435596696

From stsypanov at openjdk.org  Thu Dec 28 15:09:10 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 28 Dec 2023 15:09:10 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v18]
In-Reply-To: <7bPmKuWw3rXPzIg5F0TsMajkrZ2R6g7gYM7A9XNWGX8=.395a2759-f81a-4bde-bf85-d4b33b80086e@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <YpKGqzlqyio-LJQbTNZt7FNX3SzO_m7y4DE4od5DK-Y=.be3e69fe-dbd0-472a-ab83-a33e97cf0852@github.com>
 <7bPmKuWw3rXPzIg5F0TsMajkrZ2R6g7gYM7A9XNWGX8=.395a2759-f81a-4bde-bf85-d4b33b80086e@github.com>
Message-ID: <d1OVPWkEbhgFtmfuw7esf6MhDLFoVm6X4SF7TLCZ3YQ=.017c3e02-bdcb-4b94-a46e-a13d216bed56@github.com>

On Sat, 23 Dec 2023 13:08:06 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8320971: Fix test
>
> test/jdk/java/io/BufferedInputStream/TransferToTrusted.java line 83:
> 
>> 81:                 var internalBuffer = bis.getClass().getDeclaredField("buf");
>> 82:                 internalBuffer.setAccessible(true);
>> 83:                 if (!Arrays.equals(buf, Arrays.copyOf((byte[]) internalBuffer.get(bis), length))) {
> 
> This is not testing the absence of a copy.

Yeah, but how could I intercept the argument of OutputStream.write() and check it's identity?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1435682191

From duke at openjdk.org  Thu Dec 28 15:09:10 2023
From: duke at openjdk.org (Markus KARG)
Date: Thu, 28 Dec 2023 15:09:10 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v18]
In-Reply-To: <d1OVPWkEbhgFtmfuw7esf6MhDLFoVm6X4SF7TLCZ3YQ=.017c3e02-bdcb-4b94-a46e-a13d216bed56@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <YpKGqzlqyio-LJQbTNZt7FNX3SzO_m7y4DE4od5DK-Y=.be3e69fe-dbd0-472a-ab83-a33e97cf0852@github.com>
 <7bPmKuWw3rXPzIg5F0TsMajkrZ2R6g7gYM7A9XNWGX8=.395a2759-f81a-4bde-bf85-d4b33b80086e@github.com>
 <d1OVPWkEbhgFtmfuw7esf6MhDLFoVm6X4SF7TLCZ3YQ=.017c3e02-bdcb-4b94-a46e-a13d216bed56@github.com>
Message-ID: <4o1v16y72XemUX2k7t6qmxfmfmoV1ES2CvA1zxS8LR0=.a8ea0d78-f186-40f8-a9a7-3ab0ae593682@github.com>

On Sat, 23 Dec 2023 19:11:35 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> test/jdk/java/io/BufferedInputStream/TransferToTrusted.java line 83:
>> 
>>> 81:                 var internalBuffer = bis.getClass().getDeclaredField("buf");
>>> 82:                 internalBuffer.setAccessible(true);
>>> 83:                 if (!Arrays.equals(buf, Arrays.copyOf((byte[]) internalBuffer.get(bis), length))) {
>> 
>> This is not testing the absence of a copy.
>
> Yeah, but how could I intercept the argument of OutputStream.write() and check it's identity?

As I wrote earlier today to Vladimir (see above) I actually do not see a solution for this, frankly spoken, as the interceptor would not be trusted. That's why I asked Brian for his ok to keep the test as-is. We need to wait for his judgement, as he is the reviewer, not me (I only try to give initial advice). My comment was more a hint for me to wait for Brian's judgement, less a request to you to fix this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1435734672

From stsypanov at openjdk.org  Thu Dec 28 15:09:10 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 28 Dec 2023 15:09:10 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v18]
In-Reply-To: <4o1v16y72XemUX2k7t6qmxfmfmoV1ES2CvA1zxS8LR0=.a8ea0d78-f186-40f8-a9a7-3ab0ae593682@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <YpKGqzlqyio-LJQbTNZt7FNX3SzO_m7y4DE4od5DK-Y=.be3e69fe-dbd0-472a-ab83-a33e97cf0852@github.com>
 <7bPmKuWw3rXPzIg5F0TsMajkrZ2R6g7gYM7A9XNWGX8=.395a2759-f81a-4bde-bf85-d4b33b80086e@github.com>
 <d1OVPWkEbhgFtmfuw7esf6MhDLFoVm6X4SF7TLCZ3YQ=.017c3e02-bdcb-4b94-a46e-a13d216bed56@github.com>
 <4o1v16y72XemUX2k7t6qmxfmfmoV1ES2CvA1zxS8LR0=.a8ea0d78-f186-40f8-a9a7-3ab0ae593682@github.com>
Message-ID: <ZQ_Jtv1eCqnJYAr-lOxbMEx-W_UCNd6t-nLKDrpWrP4=.4850db2e-3212-478f-b9e1-629528a7fc4e@github.com>

On Sat, 23 Dec 2023 23:18:40 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Yeah, but how could I intercept the argument of OutputStream.write() and check it's identity?
>
> As I wrote earlier today to Vladimir (see above) I actually do not see a solution for this, frankly spoken, as the interceptor would not be trusted. That's why I asked Brian for his ok to keep the test as-is. We need to wait for his judgement, as he is the reviewer, not me (I only try to give initial advice). My comment was more a hint for me to wait for Brian's judgement, less a request to you to fix this.

@bplb are you ok with the current implementation and its test?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1437723313

From duke at openjdk.org  Thu Dec 28 15:09:09 2023
From: duke at openjdk.org (Markus KARG)
Date: Thu, 28 Dec 2023 15:09:09 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v17]
In-Reply-To: <6aj-IGk0emk8un3vjbs8x0FP6yaJFPokPBzrbZWgWCs=.4eb6a778-bd91-4bbb-96d2-6bb161cd8cd3@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <0yHNMSapOJmfRyGfe_DeqnFIl6yheCjtBKMKKNfDVK0=.78284283-237e-4b14-bb7d-bddf11026a7e@github.com>
 <7iNfYPMzS9YgYNcvPErUBjT-nuaQxNeEccXtmUCnF0A=.b89af814-f95e-49ae-bb8a-5283f5d4491b@github.com>
 <noeDADduWdGZmIP5VqlTIYpZOYnxqkUZy8pXD2PWlSg=.3dc15610-983e-461f-972f-8a61a5cd1031@github.com>
 <wK-DgnIz6FUS8mnmyM2rSEnyaI1wToAZLzfD3MugVfw=.c080f943-ece7-4a23-b29b-54c6936c4f8d@github.com>
 <iUHMng1JW8bOrtiYyc5SkJdRWC6iCMTfXuG0spm1sZA=.27cdf176-d776-4ec4-9f3b-0396e6f03ff2@github.com>
 <jJX3usPijJElNxNS05gFZ6pq7A45fQLiVqZP7Jqk0IE=.e48a30f5-a553-4097-835c-bef115c26050@github.com>
 <LISgjwRKAiuCSuKEpAdSY3P6L0bsTZ5ausLJGHbgPCA=.1683ead6-80b0-4465-bc0f-cb9de7791d97@github.com>
 <jbv8tpQ8C-MfRtWeA0Kcr-pUmwHv26xX0LymXcVqcT4=.e6beb1f6-9c03-4515-99fb-d69a272391ea@github.com>
 <6aj-IGk0emk8un3vjbs8x0FP6yaJFPokPBzrbZWgWCs=.4eb6a778-bd91-4bbb-96d2-6bb161cd8cd3@github.com>
Message-ID: <usR_GJl3i59K5qTtIAgtCRfbOgn-P2sh73tXoHClWZ4=.2933a520-20b0-4f89-b3a5-81b65814c8bf@github.com>

On Sat, 23 Dec 2023 15:02:28 GMT, Vladimir Sitnikov <vsitnikov at openjdk.org> wrote:

>> Why do you want to put *that* in a test case at all? So far I did not come across performance-based *tests* (only *benchmarks*), i. e. nobody ever requested that from me in any of my NIO optimizations. Typically it was sufficient to document the JMH results before and after a PR *just once* (not dynamically in the form of a test).
>> 
>> For *this* PR it is sufficient to proof what the PR's title says: Proof the *direct* call (i. e. the *absence of a copy*) and we're good to merge. I already explained how to proof *that*.
>
>>Typically it was sufficient to document the JMH results before and after a PR just once (not dynamically in the form of a test).
> 
> The problem with "results before and after a PR just once" is those benchmarks will not automatically fail the build if somebody else breaks the optimization unintentionally. In other words, benchmarks do not serve as a safety net.
> 
> At the same time, if the test code were to ensure "less than 20 bytes allocated" in a common case of transferring data from `BufferedInputStream` to `ByteArrayOutputStream`, then it would be a nice safety net so the optimization will not be broken unintentionally.
> 
>>The latter should be rather easy to check: Invoke transferTo(out) two times in a row and compare the identity of the two byte arrays passed to out.write(). If they stay the same, then apparently no temporary copy was created. Two achieve this, the BIS must be wrapper around an extendable input stream (like FileInputStream) so between calls the stream could get extended (e. g. by writing into the file)
> 
> Markus, I am afraid you missed that anything that "extends FileOutputStream" (I assume you mean `FileOutputStream`, not `FileInputStream`) would **not** qualify as a trusted stream, and `transferTo` will make a copy. The current check is `clazz == FileOutputStream.class`

I think we should not overcomplicate things. Nobody really asked for actually failing the test when either the number of bytes allocated or the time to allocate it execeeds an expected limit. The requirement for the test solely is that it proofs the claim outlined by the topic: Proof that BufferedInputStream.bug is used directly and fail if not. Nothing else.  Everthing beyond that is nice to have as we did not have such a test for the similar change at BAIS.

As long as it is proven that we use *the same* buffer always, it is implicitly proven that the original claim of the published benchmarks still holds true. There is no need to re-evaluate the actual benchmark again and again, it will not provide any additional benefit but would make the test much more complex, less reliable, and increase the risk of false-fail in automated test farms using alternating hardware.

I did not mean `FileOutputStream` but really `FileInputStream`: You have a file as an input, so you can extend the file between two calls to `transferTo(out)` to be actually able to execute `transferTo` two times in a row. Nevertheless you are right, the problem with my proposed solution is that the mock receiver needed in that scenario (the code that records the identity of the buffer) would not be in the set of trusted classes. Actually I do not see how we can solve this.

@bplb In https://github.com/openjdk/jdk/pull/16893 we actually did not check if the PR is actually effective, but solely if the buffer is effectively unchanged. The same could be done here. Is it OK for you if we skip checking the actual efficiency of the *actual target* of this PR itself (i. e. still not checking if it is *the same* buffer)?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1435679827

From vsitnikov at openjdk.org  Thu Dec 28 15:09:09 2023
From: vsitnikov at openjdk.org (Vladimir Sitnikov)
Date: Thu, 28 Dec 2023 15:09:09 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v17]
In-Reply-To: <jJX3usPijJElNxNS05gFZ6pq7A45fQLiVqZP7Jqk0IE=.e48a30f5-a553-4097-835c-bef115c26050@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <0yHNMSapOJmfRyGfe_DeqnFIl6yheCjtBKMKKNfDVK0=.78284283-237e-4b14-bb7d-bddf11026a7e@github.com>
 <7iNfYPMzS9YgYNcvPErUBjT-nuaQxNeEccXtmUCnF0A=.b89af814-f95e-49ae-bb8a-5283f5d4491b@github.com>
 <noeDADduWdGZmIP5VqlTIYpZOYnxqkUZy8pXD2PWlSg=.3dc15610-983e-461f-972f-8a61a5cd1031@github.com>
 <wK-DgnIz6FUS8mnmyM2rSEnyaI1wToAZLzfD3MugVfw=.c080f943-ece7-4a23-b29b-54c6936c4f8d@github.com>
 <iUHMng1JW8bOrtiYyc5SkJdRWC6iCMTfXuG0spm1sZA=.27cdf176-d776-4ec4-9f3b-0396e6f03ff2@github.com>
 <jJX3usPijJElNxNS05gFZ6pq7A45fQLiVqZP7Jqk0IE=.e48a30f5-a553-4097-835c-bef115c26050@github.com>
Message-ID: <LISgjwRKAiuCSuKEpAdSY3P6L0bsTZ5ausLJGHbgPCA=.1683ead6-80b0-4465-bc0f-cb9de7791d97@github.com>

On Fri, 22 Dec 2023 15:08:33 GMT, Markus KARG <duke at openjdk.org> wrote:

> IMHO the trigger for this PR was sparing time

That is fair. Do you know how one could create a reliable test for performance that would fail without the fix and succeed with the fix?

I think the allocation is a reasonable proxy for the duration in this case, and the allocation is more-or-less easy to measure and test if the JVM supports `getCurrentThreadAllocatedBytes`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1435200386

From stsypanov at openjdk.org  Thu Dec 28 15:09:09 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 28 Dec 2023 15:09:09 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v18]
In-Reply-To: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
Message-ID: <YpKGqzlqyio-LJQbTNZt7FNX3SzO_m7y4DE4od5DK-Y=.be3e69fe-dbd0-472a-ab83-a33e97cf0852@github.com>

> It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`.
> 
> See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  8320971: Fix test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16879/files
  - new: https://git.openjdk.org/jdk/pull/16879/files/ee035998..41a7f1a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16879&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16879&range=16-17

  Stats: 31 lines in 1 file changed: 8 ins; 14 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/16879.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16879/head:pull/16879

PR: https://git.openjdk.org/jdk/pull/16879

From jkratochvil at openjdk.org  Thu Dec 28 15:19:23 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 28 Dec 2023 15:19:23 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v2]
In-Reply-To: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
Message-ID: <TgUwQf3jeY47lvkiRQs-y0W8Tb3mVuWLAjmx6iaZINs=.93c8ee9f-12fe-4926-b6d0-4c4a7340fab8@github.com>

> The testcase requires root permissions.

Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:

  Fix gtest testcases compilation errors

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17198/files
  - new: https://git.openjdk.org/jdk/pull/17198/files/8ccd7387..395ef61f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17198&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17198&range=00-01

  Stats: 23 lines in 2 files changed: 3 ins; 0 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/17198.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17198/head:pull/17198

PR: https://git.openjdk.org/jdk/pull/17198

From duke at openjdk.org  Fri Dec 29 13:00:57 2023
From: duke at openjdk.org (Technici4n)
Date: Fri, 29 Dec 2023 13:00:57 GMT
Subject: Withdrawn: 8314986: Module readability resolution is slow with large
 numbers of automatic modules
In-Reply-To: <PnbU1D6UkPNBexrh-pNcWsEa51mkJ8gqCcEODeI6yM8=.3ab3144b-f448-46da-9d40-523c72afb8b9@github.com>
References: <PnbU1D6UkPNBexrh-pNcWsEa51mkJ8gqCcEODeI6yM8=.3ab3144b-f448-46da-9d40-523c72afb8b9@github.com>
Message-ID: <mGFqVZ4qx7MRKEpsc8VDDFMIGjOcxrx1vdJKwJt0_eE=.7cc48e53-1698-4364-945f-202ce02eb16c@github.com>

On Tue, 26 Sep 2023 14:19:55 GMT, Technici4n <duke at openjdk.org> wrote:

> Fixes the issue (hopefully) by resolving automatic modules and automatic module dependencies after propagation of non-automatic transitive dependencies. The module tests run.
> 
> I also added a few asserts to validate that the automatic modules don't read themselves (previously this was the case with > 1 automatic module). Should these asserts be added in more places or is this enough?
> 
> Alan also mentioned a conflict with the spec, I'm not sure which spec is being referred to. The documentation of `ResolvedModule#reads` states `A possibly-empty unmodifiable set`, implying that the set can be empty.
> 
> Finally, `Configuration#reads` states `// The sets stored in the graph are already immutable sets` but that does not seem to be true. Should something be done about this to limit allocation?
> 
> Please let me know!
> Cheers

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/15926

From clanger at openjdk.org  Fri Dec 29 13:50:09 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 29 Dec 2023 13:50:09 GMT
Subject: RFR: 8322772: Clean up code after JDK-8322417
Message-ID: <nOcZACdrwGSoqMwmGd8qmQwDTN-gM1CpjS_SJwdsurI=.987c6114-62bf-4026-aa7c-0d252b980666@github.com>

In the review of the PR for JDK-8322417 it was noted that a fully qualified class name "java.util.Arrays" is unnecessary but it was forgotten to clean it up prior to integration.

-------------

Commit messages:
 - JDK-8322417

Changes: https://git.openjdk.org/jdk/pull/17203/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17203&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322772
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17203.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17203/head:pull/17203

PR: https://git.openjdk.org/jdk/pull/17203

From mdoerr at openjdk.org  Fri Dec 29 13:57:37 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 29 Dec 2023 13:57:37 GMT
Subject: RFR: 8322772: Clean up code after JDK-8322417
In-Reply-To: <nOcZACdrwGSoqMwmGd8qmQwDTN-gM1CpjS_SJwdsurI=.987c6114-62bf-4026-aa7c-0d252b980666@github.com>
References: <nOcZACdrwGSoqMwmGd8qmQwDTN-gM1CpjS_SJwdsurI=.987c6114-62bf-4026-aa7c-0d252b980666@github.com>
Message-ID: <nrNmHCbRGk5eZc7VF9sa0OecojVmUSyubLG1WYvM7U4=.4c9e73dd-4fef-4600-a9cd-7e2d38f5d4fb@github.com>

On Fri, 29 Dec 2023 13:44:27 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> In the review of the PR for JDK-8322417 it was noted that a fully qualified class name "java.util.Arrays" is unnecessary but it was forgotten to clean it up prior to integration.

LGTM.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17203#pullrequestreview-1799009813

From goetz at openjdk.org  Fri Dec 29 13:57:37 2023
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Fri, 29 Dec 2023 13:57:37 GMT
Subject: RFR: 8322772: Clean up code after JDK-8322417
In-Reply-To: <nOcZACdrwGSoqMwmGd8qmQwDTN-gM1CpjS_SJwdsurI=.987c6114-62bf-4026-aa7c-0d252b980666@github.com>
References: <nOcZACdrwGSoqMwmGd8qmQwDTN-gM1CpjS_SJwdsurI=.987c6114-62bf-4026-aa7c-0d252b980666@github.com>
Message-ID: <NjEz7LagkO-7Z2V0cG1uZyg7NvLTlym06P7TBchYMJQ=.8c9cb5ed-043f-4776-a01c-672a28ece9e9@github.com>

On Fri, 29 Dec 2023 13:44:27 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> In the review of the PR for JDK-8322417 it was noted that a fully qualified class name "java.util.Arrays" is unnecessary but it was forgotten to clean it up prior to integration.

LGTM

-------------

Marked as reviewed by goetz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17203#pullrequestreview-1799010553

From mbaesken at openjdk.org  Fri Dec 29 13:57:37 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 29 Dec 2023 13:57:37 GMT
Subject: RFR: 8322772: Clean up code after JDK-8322417
In-Reply-To: <nOcZACdrwGSoqMwmGd8qmQwDTN-gM1CpjS_SJwdsurI=.987c6114-62bf-4026-aa7c-0d252b980666@github.com>
References: <nOcZACdrwGSoqMwmGd8qmQwDTN-gM1CpjS_SJwdsurI=.987c6114-62bf-4026-aa7c-0d252b980666@github.com>
Message-ID: <HfWuqlRx2jE5VwSrh8fspQ9O2QvbZgfD78Lje9j4JmE=.617ade85-ab32-4efc-b7c9-3793f80befa6@github.com>

On Fri, 29 Dec 2023 13:44:27 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> In the review of the PR for JDK-8322417 it was noted that a fully qualified class name "java.util.Arrays" is unnecessary but it was forgotten to clean it up prior to integration.

Marked as reviewed by mbaesken (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17203#pullrequestreview-1799010848

From vtewari at openjdk.org  Fri Dec 29 14:26:45 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Fri, 29 Dec 2023 14:26:45 GMT
Subject: RFR: 8322772: Clean up code after JDK-8322417
In-Reply-To: <nOcZACdrwGSoqMwmGd8qmQwDTN-gM1CpjS_SJwdsurI=.987c6114-62bf-4026-aa7c-0d252b980666@github.com>
References: <nOcZACdrwGSoqMwmGd8qmQwDTN-gM1CpjS_SJwdsurI=.987c6114-62bf-4026-aa7c-0d252b980666@github.com>
Message-ID: <5NDdgI9OwQJBPgNy_32lqQKWCOTQ_wkpq1aMkNfbrl0=.73650881-9747-42c5-8600-964937db91ac@github.com>

On Fri, 29 Dec 2023 13:44:27 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> In the review of the PR for JDK-8322417 it was noted that a fully qualified class name "java.util.Arrays" is unnecessary but it was forgotten to clean it up prior to integration.

Looks OK

-------------

Marked as reviewed by vtewari (Committer).

PR Review: https://git.openjdk.org/jdk/pull/17203#pullrequestreview-1799029015

From duke at openjdk.org  Fri Dec 29 20:13:56 2023
From: duke at openjdk.org (duke)
Date: Fri, 29 Dec 2023 20:13:56 GMT
Subject: Withdrawn: 8319386: Migrate Class::getEnclosingMethod/Constructor away
 from old generic utilities
In-Reply-To: <m_3JWl2xIxOyUfVZcw81KFstod7aixVqaQAZOunqvtM=.2b08b168-30e8-4e23-8fa2-79189fc1c888@github.com>
References: <m_3JWl2xIxOyUfVZcw81KFstod7aixVqaQAZOunqvtM=.2b08b168-30e8-4e23-8fa2-79189fc1c888@github.com>
Message-ID: <Js2poqQdSGnUvbXMWYYxGpn1J3q3dPujrtiY9zOjp5Y=.fc4e2c24-5e3a-4afb-a854-111598e64c98@github.com>

On Fri, 3 Nov 2023 14:03:02 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review a patch that migrates `Class::getEnclosingMethod` and `Class::getEnclosingConstructor`'s descriptor parsing from old generic utilities to more simple utilities from java.lang.invoke implementation. This will help migrate away from the old generic repositories in the future.
> 
> The `getClassLoader()` call plus https://github.com/openjdk/jdk/blob/1a21c1a783d64ca0930c358c06a43975f96ffac6/src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java#L93
> should be functionally equivalent to the previous `getDeclsLoader()`
> https://github.com/openjdk/jdk/blob/1a21c1a783d64ca0930c358c06a43975f96ffac6/src/java.base/share/classes/sun/reflect/generics/factory/CoreReflectionFactory.java#L60-L68
> plus
> https://github.com/openjdk/jdk/blob/1a21c1a783d64ca0930c358c06a43975f96ffac6/src/java.base/share/classes/sun/reflect/generics/factory/CoreReflectionFactory.java#L113-L114

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/16496

From clanger at openjdk.org  Fri Dec 29 21:52:54 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 29 Dec 2023 21:52:54 GMT
Subject: RFR: 8322772: Clean up code after JDK-8322417
In-Reply-To: <nOcZACdrwGSoqMwmGd8qmQwDTN-gM1CpjS_SJwdsurI=.987c6114-62bf-4026-aa7c-0d252b980666@github.com>
References: <nOcZACdrwGSoqMwmGd8qmQwDTN-gM1CpjS_SJwdsurI=.987c6114-62bf-4026-aa7c-0d252b980666@github.com>
Message-ID: <rppVyul7HQf6Ga4ye2Pc2tSrBQoLHWgtJMrTrFQw6q0=.bc38fa65-bf04-40e0-b38d-43376a2f117d@github.com>

On Fri, 29 Dec 2023 13:44:27 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> In the review of the PR for JDK-8322417 it was noted that a fully qualified class name "java.util.Arrays" is unnecessary but it was forgotten to clean it up prior to integration.

Integrating under trivial rule.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17203#issuecomment-1872353704

From clanger at openjdk.org  Fri Dec 29 21:52:55 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 29 Dec 2023 21:52:55 GMT
Subject: Integrated: 8322772: Clean up code after JDK-8322417
In-Reply-To: <nOcZACdrwGSoqMwmGd8qmQwDTN-gM1CpjS_SJwdsurI=.987c6114-62bf-4026-aa7c-0d252b980666@github.com>
References: <nOcZACdrwGSoqMwmGd8qmQwDTN-gM1CpjS_SJwdsurI=.987c6114-62bf-4026-aa7c-0d252b980666@github.com>
Message-ID: <CtE1dGzMa_shfbPv1e5f3K8XzrcEps2SIfihxSVj3LQ=.325c2058-75df-461b-945a-afb9a4ce9b6e@github.com>

On Fri, 29 Dec 2023 13:44:27 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> In the review of the PR for JDK-8322417 it was noted that a fully qualified class name "java.util.Arrays" is unnecessary but it was forgotten to clean it up prior to integration.

This pull request has now been integrated.

Changeset: 32d80e2c
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/32d80e2caf6063b58128bd5f3dc87b276f3bd0cb
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8322772: Clean up code after JDK-8322417

Reviewed-by: mdoerr, goetz, mbaesken, vtewari

-------------

PR: https://git.openjdk.org/jdk/pull/17203

From duke at openjdk.org  Fri Dec 29 22:54:48 2023
From: duke at openjdk.org (jmehrens)
Date: Fri, 29 Dec 2023 22:54:48 GMT
Subject: RFR: 6356745: (coll) Add PriorityQueue(Collection,
 Comparator) [v4]
In-Reply-To: <Gqf_U53wONgz9-UOorE6z-AJ_Z8LE1aFUVPVG9C3EPA=.f8140203-32b2-44cd-bd53-4dc2381d2f48@github.com>
References: <zAcGyJ33ZP0osNg-HMJp4UCtOXYzdqi969ugDhJ7954=.c5f8e2de-cfe8-4224-a98e-70f49da9a7a3@github.com>
 <3BInvmLUo5T1-DimTKsJ5DDcRwYUyNe5n3UqRr9tTs4=.886b4dfe-65ed-4476-9314-ce27759c034a@github.com>
 <Gqf_U53wONgz9-UOorE6z-AJ_Z8LE1aFUVPVG9C3EPA=.f8140203-32b2-44cd-bd53-4dc2381d2f48@github.com>
Message-ID: <Vz9gBrurVOMokNGrBsS9xq3BMSVAJN0liwltnQ-3wWE=.6b01f5d1-2306-45e2-bbdb-539ed47ce205@github.com>

On Mon, 25 Dec 2023 05:52:51 GMT, jmehrens <duke at openjdk.org> wrote:

>> Valeh Hajiyev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated the javadoc
>
> Would adding a fast path to addAll solve this issue?  I asked this back in 2006 in JDK-6356745.  The [TreeMap::putAll](https://github.com/openjdk/jdk/blob/2d609557ffe8e15ab81fb51dce90e40780598371/src/java.base/share/classes/java/util/TreeMap.java#L348) is already implemented to work this way so we could apply the same concept to PriorityQueue and BlockingPriorityQueue
> 
> For example sake:
> 
>  public boolean addAll(Collection<? extends E> c) {
>         if (c == null)
>             throw new NullPointerException();
>         if (c == this)
>             throw new IllegalArgumentException();
>         
>         if (size == 0) {
>             return addAllEmpty(c); 
>         }
>         return super.addAll(c);
>     }
>     
>     private boolean addAllEmpty(Collection<? extends E> c) {
>         //assert size == 0 : size;
>         Object[] old = this.queue;
>         try {
>             if (c instanceof SortedSet<?> ss 
>                 && Objects.equals(this.comparator, ss.comparator()) {
>                 initElementsFromCollection(ss);
>             }
>             else if (c instanceof PriorityQueue<?> pq
>                 && Objects.equals(this.comparator, pq.comparator())) {
>                 initFromPriorityQueue(pq);
>             } else {
>                 initFromCollection(c);
>             }
>         } catch (Throwable t) {
>             size = 0;
>             this.queue = old;
>             //super.addAll(c); //Punish the wicked or get rid of all or nothing behavior.
>             throw t;
>         }
>         return size != 0;
>     }
> 
> 
> This would allow an empty PQ to heapfiy/siftDown.  There is a change in that the addAll is all or nothing in the empty case.

> @jmehrens If we apply the similar way of thinking, the `PriorityQueue(Collection)` constructor should not exist either, as it is redundant because of the `addAll()` method. 

The copy constructor is document in in the [Collection interface](https://github.com/openjdk/jdk/blob/2a59243cbaf3e7d5d1bfc9f247d28bc648687ea5/src/java.base/share/classes/java/util/Collection.java#L52):

> ...should provide two "standard" constructors: a void (no arguments) constructor, which creates an empty collection, and a constructor with a single argument of type Collection, which creates a new collection with the same elements as its argument.

While redundant it is super convenient and common to write a "return safe copy of this collection" or "pass a safe copy of this collection" on one line.  The Queue and BlockingQueue interfaces do not seem to document these two constructors like the other interfaces.  It would be nice if Queue and BlockingQueue were updated to document constructors in a new ticket.

>Given that we already have constructors like `PriorityQueue(Collection)` and `PriorityQueue(Comparator)`, it seems appropriate to maintain a similar approach. I believe introducing `PriorityQueue(Collection, Comparator)` aligns with the selected design appraoch and offers users a clear and intuitive way to initialize the queue based on the specifications. wdyt?

The other constructors are borrowed from [SortedSet](https://github.com/openjdk/jdk/blob/2a59243cbaf3e7d5d1bfc9f247d28bc648687ea5/src/java.base/share/classes/java/util/SortedSet.java#L60)

> ... provide four "standard" constructors: 
>1) A void (no arguments) constructor, which creates an empty sorted set sorted according to the natural ordering of its elements.  
>2) A constructor with a single argument of type Comparator, which creates an empty sorted set sorted according to the specified comparator.  
>3) A constructor with a single argument of type Collection, which creates a new sorted set with the same elements as its argument, sorted according to the natural ordering of the elements.
>4) A constructor with a single argument of type SortedSet,

Even though PQ can't and doesn't implement sorted set it appears that PriorityQueue(Comparator), PriorityQueue(PriorityQueue) and PriorityQueue::comparator() are borrowed from that interface under points 2 and 4.

Going back to the JIRA issue the sections for justification, expect, and actual are about performance.  The submitter states that a new constructor was only solution known at the time and it is to serve the need of performance and not API design.  The only complaint about using addAll approach is that it is slow not that it is inconvenient.  We know that we can fix performance addAll.

Both this ticket and the duplicate ticket are really focused on performance but actively sell the reader on change the API.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17045#issuecomment-1872379255

From alanb at openjdk.org  Sat Dec 30 12:07:59 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 30 Dec 2023 12:07:59 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v18]
In-Reply-To: <YpKGqzlqyio-LJQbTNZt7FNX3SzO_m7y4DE4od5DK-Y=.be3e69fe-dbd0-472a-ab83-a33e97cf0852@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <YpKGqzlqyio-LJQbTNZt7FNX3SzO_m7y4DE4od5DK-Y=.be3e69fe-dbd0-472a-ab83-a33e97cf0852@github.com>
Message-ID: <v3WUGn4PjP39uXa8EISUSHWSZkNoHO_F3LK6uw4vlsc=.3eeadb92-8ac4-467c-8e8c-fc61fd7aee8a@github.com>

On Thu, 28 Dec 2023 15:09:09 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`.
>> 
>> See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8320971: Fix test

src/java.base/share/classes/java/io/BufferedInputStream.java line 672:

> 670:      * <li>does not modify the contents of the {@code byte[]}</li>
> 671:      * <li>{@code OutputStream.write(byte[], int, int)} write does not read the contents outside of the offset/length bounds</li>
> 672:      * </ul>

The implementation change looks fine, just a typo at L671 where it says "write write", I think you can shorten this to say that the write method doesn't read the contents outside of the offset/length bounds.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1438575672

From stsypanov at openjdk.org  Sat Dec 30 16:47:11 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Sat, 30 Dec 2023 16:47:11 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v19]
In-Reply-To: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
Message-ID: <xWaXE8akS8aryy6daASVJR6vFh_eSbKPaUfDcH7tsbk=.ebfbf96d-1343-4dec-9fc3-1b7a25e380be@github.com>

> It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`.
> 
> See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  8320971: Fix JavaDoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16879/files
  - new: https://git.openjdk.org/jdk/pull/16879/files/41a7f1a7..e769dfb2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16879&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16879&range=17-18

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16879.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16879/head:pull/16879

PR: https://git.openjdk.org/jdk/pull/16879

From stsypanov at openjdk.org  Sat Dec 30 16:47:11 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Sat, 30 Dec 2023 16:47:11 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v18]
In-Reply-To: <v3WUGn4PjP39uXa8EISUSHWSZkNoHO_F3LK6uw4vlsc=.3eeadb92-8ac4-467c-8e8c-fc61fd7aee8a@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <YpKGqzlqyio-LJQbTNZt7FNX3SzO_m7y4DE4od5DK-Y=.be3e69fe-dbd0-472a-ab83-a33e97cf0852@github.com>
 <v3WUGn4PjP39uXa8EISUSHWSZkNoHO_F3LK6uw4vlsc=.3eeadb92-8ac4-467c-8e8c-fc61fd7aee8a@github.com>
Message-ID: <UPUmVCREw9UAcy58hs6O5-cQDM0luoOKm_7Gxmwio3E=.ed2575a4-77ec-4dc3-b8fb-6c38cfaaffb6@github.com>

On Sat, 30 Dec 2023 12:05:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8320971: Fix test
>
> src/java.base/share/classes/java/io/BufferedInputStream.java line 672:
> 
>> 670:      * <li>does not modify the contents of the {@code byte[]}</li>
>> 671:      * <li>{@code OutputStream.write(byte[], int, int)} write does not read the contents outside of the offset/length bounds</li>
>> 672:      * </ul>
> 
> The implementation change looks fine, just a typo at L671 where it says "write write", I think you can shorten this to say that the write method doesn't read the contents outside of the offset/length bounds.

Done. Can we somehow modify the test to make it white-box one? Maybe it's possible to measure memory allocation before and after method invocation in the way that we could use the difference as a proof of non-allocating invocation for trusted OutputStreams?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1438651570

From duke at openjdk.org  Sat Dec 30 17:39:55 2023
From: duke at openjdk.org (Markus KARG)
Date: Sat, 30 Dec 2023 17:39:55 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v18]
In-Reply-To: <UPUmVCREw9UAcy58hs6O5-cQDM0luoOKm_7Gxmwio3E=.ed2575a4-77ec-4dc3-b8fb-6c38cfaaffb6@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <YpKGqzlqyio-LJQbTNZt7FNX3SzO_m7y4DE4od5DK-Y=.be3e69fe-dbd0-472a-ab83-a33e97cf0852@github.com>
 <v3WUGn4PjP39uXa8EISUSHWSZkNoHO_F3LK6uw4vlsc=.3eeadb92-8ac4-467c-8e8c-fc61fd7aee8a@github.com>
 <UPUmVCREw9UAcy58hs6O5-cQDM0luoOKm_7Gxmwio3E=.ed2575a4-77ec-4dc3-b8fb-6c38cfaaffb6@github.com>
Message-ID: <6QllHlYs_PFtstjUzZANE3i0CUZIALJx8bbbRduqhrQ=.45b5a537-2232-48fb-8184-1c2d2f84c962@github.com>

On Sat, 30 Dec 2023 16:44:14 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/BufferedInputStream.java line 672:
>> 
>>> 670:      * <li>does not modify the contents of the {@code byte[]}</li>
>>> 671:      * <li>{@code OutputStream.write(byte[], int, int)} write does not read the contents outside of the offset/length bounds</li>
>>> 672:      * </ul>
>> 
>> The implementation change looks fine, just a typo at L671 where it says "write write", I think you can shorten this to say that the write method doesn't read the contents outside of the offset/length bounds.
>
> Done. Can we somehow modify the test to make it white-box one? Maybe it's possible to measure memory allocation before and after method invocation in the way that we could use the difference as a proof of non-allocating invocation for trusted OutputStreams?

I assume you mean "to make it a blackbox"? Actually I do not see how we could do that *reliably*, as I already wrote recently.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1438665222

From vsitnikov at openjdk.org  Sat Dec 30 17:45:56 2023
From: vsitnikov at openjdk.org (Vladimir Sitnikov)
Date: Sat, 30 Dec 2023 17:45:56 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v18]
In-Reply-To: <6QllHlYs_PFtstjUzZANE3i0CUZIALJx8bbbRduqhrQ=.45b5a537-2232-48fb-8184-1c2d2f84c962@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <YpKGqzlqyio-LJQbTNZt7FNX3SzO_m7y4DE4od5DK-Y=.be3e69fe-dbd0-472a-ab83-a33e97cf0852@github.com>
 <v3WUGn4PjP39uXa8EISUSHWSZkNoHO_F3LK6uw4vlsc=.3eeadb92-8ac4-467c-8e8c-fc61fd7aee8a@github.com>
 <UPUmVCREw9UAcy58hs6O5-cQDM0luoOKm_7Gxmwio3E=.ed2575a4-77ec-4dc3-b8fb-6c38cfaaffb6@github.com>
 <6QllHlYs_PFtstjUzZANE3i0CUZIALJx8bbbRduqhrQ=.45b5a537-2232-48fb-8184-1c2d2f84c962@github.com>
Message-ID: <hBqRL6_6WUWtvy6Mi4fUEJNszQjshkGKI3UdNJp7rJQ=.97eb4a97-d6b6-428c-83f5-ed0ff152f06f@github.com>

On Sat, 30 Dec 2023 17:37:25 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Done. Can we somehow modify the test to make it white-box one? Maybe it's possible to measure memory allocation before and after method invocation in the way that we could use the difference as a proof of non-allocating invocation for trusted OutputStreams?
>
> I assume you mean "to make it a blackbox"? Actually I do not see how we could do that *reliably*, as I already wrote recently.

`com.sun.management.ThreadMXBean#getCurrentThreadAllocatedBytes` is reliable, isn't it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1438666817

From duke at openjdk.org  Sat Dec 30 17:55:46 2023
From: duke at openjdk.org (Markus KARG)
Date: Sat, 30 Dec 2023 17:55:46 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v18]
In-Reply-To: <hBqRL6_6WUWtvy6Mi4fUEJNszQjshkGKI3UdNJp7rJQ=.97eb4a97-d6b6-428c-83f5-ed0ff152f06f@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <YpKGqzlqyio-LJQbTNZt7FNX3SzO_m7y4DE4od5DK-Y=.be3e69fe-dbd0-472a-ab83-a33e97cf0852@github.com>
 <v3WUGn4PjP39uXa8EISUSHWSZkNoHO_F3LK6uw4vlsc=.3eeadb92-8ac4-467c-8e8c-fc61fd7aee8a@github.com>
 <UPUmVCREw9UAcy58hs6O5-cQDM0luoOKm_7Gxmwio3E=.ed2575a4-77ec-4dc3-b8fb-6c38cfaaffb6@github.com>
 <6QllHlYs_PFtstjUzZANE3i0CUZIALJx8bbbRduqhrQ=.45b5a537-2232-48fb-8184-1c2d2f84c962@github.com>
 <hBqRL6_6WUWtvy6Mi4fUEJNszQjshkGKI3UdNJp7rJQ=.97eb4a97-d6b6-428c-83f5-ed0ff152f06f@github.com>
Message-ID: <CbLSDWFUtINwEYMEMgWQwssPmdG6Tn-78MCVdFKU6Ak=.4e53be65-eea6-4928-8463-6639c521df50@github.com>

On Sat, 30 Dec 2023 17:43:25 GMT, Vladimir Sitnikov <vsitnikov at openjdk.org> wrote:

>> I assume you mean "to make it a blackbox"? Actually I do not see how we could do that *reliably*, as I already wrote recently.
>
> `com.sun.management.ThreadMXBean#getCurrentThreadAllocatedBytes` is reliable, isn't it?

According to its JavaDocs it only returns *an approximation*, whatever that means. And it is measuring memory, while I already explained that the aim of this PR IMHO is not to spare memory, but to spare *time*. I wonder why we do not simply merge this PR as-is to get the actual benefits integrated ASAP instead of holding the train by heating up this discussion again?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1438669194

From stsypanov at openjdk.org  Sat Dec 30 18:55:53 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Sat, 30 Dec 2023 18:55:53 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v18]
In-Reply-To: <CbLSDWFUtINwEYMEMgWQwssPmdG6Tn-78MCVdFKU6Ak=.4e53be65-eea6-4928-8463-6639c521df50@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <YpKGqzlqyio-LJQbTNZt7FNX3SzO_m7y4DE4od5DK-Y=.be3e69fe-dbd0-472a-ab83-a33e97cf0852@github.com>
 <v3WUGn4PjP39uXa8EISUSHWSZkNoHO_F3LK6uw4vlsc=.3eeadb92-8ac4-467c-8e8c-fc61fd7aee8a@github.com>
 <UPUmVCREw9UAcy58hs6O5-cQDM0luoOKm_7Gxmwio3E=.ed2575a4-77ec-4dc3-b8fb-6c38cfaaffb6@github.com>
 <6QllHlYs_PFtstjUzZANE3i0CUZIALJx8bbbRduqhrQ=.45b5a537-2232-48fb-8184-1c2d2f84c962@github.com>
 <hBqRL6_6WUWtvy6Mi4fUEJNszQjshkGKI3UdNJp7rJQ=.97eb4a97-d6b6-428c-83f5-ed0ff152f06f@github.com>
 <CbLSDWFUtINwEYMEMgWQwssPmdG6Tn-78MCVdFKU6Ak=.4e53be65-eea6-4928-8463-6639c521df50@github.com>
Message-ID: <wJ-92UJvOxXvCyzi0QVhMP2w9H8Jd_UM7zddYCGCnbc=.c3ad5f2a-e68a-47d0-8b6e-aec37fe436a8@github.com>

On Sat, 30 Dec 2023 17:52:41 GMT, Markus KARG <duke at openjdk.org> wrote:

>> `com.sun.management.ThreadMXBean#getCurrentThreadAllocatedBytes` is reliable, isn't it?
>
> According to its JavaDocs it only returns *an approximation*, whatever that means. And it is measuring memory, while I already explained that the aim of this PR IMHO is not to spare memory, but to spare *time*. I wonder why we do not simply merge this PR as-is to get the actual benefits integrated ASAP instead of holding the train by heating up this discussion again?

@mkarg apologies, of course I meant black box test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1438684031

From duke at openjdk.org  Sat Dec 30 19:02:46 2023
From: duke at openjdk.org (Markus KARG)
Date: Sat, 30 Dec 2023 19:02:46 GMT
Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of
 implTransferTo() is trusted [v15]
In-Reply-To: <YID5BtIoNcMdaMFfv1duC75kuOp9VI1AHDQCJiRCihU=.e6578ed3-a4f6-4312-b6da-5e9e1da254c0@github.com>
References: <wiMKk7g2U7p4dhh05Z9iLp3JuGJAyz_U_q1PTN9iJwg=.76dd0db4-e5aa-4413-92ba-4eb941221c8f@github.com>
 <8SYx9TqaT4rL2o4BZ_Fnu_ZxD3vVMdYJS51dtGMK22I=.4b226895-ec4a-49bc-ab1a-c46a2e290405@github.com>
 <YID5BtIoNcMdaMFfv1duC75kuOp9VI1AHDQCJiRCihU=.e6578ed3-a4f6-4312-b6da-5e9e1da254c0@github.com>
Message-ID: <AWJvfYZ3CExl8Ej6Img8mlECaXzgp7MztnMY0Xugx68=.cd36f2a8-01d7-40ee-98ce-0e0edd07a101@github.com>

On Sun, 17 Dec 2023 09:06:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8320971: Revert irrelevant changes
>
> For the method description, I think you can expand it to:
> 
> - does not retain a reference to the byte[]
> - does not leak a reference to the byte[] to non-trusted classes
> - does not modify the contents of the byte[]
> - its 3-arg write does not read the contents outside of the offset/length bounds
> 
> In passing, this class uses "out" for the target OutputStream in the other methods, you can keep that consistent. Also I assume the `@see` are left over from a previous iteration.

@AlanBateman Kindly requesting your review. :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16879#issuecomment-1872584495

From liach at openjdk.org  Sat Dec 30 20:54:40 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 30 Dec 2023 20:54:40 GMT
Subject: RFR: 6356745: (coll) Add PriorityQueue(Collection,
 Comparator) [v6]
In-Reply-To: <FR8BSAikgxqhGe-_lkFNUI2TOQ4V-W1iNfptNe84CoE=.f501a415-2f10-4ae9-8ded-ffc02a02dd35@github.com>
References: <zAcGyJ33ZP0osNg-HMJp4UCtOXYzdqi969ugDhJ7954=.c5f8e2de-cfe8-4224-a98e-70f49da9a7a3@github.com>
 <FR8BSAikgxqhGe-_lkFNUI2TOQ4V-W1iNfptNe84CoE=.f501a415-2f10-4ae9-8ded-ffc02a02dd35@github.com>
Message-ID: <1C_qA3n7rwerTQGNq6H7OEY1FXAW5s4ZDRjDouRN-7U=.1ed642a0-b40e-4edf-86d1-de43d6026e5c@github.com>

On Thu, 28 Dec 2023 00:09:09 GMT, Valeh Hajiyev <duke at openjdk.org> wrote:

>> This commit addresses the current limitation in the `PriorityQueue` implementation, which lacks a constructor to efficiently create a priority queue with a custom comparator and an existing collection. In order to create such a queue, we currently need to initialize a new queue with custom comparator, and after that populate the queue using `addAll()` method, which in the background calls `add()` method (which takes `O(logn)` time) for each element of the collection (`n` times).  This is resulting in an overall time complexity of `O(nlogn)`. 
>> 
>> 
>> PriorityQueue<String> pq = new PriorityQueue<>(customComparator);
>> pq.addAll(existingCollection);
>> 
>> 
>> The pull request introduces a new constructor to streamline this process and reduce the time complexity to `O(n)`.  If you create the queue above using the new constructor, the contents of the collection will be copied (which takes `O(n)` time) and then later  `heapify()` operation (Floyd's algorithm) will be called once (another `O(n)` time). Overall the operation will be reduced from `O(nlogn)` to `O(2n)` -> `O(n)` time.
>> 
>> 
>> PriorityQueue<String> pq = new PriorityQueue<>(existingCollection, customComparator);
>
> Valeh Hajiyev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix style

I think this ticket should focus on adding the new constructor as part of the API.

This constructor can always enjoy the empty-case heapify optimization simply because it is initially empty. It's no fault to mention that.

For previous usages, there is a way to modify `addAll` to heapify if this PQ is empty, but this upgrade can be done in a separate issue, and it does not solve the problem of the lack of constructor parity.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17045#issuecomment-1872604385

From eirbjo at openjdk.org  Sun Dec 31 19:34:55 2023
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sun, 31 Dec 2023 19:34:55 GMT
Subject: RFR: 7009069: ZipFile.getEntry(String name) does NOT respect the
 "language encoding flag"
Message-ID: <NeXmfG2NmlvP-1LmGmAsEGYPDf3n-pJMCKerNlsOkgg=.ae71795a-3501-424b-9eab-a1143b539fa1@github.com>

Please review this test-only PR which adds test coverage for `ZipFile.getEntry` under certain charset conditions. 

When `ZipFile.getEntry` is called for an entry which has the `Language encoding flag` general purpose bit flag set,  then `ZipCoder.UTF8` is used unconditionally, even when a different charset was supplied to the `ZipFile` constructor.

It turns out we do not have any testing for this particular case, as can be verified by commenting out the following line of code in `ZipFile.Source.getEntryPos`:


//ZipCoder zc = zipCoderForPos(pos);
``` 

and then running `make test TEST="test/jdk/java/util/zip"`

The current test verifies that the correct ZipCoder is used by `ZipFile.entries()`, but does not exercise `ZipFile.getEntry` the same way.

Seeing that [JDK-7009069](https://bugs.openjdk.org/browse/JDK-7009069) was (accidentally?) fixed by [JDK-8243469](https://bugs.openjdk.org/browse/JDK-8243469), I think it is worthwhile to add explicit testing for this case to avoid regressions.

While visiting `ZipCoding.java`, I took the opportunity to convert it to JUnit 5. The conversion and modernization of the code is done in the first commit 1384850ed51ec845af06dd6d13616f20f8bbaa6a in this PR, while the second commit 1776b258b0fe8383709ae0c095f2631a4e6237f6 actually adds the code required to verify the `Language encoding flag` condition for `ZipFile.getEntry`.

Testing: Verified that the test indeed fails when `ZipFile.Source.getEntryPos` is updated to use the ZipFile's ZipCoder as suggested above.

-------------

Commit messages:
 - This PR will probably not be approved until 2024
 - Add a test that ZipFile.getEntry returns the expected ZipEntry
 - Convert ZipCoding test to JUnit 5, add comments and modernize the code.

Changes: https://git.openjdk.org/jdk/pull/17207/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17207&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-7009069
  Stats: 137 lines in 1 file changed: 87 ins; 8 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/17207.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17207/head:pull/17207

PR: https://git.openjdk.org/jdk/pull/17207

From lancea at openjdk.org  Sun Dec 31 21:17:49 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Sun, 31 Dec 2023 21:17:49 GMT
Subject: RFR: 7009069: ZipFile.getEntry(String name) does NOT respect the
 "language encoding flag"
In-Reply-To: <NeXmfG2NmlvP-1LmGmAsEGYPDf3n-pJMCKerNlsOkgg=.ae71795a-3501-424b-9eab-a1143b539fa1@github.com>
References: <NeXmfG2NmlvP-1LmGmAsEGYPDf3n-pJMCKerNlsOkgg=.ae71795a-3501-424b-9eab-a1143b539fa1@github.com>
Message-ID: <gCTon43lE0LyifiLjSSqwSS8l-fMQ9GsjRQjFHkhOdI=.80e2e075-4279-49a4-921f-067ee64de55e@github.com>

On Sun, 31 Dec 2023 18:07:33 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this test-only PR which adds test coverage for `ZipFile.getEntry` under certain charset conditions. 
> 
> When `ZipFile.getEntry` is called for an entry which has the `Language encoding flag` general purpose bit flag set,  then `ZipCoder.UTF8` is used unconditionally, even when a different charset was supplied to the `ZipFile` constructor.
> 
> It turns out we do not have any testing for this particular case, as can be verified by commenting out the following line of code in `ZipFile.Source.getEntryPos`:
> 
> 
> //ZipCoder zc = zipCoderForPos(pos);
> ``` 
> 
> and then running `make test TEST="test/jdk/java/util/zip"`
> 
> The current test verifies that the correct ZipCoder is used by `ZipFile.entries()`, but does not exercise `ZipFile.getEntry` the same way.
> 
> Seeing that [JDK-7009069](https://bugs.openjdk.org/browse/JDK-7009069) was (accidentally?) fixed by [JDK-8243469](https://bugs.openjdk.org/browse/JDK-8243469), I think it is worthwhile to add explicit testing for this case to avoid regressions.
> 
> While visiting `ZipCoding.java`, I took the opportunity to convert it to JUnit 5. The conversion and modernization of the code is done in the first commit 1384850ed51ec845af06dd6d13616f20f8bbaa6a in this PR, while the second commit 1776b258b0fe8383709ae0c095f2631a4e6237f6 actually adds the code required to verify the `Language encoding flag` condition for `ZipFile.getEntry`.
> 
> Testing: Verified that the test indeed fails when `ZipFile.Source.getEntryPos` is updated to use the ZipFile's ZipCoder as suggested above.

Thanks for taking this on.

With the conversion, I probably would would at separating out the test runs for ZipFile and ZipInputStream and introduce a DataProvider.

This will just make it a bit clearer to identify an error that might be specific to ZipFile and/or ZipInputStream..

-------------

PR Review: https://git.openjdk.org/jdk/pull/17207#pullrequestreview-1799692059

From duke at openjdk.org  Sun Dec 31 22:00:46 2023
From: duke at openjdk.org (Axel Hultin)
Date: Sun, 31 Dec 2023 22:00:46 GMT
Subject: RFR: 7009069: ZipFile.getEntry(String name) does NOT respect the
 "language encoding flag"
In-Reply-To: <NeXmfG2NmlvP-1LmGmAsEGYPDf3n-pJMCKerNlsOkgg=.ae71795a-3501-424b-9eab-a1143b539fa1@github.com>
References: <NeXmfG2NmlvP-1LmGmAsEGYPDf3n-pJMCKerNlsOkgg=.ae71795a-3501-424b-9eab-a1143b539fa1@github.com>
Message-ID: <R9MH-5FmmltJOC_r2Dh1gICJZo5IyuJ94Vo8uvbASIM=.06556376-5106-4bdb-bf07-8218d59d112b@github.com>

On Sun, 31 Dec 2023 18:07:33 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this test-only PR which adds test coverage for `ZipFile.getEntry` under certain charset conditions. 
> 
> When `ZipFile.getEntry` is called for an entry which has the `Language encoding flag` general purpose bit flag set,  then `ZipCoder.UTF8` is used unconditionally, even when a different charset was supplied to the `ZipFile` constructor.
> 
> It turns out we do not have any testing for this particular case, as can be verified by commenting out the following line of code in `ZipFile.Source.getEntryPos`:
> 
> 
> //ZipCoder zc = zipCoderForPos(pos);
> ``` 
> 
> and then running `make test TEST="test/jdk/java/util/zip"`
> 
> The current test verifies that the correct ZipCoder is used by `ZipFile.entries()`, but does not exercise `ZipFile.getEntry` the same way.
> 
> Seeing that [JDK-7009069](https://bugs.openjdk.org/browse/JDK-7009069) was (accidentally?) fixed by [JDK-8243469](https://bugs.openjdk.org/browse/JDK-8243469), I think it is worthwhile to add explicit testing for this case to avoid regressions.
> 
> While visiting `ZipCoding.java`, I took the opportunity to convert it to JUnit 5. The conversion and modernization of the code is done in the first commit 1384850ed51ec845af06dd6d13616f20f8bbaa6a in this PR, while the second commit 1776b258b0fe8383709ae0c095f2631a4e6237f6 actually adds the code required to verify the `Language encoding flag` condition for `ZipFile.getEntry`.
> 
> Testing: Verified that the test indeed fails when `ZipFile.Source.getEntryPos` is updated to use the ZipFile's ZipCoder as suggested above.

test/jdk/java/util/zip/ZipCoding.java line 168:

> 166: 
> 167:     /**
> 168:      * Verify that a ZIP file with a written using ZipOutputStream with an entry

Missing something in the comment here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17207#discussion_r1438933329

From eirbjo at openjdk.org  Sun Dec 31 23:25:51 2023
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sun, 31 Dec 2023 23:25:51 GMT
Subject: RFR: 7009069: ZipFile.getEntry(String name) does NOT respect the
 "language encoding flag" [v2]
In-Reply-To: <NeXmfG2NmlvP-1LmGmAsEGYPDf3n-pJMCKerNlsOkgg=.ae71795a-3501-424b-9eab-a1143b539fa1@github.com>
References: <NeXmfG2NmlvP-1LmGmAsEGYPDf3n-pJMCKerNlsOkgg=.ae71795a-3501-424b-9eab-a1143b539fa1@github.com>
Message-ID: <4caeCYPWKG4cFAcP9w9rHe1v6n9iU3nt_vvP6s4JmlQ=.996311a7-5df0-4e28-b9d6-ecde61a73559@github.com>

> Please review this test-only PR which adds test coverage for `ZipFile.getEntry` under certain charset conditions. 
> 
> When `ZipFile.getEntry` is called for an entry which has the `Language encoding flag` general purpose bit flag set,  then `ZipCoder.UTF8` is used unconditionally, even when a different charset was supplied to the `ZipFile` constructor.
> 
> It turns out we do not have any testing for this particular case, as can be verified by commenting out the following line of code in `ZipFile.Source.getEntryPos`:
> 
> 
> //ZipCoder zc = zipCoderForPos(pos);
> ``` 
> 
> and then running `make test TEST="test/jdk/java/util/zip"`
> 
> The current test verifies that the correct ZipCoder is used by `ZipFile.entries()`, but does not exercise `ZipFile.getEntry` the same way.
> 
> Seeing that [JDK-7009069](https://bugs.openjdk.org/browse/JDK-7009069) was (accidentally?) fixed by [JDK-8243469](https://bugs.openjdk.org/browse/JDK-8243469), I think it is worthwhile to add explicit testing for this case to avoid regressions.
> 
> While visiting `ZipCoding.java`, I took the opportunity to convert it to JUnit 5. The conversion and modernization of the code is done in the first commit 1384850ed51ec845af06dd6d13616f20f8bbaa6a in this PR, while the second commit 1776b258b0fe8383709ae0c095f2631a4e6237f6 actually adds the code required to verify the `Language encoding flag` condition for `ZipFile.getEntry`.
> 
> Testing: Verified that the test indeed fails when `ZipFile.Source.getEntryPos` is updated to use the ZipFile's ZipCoder as suggested above.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Introduce separate tests for ZipInputStream and ZipFile, use parameterized tests with providers for write charset, read charset, name and comment arguments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17207/files
  - new: https://git.openjdk.org/jdk/pull/17207/files/466c749f..3555ec53

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17207&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17207&range=00-01

  Stats: 172 lines in 1 file changed: 49 ins; 66 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/17207.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17207/head:pull/17207

PR: https://git.openjdk.org/jdk/pull/17207

From eirbjo at openjdk.org  Sun Dec 31 23:28:47 2023
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sun, 31 Dec 2023 23:28:47 GMT
Subject: RFR: 7009069: ZipFile.getEntry(String name) does NOT respect the
 "language encoding flag" [v2]
In-Reply-To: <gCTon43lE0LyifiLjSSqwSS8l-fMQ9GsjRQjFHkhOdI=.80e2e075-4279-49a4-921f-067ee64de55e@github.com>
References: <NeXmfG2NmlvP-1LmGmAsEGYPDf3n-pJMCKerNlsOkgg=.ae71795a-3501-424b-9eab-a1143b539fa1@github.com>
 <gCTon43lE0LyifiLjSSqwSS8l-fMQ9GsjRQjFHkhOdI=.80e2e075-4279-49a4-921f-067ee64de55e@github.com>
Message-ID: <8Q9_8asyHNj6S_xHoT2IWrTPtUAc9wxRHXeQ4CdwS-k=.0922681d-aa98-4590-87b9-844c0ca18e14@github.com>

On Sun, 31 Dec 2023 21:14:54 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> With the conversion, I probably would would at separating out the test runs for ZipFile and ZipInputStream and introduce a DataProvider.

Thanks, I separated into two top-level parameterized tests as suggested. Indeed this was much cleaner!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17207#issuecomment-1873054363